Procedurally generate UVW data

[kwazzi-jack]

Procedurally generate UVW data

[kwazzi-jack]

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.

[JSKenyon]

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> .

[kwazzi-jack]

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.

[JSKenyon]

We can likely manage something that doesn't require multiple measurement sets. If you make one with the maximum number of times and channels you wish to test, we can write a fixture to select out subsets. I will shoot you a mail in the morning and we can organise a time for a demo.

…

On Tue, 23 Feb 2021, 19:41 Brian Welman, ***@***.***> wrote: 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. … <#m_-295029650542020488_> 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) <#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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSHDWPTMEI6S3UPNG3B3FTTAPSE3ANCNFSM4YCZV27A> .

[landmanbester]

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

[o-smirnov]

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.

[kwazzi-jack]

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.