Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-490

LDM-638 Header Service Requirements

    Details

    • Type: RFC
    • Status: Withdrawn
    • Resolution: Done
    • Component/s: DM, TCT
    • Labels:
      None

      Description

      The Header Service requirements are now available for review in LDM-638.

      The current draft can be found at https://docushare.lsst.org/docushare/dsweb/Get/Version-51916/LDM-638.pdf (there is no .lsst.io version yet).

        Attachments

          Issue Links

            Activity

            Hide
            rhl Robert Lupton added a comment -

            And in the lab in Tucson

            Show
            rhl Robert Lupton added a comment - And in the lab in Tucson
            Hide
            rhl Robert Lupton added a comment -

            My only serious concern is in 1.11; the specification of the unique ID.

             

            1.3 .. 1.7  I don't think we should specify that the header service write headers at the cadence for different observing modes, but that it must write a header for all exposures taken in any way except through the CCS backdoor.

            In 1.7 I think we need headers for all CCDs, not just the 189 "science" detectors.

            In 1.10 we don't specify how long after the exposure finishes the header service must wait.  How does this relate to the end-of-Telemetry Event from the Camera Device?

            1.11 How does this "unique ID" relate to the OBS-ID from LCR-1424?  It would need to add a detectorId to the tuple discussed there.  If it turns out that the project (OCS and/or CCS) cannot provide a unique tuple under all circumstances, what does the header service do?

            1.13 KT implied that was under consideration, but why does the header service know anything about fits?  Isn't that the responsibility of the code[s] that write the files?  If necessary, the header service should provide suitable comment strings.

            1.14 "hopefully" is an adverb.

            1.16 Again, why FITS?  E.g. FITS uses blank for some missing values, not NaN.  Should it provide a list of missing values?  Are default values acceptable for some fields?

            1.19 I don't understand what this is supposed to mean.  That this is a minimum list of people who get asked?  I can think of other people who may need header keywords (e.g. the commissioning teams).

            1.20 I don't think that "Project Science Team" means the PST here

            Show
            rhl Robert Lupton added a comment - My only serious concern is in 1.11; the specification of the unique ID.   1.3 .. 1.7  I don't think we should specify that the header service write headers at the cadence for different observing modes, but that it must write a header for all exposures taken in any way except through the CCS backdoor. In 1.7 I think we need headers for all CCDs, not just the 189 "science" detectors. In 1.10 we don't specify how long after the exposure finishes the header service must wait.  How does this relate to the end-of-Telemetry Event from the Camera Device? 1.11 How does this "unique ID" relate to the OBS-ID from LCR-1424?  It would need to add a detectorId to the tuple discussed there.  If it turns out that the project (OCS and/or CCS) cannot provide a unique tuple under all circumstances, what does the header service do? 1.13 KT implied that was under consideration, but why does the header service know anything about fits?  Isn't that the responsibility of the code [s] that write the files?  If necessary, the header service should provide suitable comment strings. 1.14 "hopefully" is an adverb. 1.16 Again, why FITS?  E.g. FITS uses blank for some missing values, not NaN.  Should it provide a list of missing values?  Are default values acceptable for some fields? 1.19 I don't understand what this is supposed to mean.  That this is a minimum list of people who get asked?  I can think of other people who may need header keywords (e.g. the commissioning teams). 1.20 I don't think that "Project Science Team" means the PST here
            Hide
            tjenness Tim Jenness added a comment -

            Kian-Tat Lim, Felipe Menanteau, what's the status of dealing with the comments raised in this RFC?

            Show
            tjenness Tim Jenness added a comment - Kian-Tat Lim , Felipe Menanteau , what's the status of dealing with the comments raised in this RFC?
            Hide
            ktl Kian-Tat Lim added a comment -

            REQ-0003 through REQ-0007 (1.3 through 1.7): It is easier to verify an enumeration than "all", but I think it is sufficient to say that when deployed with a CCS, the Header Service will output a header for each image taken and announced via SAL.

            REQ-0007 (1.7): Yes, WFS CCDs need headers during normal observing and calibration, and guider CCDs need headers during calibration.

            REQ-0010 (1.10): The exposure time wouldn't seem to need any post-readout information. Any time delay after readout should be very short, as it is in the critical path for visualization, Summit analysis, and Alert Production. Nevertheless, with the end-of-telemetry event in REQ-0011 (1.11), it is the Camera's responsibility to minimize this interval, not the Header Service's.

            REQ-0011 (1.11): The unique id is identically the OBS-ID from LCR-1424. If that is not unique, then there will already be other problems with persisting pixels. A detector id would only need to be added if a separate header file is written per detector. This decision is being evaluated.

            REQ-0013 (1.13): The requirement will say for now that the Header Service output will be consistent with the data needed to generate a compliant FITS header. The details of the format to be used are being evaluated.

            REQ-0014 (1.14): "hopefully" will be removed. The Header Service has complete control over the format of its configuration and can select YAML if desired, although consistency with afw.cameraGeom is desirable, which may suggest that some data should be in pex.config form.

            REQ-0016 (1.16): FITS does not need to be mentioned here and will be removed.

            REQ-0019 and REQ-0020 (1.19 and 1.20): I believe the original intent was for REQ-0019 to be a minimum list, with other potential content users or desired headers to be provided by the PST/Project Science Team.

            Show
            ktl Kian-Tat Lim added a comment - REQ-0003 through REQ-0007 (1.3 through 1.7): It is easier to verify an enumeration than "all", but I think it is sufficient to say that when deployed with a CCS, the Header Service will output a header for each image taken and announced via SAL. REQ-0007 (1.7): Yes, WFS CCDs need headers during normal observing and calibration, and guider CCDs need headers during calibration. REQ-0010 (1.10): The exposure time wouldn't seem to need any post-readout information. Any time delay after readout should be very short, as it is in the critical path for visualization, Summit analysis, and Alert Production. Nevertheless, with the end-of-telemetry event in REQ-0011 (1.11), it is the Camera's responsibility to minimize this interval, not the Header Service's. REQ-0011 (1.11): The unique id is identically the OBS-ID from LCR-1424. If that is not unique, then there will already be other problems with persisting pixels. A detector id would only need to be added if a separate header file is written per detector. This decision is being evaluated. REQ-0013 (1.13): The requirement will say for now that the Header Service output will be consistent with the data needed to generate a compliant FITS header. The details of the format to be used are being evaluated. REQ-0014 (1.14): "hopefully" will be removed. The Header Service has complete control over the format of its configuration and can select YAML if desired, although consistency with afw.cameraGeom is desirable, which may suggest that some data should be in pex.config form. REQ-0016 (1.16): FITS does not need to be mentioned here and will be removed. REQ-0019 and REQ-0020 (1.19 and 1.20): I believe the original intent was for REQ-0019 to be a minimum list, with other potential content users or desired headers to be provided by the PST/Project Science Team.
            Hide
            ktl Kian-Tat Lim added a comment -

            The above changes have been incorporated into LDM-638, but this section of that document will become LSE-400 instead.

            Show
            ktl Kian-Tat Lim added a comment - The above changes have been incorporated into LDM-638, but this section of that document will become LSE-400 instead.

              People

              • Assignee:
                tjenness Tim Jenness
                Reporter:
                tjenness Tim Jenness
                Watchers:
                Felipe Menanteau, Gregory Dubois-Felsmann, Kian-Tat Lim, Margaret Gelman, Michelle Butler, Robert Lupton, Simon Krughoff, Steve Pietrowicz, Tim Jenness, Wil O'Mullane
              • Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel