Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-5772

Comments on LSE-68


    • Type: Improvement
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: Design Documents
    • Labels:
    • Team:


      Here are some comments on LSE-68. These are likely my misunderstanding of what's being said, but I think some of this might need to be clarified.

      Comments on LSE-68:

      1 Software Delivery - ID: CM-DM-DAQ-ICD-0075
      “… in this document shall be delivered as one or more libraries that can be linked into a C++ application, compiled against the library headers, with its main program provided by the user. The libraries will be supplied as pre-compiled shareable in Unix “.so” format.”

      “The source code for the client libraries will be maintained using common LSST source control tools”.

      4.4 Crosstalk-correction algorithm portability - ID: CM-DM-DAQ-ICD-0056
      “The Camera shall provide a reference implementation for Unix in C++ of the actual algorithm used in the Camera data acquisition system.”

      Comments: I presume these are all mutually exclusive. It’s our understanding that as far as DM access to the camera buffer goes, we will never have source code delivered to us, and that we will only ever get versioned, shared libraries and library headers. Just so I’m understanding, these are saying: 1) Shared libraries with headers will be delivered; 2) Camera will maintain it’s own repository for the source code; 3) Camera will provide DM with only the source code for the crosstalk-correction algorithm.

      2.1 Image Identification - ID: CA-DM-DAQ-ICD-0059

      Comment - From reading this, it appears that the Image ID is assigned to amps.

      3.10 Selection of region of focal plane to be retrieved - ID: CA-DM-DAQ-ICD-0091

      Comment - From reading this, the largest unit we expect to be able retrieve is a raft.

      It would be good to spell out exactly what subregions we expect to be able to request from the Camera, and what “format” those will be delivered in. In other words, do we expect to get a raft back as one continuous buffer, or do we expect the raft to be delivered as a sequence of CCDs that need be reassembled in order to process it? If the image is being handed back as one raft, and the convention is that the Image ID is assigned to individual amps, what will the Image ID for a raft be? Does it even have an Image ID?

      Further, I don’t recall seeing any information anywhere of how a visitID and exposure number for the entire camera image are mapped to an image ID (or whatever) so the correct raft image can be retrieved individually. Will the camera buffer software even understand the concept of a visitID and exposure number?

      I guess what I’m asking here is that if DDS gives me a “startReadout” event for visitID “XYZZY”, exposure 0, how will we expect to get raft 4 of that exposure if the image ID hasn’t even been generated yet? …And what happens if the image ID not assigned per raft, but only per-amp?

      2.2 Structure metadata- ID: CA-DM-DAQ-ICD-0080

      Perhaps a discussion in this section to clarify this a bit more?

      3. “Interface for Buffered Data (“pull” interface) - ID: CA-DM-DAQ-ICD-0047

      This section is a bit unclear to me. It’s my understanding that the only notification DM gets from the OCS is that an image is starting to be dealt with at the camera when we get a “startReadout” event. Some time later, the buffer will be ready to be retrieved, and we don’t get any notification about that. It was my assumption that we’d either make a request to pull the data from the camera buffer and block, or that we’d be notified of the data within our own code through a call to the library which triggers a callback. Which is it?

      Also, what decides to discard the oldest available data?


          Issue Links


            There are no comments yet on this issue.


              • Assignee:
                ktl Kian-Tat Lim
                spietrowicz Steve Pietrowicz
                Steve Pietrowicz
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created:

                  Summary Panel