Stefan Oslowski

Psrsplit changes freq where no change expected

Actually, doesn't freq report the original centre frequency normally? So someone has manually changed that for the input file for some reason, but after psradding, the correct centre frequency is restored.

PS Looking at the verbose output you've sent I've noticed these suspicious lines: psrfits_read_col: DATE_PRO=Fri Sep 9 19:25:27 2016 load ProcHistory::row DATE_PRO=Fri Sep 9 19:25:27 2016 psrfits_read_col: PROC_CMD=psredit -c ext:obsfreq=1380.781250 -m load ProcHistory::row PROC_CMD=psredit -c ext:obsfreq=1380.781250 -m so it looks like the centre frequency was set manually to 1380.78125 which would ezxplain why that doesn't match what I would have expected but it doesn't explain why psredit reports...

Hey Joeri, I've verified that all the channel frequencies are preserved between the input, the intermediate files, and the output. Furthermore, 1430.78125 is the unweighted centre frequency. However, I do get confused after that as 1380.78125 does not appear to be the weighted centre frequency. And maybe I just calculated the weighted frequency wrong but even if I did, it doesn't explain why after splitting and adding the file back together the reported centre frequency is different. The weights...

Downgrading to SWIG 3.012 resolved the issue. I'm leaving this open as probably worth fixing compatibility with SWIG 4?

compiling python bindings on macos BigSur

Hey Cees, You can access the past number of channels and subints with: pdv -H "NCHAN NSUB" archive.ar If the original archive assigned a weight of 1 per channel/subint, this will let you work out the fraction of data zapped. Hope this helps. Cheers, Stefan

psrsh - delete command