#435 Frequency append (e.g. psradd -R) and subint freuqency
I don't think this is already captured in older issues with psradd -R. Here I am combining single-pulse archives from a split-band observation of MeerKAT.
The 'bug' is that sometimes, the weighting of the two sub-bands ends up different even though the input weights are the same. For an example, I have f-scrunched the two half-bands first as this doesn't seem to make any difference...
psredit -c int:wt 1123.5/pulse_585625753.F 1444.5/pulse_585625753.F
1123.5/pulse_585625753.F int:wt=384
1444.5/pulse_585625753.F int:wt=384
psradd -R 1123.5/pulse_585625752.F 1444.5/pulse_585625752.F -o add.ar
psredit -c int:wt add.ar
add.ar int:wt=154.657,154.681
Compare with the pulse before...
psredit -c int:wt 1123.5/pulse_585625752.F 1444.5/pulse_585625752.F
1123.5/pulse_585625752.F int:wt=384
1444.5/pulse_585625752.F int:wt=384
psradd -R 1123.5/pulse_585625752.F 1444.5/pulse_585625752.F -o add.ar
psredit -c int:wt add.ar
add.ar int:wt=154.657,154.657
This has the effect that the frequency of each pulse (as recorded in the subint header) ends up different, which seems wrong, breaks some post-processing code, and fundementally suggests something wrong somewhere.
In practice the meertime pipeline uses the FrequencyAppend code directly rather than psradd, so I think there is an issue within this code. I'm really not quite sure where the re-weigting comes from (or why it does so). I will try to investigate more, but it would be helpful if anyone knows the logic or where the decisions are made about the weighting.
