[DAMD-42] Reconsider the details of the pfsConfig/pfiDesign split Created: 15/Feb/19  Updated: 11/Jun/19  Resolved: 24/May/19

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

Type: Bug Priority: Normal
Reporter: rhl Assignee: hassan
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks DAMD-57 Implement range of datamodel changes Done
Relates
relates to DAMD-49 Clarify use of expId Done
relates to PIPE2D-435 PfiDesign files not renamed to PfsDes... Done
relates to SIM2D-117 Use PfsDesign not PfiDesign Done
relates to SURVEY-9 Need to track multiple cobra configur... Done
Reviewers: rhl

 Description   

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.

 Comments   
Comment by cloomis [ 16/Feb/19 ]

Isn't the exposure in pfsConfig a visit0 thing: it is an instantiation of a pfsDesign which is valid until the cobras get moved again. In which case we get a new pfsConfig.

For some fields, the `pfsConfig` will be valid for a few exposures. I think we do, if possible, want to make it explicit that a given `pfsConfig` is valid for all of those. If we slightly tweak cobras between exposures, we get different {{pfsConfig}}s.

Comment by rhl [ 16/Feb/19 ]

The consensus on slack seems to be to switch to `pfsDesign`.

Comment by rhl [ 16/Feb/19 ]

We could go with visit0 or a counter. I take your point that visit0 is managed for us, even if less user-friendly. As I hope no human will ever type it, that's fine

Comment by cloomis [ 16/Feb/19 ]

I think visit0 is safer and easier. Else some ICS thing needs to track counters somewhere.

Comment by hassan [ 06/Mar/19 ]

Following discussions with rhl, we are all signed up for visit0 for specifying the next configuration.

We define visit0 as the next visit number generated after the configuration change has been made.

References to pfiDesign will be changed to pfsDesign in datamodel.txt.

References to pfsConfigId in datamodel.txt should be replaced with the pfsDesignId + visit0 tuple.

Comment by rhl [ 21/Mar/19 ]

When do we expect to complete this work?

Comment by hassan [ 22/Mar/19 ]

I'm aiming for a week's time - 28 Mar 2019.

Comment by hassan [ 04/Apr/19 ]

Following discussions with rhl - the implementation of this ticket will be restricted to the agreed change of pfiDesign to pfsDesign. The topic of whether expId should or should not be introduced will be the subject of a separate ticket (DAMD-49).

Comment by hassan [ 24/May/19 ]

Merged to master 09b9d02.

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