Queery on RMsynth_3D output with -i option about rm-tools HOT 2 CLOSED

Hi Gabe:

What kind of Stokes I cube are you supplying? Is it a cube of Stokes I model values, or the observed Stokes I?

I'm going to guess that you're feeding in the observed Stokes I value, or a model that isn't completely safe (which is a problem with the default Stokes I modelling routine; I'm going to fix that in the next release). What can happen is if there are Stokes I values that are very close to zero the noise in Q, U, and I can result in Q/I and U/I values that are unphysically large (billions of percent polarized sources!) or with flipped sign. This tends to cause the resulting RM spectra to be complete garbage.

The safest thing to do, if you're working with polarization of sources, is to use Stokes I models (there's a script in RM-Tools, RMtools_3D/do_fitIcube.py, which should be able to generate such models, although I'll warn you that it's not robustly tested and documented yet) and/or ignore pixels that don't have enough Stokes I signal. If you're working with diffuse emission (which I'm guessing you're not -- you're doing QUOCKA stuff in George's group, right?), then you should not normalize by Stokes I at all if you have interferometer data.

The FDF_maxPI file gives the polarized intensity of the peak in the FDF, for each pixel. Internally in the code everything is calculated as fractional polarization, then at the end it is multiplied by a Stokes I reference value to convert back into polarized intensity units. The Stokes I reference value is taken as the Stokes I value at the reference frequency: if that Stokes I value is zero or negative then the resulting polarized intensity value is correspondingly zero or negative.

In short: because it divides by Stokes I, negative or low S:N values are a problem. Use a model (although that's not completely safe yet -- I'm working on fixing that) or limit yourself to bright pixels.

On a side note: if you have any other questions about RM-synthesis or RM-Tools, and it doesn't necessarily seem like a bug, feel free to directly email me (cameron.van.eck (:at:) utoronto.ca) with questions. I'm pretty good about responding quickly (although the time-zone difference means it will probably be overnight).

Cheers,
Cameron

from rm-tools.

Hi Cameron, thanks for your thorough response!
Yep I'm working in George's group on the QUOCKA data. I was feeding in observed Stokes I so will take your advice and try the model. Thanks also for explaining how the output works.
I'll get in touch with any other questions via email
Cheers!
Gabe

from rm-tools.