[evla-sw-discuss] ASDM

[Doug Tody]

The original concept of data capture was that it is the primary interface
between the telescope domain and the science domain.  In the telescope
domain you have the telescope data model, and in the science domain you
have the SDM.  The DCA translates between the two, and produces a complete
verified SDM data product at the end of an observation.

The point is to minimize coupling between the telescope and science domains.
That way for example, one generalized SDM can work (with telescope specific
extensions) for multiple telescopes, and the telescope control and science
software can evolve mostly independently on the two sides of this interface.
If instead you start using the SDM within the control system you get strong
coupling through the entire system.  A strong interface minimizes coupling
and increases flexibility, for example a custom observing program could
have a very different SDM merely by changing the DCA translation module
and probably the executor control script.

Project data needs to be known throughout the E2E components but not
necessarily at the level of the executor (if not, don't couple the two
unnecessarily).  The obsprep component will need the PDM, everything
including and downstream of the DCA.    - Doug



On Fri, 7 Apr 2006, Bryan Butler wrote:

> the question is whether we want to do it this way, or have the PDM be what's 
> passed around before observing, and quantities filled into that.  then DCAF 
> takes the PDM information and stuffs it into the SDM.
>
> 	-bryan
>
>
> On 4/7/06 16:26, Barry Clark wrote:
>> It occurs to me that propagating an incomplete (A)SDM through the software 
>> system ObservingTool -> Executor -> DCAF -> Archive,
>> having each piece fill in the things it knows about, would be a good
>> way to organize things.  This will ensure that there is a path from
>> appropriate places into the Archive for everything.  Starting down this
>> path now will give us a leg up on the eventual system, and will provide
>> a useful bit of non-throwaway code in the implementation of the interim 
>> system we are now coding for the VLA correlator.
>> 
>> The effort which I understand to now be underway to provide an XML schema
>> for the ASDM will make it easy to deal with such a thing.  The incomplete
>> (A)SDM would be passed from program to program as an XML document,
>> and unmarshalled into a java object (or C struct if we need that), via JAXB 
>> for java (and similar things are available for C).  The additional
>> things that element knows about would be inserted into the object, and
>> the object marshalled into an XML document for shipment on to the next
>> element.
>> 
>> If we go with the ASDM schema, we might like a little feedback into the 
>> process of constructing it.  Primary need would be to make many (most?) 
>> elements optional, so the incomplete object can be passed around without 
>> having to have upstream elements insert dummies for things they shouldn't 
>> have to understand.
>> _______________________________________________
>> evla-sw-discuss mailing list
>> evla-sw-discuss at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>