From server@athena.gsfc.nasa.gov Wed Mar 2 13:19:50 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1353" "Wed" " 2" "March" "1994" "13:16" "EST" "Lucio Chiappetti" "lucio@ifctr.mi.cnr.it" "" "32" "Re: OGIP/93-013 - A list of standard strings for HE missions,instruments & filters." "^From:" nil nil "3" "1994030218:16:00" "OGIP/93-013 - A list of standard strings for HE missions,instruments & filters." nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA29712; Wed, 2 Mar 94 13:19:47 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pbvTb-00014Oa; Wed, 2 Mar 94 13:16 EST Message-Id: Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: Lucio Chiappetti Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OGIP/93-013 - A list of standard strings for HE missions,instruments & filters. Date: Wed, 2 Mar 94 13:16 EST On Mon, 7 Feb 1994, Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum) wrote: > HEA FITS gurus > > At a recent OGIP FITS Working Group (OFWG) meeting, the panel made a > preliminary recommendation ("p15.1") that a set of standard strings be > employed to specify the mission, instrument (+sub-instrument) and filter > in use in a given FITS dataset. In most cases these strings would of course be > used in conjuncture with the TELESCOP, INSTRUME & FILTER keywords. > > (The start of) a list of such standard strings has been constructed by > George & Angelini, based upon comments received from within the OGIP & SAO. > This is available in the form of an OGIP Memo from anonymous ftp on > legacy.gsfc.nasa.gov as > > caldb/docs/memos/ogip_93_013.ps (Postscript) > > We would welcome any comments or additions from the community - especially > if the proposed strings will cause insurmountable problems to existing s/w. > We hope that most members of the High Energy community agree that it > would be highly desirable if such a list of standards were adopted > community-wide as soon as possible. As usual, comments of community-wide > interest should be posted to HEAFITS. > > regards > Ian M George (george@lheavx.gsfc.nasa.gov) > Lorella Angelini (angelini@lheavx.gsfc.nasa.gov) > > HEASARC NASA/GSFC > From server@athena.gsfc.nasa.gov Wed Mar 2 14:05:48 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["903" "Wed" " 2" "March" "1994" "14:02" "EST" "Jeff Bloch" "jbloch@sstcx1.lanl.gov" "" "18" "Re: OGIP/93-013 - A list of standard strings for HE missions,instruments & filters." "^From:" nil nil "3" "1994030219:02:00" "OGIP/93-013 - A list of standard strings for HE missions,instruments & filters." nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA00167; Wed, 2 Mar 94 14:05:45 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pbwC8-0001gGa; Wed, 2 Mar 94 14:02 EST Message-Id: Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: Jeff Bloch Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OGIP/93-013 - A list of standard strings for HE missions,instruments & filters. Date: Wed, 2 Mar 94 14:02 EST How logical or useful would an additional keyword be to specify the optic used for the instrument? For our ALEXIS telescopes, the multilayer mirrors in each telescope are just as important to specify as the filter in front of the detector since the mirror specifies the bandpass. For other projects, perhaps several flight type optics were prepared but only one used? In this case, I was thinking of an "OPTIC" or "MIRROR" keyword. -------------------------------------------------------------------------- Jeffrey Bloch Office: (505) 665-2568 Astrophysics and Radiation Measurements Group ALEXIS Soc: (505) 665-5975 Los Alamos National Laboratory FAX: (505) 665-4414 Mail Stop D436 e-mail: jbloch@lanl.gov Los Alamos, NM 87545 **** Goodbye SST-9 ---> Hello NIS-2 (A rose by any other name????)******* -------------------------------------------------------------------------- From server@athena.gsfc.nasa.gov Tue Mar 1 16:40:36 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["4540" "Tue" " 1" "March" "1994" "16:37" "EST" "Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)" "GEORGE@heagip.gsfc.nasa.gov" "<940301163816.20c015bf@heagip.gsfc.nasa.gov>" "84" "Re: OGIP/93-013 - A list of standard strings for HE missions,instr..etc" "^From:" nil nil "3" "1994030121:37:00" "OGIP/93-013 - A list of standard strings for HE missions,instr..etc" nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27868; Tue, 1 Mar 94 16:40:34 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pbc8N-0001mja; Tue, 1 Mar 94 16:37 EST Message-Id: <940301163816.20c015bf@heagip.gsfc.nasa.gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: "Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)" Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OGIP/93-013 - A list of standard strings for HE missions,instr..etc Date: Tue, 1 Mar 94 16:37 EST Barry Schlesinger listed a few questions/comments in his recent HEAFITS post (1994 Feb 23) regarding the OGIP Memo OGIP/93-013 "Standard Strings for Mission, Instrument, Filter & Detector Names for OGIP FITS files". Below we give our response. A number of relatively minor changes have been made to the memo resulting from all the comments received, and a new version (1993 Feb 28) is available via anonymous ftp on legacy.gsfc.nasa.gov from caldb/docs/memos/ogip_93_013.ps (Postscript) caldb/docs/memos/ogip_93_013.tex (LaTeX source) Barry writes: > The formsats given for the keyword=value statements appear to be > missing blanks. A keyword of fewer than eight characters must be > filled with trailing blanks. There must be a space between the "=" and > the quote beginning the characters value. Also, the recommended form > for character string values is that they be at least eight characters, > with trailing blanks, if necessary. While this format is not required > for optional character values, it should be followed unless there is a > compelling reasong not to. A sample keyword=value statement would be > as follows: > DETNAM = 'SDB ' ... Yes we were aware of the rules/conventions concerning character string keywords. Yet, it had not occured to us that the computer-style font used for these strings may have lead to confusion in the minds of some readers. However in order to be 100% clear & true, the latest version of the memo has the correct FITS syntax (inc trailing blanks) everywhere appropriate within the text. > Because of portability issues, underscore is preferable to hyphen. > Hyphens are standard for some FITS usages for historical reasons, but > the recommendation now is to use underscore rather than hyphen if > possible. ... We understood the recommendation to use underscores rather than hyphens was primarily aimed at keyword names, rather than character string values. Since there are no hyphens in the keywords we quote, and since it would be almost impossible to 'enforce' a re-naming of most of the instruments which commonly use hyphens as part of their instrument/detector names, we consider the suggested strings are acceptable. It's worth reiterating that our primary goal in the memo was not to invent a beautiful multi-mission naming scheme, rather to simply formalize/list the common strings used by scientists. > On page 6, there is a note that all strings in subsequent sections are > to be considerered case sensitive. What is meant by this statement? ... We mean that the values of the strings should be considered case sensitive, again in an attempt to stick to the strings commonly used by scientists, or already in use within OGIP FITS files. In fact you will see that upper case is used throughout, with the exception of a handful of filter strings. > Having two meanings for the values of IPC or SSS for INSTRUME for > EINSTEIN can be confusing. The two non-recommended definitions should > not be allowed, unless they are there to grandfather in existing files. > If that is the reason, then the usages should be allowed but > deprecated -- designated as permissible for existing data sets but not > to be used in the future. ... We agree, but in many cases (not just for the SSS & IPC) this is the result of there being several similar instruments onboard, but with one instrument being used for the vast bulk of the scientific observations. We think our disapproval is expressed, but there are simply too many files out there already to do much more. > Since data sets have been produced for a number of the experiments > included, are the designated keyword values (names) for the different > missions, instruments, detectors, and filters consistent with current > usage by the experimental groups? In the same context, I note that > indexing is inconsistent from usage to usage, sometimes starting at 0, > sometimes at 1, sometimes at other values. Does this indexing reflect > that used in by the teams in referring to their instrument? Normally, > indexing should be consistent, beginning with 1, but the actual > designations given by the experimenters would override such a > principle. ... Yes, we hope that the usage is that of the experimental groups, and yes, this is exactly the reason for the inconsistent indexing. ... But have you ever tried to tell an experimental group how they should number their detectors !!! :-) Regards Ian M George Lorella Angelini HEASARC From server@athena.gsfc.nasa.gov Thu Mar 3 08:29:09 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["978" "Thu" " 3" "March" "1994" "08:26" "EST" "ffavata@estsa2.estec.esa.nl" "ffavata@estsa2.estec.esa.nl" "<9403031328.AA19429@estsa2.estec.esa.nl>" "22" "SAX LEGSPC FITS keywords" "^From:" nil nil "3" "1994030313:26:00" "SAX LEGSPC FITS keywords" nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03659; Thu, 3 Mar 94 08:29:08 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pcDPw-0001Iya; Thu, 3 Mar 94 08:26 EST Message-Id: <9403031328.AA19429@estsa2.estec.esa.nl> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: ffavata@estsa2.estec.esa.nl Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: SAX LEGSPC FITS keywords Date: Thu, 3 Mar 94 08:26 EST We are at work to define the structure and keywords for the FITS data files for the SAX Low Energy Scintillation Proportional Counter (LEGSPC) experiment. I have placed a draft document describing the proposed FITS keywords and file structure for the raw data in our anonymous ftp machine (astro.estec.esa.nl) in the file pub/SAX/leda_0002.ps. Being a 15 page document I felt it was more appropriate to make it available in this way rather than fill every mailbox on heafits with it! We would like our file formats to be compatible (insofar as possible) with the (proposed) FITS standards. I would be grateful to any of the FITS gurus out there for any comments they would want to make on the document. Fabio Favata -- Fabio Favata Astrophysics Division, European Space Agency P.O. Box 299, 2200 AG, Noordwijk, The Netherlands Tel. +31-1719-84665, Fax. +31-1719-84690 Internet: Fabio.Favata@astro.estec.esa.nl Noi fummo i Gattopardi, i Leoni... From server@athena.gsfc.nasa.gov Fri Mar 4 14:14:28 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1319" "Fri" " 4" "March" "1994" "14:14" "EST" "William Pence" "pence@tetra" nil "29" "Re: OGIP/93-013 - A list of standard strings for HE missions,instruments & filters." "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02401; Fri, 4 Mar 94 14:14:26 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pcfKO-0001Ita; Fri, 4 Mar 94 14:14 EST Message-Id: <9403041911.AA13009@tetra.Gsfc.NASA.Gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: pence@tetra (William Pence) Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OGIP/93-013 - A list of standard strings for HE missions,instruments & filters. Date: Fri, 4 Mar 94 14:14 EST > How logical or useful would an additional keyword be to specify the optic used > for the instrument? For our ALEXIS telescopes, the multilayer mirrors in each > telescope are just as important to specify as the filter in front of the > detector since the mirror specifies the bandpass. For other projects, perhaps > several flight type optics were prepared but only one used? In this case, I was > thinking of an "OPTIC" or "MIRROR" keyword. > > > -------------------------------------------------------------------------- > Jeffrey Bloch Office: (505) 665-2568 Rather than invent a new keyword, it may be possible and preferable to encode all the necessary information into the existing TELESCOPE, INSTRUME, DETNAM, and FILTER keywords. This would make the data files more similar to those from other missions. I don't know much about ALEXIS, but couldn't you, for instance, consider each mirror as a different telescope, so you would have ALEXIS1, ALEXIS2, etc. Or you could consider each mirror to be effectively a filter, since the mirror does filter the observed bandpass. In which case you could have FILTER1 = mirror name FILTER2 = name of the other 'filter' in front of the detector. Or another idea would be to give each mirror+detector combination a unique DETNAM value. -Bill Pence From server@athena.gsfc.nasa.gov Fri Mar 4 15:03:51 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["986" "Fri" " 4" "March" "1994" "15:03" "EST" "Allyn Tennant" "TENNANT@ssl.msfc.nasa.gov" nil "24" "Comment on spacecraft with multiple telescopes" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02473; Fri, 4 Mar 94 15:03:49 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pcg6B-0001UHa; Fri, 4 Mar 94 15:03 EST Message-Id: <940304140221.20402a9c@ssl.msfc.nasa.gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: Allyn Tennant Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Comment on spacecraft with multiple telescopes Date: Fri, 4 Mar 94 15:03 EST Since we are talking about spacecraft with multiple telescopes, I'd like to mention that I have always considered the use of the TELESCOP keyword to describe a spacecraft to be incorrect. In my mind a spacecraft should be called an OBSERVATORY (carefully shortened to something that FITS would accept). Then you could have multiple telescopes on a spacecraft, each with various filters and detectors. Since EXOSAT also had more than one telescope, any solution for ALEXIS should also work for EXOSAT. Here is an example based on EXOSAT: OBSERVAT= 'EXOSAT' TELESCOP= 'LE2' FILTER = 'Lexan 3000' INSTRUME= 'CMA1' Of course, it's far too late to change the meaning of the TELESCOP keyword, but maybe someone will have a clever idea. Just to make sure you all think about the problem, let me point out that I can imagine cases where you add data from different telesopes together. How should that information be kludged into FITS keywords? Would TELESCOP='1,3,5' work? Allyn From server@athena.gsfc.nasa.gov Fri Mar 4 15:36:29 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1798" "Fri" " 4" "March" "1994" "15:36" "EST" "Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)" "GEORGE@heagip.gsfc.nasa.gov" nil "38" "RE: Comment on spacecraft with multiple telescopes" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02533; Fri, 4 Mar 94 15:36:22 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pcgbe-0001Ioa; Fri, 4 Mar 94 15:36 EST Message-Id: <940304153401.20c01482@heagip.gsfc.nasa.gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: "Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)" Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: RE: Comment on spacecraft with multiple telescopes Date: Fri, 4 Mar 94 15:36 EST Allyn Tennant writes: > Since we are talking about spacecraft with multiple telescopes, I'd > like to mention that I have always considered the use of the TELESCOP > keyword to describe a spacecraft to be incorrect. In my mind a > spacecraft should be called an OBSERVATORY (carefully shortened to > something that FITS would accept). Then you could have multiple > telescopes on a spacecraft, each with various filters and detectors. ... I think a lot of us regret the way in which TELESCOP has been adopted to 'mean' spacecraft/mission, from both aesthetics & practical viewpoints. Concerning OBSERVAT,OBSERVTY,OBSVATRY {or whatever}, I've always thought SATELLIT was a pretty obvious keyword for storing the satellite name (?!) > Of course, it's far too late to change the meaning of the TELESCOP > keyword, but maybe someone will have a clever idea. ... Unfortunately, I'm afraid I also have to agree ... However, for interest, does anybody know how the VLA folks distinguish data from individual telescopes (ie dishes) ... especially when they are linked into VLBI. Assuming they make such a distinction, do they have TELESCOP = 'VLA-1' {or whatever} INSTRUME = 'RECEIVER-A' {or whatever} or what ?? Furthermore, what do these radio people put as the TELESCOP/INSTRUME keywords when they combine the data - from different VLA dishes, ?? - from different VLA, Westerbork, Jodrell ... etc ??! as I assume they do when they're constructed their final radio map. ... Unless I'm missing something, surely the 'problems' the radio people must have dealing with multiple-telescope observatories must be analogous with 'our' problems. You never know, they might have already a beautiful scheme... cheers Ian M George HEASARC From server@athena.gsfc.nasa.gov Fri Mar 4 16:43:19 1994 Status: RO X-VM-v5-Data: ([nil nil nil t nil nil nil nil nil] ["3759" "Fri" " 4" "March" "1994" "16:43" "EST" "William Pence" "pence@tetra" nil "90" "Re: SAX LEGSPC FITS keywords" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02631; Fri, 4 Mar 94 16:43:16 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pcheT-0001J7a; Fri, 4 Mar 94 16:43 EST Message-Id: <9403042142.AA14558@tetra.Gsfc.NASA.Gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: pence@tetra (William Pence) Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: SAX LEGSPC FITS keywords Date: Fri, 4 Mar 94 16:43 EST >We are at work to define the structure and keywords for the >FITS data files for the SAX Low Energy Scintillation Proportional >Counter (LEGSPC) experiment. I have placed a draft document describing >the proposed FITS keywords and file structure for the raw data in our >anonymous ftp machine (astro.estec.esa.nl) in the file >pub/SAX/leda_0002.ps.... > Fabio Favata I've had a quick look at this document and am pleased to see that SAX is attempting to adopt many of the same conventions previously used in the ROSAT and ASCA FITS files. This should make it much easier for multimission analysis software like Xspec to read the SAX data once it is available. Here are a few detailed comments. Some of these comments reflect that fact that the current ROSAT data format has changed somewhat from the format used as a model here. Primary Header keywords: ------------------------ The SEQ_PI keyword should more properly be called OBSERVER. There is already another OBSERVER keyword that should be changed to something else. Can you add a DATAMODE keyword? Is this what SETUPID is used for? I think RDF_VERS and RDF_DATE keywords are obsolete and can be deleted. The PROC_SYS and PROC_VER keywords can perhaps be replaced by the CREATOR keyword to give the name and version number of the program that generated the FITS file. Binary Table header keywords - general comments ---------------------------- In general, it would be good to repeat the important keywords from the primary array in each extension, such as TELESCOP and INSTRUME. The philosophy within the OGIP has been to make each extension relatively independent, so that software does not have to read the primary array header to get important pieces of information. Time related keywords --------------------- Defining the exact time of events within the data is of course very important, and several more keywords need to be provided to describe what the times in the TIME column really represent. It will probably take a couple iterations to get these keywords all right (or at least the way the OGIP timing experts here would prefer) but as a start, the following keywords should probably be included: MJDREF - the zeropoint of the spacecraft clock, in MJD days TSTART - the start time of the observation in spacecraft clock seconds TSTOP - the stop time of the observation TELAPSE - = TSTOP-TSTART ONTIME - the actual amount of time observed (e.g. sum of all the good time intervals) TIMEUNIT - time unit of the TSTART and TSTOP keywords (presumably = 's') TIMESYS - time system used There are a few other timing related keywords that we would probably like to see added, but I'll leave that to the timing experts to sort out, once you know exactly what your time values represent. Misc comments ------------- It would save space, and look neater, to delete all the TUNITn = 'None' keywords. They don't serve any real purpose. The standard unit for seconds is 's' not 'seconds'. It would save space, and clarify the meaning of the column names to put all the comments about the various detector flags, etc, into the comment field of the appropriate TTYPEn keyword. It would be useful for software to provide all the conversion scale factors as keywords, not just as comments. One could even give these as TSCALn keywords so that FITS readers would automatically read the scaled physical value, and not just the telemetry value, but this can be confusing if users don't know the data is being scaled by the FITS reader. In the raw events table, is there a reason for not defining all the columns except TIME as 'B' (byte) instead of 'I' (I*2)? This would cut the size of the table nearly in half. What do the RAW_X and RAW_Y keywords mean? From server@athena.gsfc.nasa.gov Sat Mar 5 11:39:02 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1106" "Sat" " 5" "March" "1994" "11:39" "EST" "ffavata@estsa2.estec.esa.nl" "ffavata@estsa2.estec.esa.nl" nil "26" "Re: SAX LEGSPC FITS keywords " "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA05120; Sat, 5 Mar 94 11:39:01 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pczNV-0001gda; Sat, 5 Mar 94 11:39 EST Message-Id: <9403051637.AA04179@estsa2.estec.esa.nl> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: ffavata@estsa2.estec.esa.nl Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: SAX LEGSPC FITS keywords Date: Sat, 5 Mar 94 11:39 EST William Pence wrote: .I've had a quick look at this document and am pleased to see that .SAX is attempting to adopt many of the same conventions previously .used in the ROSAT and ASCA FITS files. This should make it much .easier for multimission analysis software like Xspec to read the .SAX data once it is available. Here are a few detailed comments. Just to avoid any misunderstanding, the FITS keywords I've circulated are planned be used, for the moment, for the in-house processing of SAX LEGSPC data by the ESA/ESTEC team (who built the instrument). What the other SAX instrument groups will do in terms of data processing and data formats, and in what format will GOs receive their SAX data are at the moment still subject to discussion. Thanks for the comments, I will give them a thought and answer to your questions. Fabio Favata -- Fabio Favata Astrophysics Division, European Space Agency P.O. Box 299, 2200 AG, Noordwijk, The Netherlands Tel. +31-1719-84665, Fax. +31-1719-84690 Internet: Fabio.Favata@astro.estec.esa.nl Noi fummo i Gattopardi, i Leoni... From server@athena.gsfc.nasa.gov Tue Mar 8 09:33:54 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["772" "Tue" " 8" "March" "1994" "09:33" "EST" "ffavata@estsa2.estec.esa.nl" "ffavata@estsa2.estec.esa.nl" nil "23" "Re: SAX LEGSPC FITS keywords " "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09527; Tue, 8 Mar 94 09:33:53 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pe2qo-0001dta; Tue, 8 Mar 94 09:33 EST Message-Id: <9403081432.AA01151@estsa2.estec.esa.nl> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: ffavata@estsa2.estec.esa.nl Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: SAX LEGSPC FITS keywords Date: Tue, 8 Mar 94 09:33 EST following Bill Pence comments, here are some new questions. I hope this discussion is of general enough interest. Should it be moved to "private e-mail" please let me know. .Can you add a DATAMODE keyword? Is this what SETUPID is used for? I don't see any problem. We got DATAMODE from the ROSAT FITS. Does it mean that SETUPID is obsolete? .What do the RAW_X and RAW_Y keywords mean? Raw detector coordinates, that is, not corrected in any way. Again from ROSAT FITS files. Are they obsolete, too? fabio -- Fabio Favata Astrophysics Division, European Space Agency P.O. Box 299, 2200 AG, Noordwijk, The Netherlands Tel. +31-1719-84665, Fax. +31-1719-84690 Internet: Fabio.Favata@astro.estec.esa.nl Noi fummo i Gattopardi, i Leoni... From server@athena.gsfc.nasa.gov Tue Mar 8 09:45:54 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1790" "Tue" " 8" "March" "1994" "09:45" "EST" "Mike Corcoran" "corcoran@barnegat.gsfc.nasa.gov" nil "53" "Re: SAX LEGSPC FITS keywords" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09534; Tue, 8 Mar 94 09:45:52 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pe32Q-0001cha; Tue, 8 Mar 94 09:45 EST Message-Id: <9403081447.AA15917@barnegat.lheanet> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: corcoran@barnegat.gsfc.nasa.gov (Mike Corcoran) Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: SAX LEGSPC FITS keywords Date: Tue, 8 Mar 94 09:45 EST > From heafits@athena.gsfc.nasa.gov Tue Mar 8 09:38:01 1994 > Date: Tue, 8 Mar 94 09:34 EST > Sender: server@athena.gsfc.nasa.gov (listserv server) > Reply-To: heafits@athena.gsfc.nasa.gov > Originator: heafits@athena.gsfc.nasa.gov > Sender: heafits@athena.gsfc.nasa.gov > From: ffavata@estsa2.estec.esa.nl > To: corcoran@ndadsb.gsfc.nasa.gov > Subject: Re: SAX LEGSPC FITS keywords > X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas > Content-Length: 772 > > following Bill Pence comments, here are some new questions. I hope > this discussion is of general enough interest. Should it be moved to > "private e-mail" please let me know. > > .Can you add a DATAMODE keyword? Is this what SETUPID is used for? > > I don't see any problem. We got DATAMODE from the ROSAT FITS. > Does it mean that SETUPID is obsolete? > > .What do the RAW_X and RAW_Y keywords mean? > > Raw detector coordinates, that is, not corrected in any way. > Again from ROSAT FITS files. Are they obsolete, too? > > fabio > > -- > Fabio Favata > Astrophysics Division, European Space Agency > P.O. Box 299, 2200 AG, Noordwijk, The Netherlands > Tel. +31-1719-84665, Fax. +31-1719-84690 > Internet: Fabio.Favata@astro.estec.esa.nl > Noi fummo i Gattopardi, i Leoni... > Actually, in the RDF BASIC file for the ROSAT PSPC, we have the following 2 keywords: RAWX = F / RAW X coordinates not supplied RAWY = F / RAW Y coordinates not supplied As to SETUPID, that was a keyword needed for processing the WFC data and is not really used for the X-ray data. Mike Corcoran HEASARC Goddard Space Flight Center Greenbelt, MD 20771 corcoran@barnegat.gsfc.nasa.gov HEASRC::CORCORAN From server@athena.gsfc.nasa.gov Tue Mar 8 11:18:47 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2586" "Tue" " 8" "March" "1994" "11:18" "EST" "BARRY M. SCHLESINGER" "BSCHLESINGER@NSSDCA.GSFC.NASA.GOV" nil "55" "Re: SAX LEGSPC FITS keywords" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09675; Tue, 8 Mar 94 11:18:43 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pe4UK-0001NGa; Tue, 8 Mar 94 11:18 EST Message-Id: <940308111723.2521065c@NSSDCA.GSFC.NASA.GOV> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: "BARRY M. SCHLESINGER" Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: SAX LEGSPC FITS keywords Date: Tue, 8 Mar 94 11:18 EST I would just like to note my particular concurrence with certain of the points made by Bill Pence. Failure to mention others doesn't mean disagreement; it just means that I see them as issues of specific dataset design rather than as general FITS issues. > It would save space, and clarify the meaning of the column names > to put all the comments about the various detector flags, etc, into the > comment field of the appropriate TTYPEn keyword. In point of fact, the current comments for TTYPEn and TUNITn aren't very useful. All they do is repeat the definition for the keyword. This type of redundant comment should be replaced with something meaningful. When comments such as "/physical units of column 4" appeared in the binary tables proposal, they were serving the purpose of telling what the keyword is supposed to mean as part of the process of describing the format. But in an actual data table, they don't provide any information and take up space that could be better used, for example, as TTYPE37 = 'Norm_InterrHandler' / Normal Input Interrupt Handler I understand that certain FITS writers put these generic "label for field n" comments in automatically. They should be regarded as fill values, to be replaced when there is any real information, not as reasonable comments for a data file. > It would save space, and look neater, to delete all the TUNITn = 'None' > keywords. They don't serve any real purpose. > It would be useful for software to provide all the conversion scale > factors as keywords, not just as comments. One could even give these > as TSCALn keywords so that FITS readers would automatically read the > scaled physical value, and not just the telemetry value, but this > can be confusing if users don't know the data is being scaled by the > FITS reader. In fact, this case is no different from the primary data array or an ASCII table. Users should know how their reader works, in particular whether they retrieve raw values from the file or automatically scale to get physical values. If the TSCALn were used, then the TUNITn would be the appropriate way of giving the real physical units. For example TTYPE31 = 'Cell Pressure' TUNIT31 = 'mbar' TZERO31 = 0.0 TSCAL31 = 4.7 The telemetry values would still be available in the file. What are most users expected to want, the physical values or the telemetry values? If they're going to want physical values, scaling is the natural way to provide them. Barry Schlesinger NOST FITS Support Office From server@athena.gsfc.nasa.gov Thu Mar 10 21:37:08 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1606" "Thu" "10" "March" "1994" "21:37" "EST" "Maureen Conroy" "mo@cfa234.harvard.edu" nil "51" "Re: SAX LEGSPC FITS keywords" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA18225; Thu, 10 Mar 94 21:37:06 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pex5x-0002VZa; Thu, 10 Mar 94 21:37 EST Message-Id: <9403102310.AA12212@cfa234.harvard.edu> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: mo@cfa234.harvard.edu (Maureen Conroy) Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: SAX LEGSPC FITS keywords Date: Thu, 10 Mar 94 21:37 EST ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 1 ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: comments.wu X-Sun-Content-Lines: 38 Fabio, I have reviewed your file templates briefly as well, and will add a few comments. I think you have a fairly old version of ROSAT/RDF data. There is a more recent version in the PROS/FTP area, but you may need to get the MOST recent version from HEASRC. (sao-ftp.harvard.edu pub/pros_2_3/rosfits/* ) 1) An issue for PROS compatibility are the new keyword conventions: TLMINnn TLMAXnn (or previously TALENnn) which gives the 'legal' minimum and maximum value for that data column. PROS uses these values to convert the EVENT list into an IMAGE array. (They can be entered by hand, but might as well include them in the file.) 2) ROSAT has moved the OBIB1....OBIE4 information to its own EXTENSION EXTNAME OBITABLE you can see this is the latest samples. These enumerated keywords quickly become unwieldly when NUM_OBIS gets large. 3) The RAW_X and RAW_Y keywords are special artifacts from ROSAT processing and you can drop them. They were created because of the inconsistency between ROSAT/HRI and ROSAT/PSPC data sets where HRI INCLUDES RAWX/RAWY data columns and PSPC does NOT. 4) I concur with previous comments concerning 'OBSERVER' - it needs to be a string. The important header keywords should appear in each extension header. Extensions and primary arrays are often treated as distinct files. -- Maureen Conroy SAO From server@athena.gsfc.nasa.gov Tue Mar 15 14:06:43 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1697" "Tue" "15" "March" "1994" "14:05" "EST" "Eric C. Olson" "ericco@cea.Berkeley.EDU" nil "34" "schedules and ephemeris in FITS" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13004; Tue, 15 Mar 94 14:06:38 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pgeRC-0003LZa; Tue, 15 Mar 94 14:05 EST Message-Id: <199403151903.LAA13209@id.cea.berkeley.edu> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: "Eric C. Olson" Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: schedules and ephemeris in FITS Date: Tue, 15 Mar 94 14:05 EST Hi, I'm interested in improving communications between EUVE Guest Investigators and CEA on spacecraft scheduling issues. In particular, I'm interested in finding out about FITS binary table formats that have been defined (or used) to transmit data about ephemeris. Also, has anyone worked on representing scheduling information -- ie, when a target is visible, when star trackers are operable, etc. For the ephemeris, I'm looking for a relative simple file containing say 3 columns: time, ra, dec (including appropriate header information about coordinate systems, units, etc). It would be nice to have a 4th column with the radial distance. For example, in scheduling Moon observations, EUVE must account for the relative position of the Moon to the spacecraft. Has anybody come across this type of FITS table? I think that the scheduling information is more complex. The basic information in our scheduling system is "run-length encode" -- intervals of time are suitable (or not). In practice, however, these time intervals are actually all the same size. Additionally, the suitability of the observation during the time interval has a metric that runs from 0 (not suitable) to 1 (most suitable). I'm not sure how common this system is for other spacecraft scheduling systems. For all the suitable time intervals, we would like to maintain a list of all the roll angles that are valid to use for the duration of the time interval. Additionally, for all non-suitable time intervals, we would like to know which pointing constraint was violated. I'd appreciate any information on either of these issues, or other systems that are related to these problems. Thanks in advance, Eric From server@athena.gsfc.nasa.gov Tue Mar 15 17:09:55 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5797" "Tue" "15" "March" "1994" "17:08" "EST" "Mike Corcoran" "corcoran@barnegat.gsfc.nasa.gov" nil "120" "Re: schedules and ephemeris in FITS" "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA13524; Tue, 15 Mar 94 17:09:47 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pghIJ-0003NMa; Tue, 15 Mar 94 17:08 EST Message-Id: <9403152210.AA21141@barnegat.lheanet> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: corcoran@barnegat.gsfc.nasa.gov (Mike Corcoran) Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: schedules and ephemeris in FITS Date: Tue, 15 Mar 94 17:08 EST > From heafits@athena.gsfc.nasa.gov Tue Mar 15 14:11:05 1994 > Date: Tue, 15 Mar 94 14:06 EST > Sender: server@athena.gsfc.nasa.gov (listserv server) > Reply-To: heafits@athena.gsfc.nasa.gov > Originator: heafits@athena.gsfc.nasa.gov > Sender: heafits@athena.gsfc.nasa.gov > From: "Eric C. Olson" > To: corcoran@ndadsb.gsfc.nasa.gov > Subject: schedules and ephemeris in FITS > X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas > Content-Length: 1697 > > Hi, > > I'm interested in improving communications between EUVE Guest > Investigators and CEA on spacecraft scheduling issues. In particular, > I'm interested in finding out about FITS binary table formats that > have been defined (or used) to transmit data about ephemeris. Also, > has anyone worked on representing scheduling information -- ie, when a > target is visible, when star trackers are operable, etc. > > For the ephemeris, I'm looking for a relative simple file containing > say 3 columns: time, ra, dec (including appropriate header information > about coordinate systems, units, etc). It would be nice to have a 4th > column with the radial distance. For example, in scheduling Moon > observations, EUVE must account for the relative position of the Moon > to the spacecraft. Has anybody come across this type of FITS table? > Haven't really thought to much about a FITS file for scheduling info, but ROSAT includes most of the emphemeris info you want in a trend data file. The format of the file is given in the following header (the meaning of the columns are explained in the comment fields). (I've only included the fields which seem like they might be relevant to you). I don't know if you are aware but the Office of Guest Investigator Programs at GSFC has a working group to deal with format issues for FITS files used for high energy data. (you probably have seen our posts here from time to time). Some of the prior recommendations of this working group can be downloaded anonyomously from legacy.gsfc.nasa.gov in the directory documents/fits/ofwg_recomm. Hope this is of some use. Mike Corcoran HEASARC Goddard Space Flight Center Greenbelt, MD 20771 corcoran@barnegat.gsfc.nasa.gov HEASRC::CORCORAN XTENSION= 'BINTABLE' / BITPIX = 8 / NAXIS = 2 /Binary table NAXIS1 = 126 /Number of bytes per row NAXIS2 = 1340 /Number of rows PCOUNT = 0 /Random parameter count GCOUNT = 1 /Group count TFIELDS = 30 /Number of columns EXTNAME = 'Trend ' /Contains trend data on 60 sec sample interval TFORM1 = '1D ' /Real*8 (double precision) TTYPE1 = 'TIME ' /Corrected spacecraft time of measurement TUNIT1 = 's ' /Units of column 1 TFORM2 = '1D ' /Real*8 (double precision) TTYPE2 = 'second ' /UT sec since beginning of DATE-OBS TUNIT2 = 's ' /Units of column 2 TFORM3 = '1D ' /Real*8 (double precision) TTYPE3 = 'MJD ' /Modified Julian Date (JD-2400000.5) TUNIT3 = 'd ' /Units of column 3 TFORM4 = '1E ' /Real*4 (floating point) TTYPE4 = 'RASAT ' /Satellite RA TUNIT4 = 'deg ' /Units of column 4 TFORM5 = '1E ' /Real*4 (floating point) TTYPE5 = 'DECSAT ' /Satellite Dec TUNIT5 = 'deg ' /Units of column 5 TFORM6 = '1E ' /Real*4 (floating point) TTYPE6 = 'ALT_SAT ' /Satellite Altitude TUNIT6 = 'km ' /Units of column 6 TFORM7 = '1E ' /Real*4 (floating point) TTYPE7 = 'RASUN ' /RA of Sun TUNIT7 = 'deg ' /Units of column 9 TFORM8 = '1E ' /Real*4 (floating point) TTYPE8 = 'DECSUN ' /Dec of Sun TUNIT8 = 'deg ' /Units of column 10 TFORM9 = '1E ' /Real*4 (floating point) TTYPE9 = 'RAMOON ' /RA of Moon TUNIT9 = 'deg ' /Units of column 11 TFORM10 = '1E ' /Real*4 (floating point) TTYPE10 = 'DECMOON ' /Dec of Moon TUNIT10 = 'deg ' /Units of column 12 TFORM11 = '1E ' /Real*4 (floating point) TTYPE11 = 'RAB ' /RA of local B-field TUNIT11 = 'deg ' /Units of column 13 TFORM12 = '1E ' /Real*4 (floating point) TTYPE12 = 'DECB ' /Dec of local B-field TUNIT12 = 'deg ' /Units of column 14 TFORM13 = '1E ' /Real*4 (floating point) TTYPE13 = 'LVAL ' /MacIlwain L parameter TUNIT13 = ' ' /Units of column 15 TFORM14 = '1E ' /Real*4 (floating point) TTYPE14 = 'ZENANG ' /Orbit position-look direction (zenith) angle TUNIT14 = 'deg ' /Units of column 16 TFORM15 = '1E ' /Real*4 (floating point) TTYPE15 = 'SESANG ' /Sun-Earth-Satellite angle TUNIT15 = 'deg ' /Units of column 17 TFORM16 = '1E ' /Real*4 (floating point) TTYPE16 = 'VELANG ' /Velocity vector-look direction (ram) angle TUNIT16 = 'deg ' /Units of column 18 TFORM17 = '1E ' /Real*4 (floating point) TTYPE17 = 'MAGANG ' /Magnetic field-look direction angle TUNIT17 = 'deg ' /Units of column 19 TFORM18 = '1E ' /Real*4 (floating point) TTYPE18 = 'SUNLOOK ' /Look direction-Sun angle TUNIT18 = 'deg ' /Units of column 20 TFORM19 = '1E ' /Real*4 (floating point) TTYPE19 = 'MOONLOOK' /Look direction-Moon angle TUNIT19 = 'deg ' /Units of column 21 END From server@athena.gsfc.nasa.gov Mon Mar 21 12:22:40 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["689" "Mon" "21" "March" "1994" "12:21" "EST" "ffavata@estsa2.estec.esa.nl" "ffavata@estsa2.estec.esa.nl" nil "18" "Re: SAX LEGSPC FITS keywords " "^From:" nil nil "3" nil nil nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA26134; Mon, 21 Mar 94 12:22:38 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pinfd-0003JVa; Mon, 21 Mar 94 12:21 EST Message-Id: <9403211720.AA03141@estsa2.estec.esa.nl> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: ffavata@estsa2.estec.esa.nl Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: SAX LEGSPC FITS keywords Date: Mon, 21 Mar 94 12:21 EST Thanx to all who provided lots of comments. I would just like to ask a couple of additional question, before I actually update our formats. What is the current status, in terms of cross-compatibility, of the latest FITS format for ROSAT data and for ASCA data? Can they both (the ROSAT format Maureen has pointed me to and the ASCA formats available from HEASARC) be assumed to be "final", or are there upcoming changes? fabio -- Fabio Favata Astrophysics Division, European Space Agency P.O. Box 299, 2200 AG, Noordwijk, The Netherlands Tel. +31-1719-84665, Fax. +31-1719-84690 Internet: Fabio.Favata@astro.estec.esa.nl Noi fummo i Gattopardi, i Leoni... From server@athena.gsfc.nasa.gov Mon Feb 28 16:00:11 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["538" "Mon" "28" "February" "1994" "15:57" "EST" "Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)" "GEORGE@heagip.gsfc.nasa.gov" "<940228155826.20c0133d@heagip.gsfc.nasa.gov>" "16" "The OFWG joins the WWW" "^From:" nil nil "2" "1994022820:57:00" "The OFWG joins the WWW" nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA25183; Mon, 28 Feb 94 16:00:07 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pbF1c-0001f7a; Mon, 28 Feb 94 15:57 EST Message-Id: <940228155826.20c0133d@heagip.gsfc.nasa.gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: "Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)" Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: The OFWG joins the WWW Date: Mon, 28 Feb 94 15:57 EST THE OGIP FITS WORKING GROUP ON THE WWW -------------------------------------- For those of you interested, the general information, minutes, recommendations etc of OFWG are now also available on the World-Wide Web via the URL: http://heasarc.gsfc.nasa.gov/0/docs/heasarc/ofwg/ofwg_intro.html As before, the same information is also available via the anonymous ftp account on legacy.gsfc.nasa.gov within the documents/fits directory tree. Any comments/problems to george@lheavx.gsfc.nasa.gov. Ian M George HEASARC From server@athena.gsfc.nasa.gov Mon Feb 28 16:19:07 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["88" "Mon" "28" "February" "1994" "16:16" "EST" "Nick White, HEASARC/ASCA-GOF NASA/GSFC" "WHITE@lheavx.gsfc.nasa.gov" "<940228161526.2180565a@lheavx.gsfc.nasa.gov>" "3" "RE: The OFWG joins the WWW" "^From:" nil nil "2" "1994022821:16:00" "The OFWG joins the WWW" nil nil] nil) Return-Path: Received: from athena.gsfc.nasa.gov by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA25250; Mon, 28 Feb 94 16:19:05 EST Received: by athena.gsfc.nasa.gov (Smail3.1.28.1 #4) id m0pbFK0-0001hTa; Mon, 28 Feb 94 16:16 EST Message-Id: <940228161526.2180565a@lheavx.gsfc.nasa.gov> Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@athena.gsfc.nasa.gov Originator: heafits@athena.gsfc.nasa.gov Precedence: bulk X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas From: "Nick White, HEASARC/ASCA-GOF NASA/GSFC" Sender: server@athena.gsfc.nasa.gov (listserv server) Sender: heafits@athena.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: RE: The OFWG joins the WWW Date: Mon, 28 Feb 94 16:16 EST Has this a link from the heasarc home page. Probably we should have a FITS bullet....