ALMA Scripting: A VLT S/W Developer's Comments

[jschwarz <jschwarz@eso.org>]

Erik Allaert, who wrote the sequencer for the VLT control system, has
offered the following comments on the ALMA scripting language
discussion. I hope to be able to illustrate some of these points on
Thursday, when I talk about the VLT experience in integrating data flow
and control systems.

Joe Schwarz

Erik Allaert wrote:
> 
> Hi Gianni,
> 
> Pls find included some comments on the e-mail of Barry Clark on execution
> of ALMA observations.
> 
> It is interesting to see an approach based on a language definition. It
> is certainly diagonally opposite to our approach in the Data Flow. That by
> itself does of course not make it a bad approach (as I said, it is refreshing
> to see someone attempt it differently), but I do have some remarks:
> - this language definition imposes what the system can/cannot do, instead
>   of starting from *requirements* of the system which are then translated
>   into an implementation.
> - I dislike the idea of having to design the "alma-language" of observations.
>   Designing a language is a very complicated thing, and it is very easy to
>   do it wrong. On top of that, it requires a whole framework of support
>   utilities (compilers, pre-processors, checkers, ....). I would strongly
>   recommend to use existing languages and tools, even if on paper one
>   could think of a "better", more suitable language.
> 
> The concept as explained in the e-mail contains otherwise many elements similar
> to the VLT Data Flow. There is nothing in there which cannot be projected into
> our tools, i.e. an observation contains a setup and executes a certain script
> with specific parameters. Means observation blocks with templates and parameters.
> 
> The rather "worrying" thing is that there seems to be a lot of liberty in
> defining and executing (interrupting) observations. If I've learned anything,
> it is that the set of "templates" needs to be well-known and well-defined
> for the sake of the quality control and pipeline, and that observation blocks
> which are not complete are useless. Our side (VCS) could accept a lot more
> flexibility, but this is then just the view of the data acquisition. The needs
> of the rest of the Data Flow are different, and lead to additional requirements.
> So I'd strongly suggest to have first a closer look to the *entire* life-cycle
> of the observations/data, before talking about observations.
> 
> Erik