caom2-compute doesn't recognise CTYPEs: FDEP or RM

[pdowler]

FDEP is Faraday Depth RM is Rotation Measure

Radio cubes from the GMIMS project at DRAO have CTYPE3=RM (rotation measure) and FDEP is another usage that we need to support.

[Cameron-Van-Eck]

I don't entirely understand much of the specific terminology being used here, but as a Faraday rotation expert I'm happy to try to clarify any problems that might come up with handling our data products.

The primary data products where I would expect 'FDEP' or 'RM' to be present as a CTYPE is Faraday depth cubes. These are FITS files with 3 (possibly 4) axes: 2 conventional coordinate axes (RA/DEC, Galactic long/lat, etc), 1 Faraday depth/RM axis (which acts much like a frequency axis in conventional spectroscopic data), and possibly a Stokes parameter axis (iterating over some combination of Stokes Q, U, and/or polarized intensity). The dependent variable (pixel values) contain fluxes. At the moment there is no universal standardization as to whether the FDEP axis is NAXIS3 and Stokes is NAXIS4, or vice versa.

The FDEP axis behaves in some ways like a simplified version of a frequency axis, without complicating factors like converting between different reference frames. It simply steps through a range of values, typically in equal step sizes, with the range and step size being set during the processing and put into the appropriate CDELT, CRVAL, etc, FITS keywords. Generally speaking, FDEP ranges/values never need to be manipulated/transformed and can be directly compared between different data sets.

The CIRADA pipeline I am developing will produce many of these Faraday depth cubes. If there is any additional information or structure that would be helpful to include in the FITS headers for these data products, I can make sure that our pipeline inserts these values correctly.

[pdowler]

This clarifies things alot. I also looked at some GMIMS cubes in detail and they use CTYPE3=RM and CUNIT3=rad/m/m. NAXIS=3 so this is really a 3-d cube with an RM coordinate axis. In these cases there really is a non-standard coordinate axis that replaces one of the existing axes (usually spectral). In the general case the data is rebinned along that axis so this is not a case handled by a transformation (eg the way spectral wcs can be equivalently expressed as WAV, FREQ, or some sort of velocity).

I am now considering adding a "custom" 1-D coordinate axis to Chunk so that a single non-standard axis can be included and data with zero or one non-standard axis can be described. Minimal discovery support at the plane level would also be required.

[pdowler]

There are no known use cases for multiple non-standard axes, but adding that would entail redesigning the whole Chunk with generic axes in mind: probably CAOM-3.0.

[ashill]

A few elaborations on @Cameron-Van-Eck 's comments:

In a 3D RM synthesis cube, yes, the RM axis directly replaces the velocity access in a typical 3D cube in which VOPT or VRAD is the third access. Many of the typical analysis tasks (eg taking moments, integrating over velocity/spectral/Faraday depth ranges, etc) are mathematically identical in RM cubes as in spectral cubes, though often software isn't willing to do those integrations because FDEP is non-standard.

For the GMIMS data, the intensity is polarized intensity (ie sqrt(Q^2 + U^2)). But it is entirely possible to have a 4D data cube in which we record Q and U at each position and Faraday depth. Or, equivalently, we could record polarized intensity and polarization angle (both of which are easily derived from Q and U and contain the same information).

Note that the typical brightness unit of Faraday depth cubes is either brightness temperature (K) or flux density (Jy/beam), just like in a velocity or frequency data cube.

And "Faraday depth" and "Rotation measure" are synonyms for the purposes of axis names on FITS cubes. (There are subtle, not-standardized differences between the usage of the two terms that aren't relevant to CADC.)

[pdowler]

Final note: by looking at existing data, we have adopted FARADAY and RM as acceptable ctype values

From slack conversations and by looking at the standard unit usage (VOUnits spec has a good treatment on FITS and OGIP units) we allow rad/m**2 or rad/m^2 as the supported units. We have not implemented support for scaling (kilo-rad?) but we could if necessary.

[ashill]

OK. I don’t think I’ve ever encountered krad/m^2 or mrad/m^2 or anything like that; values I’ve seen are always, in practice, stored in just rad/m^2 (or rad/m**2).

On Nov 27, 2019, at 15:03, Patrick Dowler notifications@github.com wrote:

Final note: by looking at existing data, we have adopted FARADAY and RM as acceptable ctype values

From slack conversations and by looking at the standard unit usage (VOUnits spec has a good treatment on FITS and OGIP units) we allow rad/m**2 or rad/m^2 as the supported units. We have not implemented support for scaling (kilo-rad?) but we could if necessary.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.