eugvas
commented
1 week ago That's an excellent question! Indeed, one would normally need to have consistency in units. But in this case, one has an excuse: the INI file describing the potential has only the coefficients of Multipole and CylSpline expansions, which have a dimension of velocity^2 (i.e. potential) or velocity^2/length (its derivatives). Since the mass unit is not involved in the definition of the potential, one can load this potential in a different script and still obtain the acceleration field that can be interpreted as velocity_unit^2/length_unit, whatever the interpretation of these units are (including the case of not setting units at all, keeping G=1).
This would not be possible if the potential had some components that have mass or density among their parameters (virtually all potential types except Multipole/BasisSet/CylSpline expansions and the Logarithmic profile, which is also specified in terms of velocity rather than mass). If these are mixed with components specified in terms of velocity (e.g. Logarithmic) or given by expansion coefficients, then one needs to provide a correct scaling between all three dimensional units, which in practice means providing the value of G, so that the dimensional parameters of mass, density etc. will be multiplied by G.
N-body codes such as GyrfalcON, Gadget or Arepo can operate in the "natural" units with G=1, or in some other choice of units – the specific choice of length, velocity and mass scales does not matter, only the implied value of G is important.
Until now, the Agama plugin for GyrfalcON, Gadget or Arepo assumed that the N-body codes also operate in the "natural" units with G=1. These codes can work with G!=1, and in the latest commit I generalized the plugin to handle these cases as well. For Gadget and Arepo, the value of G is taken directly from the code (which in turn reads it from the params file or infers from other dimensional units specified there). For GyrfalcON, one can provide a command-line argument Grav=..., but it cannot be accessed from the Agama plugin, so needs to be duplicated in accpars=Omega,G (where the pattern speed Omega is usually zero).
The script example_nbody_simulation.py has been modified to remove the hard-coded mass unit of 232500 Msun and instead uses 1 Msun. As explained above, this has no effect in this particular case, since the potentia file MWPotentialHunter24_full.ini contains no mass or density parameters, but it should now work also when providing other INI files, e.g. McMillan17.ini
savchenkoyana
Hello Eugene Vasiliev,
I have a question about Agama units, could you please help me out? 🙏
There is a script called example_nbody_simulation.py. It creates a snapshot in N-body units (length = 1 kpc, velocity = 1 km/s, mass = 232500 Msun) and then evolves it in an external gravitational potential. My confusion comes from the fact that this external potential is created using another units: (1 kpc, 1 Msun, 1 km/s) and in the example nothing is done to take that into account.
My quenstion is: Is it okay to use potential that is created with another physical units? Or you need to transform the snapshot first?
Speaking of the example script, I would have expected you to:
Am I wrong?