Add pyradiosky version to output file

[bhazelton]

Description

• Add pyradiosky version information to the history of the output file.
• Move all of the history setting to the run_uvdata_uvsim function so it will be set if that function is called directly (as it is in hera_sim).

Note: In order to have all the required info in run_uvdata_uvsim for the history, I needed to add some attributes to SkyModelData. I also needed to add the input catalog filename to the SkyModel object created in simsetup.initialize_catalog_from_params. For the current and older versions of pyradiosky, this will be a simple attribute. But I also made a PR on pyradiosky to add a filename attribute more generally (see RadioAstronomySoftwareGroup/pyradiosky#169). The implementation in this PR works with both the current pyradiosky and with the branch in that PR.

Motivation and Context

fixes #327

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.

[codecov]

Codecov Report

Merging #384 (8ea53d2) into main (1f88b96) will increase coverage by 0.15%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #384      +/-   ##
==========================================
+ Coverage   99.17%   99.32%   +0.15%     
==========================================
  Files          13       13              
  Lines        2054     2068      +14     
==========================================
+ Hits         2037     2054      +17     
+ Misses         17       14       -3     

Impacted Files	Coverage Δ
pyuvsim/simsetup.py	99.88% <100.00%> (+<0.01%)	⬆️
pyuvsim/uvsim.py	99.42% <100.00%> (+0.86%)	⬆️

---

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 1f88b96...8ea53d2. Read the comment docs.

[bhazelton]

@steven-murray We added this to the same place where we add the pyuvsim and pyuvdata version info in run_uvsim, which is the top-level function that is generally called to run simulations. However we note that hera_sim doesn't call that function, it calls run_uvdata_uvsim, a lower-level function. Is there a good reason to call that instead of run_uvsim? If so, we should probably ensure that the version numbers get into output files if you run that function as well.

[steven-murray]

@bhazelton the reason we use run_uvdata_uvsim is essentially to maintain API parity between different simulators, which is the whole point of the hera_sim.visibilities module. The idea is to use pyuvsim to read config files, then use the UVData/UVBeam/SkyModel classes created from those configs to run a simulator -- not necessarily pyuvsim.

Most other simulators don't have a function that will directly run from the config file, which makes it necessary for hera_sim to provide this layer. Note that hera_sim also supports running directly from objects, rather than config files, which is another reason this is necessary.

[bhazelton]

Ok, then I think we need to move the history modifications so that they get picked up by both functions.

[steven-murray]

I do have one comment that could be addressed, but approving because it's small and you might not agree. Thanks @bhazelton!

[steven-murray]

this could be written if not getattr(sky, "filename", None):

[bhazelton]

Thanks for the suggestion, I actually needed getattr(sky, "filename", None) is None:.

[steven-murray]

This looks good.