Appropriate use of the spectral WCS description

[MatthewWhiting]

At present, the default behaviour is to convert to velocity if the FITS file has a rest frequency defined.

Tobias has pointed out that it would be more sensible to use the WCS description that is actually in the FITS file, unless otherwise told.

Is it possible to do this - perhaps have an input parameter that indicates the type of axis to use (FREQ, VEL), and then do a conversion if asked? This could perhaps default to NULL or similar, in which case no conversion is done.

Putting on 1.2 milestone for now, but evaluate and see if this is easily done.

[MatthewWhiting]

Some comments from a first look at wcsIO.cc:

• We have "MHz" hardcoded in as the frequency units! Perhaps we should use whatever's in the header?
• Conversion is always done to VELO-F2V - what if this is not appropriate?

Need to read through the wcslib instructions to see if we are still doing the right things.

[MatthewWhiting]

First part of this done in [947] - we don't do any conversion, we just make use of the CTYPE as given in the FITS file. The spectral columns (that were VEL & w_VEL) now use the four-letter S-type code (e.g VRAD, VOPT, FREQ), and the spectral axis in the spectral plots makes use of the description as given by the WCSLIB function spctype.

The other thing I'd like to do is allow an optional input parameter that specifies a new CTYPE, so that we can convert (if possible) to this. The conversion should make use of the rest frequency provided in the FITS file, but perhaps we could allow the specification of a different rest frequency - if given, this should be used first. (That way you could search a cube that is formally an HI cube for e.g. OH and have it given as OH velocities).

[MatthewWhiting]

The second part of this is done in [948]. There are two new input parameters:

• spectralType -- the new CTYPE code that the spectral axis should be translated into. It should be a four-letter code, but can be the full 8-letter code.
• restFrequency -- what rest frequency to use. If a rest freq is needed for the translation, it will use this in preference to whatever the FITS file says. If it is not provided by the user, it defaults to -1 and is consequently ignored.

There is also another parameter not exposed to the user, restFrequencyUsed, which tracks whether the supplied rest freq was indeed used and should be written out with the output results (as part of the parameter output, for both the text files and the VOTable/XML files).

[MatthewWhiting]

One other thing that we might tie in here: When running the input_small test, without any translation away from FREQ, we get the following error:

ERROR <fixUnits> : WCSUNITS Error, Code = 10: Non-conformant unit specifications
Tried to get conversion from "Hz" to "km/s".

The input parset does not specify spectralUnits, so this is grabbing some default. This needs to be changed so that it only attempts the conversion if units are provided.

[MatthewWhiting]

And this is fixed by [949]. This appears to be a lot more robust now.

Should try these options out on a few more cases, but this is probably ready to be closed.

[MatthewWhiting]

Happy to close this now, it looks pretty well behaved.