I think it's import not to confuse the internal usage and data formats
of a specific package or tool with a corresponding FITS file intended to
hold the same data.

If the FITS file format was developed at the same time as the software,
there's probably a close relationship. If the FITS format was developed
primarily to aid in export of data from one piece of software to
another, I wouldn't necessarily expect that to be true - certainly not
in both pieces of software.

If there was a general SDFITS convention, demonstrated by exchange of
real data between multiple different pieces of software (which there
isn't), then you could reasonably expect that what CLASS wrote as
TELESCOP would match the definition of what ASAP wrote as TELESCOP.
CLASS could still internally combine a telescope name + other
information, but on output to SDFTIS that shouldn't be true. Similarly
for BACKEND or INSTRUME, etc. There's going to be differences in usage
within a tool and if there was a standard for exchange, those
differences would be handled by their respective writer and readers so
that there would be as much uniformity as necessary in the FITS format
used for exchanging the data. But there isn't such a standard so right
now, things look frustratingly similar but that information is unlikely
to be understood in the same way if you were to try and use SDFITS to
pass data from one tool to the other. The few successful attempts I'm
aware of typically involve steps like "I know this SDFITS file came from
aips++, so I need to do this to that field to make sense of it." It
would be ideal if those types of steps wouldn't be necessary.

-Bob

Mike Nolan wrote:
I'm struggling with this because I'm stuck in the middle between our
Spanish station where the astronomers use CLASS and our Australian station
where they use ASAP. We are now setting up a new telescope at Goldstone
with a very powerful CASPER-based backend. How do we archive data in a
common format?



Aha, now we'll all understand: We have exactly the same problem. Today's
users want class (or whatever), but it's not an archival format. I opine that
you'll need a separate archival format that should follow the standards
papers as closely as possible. If you want, you can try to add keywords
to make class (or whatever) happy, but you're likely to need a converter.
No fun when you're talking a GB/s of data, but there you are. Most of the
reduction programs want something like the TELESCOP keyword, but they're
probably less picky about what's in it. As an example, in our class writer,
I encode the sub-band in the telescope name so that you can sort on it,
since class doesn't really have another way to do that. A few years ago,
we had a class guru visit, and he wrote scripts to fix everything up.

Class and ASAP were developed on opposite sides of the globe in
pre-internet times, and they just don't want quite the same thing, and
don't quite deal with modern data rates. Aips++ was supposed to solve
all this, but it just added one more.


Cheers,

-Mike