Add support for all UVBeam files

[bhazelton]

Description

Support all UVBeam readable files. This required adding support for parameters to pass the to UVBeam.read method.

Motivation and Context

fixes #335

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• 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:

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

New feature checklist:

• I have added or updated the docstrings associated with my feature using the numpy docstring format.
• I have updated the documentation to highlight my new feature (if appropriate).
• I have added tests to cover my new feature.
• 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.
• I have updated the CHANGELOG.

[steven-murray]

Thanks @bhazelton, this will be a very nice addition. Other than the small comments I've made, I have one other broader comment.

I think it would be nicer for the beam definitions in the YAML to have a nicer YAML tag, or at least to be more consistent. That is, I think it shouldn't be possible to do e.g.

0: myfile.beamfits
1:
    filename: myfile.beams

Since in general other keywords should be supported, I think enforcing all beams to be of the form:

0:
   path: mybeam.fits
   other_param: ...

is better, and will mean more homogeneous code. As a further extension, one could imagine defining a YAML tag, so that it would be:

0: !UVBeam
    path: this.beam
    param: that
1: !AnalyticBeam
    type: gaussian
    diameter: 12.0

With these tags you can automatically read the YAML as python objects that are self-contained. The one reason you might NOT want to do this currently is that you actually don't want to read these things as full python objects, but rather in this weird "string mode" so it's lighter to pass around. I feel like there's a more pythonic way of doing this as well, but I'd have to think a bit harder. Possibly easier once the AnalyticBeam refactoring is in place on pyuvdata.

[bhazelton]

I think it would be nicer for the beam definitions in the YAML to have a nicer YAML tag, or at least to be more consistent.

I agree with you on this, but we'll have to go through a deprecation process and I'm pretty sure this will trip up on our reference sims. I'm happy to start the deprecation process by putting in the appropriate warnings now.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (92ab9e9) 99.50% compared to head (abd1ac9) 99.50%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #444   +/-   ##
=======================================
  Coverage   99.50%   99.50%           
=======================================
  Files          12       12           
  Lines        2208     2240   +32     
=======================================
+ Hits         2197     2229   +32     
  Misses         11       11           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[steven-murray]

Hmmm, let's just make an issue and merge this branch, because I think the process of deprecation should be handled carefully.