[alma-sw-ssr] Analysis comments

["Brian Glendenning" <bglenden@nrao.edu>]

Sorry these comments are somewhat light, and very nearly late!

Cheers,
Brian

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

p.8 s2.1 I'm a bit confused about the primacy of the sequence diagrams. I
would have thought that since sequence diagram is to use case as object is
to class, that the objective would be to come up with "clean" (factored,
actor inheritance, etc) use cases, perhaps illustrating them with some
sequence diagrams.

p.15 s2.1.3 It's not clear (to me) that this discussion is consistent with
the SB Groups which are discussed in the state machine section (e.g., p.30).
It seems like the concept is fundamental in the later discussion and omitted
here.

p.17 s2.1.4 The numbering is odd (6,7,8,9,5,6,7,8). I assume in the 1st
point 7 by configuration you mean the physical antenna distribution rather
than sub-arraying? Or does it include sub-arraying? An explicit statement
might be helpful.

p.19 s2.1.5. I'm similarly confused by subarraying here. When is this
sub-array made? How/where is it decided whether to do calibrations in a
sub-array or with the full-array? Is it a decision outside the scope of the
dispatch/ranking process, or within it?

p.19 s2.1.5 Do you automatically do, e.g., a pointing & delay calibrations
even if you've done one recently? (The single field observation could be a
few-second snapshot, and these calibrations could dominate the observing
time if many single fields were being observed). It's not clear to me which
of these are in the preamble (and hence in principle sharable) and which
aren't.

p.20 s2.1.5 Besides RMS time-out should be supported?

p.21 s2.1.5.1 pt 1 Should we not have synchronous delivery of calibration
values with some timeout? Presumably observing should not proceed until we
have the various required calibrations.

p.21 s2.1.5.1 pt 2 I sometimes wonder if the pre-amble/post-amble structure
isn't more complicated than we need. Would we really lose much observing
efficiency if each SB had a list of the calibrations it needed. Each
calibration would have various required parameters associated with it,
including maximum "age" of that calibration. When an SB is started the
missing calibrations are observed and stuck into a "common" for potential
later reuse. Part of the TBD SB ranking criteria is to pick SB's that
minimize new calibration observations.

p.21 s2.1.5.1 pt 3 The Doppler tracking question is a good one for the SSR.
I imagine that we might want both continuously variable (or every
integration) and constant for a given scan (or perhaps observation). I am
told that the right thing to do is a matter of some debate.

p.23 s2.1.6 pt 6 By error do you mean the formal error from the fitting
process? Is this OK or will systematics dominate?

p.25 s2.1.7 pt 1 I would have thought this would be done well before the raw
data becomes available, i.e. the setup happens then data flows automatically
into the archive.

p.25 s2.1.7 pt 2 Where are the temporary copies? I would have thought the
first time the data bits hit magnetic media is in the archive system (which
might have a front-end buffer to be sure).

p.25 s2.1.7 pt 3 Don't forget the minimum integration time can be 1ms! I
think rather than a "push" model to the UI's the UI's should "pull", or
subscribe to, information of interest.

p.25 s2.1.7 pt 4 Similar push vs. pull comments. More importantly, some
operations can happen incrementally on a (in principle) per-integration
basis (e.g., gridding) whereas others require the complete dataset to start
(e.g. deconvolution). Presumably the quick-look wants to run fairly often
(perhaps per SB or faster), whereas the image pipeline might only operate
when the program completes. And of course break-points etc will often have
pipeline consequences (since the observer will want to see something before
deciding how to proceed). In general the processing aspects appear to have
received considerably less attention than the ones related to observing.

p.26 s2.1.7 pt 13 I think this is the first time we've said that the user is
notified. Probably he should have been notified at some earlier points (at
least when his first and last SB are observed).

p.27 s2.2 I think it would be better to integrate the sequence diagrams and
the state diagrams together, e.g., rather than having them in separate
sections put the sequence and state diagrams related to proposal preparation
together.

p.32 s2.2.4 pt 8 There's lots of missing pipeline structure I think (e.g.,
the quick-look pipeline probably does something after every SB).

p.33 s3 Document organization comment. Personally I would rather see the
classes and packages first to get the overview, and then the details later,
rather than vice versa as you do now. (For example, the sequence diagrams
and state diagrams related to proposal prep would then be an elaboration of
a package or set of classes.) Here you talk about packages, whereas lower
level entities (e.g. observing template package) are also packages. So here
I'd call these things "top-level" packages or some such to (possibly!)
prevent confusion.

p.33 s3 I find it hard to get "read" the figure. Maybe a package diagram
like the "layer" diagram in the ACS architecture doc would be easier to
read? (Maybe it's not topologically possible...).

p.36 s3.2.3+ Is it an image production script, or image production
parameters? In my view, image production parameters pass through to the
pipeline, which uses them in a script (which it attaches to the data for
archiving). Script languages may change, parameters can probably always be
carried forward. Similar comments about observing script et. al. (Or at
least it seems like this is an implementation decision, or is it really a
requirement that they be scripts?).

p.42 s3.7 OK, I admit it. I have no idea what a "Bodega" is.

p.43 s3.7.2 Manuals seems a peculiar sub-package (?) of Science Archive.
Maybe repository?

p.45 s3.7.4 Person repository? Is this what the Person utility uses?

p.47 Resources: this seems like a pretty broad mandate!

p.51 fig 3.3. In my opinion, in a class diagram like this you should either
show a get method, or an association, but not both (I would tend to show the
association). So, for example, I would show the ImageScript attached to
Scheduling Block but suppress the getImageScript() method. I assume that
associations/aggregations are forward navigable, especially in an analysis
document.

p.56 s4 What a good idea this section is!

p.58 s5 I assume that, e.g., the quick-look images (which will be used by
ops and the PI) then do not go in the "online ALMA archive". So where *do*
they go?

p.60 s6.1 alternate courses 4-6. I assume that different subarrays can be in
different modes, which means that the entire system is not in one of the
alternate courses.

p.61 s6.1 alternate course system error processing. This makes it sound like
the exec handles all the problems, whereas a subsystem (e.g. pipeline) might
handle it without the exec being notified. Or is that possibility precluded?
I would argue that the intelligence should be embedded close to the problem
rather than in the executive when possible.

p.75 (of 69!) s8.1. This is not logically a subsection of s8, so maybe it
should be s9.

p.75 s8.1 pt f. I don't see why you're picking on this point of all the ones
that might be hard to do!