Rmsynth 3D returning zero output
Jaswanth-Jza opened this issue · 5 comments
Hello,
This is not exactly an issue with RMsynth but some unexpected output I don't know how to interpret.
I am using RMsynth3D on a set of fits files for a target (T200) in my dataset. I am using stokes I,Q and U cubes as input. Image is 100x100 pixels in size. When I run rmsynth3D with the necessary freq file on this target it runs with no major errors and seems to finish. The output FDF_tot_dirty image is just a blank image with 0 value. hen I try to open the image I get the message saying it has bad data, i.e, maxis not geater than min as max=min=0.
I am attaching a screenshot showing the rmsynth log and the consecutive attempt to open the image.
I do not have this problem with my other target(C215). I am trying to understand why this is happening. For T200 there is almost no signal in the Q channel cubes, the U images however have a strong signal. For C215 there is a strong signal in both Q and U, could this be a reason why RMsynth seems to be unable to process the T200 cubes?
Your insight would be really helpful!
Hi @Jaswanth-Jza:
That's definitely strange behaviour. Since it looks like your (frequency) cubes are fairly small, would you be willing to email them to me (along with the frequency file). That'll make it easier for me to diagnose what's going on. Please send them to cameron.van.eck@utoronto.ca.
Cheers,
Cameron
Thank you for your quick response! I just emailed the files to you!
Hi Jaswanth:
Thanks for the files. I've taken a look, and I at least partially understand the issue. The cause seems to be the use of the Stokes I cube. It's not intended that rmsynth3d should be fed an observed Stokes I cube, because those values are used directly for dividing Stokes Q and U and the observed cubes are typically very noisy (this is not very well explained in the documentation; I will improve that). I haven't tracked down the exact reason why the Stokes I cube is causing the outputs to be zeros -- I'll do that soon because there's probably an interesting bug hidden in there -- but I have found that not using the I cube does solve the problem.
The intended usage is to either not incorporate the Stokes I information (just using Q and U), or to use a Stokes I model. There is a tool for creating Stokes I model cubes: rmtools_fitIcube aka RMtools_3D/do_fitIcube.py. This tool can generate a smooth Stokes I model cube given an observed cube. I did find a bug in that script when testing it with your data -- I've released an update here on the Github, but not to Pypy. Something like: rmtools_fitIcube T200324_I_ncell30_cube_masked.fits Ncell30_FREQ_T200324.dat -p -2 -o model_ -v should work. I've confirmed that if you run rmsynth3d either with no Stokes I cube, or with the model cube, the outputs look reasonable.
As a side note, you've set your Faraday depth sampling (-d option) very small, which increases compute time and output size considerably. Given that your data produces an RMSF of over 400 rad/m2, you don't really need a sampling smaller than 20 rad/m^2. Even a much coarser value like 50 would probably be fine.
Cheers,
Cameron
Hello Cameron,
Thank you! I will try the sokes I model cube, I did not try it without stokes I but I need to do it and the model methods helps me with this.
Thanks again for giving me a solution for this issue!
I've figured out why the output FDF cubes are completely zeros, so I'm going to make some notes here for my own future reference:
When a Stokes I cube is supplied, after RM synthesis it uses the value of Stokes I at lambda^2_0 to re-normalize the FDF cube into the same units as Stokes IQU. Jaswanth's data has an unusual property: the Stokes I cube has two zeroed out channels right in the middle, so when the code goes to re-normalize, it interpolates between those channels (interpolating between 0 and 0, haha), then multiplies the FDF cube by that value (producing the zero cube).
It's quite unexpected. I don't expect this to come up again, so I'm not prioritizing any changes to the code. I suppose the simple solution is that users shouldn't be putting in cubes with completely blank channels (in principle, if it's a Stokes I model and not data with missing channels, this shouldn't happen either). I need to go back and make the documentation more clear that Stokes I cubes must be models, not data...