LOFAR beam #334
LOFAR beam #334
Conversation
| if ~tag_exist(antenna, 'K') and ~tag_exist(antenna, 'F') and ~tag_exist(antenna, 'D') then begin | ||
| ;Finally, update antenna structure to include the response of each antenna | ||
| antenna=general_antenna_response(obs,antenna,za_arr=za_arr,az_arr=az_arr,psf_image_dim=psf_image_dim,_Extra=extra) | ||
| endif |
There was a problem hiding this comment.
I'm a little confused by this. should it really be skipped if you don't have these tags, or should it be skipped because it's a LOFAR beam? I'd like to implement this soon for MWA beams, will we want to skip this for MWA beams once we're doing this breakdown?
There was a problem hiding this comment.
As far as I can tell, the output of general_antenna_response (response tag in antenna) only gets used in beam_image_hyperresolved to get the power beam. I think this little bit of math is in Ruby's FHD polarisation paper. And I think we don't need it with Nicel's formulism. Let me know if I have that wrong.
There was a problem hiding this comment.
yeah, after looking through the matching stuff in pyFHD I think this is ok.
| ; Find indices where a flip in phase occurs, given a 0.1 rad tolerance. | ||
| ; To define a positive delay from the dipole arm, these J matrix indices will be multiplied by -1. | ||
| delay_element = atan(imaginary(float(gx_element[pix_use_input])), real_part(float(gx_element[pix_use_input]))) | ||
| flip_inds_J00 = where(delay_element GT (!pi-0.1)) | ||
| delay_element = atan(imaginary(float(Dx_element[pix_use_input])), real_part(float(Dx_element[pix_use_input]))) | ||
| flip_inds_J01 = where(delay_element GT (!pi-0.1)) | ||
| delay_element = atan(imaginary(float(Dy_element[pix_use_input])), real_part(float(Dy_element[pix_use_input]))) | ||
| flip_inds_J10 = where(delay_element GT (!pi-0.1)) | ||
| delay_element = atan(imaginary(float(gy_element[pix_use_input])), real_part(float(gy_element[pix_use_input]))) | ||
| flip_inds_J11 = where(delay_element GT (!pi-0.1)) |
There was a problem hiding this comment.
If this is based on Nicel's memo, you should be able to get these locations from the coordinate system rather than from the data, which I think is much safer. Certainly this approach wouldn't work for e.g. HERA because there are real flips in the beams due to reflections.
There was a problem hiding this comment.
This was one of the small deviations from Nicel's memo that I had to make, though it's hard to see here. The delay flip is actually happening around the orientation of the dipole, and is not necessarily a coordinate issue per se but a "delay is positive radiating from the dipole orientation." Both are the same if your dipole is orientated north/south, but LOFAR dipole's are all over the place.
This is also a little bit of an issue with the LOFAR beam itself. I think there is a bit of a wobble along the orientation of the dipole which comes out of Everybeam, and I'm not sure how that important that is to them. I suspect it's a modelling artifact, but I currently don't have any evidence for that.
I can make an issue to orient the dipole north south for the LOFAR template and make this a little more straightforward in the future (it would require some extra work)
There was a problem hiding this comment.
So I have thought about this a lot more in the last few days. I agree it's about the dipole axis. I have a really clean way to handle this that uses the phase structure at zenith as you go around the different azimuths. Is that something you have in the LOFAR beam? If not, you could use a circle just a little outside of zenith. I'll push the logic up to a branch on pyFHD soon so you can see it.
bhazelton
left a comment
bhazelton
left a comment
There was a problem hiding this comment.
I think this is looking good, although I have limited understanding of LOFAR beams.
I'd like to think a little more about what we call the Jones decomposition matrices. In Nicel's memo F is the complex diagonal matrix which is the product of the old F (which was strictly real and positive definite) and D. So what you have labeled as F in this code is actually the old F or F magnitude. I'm not opposed to keeping it separate from D but I am worried that calling it F here is confusing. I'd be fine with F_mag or something like that.
Using the LOFAR beam as an example, I've implemented Nicel's beam formulism. There are also a few different requirements for using LOFAR data/sims, which I've had to incorperate.
beam_image_hyperresolved.pro: This is the calculation of the power beam from the matrices F and D. Backwards compatibility is available for psf structures which do not have a F and D tag. This has been tested extensively with the LOFAR beam, but not the MWA beam. Some further work to decompose the MWA beam into F, D, and K would be required for further testing.
beam_setup.pro: Found an edge-case bug in individual snowflake beams with LOFAR beams, which are all unique.
fhd_struct_init_antenna.pro: Need a bit of help with this one. I need to define an antenna structure with F, D, K tags if that is going to be used, or an antenna structure without those tags if not. Couldn't think of a better way at this stage other than sorting on instrument (and/or beam_model_version for MWA if that happens).
rotate_Jones_matrix.pro: Use the K matrix if it exists.
fhd_struct_init_meta.pro: Changing floats to doubles. Was having difficulty later on with metadata not lining up with simulations.
vis_model_transfer.pro: Bit the bullet and added uvfits as an option to the model transfers. Uncovered a few bugs in doing so.
vis_flag_basic.pro: LOFAR core stations that share the same receiver box experience RFI on their shared baseline, so set up basic flagging for those baselines. Stations are paired in their index with the receiver box, i.e. station 1 and 2 share, station 3 and 4 share, etc
vis_header_extract.pro: Some silly little spacing stuff and a changing read-in JDate from integer of minimum length one to no minimum length. I forget why, exactly, but LOFAR data seems to die otherwise.
LOFAR beam files: Read-in and generate F, D, K.