<div dir="ltr"><div><div><div><div>For Chandra FITS conventions, see: <a href="http://cxc.cfa.harvard.edu/contrib/arots/fits/ascfits.ps">http://cxc.cfa.harvard.edu/contrib/arots/fits/ascfits.ps</a><br></div>It's a bit out of date, but should still be informative.<br>
</div>Our complete list of data products is contained in <a href="http://cxc.cfa.harvard.edu/contrib/arots/fits/content.txt">http://cxc.cfa.harvard.edu/contrib/arots/fits/content.txt</a><br><br></div><div>We (Chandra) have also been working on a FITS dictionary for a number of years<br>
</div><div>- with unlimited resources it would have been done a long time ago.<br></div><div><br></div>General HEA FITS conventions are documented at <a href="https://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html">https://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html</a><br>
</div><div>These are pretty much accepted throughout the HEA community.<br></div><div><br></div> - Arnold Rots<br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>
Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>
Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>
--------------------------------------------------------------------------------------------------------------<br><br></div></div>
<br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 12:01 PM, Erik Bray <span dir="ltr"><<a href="mailto:embray@stsci.edu" target="_blank">embray@stsci.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 04/03/2014 10:51 AM, Joe Hourcle wrote:<br>
> On Wed, 2 Apr 2014, Tom Kuiper wrote:<br>
><br>
>> On 04/02/2014 02:10 PM, Erik Bray wrote:<br>
>>> I wasn't intending to broadcast this to the broader community yet, so I won't go<br>
>>> into too much detail here. I just decided to go ahead and bring it up since it<br>
>>> was relevant to your search for related efforts. The documentation for the<br>
>>> current prototype can be read here:<br>
>>><br>
>>> <a href="http://embray.github.io/PyFITS/schema/users_guide/users_schema.html" target="_blank">http://embray.github.io/PyFITS/schema/users_guide/users_schema.html</a><br>
>>><br>
>>> A prototypical example of a schema can be seen here:<br>
>>><br>
>>> <a href="https://github.com/embray/PyFITS/blob/standard-keywords/lib/pyfits/hdu/base.py#L71" target="_blank">https://github.com/embray/PyFITS/blob/standard-keywords/lib/pyfits/hdu/base.py#L71</a><br>
>> Hi Erik and Joe,<br>
>><br>
>> I'd just like to register interest in this discussion, in case it<br>
>> continues off-line.<br>
>><br>
>> My interest is in using FITS headers to record faithfully the equipment<br>
>> configuration used during an observing session. True, FITS was designed<br>
>> as a data transport format, but a conscientious analyst wants to know<br>
>> pretty much everything about how the data were gathered. For the<br>
>> purpose that I have in mind, current usage is pretty inadequate.<br>
>> Consider, for example, the paucity of information conveyed by TELESCOP<br>
>> and INSTRUME.<br>
><br>
> I've actually had some other thoughts regarding those two keywords<br>
> specifically.<br>
><br>
> I was thinking that much like the 'file' command in UNIX, it might be<br>
> worth making a list of values in use, so that if someone had some<br>
> random FITS file, they could run it through a program that would attempt<br>
> to identify the file, and possibly give a reference of where to find more<br>
> information about that particular instrument.<br>
<br>
</div></div>Indeed, that is along the lines I was thinking as well when working on this.<br>
One could have, for example, a generic HST schema that recognizes an HST<br>
observation from<br>
<br>
TELESCOP= 'HST'<br>
<br>
which then would also check that it has one of<br>
<br>
INSTRUME= 'ACS'<br>
INSTRUME= 'STIS'<br>
INSTRUME= 'WFC3'<br>
<br>
etc...<br>
<br>
Except it's not that simple. For one, I've had a heck of a time finding exactly<br>
what strings should be allowed here. For example the ACS Data Handbook, while<br>
including a comprehensive listing of keywords used in ACS images, simply lists<br>
the INSTRUME keyword and does not anywhere explicitly prescribe an specific<br>
value for it (much less a case-sensitive on--I have seen all of 'ACS', 'acs',<br>
and sadly 'Acs' in the wild). At least the meanings of those variations is<br>
unambiguous.<br>
<br>
But it gets worse--MAST's guidelines for HLSPs [1] makes some recommendations<br>
here too but also allows '<instrument>/<detector>' values for INSTRUME such as<br>
'ACS/WFC' despite there already being a separate DETECTOR keyword. Granted,<br>
DETECTOR has not always been officially part of the FITS Standard. But so<br>
really what one might need here are separate schemas for raw observations and<br>
different higher-level data products (this makes sense for other reasons<br>
anyhow). Point being, it would be really cool to actually have this information<br>
organized in a single format, as it would make it vastly easier for software to<br>
determine what a file is *supposed* to contain and validate it.<br>
<br>
Going back to the ACS Data Handbook it does give 'WFC', 'HRC', and 'SBC' as the<br>
valid values for DETECTOR as one might guess anyway. But a little above there<br>
it lists OBSTYPE as one of "imaging", "spectroscopic" or "coronographic" which<br>
makes sense as an enumeration of allowed values but again I've seen these<br>
spelled (or at least cased) different ways. I hear that some of the instrument<br>
teams do have fairly comprehensive sets of header templates that they check<br>
against, but I haven't been able to find these published anywhere and have yet<br>
to ask around enough.<br>
<br>
Most of this is "merely a documentation problem, but I think it's one that can<br>
and should be solved, and a standard means of documenting these things would<br>
help a lot there.<br>
<br>
[1] <a href="http://archive.stsci.edu/hlsp/hlsp_guidelines_image.html" target="_blank">http://archive.stsci.edu/hlsp/hlsp_guidelines_image.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
> (and even better, check with the authoritative archive to see if the<br>
> file's still current, or if it's been deprecated by a better calibration<br>
> ... but then I start getting really far ahead of myself)<br>
><br>
><br>
>> In moving ahead I will invent new keywords, which most FITS readers will<br>
>> hopefully ignore but which a custom Python program could extract. I<br>
>> want to be sure that I stay close to the generally accepted meanings of<br>
>> the existing keywords. In "generally accepted" lies the problem, so<br>
>> I'll be interested in what you come up with.<br>
><br>
> I'm not sure that there really is a 'generally accepted' for some of these<br>
> keywords.<br>
><br>
> For solar physics, INSTRUME is the investigation name, and TELESCOP could<br>
> be the same, the name of the mission, or the name of the specific detector<br>
> used by the investigation.<br>
><br>
> So, for SOHO/LASCO (a package of three coronagraphs) we have:<br>
><br>
> TELESCOP= 'SOHO ' /<br>
> INSTRUME= 'LASCO ' /<br>
> DETECTOR= 'C2 ' /<br>
><br>
> For STEREO/SECCHI (3 telescopes + 2 coronagraphs on two different<br>
> spacecraft), we have:<br>
><br>
> DETECTOR= 'HI2 ' /<br>
> INSTRUME= 'SECCHI ' /<br>
> OBSRVTRY= 'STEREO_A' /<br>
> TELESCOP= 'STEREO ' /<br>
><br>
> ... and we have cases where INSTRUME is changed depending on the optical<br>
> path through the instrument ... so Hinode/SOT as a filtergram:<br>
><br>
> TELESCOP= 'HINODE'<br>
> INSTRUME= 'SOT/WB'<br>
><br>
> ... vs. Hinode/SOT as a 4D spectropolarimeter:<br>
><br>
> TELESCOP= 'HINODE'<br>
> INSTRUME= 'SOT/SP'<br>
><br>
> ... but those are all from spacecraft .. there's much more variability<br>
> from ground-based observatories:<br>
><br>
> INSTRUME= 'CLIMSO C1' / Name of the instrument<br>
> CAMERA = 'U4000 ' / Name of the CCD camera<br>
><br>
> ORIGIN = 'MT. WILSON' /<br>
> TELESCOP= '60 FT' /<br>
><br>
> INSTRUME= 'NRH ROUT' /<br>
><br>
> TELESCOP= 'NRH' / Nancay Radioheliograph<br>
> INSTRUME= 'NRH2' / Nancay 2D-images Radioheliograph<br>
><br>
> ORIGIN = 'National Solar Observatory -- GONG' / FITS file originator<br>
> OBS-SITE= 'NSO/GONG NETWORK' / Instrument Site location<br>
> TELESCOP= 'NSO-GONG' / NSO/GONG Network<br>
><br>
> ORIGIN = 'BBSO' / BIG BEAR LAKE, CA<br>
> TELESCOP= '26W' /<br>
> CAMERA = '1.4i' / KODAK MODEL NUMBER; SHUTTER DIRECTION: 1<br>
> OBSERVER= 'BBSO' /<br>
><br>
><br>
> But in some cases, neither of those is present, but we have other<br>
> keywords that might be useful for identification:<br>
><br>
> COMMENT NSO/SP/ESF spectroheliogram<br>
><br>
> MPROGNAM= '<a href="http://TR_REFORMAT.PRO" target="_blank">TR_REFORMAT.PRO</a>' /<br>
> PROG_NAM= 'TR_WRT_FITS_I1' /Make a FITS file per hour<br>
><br>
> LAMBDA = 6562.80 /(float) Wavelength of Image [A]<br>
> ARCS_PP = 0.0710000 /(float) Image Scale [arcs/pixel]<br>
> TEL_DIA = 43.8000 /(integer) Telescope aperture [cm]<br>
><br>
> CREATOR = 'BASS2000 Full Sun - Meudon' /<br>
><br>
><br>
> ... this has been a problem for the Virtual Solar Observatory, as try to<br>
> work with the different archives to determine how we should register<br>
> different collections in our system so that a search on an 'instrument'<br>
> will give an expected result.<br>
><br>
> (we cheat some ... if the match for 'instrument' comes up empty, we swap<br>
> 'instrument' and 'detector' and run the search again ... so searching for<br>
> 'instrument=c1' will match both CLIMSO/C1 and LASCO/C1)<br>
><br>
> As I don't think it's realistic for archives to go back and change their<br>
> headers, part of the reason for this documentation is so we can fill in<br>
> constants and synonyms... or maybe even specify how missing keywords<br>
> should be derived from existing ones.<br>
><br>
> -Joe<br>
><br>
> ps. I'm not sure if I should also bring this up on VOTable mailing lists<br>
> ... I would assume that a solution that could document both formats would<br>
> be preferable.<br>
><br>
> -----<br>
> Joe Hourcle<br>
> Programmer/Analyst<br>
> Solar Data Analysis Center<br>
> Goddard Space Flight Center<br>
><br>
> _______________________________________________<br>
> fitsbits mailing list<br>
> <a href="mailto:fitsbits@listmgr.cv.nrao.edu">fitsbits@listmgr.cv.nrao.edu</a><br>
> <a href="http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits" target="_blank">http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits</a><br>
><br>
<br>
_______________________________________________<br>
fitsbits mailing list<br>
<a href="mailto:fitsbits@listmgr.cv.nrao.edu">fitsbits@listmgr.cv.nrao.edu</a><br>
<a href="http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits" target="_blank">http://listmgr.cv.nrao.edu/mailman/listinfo/fitsbits</a><br>
</div></div></blockquote></div><br></div>