Fix code to use new pyradiosky and pyuvdata methods

[bhazelton]

Description

• Use future array shapes for UVData objects. This requires having pyuvdata >= 2.1.5, so I updated our requirements to this version
• Support writing measurement set files. This requires having pyuvdata >= 2.2.2, an error is raised with a useful error message if the pyuvdata version is too old.
• Use the newer replacements for SkyModel.source_cuts if they are available.

Motivation and Context

Stay up to date with changes in pyuvdata & pyradiosky:

• use future array shapes on UVData objects (see https://github.com/RadioAstronomySoftwareGroup/pyuvdata/pull/967)
• support writing measurement set files (see https://github.com/RadioAstronomySoftwareGroup/pyuvdata/pull/995)
• don't use source_cuts method on SkyModel (see https://github.com/RadioAstronomySoftwareGroup/pyradiosky/pull/161)
• fixes #332

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Reference simulation update or replacement
• [ ] Documentation change (documentation changes only)
• [ ] Version change
• [ ] Build or continuous integration change

Checklist:

For all pull requests:

• [x] I have read the contribution guide.
• [x] My code follows the code style of this project.

Bug fix checklist:

• [x] My fix includes a new test that breaks as a result of the bug (if possible).
• [x] All new and existing tests pass.
• [ ] I have checked that I reproduce the reference simulations or if there are differences they are explained below (if appropriate). If there are changes that are correct, I will update the reference simulation files after this PR is merged.
• [ ] I have checked (e.g., using the benchmarking tools) that this change does not significantly increase typical runtimes. If it does, I have included a justification in the comments on this PR.
• [x] I have updated the CHANGELOG.

New feature checklist:

• [x] I have added or updated the docstrings associated with my feature using the numpy docstring format.
• [x] I have updated the documentation to highlight my new feature (if appropriate).
• [x] I have added tests to cover my new feature.
• [x] All new and existing tests pass.
• [ ] I have checked that I reproduce the reference simulations or if there are differences they are explained below (if appropriate). If there are changes that are correct, I will update the reference simulation files after this PR is merged.
• [ ] I have checked (e.g., using the benchmarking tools) that this change does not significantly increase typical runtimes. If it does, I have included a justification in the comments on this PR.
• [x] I have updated the CHANGELOG.

[codecov[bot]]

Codecov Report

Merging #375 (65bddc5) into main (d644607) will increase coverage by 0.05%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #375      +/-   ##
==========================================
+ Coverage   99.09%   99.14%   +0.05%     
==========================================
  Files          13       13              
  Lines        1980     1997      +17     
==========================================
+ Hits         1962     1980      +18     
+ Misses         18       17       -1     

Impacted Files	Coverage Δ
pyuvsim/antenna.py	96.07% <100.00%> (+1.84%)	:arrow_up:
pyuvsim/simsetup.py	99.88% <100.00%> (+<0.01%)	:arrow_up:
pyuvsim/utils.py	98.10% <100.00%> (+0.12%)	:arrow_up:
pyuvsim/uvsim.py	98.55% <100.00%> (+0.01%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update d644607...65bddc5. Read the comment docs.

[bhazelton]

There are some checkmarks in the PR template about reproducing the reference sims. I haven't done that yet, are there scripts for that?

[mkolopanis]

I think we decided that it should not be necessary for complete reproduction of the reference sims for this PR. Maybe wouldn't hurt to run sim 2.1 though on a cluster? That one takes a few hours generally.

[bhazelton]

I think that would be more than sufficient and if you're willing, I'd be grateful. I was going to try to figure out how to run the v1 sims on my own machine but haven't had the time yet.

[mkolopanis]

Yeah I'll run them and report back.

[mkolopanis]

Reference sim 2.1 took 516.642 min, on par with the ~8.5ish hours we saw in the PR we just merged. I didn't think a comparison with main was strictly necessary since this PR has such quick turnaround with the blt ordering one.

[bhazelton]

@mkolopanis did you also check that it got the same results? If so, I think this might be ready for another review.

[mkolopanis]

So this is a fun point. We don't have a saved reference sim 2.1 on the google drive. I can check that it matches some other reference sim 2.1 outputs.

[mkolopanis]

But yes all the results match the previous simulations I have run for timings (including from the old main branch). in that case. I agree ready for a review

[bhazelton]

@aelanman I think this PR is ready if you want to have another look.