Phantom Run: MOND Galaxy Simulations

• Phantom Run is a simulation workflow integrating the Phantom of RAMSES patch into RAMSES to perform MOND (or Newtonian) disc-galaxy simulations.
• It leverages adaptive mesh refinement, customized initial conditions with modified DICE, and consistent runtime configurations to accurately model baryonic dynamics.
• The process demands careful control of gravity patches, resource limits, and parameter settings to ensure numerical stability and meaningful scientific outcomes.

Searching arXiv for papers relevant to “Phantom Run,” especially Phantom of RAMSES and its simulation workflow. “Phantom Run” denotes the practical workflow for setting up, executing, and analysing galaxy simulations with Phantom of RAMSES (PoR), a MOND-capable patch to the grid-based RAMSES code. PoR is not a standalone code; it is a customized version of RAMSES that replaces RAMSES’s standard gravity treatment with a MOND Poisson solver when desired, while retaining RAMSES’s strengths in adaptive mesh refinement (AMR), particles, hydrodynamics, and star formation (Nagesh et al., 2021). In this usage, a phantom run can be performed in Milgromian dynamics (MOND/QUMOND) or in ordinary Newtonian gravity, and is especially suited to disc-galaxy simulations with baryons only, including isolated and interacting systems (Nagesh et al., 2021).

1. Definition and computational scope

Within the PoR manual, the operative meaning of a phantom run is a simulation campaign carried out by combining a patched RAMSES executable, MOND-aware disc-galaxy initial conditions, a problem-specific namelist, and post-processing tools (Nagesh et al., 2021). The code implements QUMOND, and in MOND the modification becomes relevant below the acceleration scale

$a_0 = 1.2\times 10^{-10}\,\mathrm{m\,s^{-2}},$

with the deep-MOND limit summarized by

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$

In PoR, the MOND potential $\Phi$ satisfies

$$\nabla^2 \Phi \equiv -\nabla\cdot \mathbf{g} = -\nabla\cdot(\nu\,\mathbf{g}_\mathrm{N}),$$

while the Newtonian field is obtained from

$\nabla\cdot \mathbf{g}_\mathrm{N} = -4\pi G\rho_b,$

using the “simple” interpolating function

$\nu(y)=\frac{1}{2}+\sqrt{\frac{1}{4}+\frac{1}{y}}.$

For isolated systems, the far-field MOND boundary condition is the logarithmic potential

$\Phi \sim \sqrt{GMa_0\ln R},$

rather than a Newtonian $1/r$ asymptotic form (Nagesh et al., 2021).

This computational framing matters because PoR is designed to evolve stars and gas self-consistently without dark matter haloes. A plausible implication is that the phrase “phantom run” refers less to a single executable mode than to a numerically consistent end-to-end procedure for MOND or Newtonian disc-galaxy evolution inside the RAMSES ecosystem.

2. Code architecture and relation to earlier MOND solvers

PoR is presented as part of a longer development line of MOND simulation software. The manual notes the first multigrid Milgromian $N$-body code by Brada & Milgrom, used for disc stability and for warps via the external field effect (EFE); the Tiret et al. AQUAL solver extended to gas via sticky particles; n-mody, which solved the MOND equation in spherical coordinates and was used for dynamical friction, orbit instabilities, and stellar kinematics; cosmological MOND solvers by Llinares, Angus, and collaborators; and raymond, which implemented both AQUAL and QUMOND for cosmology and galaxy-cluster problems (Nagesh et al., 2021). The manual’s stated limitation of many earlier codes is that they are specialized and may not handle generic mixtures of particles, gas, and star formation.

PoR’s distinctive role is precisely that it patches RAMSES so those components can be evolved in one framework (Nagesh et al., 2021). Because RAMSES already provides AMR, particles, hydrodynamics, and star-formation modules, PoR changes the gravity sector while inheriting the rest of the baryonic machinery. This suggests that the operational difficulty of a phantom run lies mainly in keeping the gravity patch, the initial-condition generator, and the runtime namelist mutually consistent.

3. Installation and compilation workflow

The recommended setup is RAMSES 2015, because later RAMSES versions are not compatible with the PoR patch (Nagesh et al., 2021). RAMSES is compiled from its bin directory by editing the makefile, with settings such as:

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$3

and a patch chosen according to the target problem. For particle-only MOND or Newtonian simulations, the relevant patch is

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$4

whereas for hydrodynamical MOND simulations the patch is

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$5

