When you are looking at simulations inside SimulationsMain/, there may be multiple Config files that load in different packages for one simulation at different levels of the directory. For example, if we look at the example SimulationMain/magnetoHD/Torus/
which simulates an accretion torus (donut) with a point mass (black hole or young star) at its center, when you compile it looks at all the Config
s in the other modules:
SimulationMain/magnetoHD/Torus/Config
: loads in gravitational pointmass potential to be place at the center of the TorusSimulationMain/magnetoHD/Config
: loads in 8 wave solver for MHDSimulationMain/Config
: loads in basic Hydro stuffWhen making small changes to the F90 files, rather than changing the F90 files inside SimulationMain/<Simulation-module>/
, it is often faster to change the copy of the F90 source code inside object/
, then make
compile the source inside object/. If only the object/flash.par is changed, then no compilation is necessary (which is useful when restarting a run). This also seems to automatically copy the updated F90 files to SimulationMain/<Simulation-module>/
, but note that the flash.par will not be updated.
For some hydro solvers, the minimum pressure, energy, density, or any scalar value stored in the simulation can not be smaller than the default 1E-10. This means that if these values every drop below 1E-10, the values would just be coerced to raise up to 1E-10. This can be problematic for astrophysical simulations, where the densities that we are dealing with (even in a "dense" core) is on the order of 1E-19. So we need to override these default values with a lower density cutoff inside Config
:
D tiny Threshold value used for numerical zero
PARAMETER tiny REAL 1.e-30
D smallt
PARAMETER smallt REAL 1.e-30
D smallp
PARAMETER smallp REAL 1.e-30
D smalle
PARAMETER smalle REAL 1.e-30
D smlrho
PARAMETER smlrho REAL 1.e-30
Then when you do setup, you should see something like this:
INFO: Parameter smallp defined in both
physics/Hydro/HydroMain/unsplit (default 1.E-10) and
Simulation/SimulationMain/RotatingSinkSphere (default 1.e-30)
Simulation instance overrides; removing other instance.
Generally, "grepping" around the object/
directory can often be helpful to understand what part of the source code is actually loaded into your simulation and causing the error.
grep -rnw 'object/' -e '<matching-strings>'
Terminating execution. DRIVER_ABORT: Nonconvergence in subroutine rieman
DRIVER_ABORT: ERROR: cannot locate real runtime parameter.
RuntimeParameters_read: ignoring unknown parameter "<variable-name>
should give a good clue to where to start lookingToo many blocks! Increase MAXBLOCKS or use more processors.
For example, I have 24 processors, then I could assign 2 processor in the x direction, 3 processors in the y direction, 4 processors in the z direction (Check that 2x3x4=24proc)
iProcs = 2
jProcs = 3
kProcs = 4
As a rule of thumb, if your simulation is symmetric, there is the same amount of work to be done in each direction, so it's best to keep the number of processors in each direction equal, so that the code has an easier time balancing the work load.