[INSTRM-1023] Minor FITS edits Created: 23/Jun/20  Updated: 30/Jun/20  Resolved: 30/Jun/20

Status: Done
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: cloomis Assignee: Unassigned
Resolution: Done Votes: 0
Labels: FITS, SPS
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to INSTRM-1022 Add Subaru-compliant spectroscopy cards Done
relates to PIPE2D-610 Accept DATA-TYP = "COMPARISON" Won't Fix
Sprint: SM1PD-2020 G

 Description   

There are a handful of minor FITS errors described in the PFSA01894911_20200619 comments. I plan to fix these all at once.

 

1) Violation in Value range or Comment part

- DATA-TYP : value 'ARC' is not registered in Subaru FITS rule
- DET-TMP  : unit should be [K] -> needs to fix on the dictionary side?
- ADC-TYP  : Comment 'ADC name' is wrong for the present example 'IN'
             Dictionary requests name of ADC rather than state (such as 'IN')
             but this may need further discussion on the dictionary side (ex. HSC also shows state 'LINK' for this card)
- EXPTIME  : Unit is missing

2) Unregistered keyword (to be registered in Subaru basic keyword dictionary)
- DARKTIME : Unit is also missing

4) Unnecessary keyword that may be better to be removed
- M2-TYPE : existence of M2 may be confusing

5) Wrong keyword name
- ADC-TYP --> ADC-TYPE
- FOC_VAL --> VOC-VAL

8) Others/Misc
- DET-ID : recommended for STARS
- BLANK/ZBLANK :  Subaru rule also needs to define where to put BLANK keyword in the MEF case
                and presumably should require ZBLANK in compressed data

 

ADC-TYP comes directly from Gen2, so I will leave that alone for now.

So for SPS, should DATA-TYP be one of: BIAS, COMPARISON, DARK, FLAT, OBJECT, and maybe TEST? I think that is all we plan to take. We could add FOCUSING, but I think that will confuse matters. 

 

 Comments   
Comment by cloomis [ 23/Jun/20 ]

Hisanori Furusawa Can you tell me whether DET-ID should distinguish between low_red and med_red "detectors"? Or should it simply count the physical FPAs? In other words, are there 3 DET-IDs per SM, or 4?

Comment by Hisanori Furusawa [ 23/Jun/20 ]

Interesting. I don't think we need to alter the DET-ID for different resolution modes, as long as a detector is physically the same. I believe under the current rule that DET-ID should be mapped to each physical detector. Do you handle a pair of CCDs in an optical arm as a single detector in everywhere of data flow? I think the keyword is intended to identify from which physical detector a certain pixel of interest comes from, and in this sense, we may want to have 2 DET-IDs for each of blue and red arms, and 1 for NIR per SM. However, if the images from the pair CCDs are inseparable and consistently in a single FITS from the arrival at Gen2, then we may well use 1 DET-ID for every arm (3 DET-IDs per SM). For archive end-uses, this is keyword would help STARS queries to narrow a data range into a decently qualitatively-different groups, too.

Comment by cloomis [ 23/Jun/20 ]

We treat each FPA as a single detector. That might have been a mistake, but it is too late to change.
OK. In that case I will use the mapping which is used by the DRP. Thanks.

Comment by Hisanori Furusawa [ 24/Jun/20 ]

Thank you. 1 unique DET-ID for each FPA is acceptable & still useful enough, I believe. The archive will treat a 4k4k FPA image as a unit raw data.

Comment by cloomis [ 30/Jun/20 ]
  • pfs_utils 5.2.1
  • ics_actorkeys 1.4.3
  • tron_actorcore 2.2.4
  • ics_ccdActor 1.6.5
  • ics_gen2Actor 1.4.4
Generated at Sat Feb 10 16:31:05 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.