There are essentially two different versions of frames to deal with

1) channel mode

2) frequency and velocity mode. (I will deal with the differences of freq and vel a bit later)

Then, we had two major problems in the definition of the output cubes using, nchan, start and width

a) the parameters start and width in channel mode refer to the input data whereas in freq/vel mode the refer to the output cube, which led to confusion

b) start was ill defined in freq/vel as it could be the edge of the first channel or the center

So my proposal is to:

1) define the input entirely over the spw parameter, like spw='0:10~60' or whatever

2) in vel/freq do not specify start but specify center of the output cube. In that case we avoid the problem (b) above. There are two cases implied in this:

- nchan ist an even number: in that case the center value is exactly between the two central pixels
- nchan is an odd number: in that case the center is the central value of the central pixel
There's no room for a half pixel confusion anymore.

3) in channel mode only specify nchan. Delete the start and width keywords.

- then regrid whatever is specified in spw to the number of channels given. The width will fall out naturally. And again no confusion with half channels.

This proposal will also help to only have output cube parameters in the vel/freq/chan definitions.

Given the center rather than the start value of a cube in vel/freq also helps to decrease the problems with non-linearity in certain velocity frames (like optical). Then, the calculation would be most accurate in the center of the line (ok cube) and not the start channel. Non-linearities are then equally spread on either side.

I welcome any comments. I am still thinking about any problems with these definitions and ambiguities. Please let me know if you find any issues.

My feeling is that those definitions are more intuitive and less prone for errors than the old ones. If we have 50 emails on that in the CASA team I wonder how a user would have problems. So maybe we lose a bit of flexibility in channel mode but we gain simplicity and clarity. And most of the science is in velocity mode anyway.

-- JuergenOtt - 2010-03-23
Topic revision: r1 - 2010-03-23, JuergenOtt

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback