search

CIRADA-Tools / RM-Tools

RM-synthesis, RM-clean and QU-fitting on polarised radio spectra
MIT License
43 stars 23 forks source link

Odd behaviour in peak outputs from RMsynth3d #84

Closed AstroRipples closed 1 year ago

AstroRipples commented 1 year ago

Hi folks,

Running RM-synthesis on some ASKAP Q & U cubes and I'm noticing some odd behaviour in the outputs. Specifically the FDF_peakRM.fits map produced after the RM-synthesis step.

I'm running the following: rmsynth3d -v -d 7 -l 500 -o askap_rmsynth_ qcube.fits ucube.fits freqs.txt on a standard cube of dimensions (288, 4096, 4096) outputted by ASKAPsoft... and the printout in my terminal suggests everything is proceeding normally:

...
Reading qcube.fits ...
done.
Dimensions of the input cube are:  NAXIS1 = 4096  NAXIS2 = 4096  NAXIS3 = 288  
Dimensions of the input array are:  (288, 4096, 4096)
Reading ucube.fits ...
done.
Dimensions of the input cube are:  NAXIS1 = 4096  NAXIS2 = 4096  NAXIS3 = 288  
Dimensions of the input array are:  (288, 4096, 4096)
PhiArr = -497.00 to 497.00 by 7.00 (143 chans).
Weight type is 'uniform'.
Running RM-synthesis by channel.
...

And yet the output askap_rmsynth_FDF_peakRM.fits map only ranges from -497 to 0. I find it extremely difficult to believe that all the peaks are at or below and RM of 0 (even the noise) especially as I know there are sources in the field with positive RM.

I've never seen this before running on other datasets. This is wholly unexpected, and the output cube has the correct PHI axis range, but I've run both the command-line rmsynth3d and script-based RMtools_3D/do_RMsynth_3D.py versions with identical outputs. I should note that when I run rmtools_peakfitcube on the FDF cube I see the full range of RM values, so this appears to be specific to the script run at the conclusion of rmsynth3d.

Anyone experienced anything similar? Is there some peculiarity to running RMtools on ASKAP data I should be aware of?

Cameron-Van-Eck commented 1 year ago

Hey Chris:

That is pretty bizarre. I can't reproduce it with the data I have on hand, so it doesn't seem like it's broken for all data. If it was also broken in the peakfit tool, I might speculate about something like accidentally feeding in Stokes Q twice rather than Q and U, but that can't be the case here. So the peakRM and the phiPeakPIfit_rm2 maps aren't similar? Weird....

I don't think there's anything weird about ASKAP data in this regard? It's been a while (about a year?) since we ran the 3D pipeline on any ASKAP data, but the data back then had both positive and negative RMs in the peakRM map.

Is there anywhere you could stick the Q and U cubes where we could download them? Or cutouts, if there's a region that definitely contains both positive and negative RMs.

Cheers, Cameron

AstroRipples commented 1 year ago

Hi Cameron. Thanks for looking into this, however, the issue has now been solved, and the problem was nothing to do with RM-Tools or ASKAP specifics.

The cause was a subtle bug in the getnoise_list function of RACS-tools (now fixed as reported here), which wrote Stokes Q into both Q and U data cubes but only when blanking bad channels with the -b option. As such, I was inadvertently passing Q and Q cubes to RM-tools 🙃

AlecThomson commented 1 year ago

Apologies for the pain, all! The bug in question should be solved by https://github.com/AlecThomson/RACS-tools/pull/29