S. Digel, 18 October 2005
Cycle 12 ends November 11
Cycle 13 ends December 23
Cycle 14 ends February 3
DC2 itself is likely to kick off around Feb. 15, where 'kick off' means a workshop at SLAC at which the tools and data are released for people to use and analyze. The date of the kick off is not certain, although it fairly certainly will not be moved earlier.
The development goals summarized there for Checkout 3 were to produce good user-level documentation, prototype the ephemeris computer tool, and refine the definitions of the science data products. So, 2 out of 3 have been met. The 3rd has been resistant to prodding on the non-SAE-related data products and needs more attention.
The DC2 development goals summarized there were (in addition to the Checkout 3 goals), prototyping the event display server, and work on DC2-era IRFs (supported by studies with high-level analyses). We have not made progress on those goals, although the Data Server/Data Catalog system at SLAC has come a long way.
The experience of Checkout 3 suggests some additional pre-DC2 development goals. One of them, as we discussed last time and is now the subject of a Confluence page, is how time is represented and handled in the simulators, data products, and tools. I don't have much new to report on this right now; Toby, Jim, and I have exchanged some e-mail. There isn't any one obviously best way to allow user-specified reference dates for source models containing time-dependent sources.
Regarding other pre-DC2 goals in light of the results of Checkout 3, some can be gleaned from the reports posted in Confluence. With what amounts to an additional build cycle being available before DC2 starts, what are reasonable additional goals from the development areas?
We have a detailed specification now of what attitude and position information will be coming from the spacecraft and copied into the LAT science telemetry. There's no LAT document that has this information in it yet, but it will look a lot like what is in the equivalent GBM attitude history data product (which is derived from the spacecraft housekeeping data); see GS-006 in the draft Science Data Products ICD. (Note that GS-006 says that the times will be in UTC; this is not right.)
This means that it will include angular velocities and linear velocities. Also the orientation will be give as a quaternion. And (what I hear from a FSW source) this information will be updated at 5 Hz from the spacecraft; the GS-006 says 1 Hz, so one or the other may be wrong.
In the Level 1 processing, we'll certainly want to have this detailed information available, in order to make the most accurate possible interpolations for the events. For FT2, we don't need the detail, although it certainly can't hurt. One question is if we don't stash all of the attitude and position information in FT2, where will we keep it? Another is whether we should write a quaternion-to-FT2 format translation for orientations, or whether we should use the spacecraft attitude information as directly as we can for the science tools? What do you think?