-
Notifications
You must be signed in to change notification settings - Fork 1
Recent work and next steps
The Research Software Engineering group at the University of Exeter has been working to interface two pieces of computational astronomy, AMUSE and Arepo. We outline recent contributions by Stephen Cook, and some potential next steps. The main progress has been to enable two examples from Arepo to be run through AMUSE, albeit with restrictions.
This work was funded by DiRAC.
These notes were discussed at a close-out meeting on <2022-12-22 Thu>.
The principal progress made to date was to get two Arepo examples running through AMUSE, namely a collisionless galaxy (3D) and a Noh (3D) problem. In the following text we outline the steps taken to enable these two example, and the limitations of the code.
The following bullet-points highlight some of the steps taken to get the 3D collisionless galaxy Arepo example running in AMUSE:
- Set up a virtual machine with AMUSE and Arepo.
- Add calls to Arepo memory management functions in AMUSE initialisation.
- Add the example’s compiler flags to the AMUSE-Arepo interface makefiles.
- Intercept Arepo’s “final time” variable to only run for an amount of time specified by AMUSE.
- Add interface functions for accessing global and particle states (only get-functions).
- Copy an initial conditions (ICs) file from Arepo source (ICs file not added to source control, only a placeholder file).
- Write a python script to run the example simulation and plot the positions of a subset of the particles.
In addition to the steps taken above, the following bullet-points highlight the steps taken to enable the Noh 3D example running through AMUSE:
- Replace the collisionless galaxy compiler flags with the Noh-3D compiler flags in the AMUSE-Arepo interface makefiles.
- Add an interface function for setting-up the parameters for the example problem.
- Add interface functions for accessing gas-specific properties of density and pressure (as above, only the get-functions).
- Replace the previous initial conditions (ICs) file with the Noh-3D ICs file (again, binary file not included in source control).
- Write a second python script to run the example simulation and plot the position and relative density of a subset of particles.
Perhaps the most pressing limitations of the current code is the incomplete interface and the hard-coded aspects of the two examples.
In its current form, the interface is incomplete - functions to modify particles have yet to be written for creating, updating and deleting particles.
For the existing functions for reading the properties of particles, the codes returned for error states are inconsistent. In addition, the interface functions do not allow for co-moving frames of reference. There are certainly other Arepo modes of operating which are not properly handled.
The other main restriction in the code is the hard-coded compiler flags and run parameters.
Currently the Arepo compiler flags are hard-coded into the two AMUSE-Arepo makefiles. This means the whole Makefile must be edited to change the example being run (or indeed any other simulation), as well as there being duplication across the two Makefiles.
The parameter set for the Arepo collisionless galaxy example has been put into a “set parameters” interface function. The parameter set for the Noh 3D example has been put into a separate interface function. In each case, this can be considered part of the “incomplete interface” issue.
There are a number of other limitation which have yet to be explored. One such example is the snapshots created by Arepo, specifically HDF5 snapshots, which do not currently work (although it is not expected that this functionality will be used by AMUSE, and can thus be removed).
The range of Arepo compiler flag combinations has not been touched on;
this includes the co-moving frame of reference, mentioned above.
There may be scope to change a limited number of the Arepo IFDEF
compiler flags to runtime flags. Otherwise, there may be a set of
different AMUSE workers for different sets of Arepo flags.
- Populate the remaining interface functions.
- Address the inconsistent error-codes.
- Allow for fine-grained control of the parameters, but with default values.
- Develop a method for handling Arepo compiler flags.
- Explore the implications of Arepo compiler flags on the interface functions (such as a co-moving frame of reference and arbitrary mesh-movement).
These tasks can be further motivated by discussing with AMUSE users who may want to use Arepo.