-
Type: Bug
-
Status: Done (View Workflow)
-
Priority: Normal
-
Resolution: Done
-
Labels:None
The DAMD-32 ticket was not adequately reviewed, so I'm opening this ticket to reconsider the details.
I am not objecting to the split – the original design by me was clearly naïve – but the partial introduction of a pfi prefix is a problem. We could change pfsConfig to pfiConfig but I think it's too late for that; and the use of two different prefixes doesn't really improve the system although it is slightly more logical. The only counter-argument would be if we needed a different file to track other parts of the instrument configuration, but I'd argue that we should just add the extra information to the pfsConfig file.
Also, the new pfsConfig file introduces but doesn't define expId. We can take more than one exposure with a single cobra configuration so this isn't a simple visitId; we also can come back to the same pfiDesign but with a different pfsConfig so maybe it's a counter in that space? We can also integrate on the same set of objects but with a different pfiDesign if we need to rotate the PFI, but I think the book-keeping for that is outside the scope of this discussion.
I also see that we have denormalised the pfiDesign into the pfsConfig; this is probably OK, but I'd like to see it called out as part of this discussion.
So I'd like price to clarify his proposal for expId, and for everyone to think about whether having two prefixes is worth the inevitable mistakes.
- blocks
-
DAMD-57 Implement range of datamodel changes
- Done
- relates to
-
DAMD-49 Clarify use of expId
- Done
-
PIPE2D-435 PfiDesign files not renamed to PfsDesign files
- Done
-
SIM2D-117 Use PfsDesign not PfiDesign
- Done
-
SURVEY-9 Need to track multiple cobra configurations
- Done