VCSbeam Frequency Channel and Frequency Mismatch

[YuTing-pulsar]

This is regarding the testing of coarse channel pairs in the context of Project D0036 using MWAX data. Taking the example of channels ch153-154, it has been observed that the low/high channels do not match the actual frequency values. Additionally, there seems to be an issue with the numerical value of the center frequency.

[bwmeyers]

Thanks @YuTing-pulsar

I think the issue lies somewhere in the DAT_FREQ table of the PSRFITS file, since that is how PRESTO determines the low/high frequencies. The central frequency is grabbed directly from the header data and is therefore not affected by the same issue.

[YuTing-pulsar]

Is the issue caused by incorrect correspondence of values in the frequency channels or is there a problem with the frequencies themselves? And seems like the central channel is not correct, such as the ch153-154:(153+154)*1.24/2=190.34MHz, but show 196.48MHz.

[bwmeyers]

The channels are 1.28 MHz wide, so chan153 = 195.84 MHz and chan154 = 197.12 MHz, which seems correct to me based on that central frequency.

[YuTing-pulsar]

Yes, thank you@bwmeyers. You are right.

[bwmeyers]

I think this is likely due to a miscalculation of the frequency tables due to incorrectly grabbing the 0th metafits frequency channel as opposed to the actual current data's first coarse channel value.

The following places need to be inspected and brought into agreement.

---

Possible error 1: https://github.com/CIRA-Pulsars-and-Transients-Group/vcsbeam/blob/b9ca9ea45dc66bfc4c6e41fc5c15aadca9182975/src/beam_psrfits.c#L148 I think in this instance, replacing

uint32_t start_hz = vm->obs_metadata->metafits_coarse_chans[0].chan_start_hz;

with

uint32_t start_hz = vm->obs_metadata->metafits_coarse_chans[first_coarse_chan_idx].chan_start_hz;

will likely work.

---

Possible error 2: https://github.com/CIRA-Pulsars-and-Transients-Group/vcsbeam/blob/b9ca9ea45dc66bfc4c6e41fc5c15aadca9182975/src/beam_psrfits.c#L360-L363 If this particular function is only ever called for a single coarse channel then I think it's correct (assuming that the hdr.x keys are define for the particular coarse channel being worked on. If not then I can certainly see this causing additional grief in a non-contiguous channel situation on top of Possible error 1.

The solution would be to have it do something more akin to what is done in populate_spliced_psrfits_header (after the aforementioned error is fixed there).

[bwmeyers]

@YuTing-pulsar I have made a change to address "Possible error 1" above. I will try to get this development version installed on Garrawarla for you in the next couple of days so that you can try it out!

[bwmeyers]

Okay, I believe I have actually found the issue. It was (I think) in part due to the above bugs, and in part due to an indexing quirk in the header population of the PSRFITS data.

Essentially, there was an offset corresponding to the "first" coarse channel index being processed. Normally, for contiguous data, this list of numbers ranges from 0-23, and so the first index is always 0, hence it was a non-issue. But when starting with, say, coarse channel 22 in a picket fence observation, this means the first coarse channel index was now 22 and so added 22 * 1.28 MHz = 28.16 MHz to all of the fine-channel frequency labels, even if the centre frequency was set correctly.

Currently testing this change out on picket-fence and contiguous data and will report back with a commit once I'm convinced it works.

[bwmeyers]

Okay, from what I could tell by looking at a beamforming job on a contiguous 4 coarse channel block, it seems to be working as expected. I think it's now time to let users try it out.