caracal-pipeline / caracal

Containerized Automated Radio Astronomy Calibration (CARACal) pipeline
GNU General Public License v2.0
28 stars 6 forks source link

ROTATION_ANGLE potentially insufficient/incorrect in polcal #1465

Open o-smirnov opened 1 year ago

o-smirnov commented 1 year ago

Just want to note this here after a conversation with @bennahugo... we can potentially be getting incorrect results from polcal at the moment. This is because the MeerKAT HV feeds are swapped. We have been dealing with this by honouring the RECEPTOR_ANGLE field in the MS, which is set to -90, which effectively swaps the dipoles, but also applies a -1 sign to one. Depending on the magnitude of crosshand phase, this may or may not flip the sign of Stokes U after correction. We may have been "lucky" in L-band, but UHF is particularly susceptible to large crosshand phases.

The correct procedure is to apply a [[0,1],[1,0]] matrix (i.e. truly swap X and Y), and reset RECEPTOR_ANGLE to 0, to all the data (calibrators and targets) before processing. https://github.com/bennahugo/LunaticPolarimetry/blob/master/correct_parang.py can do the swap.

@bennahugo please correct if I have anything wrong?

o-smirnov commented 1 year ago

Oh and @bennahugo didn't you and Rick also discover some individual antennas with dipoles wired backwards?

JSKenyon commented 1 year ago

For what it is worth, I strongly advocate for doing as you suggest and doing this directly on the data. In previous discussions, @bennahugo has suggested we do this OTF during calibration and, while I am not nixing the idea, it is just more opportunity for mistakes during configuration. What I would really like to know is why this isn't being addressed upstream, i.e. why are MeerKAT MSs being dumped in this weird state?

francescaLoi commented 1 year ago

I made some comparison with the NVSS polarization last year. There are few polarized source in the NVSS area observed with MeerKAT during the MeerKAT Fornax Survey. The plots below made me decide to keep doing my pol analysis (also because I could not due more about it). In total intensity we match the NVSS within the 10% (please check the mosaic blue points): plot_i plot_i_err

These are the Q and U plots. plot_q plot_q_err plot_u plot_u_err

Perc and pol angle: plot_perc plot_pang plot_p

The Pol angle has been corrected for the 7 deg offset, the average offset observed at the NVSS frequency in each MeerKAT pointing.

@bennahugo and @o-smirnov do you have a plot or something that tells us what is the impact of the method you just proposed compared to the "polcal" methods?

bennahugo commented 1 year ago

The full discussion is contained in EVLA memo series 219 (https://library.nrao.edu/public/memos/evla/EVLAM_219.pdf). You will see that for UHF the HV phase is highly variable across the entire array (ranges from -180 to +180), for L-band it is much less so (-100 to +100) and for S band it is within 60 degrees of being flipped in sign indicating that the dipoles of the S-band system is "wired in reverse". What Oleg mentioned is correct - the corrections applied in the Caracal (and vermeerkat) pipeline is not correct. Depending on your application of HV phase there is the potential of sign flippage on the linear polarization depending on your choice of reference antenna - [edit]: by luck the magnitude of the HV phases have been such that the linear angle comes out correct, the situation is markedly different on S band -- the linear angles after calibration with the -90 trick are all wrong.

The issue in signage is most easy to spot off axis on something polarized like the Moon (see figure 1 of that memo).

I'm however not advocating for changing behaviour of meerkat dumping inside katdal - if changed the defined historic MeerKAT convention will change between datasets which will further add to user confusion. I advocate (like Eric has done with AIPS) that Quartical and others define corrective routines for data coming from telescope with name "MeerKAT" @JSKenyon . Both Rick and I (and after a discussion with Bruce Merry quite a while back) have decided that convention changing ship has sailed long ago. We should correct it for MeerKAT+ though.

Re the offsets. As discussed offline @francescaLoi the linear angle for 3C286 is a few degrees lower and is heavily dependent on the ionosphere (I suggest using ALBUS to derive corrections for this). Intrinsically, in none of the bands the receivers are on average severely offset from the true alignment once X is defined towards +Q and Y defined towards -Q. Here is my latest measurements after correcting for ionosphere and checking offsets on the Lunar limb EVPA image image image

bennahugo commented 1 year ago

As discussed with Oleg it is not strictly necessary to set models to compute HV phase (the calibration procedure does not calibrate the absolute EVPA angle. As long as there is sufficient correlated power on X and Y you can solve for the elipticity of the system. In UHF I would recommend sticking with the top 1/3 of the band after flagging the GSM really well.

bennahugo commented 1 year ago

For S2 and above 3C286 starts resolving and it is doubtful we can use it without further modelling work to model the jets prior to calibrating any diagonal or off diagonal phases edit: putting in a uvcut seem to help the situation, so we may yet be able to use it

francescaLoi commented 1 year ago

@bennahugo : about the offset, I just wanted to explain why I plotted the linear trend + 7 deg on top of the polarization angle data. But... if the QU inconsistency with NVSS comes from the receptor angle/swapping issue this is affecting the polarization angle as well. In addition there's the ionosphere, clearly we should correct for both the effect.

As far as I understood from a quick look at the memo, we should change the default parameter of the receptor angle, swap the feeds and calibrate the total intensity with an unpolarized calibrator. To calibrate the polarization you have to correct for the leakage and the crosshand phase and delays, then you image the calibrator and check if it matches the model. If it does not, you re-calibrate the phase adding 180 deg to the phase. I really hope that this will fix the polarization calibration for good... @o-smirnov let's talk about this tomorrow during the CARACal telecon. @bennahugo it would be awesome if you can join as well.

bennahugo commented 1 year ago

Casa polcal does the correct thing when the feeds are aligned with IAU convention - it comes out correct for phases close to 0 and 180 so no need to flip the HV phase as in AIPS - it seemingly has the automatic logic to deal with this case that AIPS does not. No need to worry about the last step

When the -90 is left with Sband's ~180 HV phases the sign of Stokes U is negated. The discussed procedure gives consistent correct signage on all bands.

On Mon, 06 Feb 2023, 17:21 francescaLoi, @.***> wrote:

@bennahugo https://github.com/bennahugo : about the offset, I just wanted to explain why I plotted the linear trend + 7 deg on top of the polarization angle data. But... if the QU inconsistency with NVSS comes from the receptor angle/swapping issue this is affecting the polarization angle as well. In addition there's the ionosphere, clearly we should correct for both the effect.

As far as I understood from a quick look at the memo, we should change the default parameter of the receptor angle, swap the feeds and calibrate the total intensity with an unpolarized calibrator. To calibrate the polarization you have to correct for the leakage and the crosshand phase and delays, then you image the calibrator and check if it matches the model. If it does not, you re-calibrate the phase adding 180 deg to the phase. I really hope that this will fix the polarization calibration for good... @o-smirnov https://github.com/o-smirnov let's talk about this tomorrow during the CARACal telecon. @bennahugo https://github.com/bennahugo it would be awesome if you can join as well.

— Reply to this email directly, view it on GitHub https://github.com/caracal-pipeline/caracal/issues/1465#issuecomment-1419255925, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4RE6QPO2NGDMKKV67LA6DWWEJG5ANCNFSM6AAAAAAUSMKRKY . You are receiving this because you were mentioned.Message ID: @.***>