The manual stresses that only one patch should be active at a time (Nagesh et al., 2021). A Newtonian run still uses the phantom patch but sets mond = .false. in the namelist (Nagesh et al., 2021).

Compilation uses MPI-capable Fortran settings such as

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$6

followed by make. If needed, one can clean and recompile with:

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$7

The manual also cautions that some parameter-file details may differ from the modern code base, so unfamiliar parameters should not be edited blindly (Nagesh et al., 2021).

4. Initial conditions and problem classes

PoR relies on a modified version of DICE (Disk Initial Conditions Environment) for galaxy initial conditions (Nagesh et al., 2021). Two versions are distinguished:

• p-dice in dice_particle for particle-only disc models
• h-dice in dice_gas for gas + stars

Both are adapted to MOND and compiled with the usual CMake workflow after installing CMake, GSL, and FFTW (Nagesh et al., 2021). The example package contains configurations for MW, M31, and M33, but those are the cases the authors state are “rated to work” (Nagesh et al., 2021). A Milky Way-like example uses a configuration such as:

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$8

with the redshift entry unused in the MONDified DICE (Nagesh et al., 2021). Running DICE is then

$$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$9

which produces, for particle-only runs, a file such as Milky_Way_output_p2_k0.txt; for hydrodynamics it also outputs Milky_Way_rotation_curve.txt (Nagesh et al., 2021).

For a particle-only isolated disc, the workflow is explicitly:

1. compile RAMSES with phantom_staticparts,
2. generate the DICE particle IC file,
3. feed that file into PoR using a namelist such as PoR-static.nml (Nagesh et al., 2021).

A representative namelist includes the mandatory blocks:

• RUN_PARAMS
• AMR_PARAMS
• OUTPUT_PARAMS
• INIT_PARAMS
• POISSON_PARAMS
• BOUNDARY_PARAMS

with MOND-specific switches

$\Phi$0

and Poisson controls

$\Phi$1

The particle-only patch integrates particles below a threshold mass, while particles above m_threshold remain static but still contribute to the Newtonian field $\mathbf{g}_\mathrm{N}$ used by the MOND solver. If all stars are intended to evolve, the manual suggests choosing an extremely large threshold like $$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$0 (Nagesh et al., 2021).

For a hydrodynamical isolated disc without star formation, PoR uses h-dice and a more elaborate setup. The Milky Way parameter file is modified with entries such as

$\Phi$2

The manual emphasizes that this gas temperature is not literally a thermodynamic temperature but a velocity-dispersion-like parameter controlling stability, and it should match the PoR namelist parameter T2_ISM (Nagesh et al., 2021). It also states that the gas fraction must exceed the outer-disc mass fraction used by DICE, about 17.64% in the default setup, because of how h-dice distributes gas between components (Nagesh et al., 2021).

5. Runtime control, AMR parameters, and numerical caveats

The AMR controls given in the manual are central to a successful phantom run:

$\Phi$3

with the note that ngridmax and npartmax should be of order $$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$1 to avoid memory errors (Nagesh et al., 2021). The output schedule may be set through entries such as

$\Phi$4

A run can be launched with MPI, for example

$\Phi$5

or without MPI:

$\Phi$6

