EoRImaging / FHD

Fast Holographic Deconvolution
BSD 2-Clause "Simplified" License
20 stars 10 forks source link

Beam model question #72

Open nicholebarry opened 7 years ago

nicholebarry commented 7 years ago

Please see beam_model_version in dictionary.md for question, copied below.

beam_model_version: a number that indicates the tile beam model calculation. This is dependent on the instrument, and specific calculations are carried out in _beam_setup_gain.pro. For the MWA, there are currently three options: 0) !Q, 1) a Hertzian dipole as prescribed by Cheng 1992 and Balanis 1989 (!Q Ian, dipole looks flipped from what Sutinjo has in paper?), 2) the average embedded element model from Sutinjo 2015. For PAPER, there are currently two options: 1) !Q, 2) !Q. For HERA, there is currently one option: !Q. -EoR_firstpass settings: 2 -Default: 1 -MWA range: 0, 1 (or anything else captured in the else statement), 2 -PAPER range: 1 (or anything else captured in the else statement), 2 -HERA range: automatically defaults

nicholebarry commented 7 years ago

Sutinjo says (on pg 56 of http://onlinelibrary.wiley.com/doi/10.1002/2014RS005517/epdf)

image

and it looks like in mwa_beam_setup_gain.pro that the rows are flipped:

image

isullivan commented 7 years ago

It is possible the polarizations are switched when reading the version 2 beam model fits files. The test is to change line 52 of mwa_beam_setup_gain.pro to Jmat_arr[ext_i,p_j,p_i,*] from:

FOR p_i=0,n_ant_pol-1 DO FOR p_j=0,n_ant_pol-1 DO BEGIN Jmat_arr[ext_i,p_i,p_j,*]=Jmat1[2+p_i*2+p_j*4,*]+icomp*Jmat1[2+p_i*2+p_j*4+1,*] ENDFOR

nicholebarry commented 7 years ago

Ran that test on one obsid. Calibration and weights are allowed to change, sky catalog is the same. I'm not really sure why yy changes drastically, but xx does not.

fhd_nb_notimeavg_cal_averemove_bh_dencorr__cableave_obs_id_6296_minus_cableave_flippedbeam_obs_id_6296_2dkpower

fhd_nb_notimeavg_cal_averemove_bh_dencorr__cableave_obs_id_6296_diffratio_cableave_flippedbeam_obs_id_6296_2dkpower

nicholebarry commented 7 years ago

Trying to answer Miguel's request: "check apparent versus true brightness". Let me answer a different question.

Here is the difference in apparent brightness between the default beam and the flipped beam for XX (left) and YY (right). This might help illuminate what's going on. XX is less bright for the flipped beam (shows up as positive in the diff), and YY is brighter for the flipped beam (shows up as negative in the diff). flippedbeam_diff

Here is looking at the residuals for the default beam (bottom row) and the flipped beam (top row) for XX (left) and YY (right). I've chosen to look first at the bright southern sidelobe source, and then the western sidelobe sources. The color scale is squared to diminish noise in the sidelobes. There really isn't a clear indication that one beam is subtracting better than the other...though I can convince myself of various interpretations. flippedbeam_ss flippedbeam_ws

miguelfmorales commented 7 years ago

This had calibration turned on, right? I'm wondering what transferring cal would show.

My latest thought is that as our brightest source is well off EW and sometimes near the beam null, it might be throwing off the calibration with a beam change. I always forget how much flux is in those bright sources.

nicholebarry commented 7 years ago

I've finally been able to constrain the cal....and oh boy did I get something weird. Below is the difference between a default run (weights constrained to the longrun results) and a flipped beam run (weights constrained to the longrun results, calibration constrained to the default run).

The dirty xx has the exact same power as the default, hence nothing was plotted. But I thought I changed the beam. There should be a difference.

The same models were used between both runs, so the difference between the models should be the beam difference. And yes, there is a difference, so the beam model is different for XX and YY. But the dirty in XX was the same?!?!?!?!

fhd_nb_notimeavg_cal_averemove_bh_dencorr__cableave_obs_id_6296_minus_cableave_flippedbeam_calconstrained_obs_id_6296_2dkpower

isullivan commented 7 years ago

I'm having a very hard time figuring out how these plots could come about, but going back to the math and Sujinto's equation 9 that prompted this, I'm not convinced there is a problem. The original concern was that the analytic dipole expression didn't seem to match the expression given in his paper, after going over it carefully I think they might be in agreement. From Sujinto's paper: image And the corresponding equation in mwa_beam_setup_gain.pro: Jones_matrix[0,0,freq_i]=Ptr_new(Cos(za_arr*!DtoR)*Sin(az_arr*!DtoR)*groundplane) Jones_matrix[1,0,freq_i]=Ptr_new(Cos(az_arr*!DtoR)*groundplane) Jones_matrix[0,1,freq_i]=Ptr_new(Cos(za_arr*!DtoR)*Cos(az_arr*!DtoR)*groundplane) Jones_matrix[1,1,freq_i]=Ptr_new(-Sin(az_arr*!DtoR)*groundplane)

In IDL, the axes are ordered (x,y), and (0,0) is at the bottom left corner, so putting the above code into the appropriate parts of a 2x2 matrix and setting zenith=theta azimuth=phi we have: [[Cos(theta)*Cos(phi), -Sin(phi)], [Cos(theta)*Sin(phi), Cos(phi)]]

This now looks just like the equation in Sujinto's paper.

nicholebarry commented 7 years ago

I want to bring this back up. I am willing to accept Ian's answer for why the index appears flipped...but it looks like there is a bug of sorts that is unrelated. The dirty XX PS was exactly the same in the new "flipped beam test", but if the beam was different, it should have been gridded differently!

1061316296_settings.txt firstpass.o77527.1.txt