phase_to_time alters the first time sample

[aelanman]

phase_to_time() works differently from phase(). When I try phase_to_time(uvd.time_array[0]), it runs just fine, but then passing the resulting file through FHD simulations leads to waterfall plots like the one below: This shows one baseline with 100 sources, with one hour of simulated data split among 15 files. Each file is phased to the first time sample using phase_to_time(), and the sav files output from FHD are unphased to drift before being plotted.

[bhazelton]

Can you post comparable plots using phase()? It sounds like that works better, so I'd like to see one that behaves properly.

[aelanman]

Here's an example:

[jpober]

@aelanman can you post the code you use to generate the blank uvfits? And point us to the the phase line where you're switching between phase() and phase_to_time()?

[aelanman]

The code is available on the brownscripts repository: SIM_SETUP

The script uvfits_zeros_par.py is doing the work. The rest is just for setting up the parameters of the files and running the script on slurm.

Lines 223 to 225 run the pyuvdata phasing commands.

[adampbeardsley]

Working on recreating the issue... First run Adam L's script as is: python uvfits_zeros_par.py -N 2 -o outfile_phase_RAdec hera37_cal.py HERA_sim_3.py Then comment line 225 and uncomment line 224 to create another file using phase_to_time. Now I have two uvfits files: outfile_phase_RAdec_0.uvfits and outfile_phase_halftime_0.uvfits. Note that because the first method uses t0 for the phasing epoch, we do expect very minor differences between these two files. Just to get an even better comparison, I reran the first version, but setting the epoch using halftime. Now I also have outfile_phase_RAdecHalftime_0.uvfits.

The first thing to check is the uvfits headers -- just in case there are any differences there that pyuvdata wouldn't pick up, but FHD would. I run a diff on each pair of headers. The only differences are in CRVAL6 and CRVAL7 (RA and dec). All three are different -- RAdec and RAdecHalftime are different at 10^-7 degrees, while halftime is different from those at 10^-5 degrees. This is a little surprising because I would have expected RAdecHalftime to be closer to halftime. But if the script is calculating epoch data differently... maybe it's not surprising? Either way, this shouldn't cause the jumps in data.

Next I create three UVData objects and read in the three uvfits. Doing an equality check, we find RAdec is equal to RAdecHalftime. The only difference given between RAdec and halftime is the phase_center_ra. They're off by a part in 10^6, but nothing alarming. So far no hint at what causes the bug.

To be continued...

[adampbeardsley]

Adam L pointed out that the bug may only manifest when running the script to create > 1 file. So I tried again, this time with -i 0 and -i 1, but with -N 2, for the first two versions above. This gives me four uvfits files, similar to above, but with 0 and 1 for each version. I haven't been able to find any peculiarities in the files, other than the slight difference in ra/dec noted above.

[aelanman]

Here's a more recent image demonstrating this issue. This is a waterfall plot for two otherwise identical FHD simulations using MWA beams on a single 100m east-west baseline and 1000 sources, 10 second integrations, 56 integrations per file. The top half was phased to zenith at the halfway point in each file using phase(), while the bottom half was phased using phase_to_time().

You can see the stripes appear at the midpoint of some of the files.

[adampbeardsley]

I've read in the uvfits files Adam L used, as well as the FHD files. I can't seem to find anything afoot in any of the files, except for the actual visibility data of course. Next step will be to try stopping FHD when it calculates the visibilities and see if anything is funny there.

[adampbeardsley]

There was a lot of troubleshooting, documented in the corresponding slack channel. But the takeaway is that this is actually an FHD bug (see https://github.com/EoRImaging/FHD/issues/62). So I'm closing this issue.