[evla-sw-discuss] correlator output team raison d'etre

[Michael Rupen]

Hi Martin,

   glad to see this is finally moving :)  A few comments, mostly trying to
limit the initial scope...

On Tue, 24 Jul 2007, Martin Pokorny wrote:

> - Where do the files written by the CBE go? Do the files get written to
> a staging area, or directly to the archive?
> - If CBE files are written to a staging area, how do other components
> (DCAF and TelCal) access the data, and how do the files get written to
> the archive? In short, how does the staging area work?
> - Where, that is, on what machines located in which places, do the
> staging area, archive, DCAF and TelCal reside? What is the physical
> architecture and deployment plan?
> - How does DCAF get the data it needs to create SDMs? How do the SDMs go
> from DCAF to the archive?

While this is obviously important, it's not clear to me it's part of the 
_correlator_ output.  We can ask what DCAF needs from the correlator
in order to create the SDM, which is a nice focused question...

> - How does TelCal use the correlator data?

Again, while we should talk about what data TelCal needs from the correlator 
and how it gets those data, I don't think we want to define all the use cases 
for TelCal.

> - How does the RTDD fit in with the architecture? Should it, or does it
> need to?
> - Where do station board data products go? Which products?

Some sub-questions:
* Which SB products go into the SDM?
* Which SB products go into the BDF?
* Which SB products go into the monitor database?
* Do we care about any of this? or does the correlator just multi-cast
   everything, and lets others worry about what they want?

> - Where can EVLA reuse ALMA software?

Far too broad a question.  I hope you're asking this only with regard
to correlator output...

> Although many of these issues are outlined by the high-level system
> architecture and, doubtless, other documents, the correlator output team
> should elaborate on the design to provide more detailed information,
> sufficient to begin detailed design work on the required components and
> interfaces.

And we should also try to gather all those random thoughts into one place, 
and figure out how it all fits together.

> After some time for the discussion of the scope of issues that the team
> will work on, the team will be "recruited", and begin meeting in early
> August (if all goes well).

Note that I'm out, 2-16aug07.


Some further questions:
* What information do we need to effectively diagnose correlator problems,
   and where should that information go (and reside)?

* What flags should the correlator produce?

* What do we do with the orphan outputs (radar mode, phased array data, ...)?

That's it for now --

             Michael