[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: |
|
||||||||||||
| 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. |
| 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. |