Frequency alignment fails for observations at different frequencies

[Malte Marquarding]

from Max

It seems to me I found the cause of the problem. In STMath.cc, lines 1828-1830 frequencyAligner<Float>::align method is called with useCachedAbcissa, which is True for all but first spectrum (!first is passed). As a result a change in reference value is ignored.

We also have to relax the condition in lines 1752-1756, which currently throws an exception if the input and output reference frames are the same. They could be the same, but with different reference values/increments/reference pixels.

[Malte Marquarding]

Max,

we are iterating over FREQ_ID which should vary if any of refpix,refval, inc change. So each row in that selection should have the same freqquency set up. Or am I wrong?

[Malte Marquarding]

Max,

As discussed this is due to the fact that hits handles only alignment within the same FREQ_ID. What you want is alignment of the same IFNO.

I'll assign it to you but feel free to bounce it back.

[Max Voronkov]

That's OK. I'll probably look at the issue in two weeks time.

[Max Voronkov]

Sorry that it takes so long. I'll try to look into the issue in the nearest future.

Max.

[Max Voronkov]

I've just checked in a fix. The problem happened because different scans may have different FREQ_IDs, which were not aligned together in the past (only time alignment was performed). Now the code always aligns every FREQ_IDs within the same IF. Different IFs are not aligned and such an alignment is a more tricky problem because they could have different number of spectral channels (although can be done with some scripting in python). It was found that the Tid test case suffered from the issue as well as the Mopra project where the problem was discovered. It wasn't very apparent because the frequency was lower and the time span between observations was small (i.e. not different days). Different transitions were observed in different IFs and therefore this bug fix doesn't cause unwanted alignment of too different frequencies. Even if we have a dataset with two spectral lines at notably different frequencies presented in the dataset as two FREQ_IDs, rather than two IFs (quite possible for Mopra zoom modes from my point of view), masking will take care of such situation automatically. The user would have to do some more accurate selection of the data if a particular behavior is required (it is unavoidable anyway). Therefore, I consider this fix rather general and no special parameter is required to revert the behavior to the old one.

The fix has been rigorously tested on the Mopra and Tid data. I suggest to inform 3mm observers who did long integrations as they probably loose S/N with the old version of asap (or even had a totally invalid reduction).