[DAMD-71] TargetType should be defined in datamodel.txt and headers Created: 21/Dec/19 Updated: 05/Jan/21 Resolved: 24/Mar/20 |
|
| Status: | Done |
| Project: | Data Model |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Normal |
| Reporter: | hassan | Assignee: | price |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Story Points: | 2 | ||||||||
| Sprint: | 2DDRP-2021 A | ||||||||
| Reviewers: | hassan | ||||||||
| Description |
|
Define the values of the TargetType enum in datamodel.txt along with a new enum, FiberStatus. Also write this definitions in all the relevant product headers (pfsObject, pfsMerged etc) so they are self-describing. The TargetType enum should contain the following values: SCIENCE SKY FLUXSTD UNASSIGNED ENGINEERING The new ENGINEERING value is to accommodate data where the engineering fibers are illuminated. Note that the fiber characteristics (broken, blocked etc) have been moved. They are now in a new enumeration, FiberStatus (or better name), with values: GOOD BROKENFIBER BLOCKED BLACKSPOT UNILLUMINATED The value BROKENFIBER replaces BROKEN (which is confusing as 'BROKEN' could indicate a broken cobra or a fiber). A perfectly functioning fiber is labelled with FiberStatus==GOOD.
|
| Comments |
| Comment by price [ 12/Mar/20 ] |
|
I don't think the TargetType and FiberStatus are orthogonal, as your design implies. If a fiber has a status of BLOCKED, it can't be targeted to anything. Similarly for all other fiber statuses than GOOD. I suggest that instead of being a separate enumeration, the statuses you have identified should all be included in TargetType. We could rename TargetType to FiberTarget or similar to reflect the all-encompassing nature. |
| Comment by rhl [ 12/Mar/20 ] |
|
Please keep the separate. For example, we could design a plate and then discover that a fibre is broken. They capture different sorts of information. What is the downside? |
| Comment by price [ 12/Mar/20 ] |
|
The only downside is extra work for something unnecessary, but I'm happy to do it if you think it's important. |
| Comment by price [ 12/Mar/20 ] |
|
Here's an example of the values and definitions in the FITS header: HIERARCH TargetType.SCIENCE = 1 / science target HIERARCH TargetType.SKY = 2 / blank sky; used for sky subtraction HIERARCH TargetType.FLUXSTD = 3 / flux standard; used for fluxcal HIERARCH TargetType.UNASSIGNED = 4 / no particular target HIERARCH TargetType.ENGINEERING = 5 / engineering fiber HIERARCH FiberStatus.GOOD = 1 / working normally HIERARCH FiberStatus.BROKENFIBER = 2 / broken; ignore any flux HIERARCH FiberStatus.BLOCKED = 3 / temporarily blocked; ignore any flux HIERARCH FiberStatus.BLACKSPOT = 4 / hidden behind spot; ignore any flux HIERARCH FiberStatus.UNILLUMINATED = 5 / not illuminated; ignore any flux |
| Comment by price [ 12/Mar/20 ] |
|
I've split TargetType into TargetType and FiberStatus, improved the python docs and put docs in the FITS headers. |
| Comment by price [ 12/Mar/20 ] |
|
Oh, this will need a new drp_stella_data. I'll start that now, and hopefully submit it later tonight. There are conflicts between this work and |
| Comment by price [ 13/Mar/20 ] |
|
It's important to point out that this changes PfsDesign and PfsConfig. |
| Comment by price [ 24/Mar/20 ] |
|
Merged to master. |