Part of the problem: miriad tries to keep velicities consistent. CASA tries to keep frequencies consistent.

Some explanations, mostly from George:

Are you assuming that the miriad images are labelled with frequencies and velocities that are in the same frame and related to each other simply by the rest freq? I wonder if this is actually true. I know that for AIPS (and possibly also miriad?), the frequencies in data and images are not well-accounted as regards frame (LSR, BARY, etc.). All of the effort is spent on assigning correct velocity start/step header parameters as alternate axis parameters (necessarily linear, I think). The frequencies (which, for VLA at least, are TOPO at some difficult-to-ascertain [especially after split] timestamp), such as they are, just come along for the ride.

To be clear, CASA is nominally attempting (with some difficulty in clean, at the moment, granted) to maintain frequency accountability throughout, including through frame changes, so that velocities may be calculated flexibly (e.g., for different species) and, if needed, non-linearly over the full bandwidth (i.e., not as alternate linear axis parameters, the inherent errors in which will be more noticable for the wider fractional bandwidths of the new instruments). If the frequency labels are always correct---and I think we should be able to achieve this in both data and images---revisable renderings in velocity will generally be more straightforward and accessible, and without having to refer to any external information.

'> - in casa in the ms (is there a difference between importuvfits and
'> carmafiller? hope not)

I wouldn't be very surprised if there is a difference. I would tend to want to believe carmafiller more than importuvfits, but I don't know anything about carmafiller. Note that it is precisely the point I made in the last email that makes it very difficult to ensure robust frequency accountabilty in CASA for data originating in UVFITS. We just don't know when those (TOPO) frequency labels were actually correct (and there may be convention differences in miriad and AIPS when writing UVFITS). Our best efforts in importuvifts involve a stationary frame (the Doppler-tracked frame, if any) "back-calculation" according to the alternate velocity parameters. Basically, velocity parameters imply Doppler-tracking, and assuming the frequencies are stationary in the Doppler tracked frame (that is the point, after all) enables us to assign a reasonably secure fixed-frequency spectral window in CASA.

If the data in question were taken without Doppler tracking---i.e., with fixed frequencies throughout---I would be a little more confident. But if the alt vel parameters are present, importuvfits probably assumes that it was Doppler tracked (when, in fact, they were only Doppler set and left fixed), that the frequency labelling is therefore unreliable, and do the back-calculation anyway. Basically, UVFITS simply cannot describe variations on these subtleties well enough to permit CASA to proceed with reliable frequency accountability.

'> But actually what you say below may explain something Michelle was
'> telling me about this morning, that in some of her conversion
'> experiments between miriad and CASA, the vels came out right but not the
'> freqs.

YES! This is to be expected, I think, given AIPS/miriad/UVFITS conventions (or lack thereof?) about frequency accountability.

CASA will make an attempt at discerning the correct frequencies from the velocity info, and the MS will be different than the UVFITS. If there is no velocity info in the header, and the frequencies are TOPO and constant in time, then (I thinK), the frame will be TOPO in CASA and the frequencies will be correct. Then, when imaging in CASA, the frequencies should (if all is working) come out correct, too (in whatever frame you image to), but they will still differ from what AIPS/miriad produce because they never bothered to convert the frequencies to the output frame. If CASA's frequencies are correct, then its velocities will be correct, too, and if AIPS/miriad are calculating the velocities correctly, they'll match.
Topic revision: r1 - 2010-03-15, RemyIndebetouw
This site is powered by FoswikiCopyright © 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