Architecture Discussion Topics

[TMH2k]

1. How do we handle telemetry (specifically communication between actors...do they go through a central "arbitrator" or do actors communicate directly "horizontally"? An example of the latter is lvmscp putting together a FITS header, which will need information from the telescopes.
   1. Using "horizontal" communication between actors could cause circular dependencies, which should be avoided,
   2. A central passive actor (at the same archtectural level as lvmops) in the sense that the other actors (lvmagp, lvmscp, lvmecs etc.) push values to it, and if needed, request values from it. See here for more.
2. With an 8-character limit on FITS tags, we will struggle to make intelligible names. For example, referring to the exposure time of the east-side AG camera on the SkyW telescope requires many letters (AG_SkyW_E_ExpTime is 17 letters long). More info here.
3. Exception handling. We need some interface to the science script that checks that everything is under control. If a telescope stops working, what happens? This should be the function of lvmops in this figure.
4. Should we separate out simple wrappers from more complicated actors ?
   1. We want to avoid repeated effort. An example is astrometry. Where should the astrometry be done...in lvmops or lvmagp ? Or in a separate python module (in lvmtipo) ? You can see a list of all modules here.
   2. We should avoid actors simply relaying commands to sub-actors. An example appears here.
   3. If functionality is moved from the actors to lvmops, then lvmops has to be restructered - see here.

[albireox]

A few comments for tomorrow's discussion.

1. By architecture, the actor system doesn't "allow" horizontal communication between actor (of course, one can implement one, but it's not the default and established model). Instead all communication goes through the central passing system (in LVM's case, RabbitMQ). If an actor, say the TCC, is outputting values (let's say, the RA and Dec position of the telescope), any other actor that is subscribed to the TCC maintains a model of any keyword output by the TCC. So it that actor needs use that information, for example, to create a header, the actor just needs to subscribe to the actors needed, and then create the header with that information. The only thing the actor may need to do is to issue commands against the other actors (e.g., tcc status) to refresh/output certain keywords.

In general I think that creating additional structure, like actors or databases that hold that information, is overcomplicating the architecture, but there may be cases where it's of use.

2. My opinion is that using FITS keywords with more than 8 characters always causes problems down the line. Although there are solutions for that, and technically they are supported by the FITS standard, many pieces of software don't support it and they always get truncated. Eight chars is usually good enough along with a good comment in the header.

3. i) Overall I agree with that. Maintaining an actor is significantly more effort than maintaining a library, so things that are going to be reused and that are algorithmic in nature don't need to be actors. But I'd also caution against collection packages that serve many purposes and have code for many things.

[wasndas]

1. 1. Sure from a technical point of view we do have a star shaped communication with rabbitmq in the center, but from a system level abstracted view we do/should have a hierachical system.
   2. We do have 6 subsystems - four tcs, one scs and ecs subsystems and each has 4-5 sub-subsystems. If every sub-system with a camera starts polling with the status command on the 21 sub-subsystems for the status we do have 4 * 21 = 84 calls of status() - even if status() is called only between subsystems and the subsystems call their sub-subsystems. If we do have a central actor we do have 4 calls from subsystems with a camera and some status updates from the (sub-)subsystems from time to time.
   3. Another advantage of this concept, you do have a status of the whole system for free - eg for status display, logging, snapshots...
   4. My favorite one for collecting instrument data is #4
   5. Is it a bug or feature that all conmand replies are send to all clients/actors connected to the exchange ?
2. Thought so that hierachical keywords are not welcome. How about mapping the hierachy (see 1.ii) to 3+5 , the first three letters for the (sub-)subsystem and the other five for the keyword. If there is no hierachy in the fits keys, then someone has to define system wide fits keys or we do use hash-keys from the actor name and value name.
3. Sure I do agree.
   1. In my opinon everything that doesnt have a state or hardware shouldnt be an actor.
   2. But too many packages is also bad, so far we do have quite a lot.