[DAMD-32] Split pfsConfig into pre- and post- mapping files. Created: 30/May/18  Updated: 04/Apr/19  Resolved: 30/Jan/19

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

Type: Task Priority: Normal
Reporter: cloomis Assignee: price
Resolution: Done Votes: 0
Labels: SIM2D
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to DAMD-49 Clarify use of expId Done
Reviewers: cloomis

 Description   

The current pfsConfig mechanism covers two different concepts: the design of a targeted field, which is the input to the FPS cobra motion process, and the instantiation of that field where both the measured cobra positions and the starting visit number are known.

Discussions have led to the suggestion that we should split pfsConfig into:

  • pfsFieldDesign, specifically pfsFieldDesign-$configId.fits
  • pfsConfig, specifically pfsConfig-$configId-$visit0.fits

The only significant internal difference would be the MCS positions and the PFS visit from which the field is valid. Given that, the final pfsConfig could either refer to the pfsFieldDesign, or include it. I think we should denormalize and include it: that single $pfsConfig-$configId-$visit0 would then neatly contain all that we need to know about field.

A couple of notes: the $configId is not strictly necessary in the pfsConfig file name, since only one configuration can be active at any given time (visit+}. But binding the two seems informative.



 Comments   
Comment by hassan [ 01/Aug/18 ]

Blocked. Requires discussion at the architectural level between cloomis, rhl, hassan and possibly LSST members such as jbosch.

Expect this to move forward end of August, after LSST2018.

Comment by rhl [ 01/Aug/18 ]

No need for jbosch.  We just have to sort this out;  my original design was wrong and we haven't had time to fix it.

 

Comment by cloomis [ 01/Aug/18 ]

I'll edit/split the relevant section of datamodel.txt, adding details for discussion.

Comment by hassan [ 14/Sep/18 ]

price to review datamodel.txt and make necessary updates to pfi(Field)Design and pfiConfig

Comment by hassan [ 05/Nov/18 ]

cloomis price: can we merge to master now?

Comment by price [ 06/Nov/18 ]

Fine with me.

Comment by price [ 06/Nov/18 ]

Oh, I see that I own this now. Let me look through it once the dust settles from my trip.

Comment by price [ 21/Nov/18 ]

We recently agreed that there's no need for us to worry about the design part, at least right now. However, we do need the configuration (the implementation of the observation design that specifies where the cobras ended up for actual exposures) to advance work on the simulator (SIM2D-88).

Comment by price [ 23/Nov/18 ]

Here’s the text I’m putting in datamodel.txt. Any objections, concerns or comments?

The design of a PFI setup, i.e., the targetting of fibers, is a PfiDesign:

"pfiDesign-0x%016x.fits" % (pfiDesignId)

The choice of a hex format is because the the pfiDesignId is a SHA-1
of the intended fiber positions.

FITS file format:

HDU #0 PDU
HDU #1 FITS binary table named "DESIGN"

The DESIGN table lists for each object:
fiberId 32-bit int
catId 32-bit int
tract 32-bit int
patch string
objId 64-bit int
ra 64-bit float (degrees)
dec 64-bit float (degrees)
pfiNominal pair of 32-bit floats (microns on the PFI)

N.b. fiberIds start at 1.

=======================================

The realisation of a PfiDesign for a particular exposure is a PfsConfig:

"pfsConfig-0x%016x-%06d.fits" % (pfiDesignId, expId)

The choice of a hex format is because the the pfiDesignId is a SHA-1.

FITS file format:

HDU #0 PDU
HDU #1 FITS binary table named "CONFIG"
HDU #1 FITS binary table named "PHOTOMETRY"

The CONFIG table lists for each object:
fiberId 32-bit int
catId 32-bit int
tract 32-bit int
patch string
objId 64-bit int
ra 64-bit float (degrees)
dec 64-bit float (degrees)
pfiCenter pair of 32-bit floats (microns on the PFI)
pfiNominal pair of 32-bit floats (microns on the PFI)

N.b. fiberIds start at 1.

The PHOTOMETRY table lists:
fiberId 32-bit int
fiberMag 32-bit float
filterName string

A fiberId may be listed multiple times in the PHOTOMETRY table in order to
provide measurements in multiple filters for a single object.

The 'filterName' values in the PHOTOMETRY table will specify particular
transmission curves used by the pipeline, and therefore the range of
permitted values is limited to a set to be specified by the DRP team.
There will be a mechanism for adding to this set.

Comment by cloomis [ 29/Nov/18 ]

I'd say that the PHOTOMETRY table needs to be in the Design file: that is one of the things coming from the targeting/proposal folks.

Also that it's worth explicitly stating that a pointing ra/dec must be in the header: where the telescope is slewed to.

Comment by price [ 05/Dec/18 ]

Moved cloomis's contribution from tickets/DAMD-32 to u/cloomis/DAMD-32 in anticipation of stealing the official ticket branch for my work which is currently on u/price/DAMD-32.

Comment by price [ 18/Dec/18 ]

Sorry to give you this as well as the simulator changes, cloomis, but I think they naturally go to you.

Comment by price [ 18/Dec/18 ]

Ack, I forgot that there needs to be coordinated changes in drp_stella.

Comment by price [ 19/Dec/18 ]

Made some fixes in drp_stella, and the PR is open.

Comment by price [ 30/Jan/19 ]

Merged along with PIPE2D-310.

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