[DAMD-97] Add missing 2D pipeline outputs Created: 03/Dec/20  Updated: 30/Jul/22  Resolved: 30/Jul/22

Status: Done
Project: Data Model
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Normal
Reporter: price Assignee: price
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

A


Issue Links:
Relates
relates to DAMD-132 Will the science database include "Cl... Open
relates to PIPE2D-1024 Convert pfsMerged fluxes to electrons/nm Done
Story Points: 4
Sprint: 2DDRP-2021 A 2, 2DDRP-2022 D, 2DDRP-2022 E
Reviewers: hassan

 Description   

The 2D pipeline generates products that aren't captured in datamodel.txt. pfsMerged is one. Audit the pipeline outputs and add them to datamodel.txt.



 Comments   
Comment by price [ 08/Apr/22 ]

At the DRP telecon just now, we decided that there are two classes of DRP2D data products. Class I products are the spectral products that scientists will use frequently, e.g., pfsArm, pfsMerged, pfsSingle, pfsObject. These need to be described in detail, including listing what important header keywords will be available. We need to document any changes to the format, since scientists will want to be able to compare spectra between different data releases. Class II products are the calibration products that scientists will use rarely, and can be regenerated by running the pipeline, e.g., sky2d, sky1d, fluxCal. These need to be described in sufficient detail that the contents can be used, but only the current format in use need be documented. A note should be affixed to the effect that the format is subject to change.

Comment by price [ 05/May/22 ]

Do the Class II products need to have python I/O implementations in the datamodel package?

We currently have I/O implementations in datamodel for detectorMap and fiberProfiles which I think would fall under Class II. I would like to avoid moving the I/O for additional products into datamodel if I can, and even remove those existing Class II implementations. But let me know what the policy should be, and I will implement it.

Comment by Takuji Yamashita [ 19/Jul/22 ]

pfsSingle is one of the outputs from flux calibration. In terms of flux calibration, I do not have any demands on the current form.
fluxCal is also output from flux calibration, but it is still not determined on our side. This year we will work on modeling flux calibration vectors across the focal plane. After that, we will have a concrete idea of the datamodel of fluxCal. I can of course make some descriptions for the current fluxCal if needed. 

Comment by price [ 20/Jul/22 ]

We probably haven't written the particular subclass that we want to use for flux calibration yet, but fluxCal will be a subclass of FocalPlaneFunction.

Comment by Takuji Yamashita [ 20/Jul/22 ]

Yes. That's right. We will write a subclass of FocalPlaneFunction for flux calibration. 

Comment by price [ 30/Jul/22 ]

Added descriptions in datamodel.txt, and moved I/O to the datamodel package.

Comment by hassan [ 30/Jul/22 ]

Changes approved. Minor comments added to pull request https://github.com/Subaru-PFS/drp_stella/pull/281 .

Comment by price [ 30/Jul/22 ]

Minor comments addressed and merged.

Generated at Sat Feb 10 15:34:13 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.