Procedurally generate UVW data
kwazzi-jack opened this issue · comments
The simplest route for me (for now) with the testing is to generate my own data that would come from a measurement set (using simms). Right now, I am trying to figure out how I could possibly create the UVW data with shape (n_row, 3). The code that fetches it from the table for data simulation is as follows:
...
# Get convention
if args.phase_convention == 'CASA':
uvw = -(ms.UVW.data.astype(np.float64))
elif args.phase_convention == 'CODEX':
uvw = ms.UVW.data.astype(np.float64)
else:
raise ValueError("Unknown sign convention for phase")
...
where it is then used to generate model-visibilities using the africanus.dft.dask.im_to_vis. How would I go about trying to do this?
My only method right now would be to have a separate uvw_XXX.npy file that contains the array of pre-calculated coordinates (from using casa through simms) for XXX time-steps, and just load that in when needed. I've also had a look at katpoint in kern-suite (repo) to see if something could be used for kat-7 specific positioning, but with no luck yet.
Having a small .npy file committed to your repo is fine in my opinion. It is also completely ok to have a measurement set which you read data from. If you want a bit of a hands on demo with how I do this in QuartiCal, I would be happy to take you through it. Generating realistic uvw coordinates is probably more effort than it is worth. Plus, static uvw in a .npy file won't change under you.
…
On Tue, 23 Feb 2021, 18:54 Brian Welman, @.***> wrote: My only method right now would be to have a separate uvw_XXX.npy file that contains the array of pre-calculated coordinates (from using casa through simms) for XXX time-steps, and just load that in when needed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSHDWIJRH2LMJ6SQ4EXRDLTAPMVJANCNFSM4YCZV27A .
I think a demo with QuartiCal would be useful. If I had to use a measurement set for it, I would then still have to generate the measurement set or at least have it pre-generated, for different combinations of n_time and n_chan, which is what I am trying to avoid, especially with the testing. I would essentially be creating an measurement set for the single purpose of retrieving the UVW coordinates.
I could do the .npy files as a short fix for now, but ideally I would like to dynamically generate it.
I would essentially be creating an measurement set for the single purpose of retrieving the UVW coordinates.
Not necessarily a bad idea considering the alternative... I would just pull a single empty measurement set from packratt and populate it at the time of testing. I'm sure we can host it on elwood
I would essentially be creating an measurement set for the single purpose of retrieving the UVW coordinates.
Indeed why not. Making a single-channel MS for this purpose creates very little overhead, and saves you a ton of headaches with coordinates.
And if you're only using it to retrieve UVWs and don't write anything back, there's no problem with locks and the MS can be shared among multiple tests.
Thank you for all the assistance. I had a short meeting with Jon and he discussed how he accomplishes parameterizing with a single MS. I have yet to see if github actions will build and pass some simple tests, but so far so good. For now, I have one MS with a large number of channels and time-steps. Then using Jon's advice, I cut it up as need be for each test using pytest.fixture. It is easy enough to keep one MS on my repo for this use as you all mentioned.