[fitsbits] INSTRUME and TELESCOP

[Tom Kuiper]

In the SDFITS documentation I find the meaning of TELESCOP and INSTRUME
quite clear. (BACKEND seems to be disappearing in favor of INSTRUME.)
However, in CLASS the command
set telescope <string>
seems to expect a string that identifies both the telescope and the
backend (e.g. "CSO 1GHZ IF3"). On the other hand, in ASAP, the command
set_instrument(<string>)
seems to want a telescope identifier (e.g. "MOWPRA"). (I haven't
figured out yet how one selects a specific back end in ASAP.) Because
CLASS and ASAP have a long history I'm reluctant to suggest that either
or both should change but I don't see how either can be fully SDFITS
compliant otherwise.

Your opinions?

Regards

Tom

[Bob Garwood]

That's all an internal view of the system. SDFITS doesn't care.
Standard telescope names would be useful, but they aren't defined. And
again, SDFITS isn't really a standard - just a dream of a standard
that's never been really realized.
Bob

> _______________________________________________
> fitsbits mailing list
> fitsbits@

[Tom Kuiper]

Hi, Bob!

Bob Garwood wrote:

That's all an internal view of the system.  SDFITS doesn't care.   
Standard telescope names would be useful, but they aren't defined.  And 
again, SDFITS isn't really a standard - just a dream of a standard 
that's never been really realized.
  

TELESCOP is a core keyword:

TELESCOP

A string value giving the telescope name.

It doesn't seem ambiguous to me.  Standardizing the possible values of TELESCOP seems like a good idea.

BACKEND is a shared keyword:

BACKEND

A string giving the name of the back end device.

AIPS++ SDFITS doesn't seem to know about INSTRUME. Personally, I prefer backend anyway.

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?

Let me ask you, since NRAO has adopted ASAP as part of CASA, how are you going to deal with peculiarities of ASAP which exist for historical reasons? (Like 'set_instrument'!)

Best regards

Tom

[Mike Nolan]

>
> 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

--
Dr. Michael C. Nolan, Observatory Director
+1 787 878 2612x212 Fax: +1 787 878 1861 no...@naic.edu
Arecibo Observatory, HC 3 Box 53995, Arecibo, Puerto Rico 00612 USA

[Bob Garwood]

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

[Steve Allen]

On Wed 2009-05-06T15:27:04 -0400, Bob Garwood hath writ:

> 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.

Alas, in many cases the initial requirements on keyword values were
somewhat lax (if they existed at all). The only way to make that not
necessary is to fight the battles of adding bits to the standard.

In order to avoid utter confusion that usually requires adding new,
previously unused keywords to the standard in order to require that
they may only have values with specific, precise characteristics.

This is the battle that is in progress right now for the time-related
keywords of FITS WCS paper 5. It is particularly tricky to deal with
keywords that relate to star/end/duration of an observation or
exposure. There are many keywords already in use by various agencies
with various meanings. "All the good names are already taken", so
the paper is suggesting things like XPOSURE.

I'll close with this repeated plea that everyone from radio to gamma
ray look at the keywords related to exposure times in the draft of
FITS WCS 5
http://hea-www.harvard.edu/~arots/TimeWCS/
and reply to the fitswcs list.

--
Steve Allen <s...@ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855
University of California Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m