<!-- 
RSS generated by JIRA (8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b) at Sat Feb 10 16:31:05 JST 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>PFS-JIRA</title>
    <link>https://pfspipe.ipmu.jp/jira</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.3.4</version>
        <build-number>803005</build-number>
        <build-date>13-09-2019</build-date>
    </build-info>


<item>
            <title>[INSTRM-1023] Minor FITS edits</title>
                <link>https://pfspipe.ipmu.jp/jira/browse/INSTRM-1023</link>
                <project id="10300" key="INSTRM">Instrument control development</project>
                    <description>&lt;p&gt;There are a handful of minor FITS errors described in the&#160;PFSA01894911_20200619 comments. I plan to fix these all at once.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;1) Violation in Value range or Comment part

- DATA-TYP : value &apos;ARC&apos; is not registered in Subaru FITS rule
- DET-TMP  : unit should be [K] -&amp;gt; needs to fix on the dictionary side?
- ADC-TYP  : Comment &apos;ADC name&apos; is wrong for the present example &apos;IN&apos;
             Dictionary requests name of ADC rather than state (such as &apos;IN&apos;)
             but this may need further discussion on the dictionary side (ex. HSC also shows state &apos;LINK&apos; 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 --&amp;gt; ADC-TYPE
- FOC_VAL --&amp;gt; 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
 &lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;ADC-TYP comes directly from Gen2, so I will leave that alone for now.&lt;/p&gt;

&lt;p&gt;So for SPS, should DATA-TYP be one of:&#160;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.&#160;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</description>
                <environment></environment>
        <key id="14528">INSTRM-1023</key>
            <summary>Minor FITS edits</summary>
                <type id="3" iconUrl="https://pfspipe.ipmu.jp/jira/secure/viewavatar?size=xsmall&amp;avatarId=10518&amp;avatarType=issuetype">Task</type>
                                            <priority id="10000" iconUrl="https://pfspipe.ipmu.jp/jira/images/icons/priorities/medium.svg">Normal</priority>
                        <status id="10002" iconUrl="https://pfspipe.ipmu.jp/jira/images/icons/statuses/generic.png" description="The issue is resolved, reviewed, and merged">Done</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10000">Done</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="cloomis">cloomis</reporter>
                        <labels>
                            <label>FITS</label>
                            <label>SPS</label>
                    </labels>
                <created>Mon, 22 Jun 2020 21:55:28 +0000</created>
                <updated>Mon, 29 Jun 2020 19:01:50 +0000</updated>
                            <resolved>Mon, 29 Jun 2020 19:01:50 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>2</watches>
                                                                <comments>
                            <comment id="17359" author="cloomis" created="Mon, 22 Jun 2020 23:31:31 +0000"  >&lt;p&gt;&lt;a href=&quot;https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=furu&quot; class=&quot;user-hover&quot; rel=&quot;furu&quot;&gt;Hisanori Furusawa&lt;/a&gt; Can you tell me whether DET-ID should distinguish between low_red and med_red &quot;detectors&quot;? Or should it simply count the physical FPAs?  In other words, are there 3 DET-IDs per SM, or 4?&lt;/p&gt;</comment>
                            <comment id="17363" author="furu" created="Tue, 23 Jun 2020 05:28:49 +0000"  >&lt;p&gt;Interesting. I don&apos;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.&lt;/p&gt;</comment>
                            <comment id="17364" author="cloomis" created="Tue, 23 Jun 2020 12:39:26 +0000"  >&lt;p&gt;We treat each FPA as a single detector. That might have been a mistake, but it is too late to change.&lt;br/&gt;
OK. In that case I will use the mapping which is used by the DRP. Thanks.&lt;/p&gt;</comment>
                            <comment id="17365" author="furu" created="Wed, 24 Jun 2020 00:32:13 +0000"  >&lt;p&gt;Thank you. 1 unique DET-ID for each FPA is acceptable &amp;amp; still useful enough, I believe. The archive will treat a 4k4k FPA image as a unit raw data.&lt;/p&gt;</comment>
                            <comment id="17403" author="cloomis" created="Mon, 29 Jun 2020 19:01:50 +0000"  >&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;pfs_utils             5.2.1&lt;/li&gt;
	&lt;li&gt;ics_actorkeys    1.4.3&lt;/li&gt;
	&lt;li&gt;tron_actorcore  2.2.4&lt;/li&gt;
	&lt;li&gt;ics_ccdActor     1.6.5&lt;/li&gt;
	&lt;li&gt;ics_gen2Actor   1.4.4&lt;/li&gt;
&lt;/ul&gt;
</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10003">
                    <name>Relates</name>
                                                                <inwardlinks description="relates to">
                                        <issuelink>
            <issuekey id="14527">INSTRM-1022</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="14529">PIPE2D-610</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10500" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|zzs1sv:i</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10005" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="80">SM1PD-2020 G</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                    </customfields>
    </item>
</channel>
</rss>