The manual warns that SEGSEV / invalid memory reference errors usually indicate npartmax or ngridmax that are too small; suggested fixes are to increase them, sometimes up to npartmax ~ [10](https://www.emergentmind.com/topics/supersymmetric-su-10-chiral-gauge-theory)^7 and ngridmax ~ 8\times 10^6, although these are stated as upper practical limits (Nagesh et al., 2021). Restart support is built in: if a run stops at output 45, one sets nrestart = 45 and resumes (Nagesh et al., 2021).

These details define the most practical meaning of phantom run: it is a RAMSES-based production run under the PoR patch, where resource limits, patch selection, and physics switches directly determine whether the evolution is numerically meaningful.

6. Hydrodynamics, star formation, Newtonian mode, and the external field effect

For hydrodynamical runs, PoR often uses the merger-template condinit from RAMSES’s hydro/merger patch (Nagesh et al., 2021). Although this template normally sets up two disc galaxies, an isolated-galaxy configuration can be obtained by turning off the second system through parameter choices such as

$\Phi$7

while placing the primary galaxy at the box center and using

$\Phi$8

for isolated runs (Nagesh et al., 2021). A representative namelist excerpt includes

$\Phi$9

The gas component is not taken directly from DICE’s output; PoR reads the rotation-curve file and uses namelist parameters such as gas mass and temperature to construct the gas distribution internally. The manual therefore stresses that DICE and PoR settings must be made mutually consistent (Nagesh et al., 2021).

The external field effect is available in the hydro patch, and Activate_g_ext = .false. turns it off (Nagesh et al., 2021). The same numerical machinery can also be operated in Newtonian mode by setting mond = .false., which allows direct MOND-versus-Newtonian comparisons within essentially the same framework (Nagesh et al., 2021).

For hydrodynamical runs with star formation, PoR inherits RAMSES’s baryonic treatment and adds the PHYSICS_PARAMS block with standard RAMSES controls, for example:

$$\nabla^2 \Phi \equiv -\nabla\cdot \mathbf{g} = -\nabla\cdot(\nu\,\mathbf{g}_\mathrm{N}),$$0

The crucial switch is t_star: if finite and non-zero, star formation is active (Nagesh et al., 2021). Since PoR only alters the gravitational solver, the hydrodynamic and star-formation modules remain RAMSES’s own.

7. Analysis pipeline and scientific applications

Post-processing is performed with extract_por or extract_por_sfr, utilities that read RAMSES outputs and produce particle data products and optional plots (Nagesh et al., 2021). Installation is a simple

$$\nabla^2 \Phi \equiv -\nabla\cdot \mathbf{g} = -\nabla\cdot(\nu\,\mathbf{g}_\mathrm{N}),$$1

The main configuration file is fmtRAMSES.par, which includes the path to the output directory, the output number to read, the number of CPU threads, optional center-of-mass reset, radial binning settings, and image or plot settings (Nagesh et al., 2021). A typical extraction setup is

$$\nabla^2 \Phi \equiv -\nabla\cdot \mathbf{g} = -\nabla\cdot(\nu\,\mathbf{g}_\mathrm{N}),$$2

The resulting output files include:

File	Content	Notes
part.asc	particle data in ASCII	columns 1–3 position, 4–6 velocity, 7 mass, 8 particle ID
sfr.dat	star-formation rate data	column 1 time interval in Myr, column 2 SFR in $$g \approx \sqrt{g_\mathrm{N} a_0}\qquad \text{for } g_\mathrm{N}\ll a_0.$$2
image.dat	optional image data	may be plotted with gnuplot

The SFR is computed by comparing stellar mass between snapshots, so higher temporal resolution can be obtained by reducing delta_tout during the run or by extracting particle birth times (Nagesh et al., 2021). For visualization, the manual recommends grayscale (1:gray) for ordinary cases rather than rgb modes, and suggests tuning the binning radius and image field of view for better resolution (Nagesh et al., 2021). A corresponding plotting command is

$$\nabla^2 \Phi \equiv -\nabla\cdot \mathbf{g} = -\nabla\cdot(\nu\,\mathbf{g}_\mathrm{N}),$$3

The manual also describes a random-turbulence option based on square-square subdivision, conceptually similar to diamond-square terrain generation but intended to give higher-quality 3D randomness with fewer artifacts (Nagesh et al., 2021). It is controlled by extra MERGER_PARAMS entries such as

$$\nabla^2 \Phi \equiv -\nabla\cdot \mathbf{g} = -\nabla\cdot(\nu\,\mathbf{g}_\mathrm{N}),$$4

with flg_qqm3d = -1 meaning off, while the accompanying file qqm3d.par specifies recursion details and the power spectrum (Nagesh et al., 2021). The manual notes that only certain hr_mode values should be used for science: hr_mode = 4 uses the power-spectrum weights, and hr_mode = 10 uses a flat spectrum (Nagesh et al., 2021).

PoR has been used for polar ring galaxies, Antennae-like encounters, Sagittarius and Palomar 5 tidal streams, satellite-plane formation in the Local Group, spontaneous disc formation in collapsing gas clouds, and M33’s long-term evolution (Nagesh et al., 2021). In that sense, a phantom run is not a narrow technical mode but a reusable MOND simulation workflow with broad applicability to baryonic galaxy dynamics.

A common misconception is that PoR is a separate simulation code or a MOND-only package. The manual states instead that it is a patch to RAMSES, and that the same infrastructure can be run in Newtonian mode by setting mond = .false. (Nagesh et al., 2021). Another misconception is that DICE alone defines the gas disc; in the hydro workflow, PoR constructs the gas distribution internally from the rotation-curve file and namelist parameters, so consistency between the two stages is essential (Nagesh et al., 2021).