EveryBeam Testing and Development¶
Click these links to go to notebooks of integration tests
Installing EveryBeam¶
The build instructions for EveryBeam live on the everybeam insallation page. However, you need to clone my branch as currently it’s the only branch with an MWA Python wrapper:
$ git clone -b mwa_python_wrapper --recursive -j4 https://git.astron.nl/RD/EveryBeam.git
When I ran cmake, I did:
cmake .. -DCMAKE_INSTALL_PREFIX=/home/jline/software/installed/ \
-DBUILD_WITH_PYTHON=ON
so I would know where the installation went. I also did all of this inside a conda environment called woden_dev, but I think cmake still found the system Python. Once installed, I had to do:
export PYTHONPATH=$PYTHONPATH:"/home/jline/software/installed/lib/python3.12/site-packages"
ln -s /home/jline/software/installed/share/everybeam /home/jline/software/anaconda3/envs/woden_dev/share/everybeam
which let me conda environment see everything it needed to.
When I was running notebooks, which don’t load stuff from system, only the conda environment, I had to do:
conda install -c conda-forge libstdcxx-ng
conda install hdf5
for certain things to work.
Work still to be done on EveryBeam in WODEN¶
I’ve managed to read the antenna locations from a measurement set, needed to calculate
u,v,wcoords. But I haven’t worked out where the central latitude/longitude are stored in the measurement set. At the moment you have to put that in via command line arguments. Something to figure out.You can only run one
WODENfrequency band at a time. This is becauseWODENis designed to calculate the beam values on GPU, iteratively band by band. It’s not the end of the world but a slight design flaw.Only certain frequencies exists in certain models. This means we don’t need to call EveryBeam for every single frequency. So create some kind of cache or map for the existing beam models to save compute.
Things are threaded over
EveryBeam now, but we still need more optimisation. CPU-only version?Unit tests. Mostly everything is an integration test at the moment. Best practice is to break down the testing into units.
Adding new beam models¶
You need to update the following Python functions to add a new EveryBeam model (in general, look for anywhere EB_OSKAR is already used, and make sure whatever is done with EB_OSKAR is also done with your new beam model):
Update the help for
--primary_beamin the parser defined inWODEN/wodenpy/wodenpy_setup/run_setup.get_parserto show a new recognised beam model. A.k.a add a “my_new_beam” as an accaptable argument to--primary_beam.Add this “my_new_beam” to the
eb_argslist inWODEN/wodenpy/wodenpy_setup/run_setup.check_args.Add a new beamtype to the
BeamTypesandBeamGroupsenums inWODEN/wodenpy/use_libwoden/beam_settings.py. You must also update the equivalente_beamtypeinWODEN/include/woden_struct_defs.h. E.g. MWA already has a value ofEB_MWA, so try adding in a newEB_YOURBEAM. If the beam model you add in has off-cardinal dipoles, you should add in to theBeamGroups.off_cardinal_beam_valueslist.Make sure your beam model is added to
woden_settingsin theWODEN/wodenpy/use_libwoden/woden_settings.create_woden_settingsfunction.Add a new function to load in the beam model in
WODEN/wodenpy/primary_beam/use_everybeam.py(similar toload_OSKAR_telescopeorload_LOFAR_telescope).In
WODEN/wodenpy/skymodel/read_fits_skymodel.read_fits_skymodel_chunks, ensure the new beam model initiated correctly.
You need to update the following GPU functions:
Ensure your beam model is added to
beam_settingsinWODEN/src/primary_beam.cAt the start of
calculate_visibilitiesinWODEN/src/calculate_visibilities.cpp, ensureuse_twobeams, num_beamsare set correctly for new beam.Wherever
copy_CPU_beam_gains_to_GPUis called inWODEN/src/calculate_visibilities.cpp, ensure that happens for your new beam model.Add your model to
WODEN/src/source_components.cpp.free_beam_gainsfunction to ensure the leakage terms are freed correctly.