iancze
commented
9 months ago I've now completed the reorganization of visread via visread #9. So the next steps here are to remove the mpol.utils.convert_baselines and mpol.utils.broadcast_and_convert_baselines routines from MPoL and change any tutorials or other scripts to use the visread.process.convert_baselines and visread.process.broadcast_and_convert routines.
Also move fourier.safe_baseline_constant_kilolambda and fourier.safe_baseline_constant_meters to visread.
Is your feature request related to a problem or opportunity? Please describe. The two utility routines
mpol.utils.convert_baselinesandmpol.utils.broadcast_and_convert_baselinesduplicate functionality that is provided by visread. This creates another source of code to maintain. IIRC, we originally duplicated this into MPoL this because a) we want to store visibility datasets using baselines measured in meters because if nchan > 1 it is a more efficient way to store them than lambda (all baselines are the same in meters, but lambda values change when observing frequency changes) and b) we don't want to require visread as a dependency of MPoL because as it's currently implemented, visread has a core dependency ofcasatools, which significantly restricts the ability to install MPoL into modern compute environments. However...Describe the solution you'd like ... I think a better solution is to reorganize visread into a set of minimal functionality (including these aforementioned routines) that does not require
casatools. The larger set of visread functionality can be maintained through apip install visread[casa]install, and cleanly separated into their own module imports. It may or may not make sense to add the minimal visread to the core set of MPoL dependencies, since this is not really core MPoL functionality, it's more of a data prep helper.How might you be able to help with the development of this feature? I'll do this to visread.