Running hera-sim-vis from the command line

As of v2.4.0 of hera_sim, we have included a command-line interface for performing visibility simulations using any compatible visiblity simulator. The interface for the script is (this can be run from anywhere if hera_sim is installed):

$ hera-sim-vis.py --help
usage: hera-sim-vis.py [-h] [--object_name OBJECT_NAME] [--compress COMPRESS]
                       [--normalize_beams] [--fix_autos]
                       [--max-auto-imag MAX_AUTO_IMAG] [-d] [--run-auto-check]
                       [--profile] [--profile-funcs PROFILE_FUNCS]
                       [--profile-output PROFILE_OUTPUT]
                       [--log-level {INFO,ERROR,WARNING,CRITICAL,DEBUG}]
                       [--log-width LOG_WIDTH] [--log-plain-tracebacks]
                       [--log-absolute-time] [--log-no-mem]
                       [--log-mem-backend {tracemalloc,psutil}]
                       [--log-show-path]
                       obsparam simulator_config

Run vis_cpu via hera_sim given an obsparam.

positional arguments:
  obsparam              pyuvsim-formatted obsparam file.
  simulator_config      YAML configuration file for the simulator.

options:
  -h, --help            show this help message and exit
  --object_name OBJECT_NAME
                        Set object_name in the UVData
  --compress COMPRESS   Compress by redundancy. A file name to store the
                        cache.
  --normalize_beams     Peak normalize the beams.
  --fix_autos           Check and fix non-real xx/yy autos
  --max-auto-imag MAX_AUTO_IMAG
                        Maximum fraction of imaginary/absolute for autos
                        before raising an error
  -d, --dry-run         If set, create the simulator and data model but don't
                        run simulation.
  --run-auto-check      whether to check autos are real

Options for line-profiling:
  --profile             Line-Profile the script
  --profile-funcs PROFILE_FUNCS
                        List of functions to profile
  --profile-output PROFILE_OUTPUT
                        Output file for profiling info.

Options for logging:
  --log-level {INFO,ERROR,WARNING,CRITICAL,DEBUG}
                        logging level to display.
  --log-width LOG_WIDTH
                        width of logging output
  --log-plain-tracebacks
                        use plain instead of rich tracebacks
  --log-absolute-time   show logger time as absolute instead of relative to
                        start
  --log-no-mem          do not show memory usage
  --log-mem-backend {tracemalloc,psutil}
  --log-show-path       show path of code in log msg

Two main configuration files are required. The first is an “obsparam” file, which should follow the formatting defined by pyuvsim. As described in the visibility simulator tutorial, the hera_sim.visibilities module provides a universal interface between this particular configuration setup and a number of particular simulators.

To specify the simulator to be used, the second configuration file must be provided. An example of this configuration file, defined for the VisCPU simulator, can be found in the repo’s config_examples directory. Here are its contents:

$ cat -n ../config_examples/simulator.yaml
     1	simulator: MatVis
     2	precision: 2
     3	ref_time: mean
     4	correct_source_positions: true

Notice that the file contains a simulator: entry. This must be the name of a simulator derived from the base VisibilitySimulator class provided in hera_sim. Usually, this will be one of the built-in simulators listed in the API reference under “Built-In Simulators”.

However, it may also be a custom simulator, defined outside of hera_sim, so long as it inherits from VisibilitySimulator. To use one of these via command line, you need to provide the dot-path to the class, so for example: my_library.module.MySimulator.

The remaining parameters are passed to the constructor for the given simulator. So, for example, for the VisCPU simulator, all available parameters are listed under the Parameters section of its class API. In general, the class may do some transformation of the YAML inputs before constructing its instance, using the from_yaml_dict() method. Check out the documentation for that method for your particular simulator to check if it requires any transformations (eg. if it required data loaded from a file, it might take the filename from the YAML, and read the file in its from_yaml_dict() method before constructing the object with the full data).