[fitswcs] [fitsbits] Draft WCS Paper V: Time
Lucio Chiappetti
lucio at lambrate.inaf.it
Tue Apr 7 13:05:14 EDT 2009
On Thu, 2 Apr 2009, Arnold Rots wrote:
> FITS WCS Paper V: Time
> Draft is available for comment
Here it is a somewhat long though perhaps marginal list of comments.
Thanks to all the authors for the work done !
----------------------------------------------------------------------
- I declare my incompetence on the following sections (despite they are
probably among those with deepest science content) :
most of details in 3.3.1 and almost all of 3.3.2, 3.3.4, 3.3.5, 4.2.1,
4.2.2, 4.4
- I declare my complete agreement with the following sections :
note at end of 3.2, 3.5.5 specially about TIMEPIXR, 4.2.3, 4.3.1
......................................................................
... then comments follow in section order
......................................................................
- sect. 2 first item list (pag. 1)
"in table vector columns" sounds a bit cryptic
- sect. 2 third item list (acrosspag. 1/2)
1) the reference to "pulsar pulse profile" may refer ALSO to folded
light curves of variable stars (I am thinking of cataclysmic
variables and X-ray binaries, but any binary will do)
2) there is a "promise" here to deal with folded light curves which is
not "mantained" in the rest of the paper.
In the past I found it was often convenient for my s/w to deal with
folded light curves in the same way as for standard light curves, it
is just a matter of replacing the time axis with a phase axis.
I'd expected to find conventions about PHASE as an axis, and perhaps
about a way to describe ephemeris in the header.
- sect. 3.1 "times ... will all be considered relative".
Does this mean that time bins are all elapsed times from either DATEREF,
MJDREF, JDREF ? Am I correct in interpreting that e.g. in the example
given in Tab.5 times in column 1 are elapsed times from MJDREF 50814.0
(which is presumably the start of the day containing the first bin of
the observation) ? If so this is very similar to formats I've been using
myself, and I fully agree with this.
But then I fail to see the need for high precision beyond REAL*8 (see
comments further below). Actually one of the main purpose my own rate
files used "elapsed time since since day of observation start" was to
preserve precision allowing not to exceed a REAL*8 range.
- sect. 3.1 need for 128-bit data type
I will question the need for this further below. I just wonder how
standard such a type is as far as software and compiler support. I see
e.g. that some Fortran compilers do support a REAL*16, I haven't checked
other languages. Is it also an IEEE standard ?
- sect. 3.1.1 (about datetime type)
I do agree with the need for a standard to express a date and time as a
string, and see it essentially confined to header keywords.
It is true that it could be stored in columns of ASCII tables, but this
seems a waste to me, and I'm inclined to consider ASCII tables, if not
deprecated, as confined to things like catalogues.
It is true that formally it could be used in string columns of binary
tables, but this is not only a waste of space w.r.t. more efficient
formats, but also a waste as it will require to decode the ISO string
into some binary time for each bin.
Is this what you mean when you say "in 'pixel list' mode" ? Still I
consider datetime strings are primarily used in keywords and only
secondarily, if at all, elsewhere (I agree they cannot be used in CRVAL)
So I fail to see the need for a data type T (since, unfortunately in my
opinion, but true as a matter of fact, FITS does NOT define EXPLICIT
types for header keywords ... if it were, I'd fully support an internal
standard binary encoding for times, and a default standard way to
display it, sort of like mysql does). And I fail to understand the
sentence about "premature to prescribed a full format specifier ...
similar to ... the A format"). ISO times are strings handled WITH an A
format, full stop.
Unless you are thinking just of TDISPn formats (in fact I had a plotting
program which accepted for axis labels an H format, H2 printed hours as
0-24, H4 printed as 00:00 or 23:59 (or even 34:15), H6 printed 00:00:00
or 23:59:59 etc.). I.e. of a way specifying how many characters of the
*standard* ISO form will be shown)
- sect. 3.1.1 gregorian calendar
1) about reference to the papal bull "Inter gravissimas", I'm not quite
sure it is inline with the current standard of A&A citations nor with
the one historians may use.
I mix a bit of humour with real facts now.
In the references you quote a "Gregorius, Pope" and in the text a
"Pope Gregorius 1582" which is like quoting "Rots, PhD" and "Phd Rots
2009". Also there were at least 16 popes of such name, and this one
is the 13th, and one should not mix English and Latin. So (seriously)
either one quotes (presumably) "Gregorius P.P. XIII" (this should be
how modern popes sign) or "Pope Gregory XIII" unless <GRIN MODE ON>
one wants to quote it as "Boncompagni, U. 1582" ... might sound a bit
anti-clerical (*) <GRIN MODE OFF> [although I've seen a literary work
of pope Pius II quoted as Piccolomini, E.S.]
Also the reference to the Vatican is anachronistic. Vatican as a
state exists only since 1929, when the Concordato (agreement) between
the Catholic Church and the fascist government of Italy was signed.
In 1582 the state was probably the "State of the Church" or the
"Pontificial State" or the "Patrimonium Petri", I don't know if
an official name was in use.
I'm not even sure that popes in 1582 resided in the Vatican or
elsewhere in Rome (the cathedral church is S.Giovanni in Laterano,
not S.Peter ; and the last popes before Pius IX inclusive resided in
the Quirinal - where later the kings of Italy, and now the Presidents
of the Republic reside). If you want to quote the "organization"
publishing the bull (as Her Majesty's Stationery Office publishes the
Astronomical Almanac), I do not know, probably it was the Apostolic
Chancery or something similar.
I suggest that if one wants to make a serious reference one either
asks our colleagues of the Specola Vaticana (Vatican Observatory,
based at Steward), or an historian of astronomy (a person like Owen
Gingerich will surely know).
The alternative is to forget (pity!) these nices historical
citations.
2) the fact that the ISO format can express dates between years 0000 and
9999 is accidental to the fact 4 digits are used (the Y10K bug, or
ISO is not confident to last that long, unlike ancient Mayas :-)). I
would definitely exclude the usage of ISO format for dates before
october 1582. It is the first time I hear of a gregorian proleptic
calendar, while the JD system itself starts at 1 Jan 4713 B.C.
*JULIAN proleptic calendar*, according to the Astronomical Almanac
(pag.L4 in the 1993 issue accidentally present on my shelf).
Or leave it at discretion of the few archeo-astronomers which would
ever write a FITS file with some ancient phenomena.
<GRIN MODE ON> I never thought to extend the rule "Once FITS forever
FITS" to the past <GRIN MODE OFF>
- sect. 3.1.1 misc
where does the difference UTC 00-60 vs all other 00-59 come from ?
- sect.3.1.3 about higher precision
The reference to sect. 4.2.4 of the FITS standard seems to me mostly
irrelevant, while I'd liked (here *and there*) a recommendation not to
use "wasteful" data types (I've seen too many photon images where pixel
contains a handful of photons, and stored as double precision).
However I appreciate the fact that timing (and angular coordinates) do
often require a higher precision (REAL*8 being usually required instead
of REAL*4 e.g. for angles, and INTEGER*4, and not old INTEGER*2 in the
old times, for integer number of JDs). The need for higher precision
comes from the need of : (a) high time resolution ; (b) long time
baselines. And may become critical if both (a) and (b) apply
*simultaneously*. Which I'm not convinced it is sufficiently frequent
(but I do NOT do millisecond pulsars). In most cases I found that a
REAL*8 (eventually with a specified weight (TIMEDEL ?) on the LSB,
expressed as elapsed time from an offset (I called it offset, but it is
sort of DATEREF, the beginning of the day of the observation start time
in "Unix 1970" seconds).
An other issue to be considered, is that spacecraft clocks are usually
binary clocks with the resolution of some 2**-n on the LSB, so that they
can be kept as binary sequence of some "strange" number of bits (40 ?
48 ?) ... anyhow well contained into a K integer (64-bit) ... and giving
full precision (as full as that particular clock allows !)
- sect. 3.1.4 doublet vectors
I do not quite like this possibility, or at least the fact to
incorporate it in the standard (remember that a WCS paper is likely to
be "incorporated by reference" in the FITS standard, as it occurred to
the other ones).
It might well be a possible "mission dependent" convention, supported by
current standard (provided the particular software using it is aware of
it) and which therefore cannot be invalidated. but then it should be
clearly marked. I presume the example in Tab. 5 with TFORM1='2D' is of
this type. But a vector column of depth 2 can be anything (value and
error, values in two bands etc.) unless some header kwd documents it
adheres to a specific convention.
But there should be some header kwd telling this particular convention
is in effect.
And it should be registered in the IAU FWG registry !
- sect. 3.1.5 higher precision S format
Although not convinced about its need, for analogy with the K and Q
formats, I could stand (obtorto collo) to a 64-bit REAL*16 at some
conditions :
- widespread and univocal support by compilers
- is it an IEEE standard (like E and D are) ?
However I do not understand the reference to L and Q types (did you mean
K and Q ?).
Also I do not understand the reference to ASCII tables in the title, and
to its usage in timestamps (I assume that by timestamps you mean an
*header kwd* like DATE or DATE-OBS). An S descriptor is a binary
descriptor for binary tables. How can it apply to ASCII tables, or to
(typeless by definition) header kwds) ?
- sect. 3.2
1) the "are found" in the first line is presumably a "can be found".
Tou are defining reserved kwd names, not specifying mandatory kwds,
aren't you (should we use "shall" and "should" according to RFC2119
as in the main FITS standard ?
2) somw kwds are in the main standard (DATE DATE-OBS), some other in
earlier WCS papers. The rest is new.
3) I do not understand how "higher precision floating" may refer to an
HEADER KWD (see comment above).
- table 1
The order of the possible TIMESYS values is not the same as in the
Appendix B of the standard (which will have to be suppressed once WCS V
is incorporated). Either alphabetic or importance order please !
Also the list is not the same as in App. B. There are no UT and AT, but
there is a new IAT (which however is deprecated).
What is the sense of listing TDT and IAT and deprecate them ? One cannot
deprecate what was not in the standard and there is no sense in
instituting a deprecated standard !
Also GPS was deprecated in App. B and now it is no longer. Correct ?
- table 2
some of these 8-char code do occur already in the standard in 8.7
(spectral reference systems). Some other codes which are in 8.7 are not
reported here (why ? are they not applicable ? I am not a radial
velocity expert)
Somebody criticised the 8 char codes. Could we relax the prescription
allowing longer legible names (e.g. GEOCENTEr), providing that only the
first 8 char are significant (pad with blanks the shorter planet names
?)
- sect 3.3.2
in the description of TREFPOS make *explicit* reference to tab. 2
- sect 3.3.3
1) OBSORBIT : who guarantees that a given URL be long-lived ? Should we
institute an IAU repository ?
2) include in footnote an URL for OGIP conventions (or have them linked
in the IAU FWG convention registry)
- sect. 3.3.4
last note on OGIP RA_NOM DEC_NOM convention deserves a reference and/or
inclusion in the IAU FWG convention registry
- sect 3.4
The reference should be section 4.3 and tab. 4.2 in the FITS standard,
correct ?
I note "cy" (century, i.e. hetto-year, not centi-year :-)) is not in
table 4.2. Is it worth including ?
Does 3.4 allow the usage of multipliers in sect. 4.3 of the standard ?
In particular both 10**n and 2**n multipliers ? 2**n multipliers should
allow to work with spacecraft clocks unchanged.
- sect. 3.5.1
usage of offset unclear
- sect. 3.5.4
resolution of timestamps a single double. Why double ? to timestamp a
creation time an Unix 1970 (32-bit) time suffices (or at least it will
until 2038)
Or am I not understanding what you mean by time stamps ? I am thinking
of file creation or modification times, or record time stamps (as e.g.
present in mysql with TIMESTAMP datatype).
Are you talking instead of photon time tags ?
- sect. 3.6
why include (only) the Chandra examples ? Either no examples, or more
than one.
I do not like the truncated name XPOSURE (if not a typo)
In general this section seems excessive, it contains the reference to a
plethora of instrument-specific or context-specific conventions. Also
the interpretation of most of these kwds is of administrative nature,
and in general I do not like the fact that presence or absence of kwds
which can be irrelevant in some cases forbid the application of certain
s/w modules (or require workarounds because of administrative
inconsistencies).
With the exception of a possible standard regulation of GTIs (exposure
profiles) I'd remove most of the section.
Instead of XPOSURE one could have EXPOKWD with a string value, pointing
to the name of the keyword (file dependent according to pre-existing
conventions) containing the "main" exposure.
- sect. 4.3
a light curve example could be useful along with an event file example
as now
- sect. 4.4
why regulate by standard a feature which is deprecated outside of a
particular community usage ?
- sect. 5
1) line 1 : typo "salient"
2) You "anticipate" the inclusion in the standard of the T and S types
(see above for substantial comments). As a procedural point, how can
a paper which will be "incorporated in the standard" "anticipate"
something ?
3) ah, you quote here an IEEE standard. Then appendix E of the FITS
standard should be updated.
4) about the 2D convention see comment below (it belongs to the
convention registry, and shall be flagged in the header)
- references
see above about the papal bull
also is it necessary to quote Herschel, or cannot we find the same thing
in some recent issue of the Astronomical Almanac ?
There are some URL references. Please verity A&A style (give URL in
footnotes, or quote with a name,year and/or abbreviation (e.g. first
time "IAU FWG 2008, hereafter 'the FITS standard'")
- general
I repeat the comment at beginning that there is nothing about folded
light curves containing phase instead of time.
----
(*) curiosity note,
Nobel Laureate poet G.Carducci, which had anti-clerical orientations,
wrote a poem (called "Il canto dell'amore", i.e. "the love song") which
starts recalling how pope Paul III (in 1500) built a fortress (Rocca
Paolina) in Perugia to menace of bombing the inhabitants of Perugia. The
poem ends invitubf to a toast Pius IX (Giovanni Maria Mastai Ferretti),
the pope who secluded himself in the Vatican when Rome was annexed to the
Kingdom of Italy (1870) : "Cittadino Mastai, bevi un bicchier !" (Citizen
Mastai, have a glass !"). The (italian) text can be found e.g. at
http://digilander.libero.it/interactivearchive/carducci_canto.htm but
unfortunately Babelfish gets quite confused by old poetical italian.
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
-----------------------------------------------------------------------
"Nature" on government cuts to research http://snipurl.com/4erid
"Nature" e i tagli del governo alla ricerca http://snipurl.com/4erko
More information about the fitswcs
mailing list