|
Quick Links
|
|
|
|
Cactus
|
|
|
|
Carpet
|
|
|
|
|
Whisky: Problems and how to fix them
Here are a few problems that you might come across when trying to
compile or run Whisky. If you find that your query isn't answered
below then please could you
-
Update your source tree (including BSSN_MoL, MoL and BAM if
necessary) to see if the bug has already been fixed.
-
If not, write to the
whisky users mailing list
including as many details as possible (machine, error messages,
particular thorns and/or parameters that cause the problem).
Compiling
Running
The code stops, complaining about the stencil width.
The size of the ghost zones needs to be correct both in Whisky and in
the driver. These are changed by the parameters
whisky::whisky_stencil
and
driver::ghost_size.
These must be at least 2. For PPM these must be at least 3. When ENO
is implemented they must be at least the order of the ENO
reconstruction.
Trying to run a "lower dimensional" test by reducing the size of the
box suddenly stops it doing any evolution.
Cactus uses internal ghosts zones. So to run a "1d" test in the x
direction you would set
driver::global_ny
to be
2*driver::ghost_size+1,
and similarly for
driver::global_nz.
The code stops, complaining that the specific energy is below zero
or the pressure has failed to converge.
These errors occur in the routine that converts between conservative
and primitive variables. The trouble is, it's difficult to tell
whether this is caused by a bug or not. Various possibilities
include
-
The code is "correct" but producing unphysical answers. Possible
fixes: decreasing the timestep (unlikely to work), increasing the
atmosphere factor (may lead to bad physics), increasing the
resolution.
-
There is a bug producing unphysical answers. This may not even be
a bug, but just an unfortunate choice of initial data, equations
and methods.
-
There is a bug generating NaN's. This can be really hard to spot,
as the enforcement of the atmosphere can merely mean that a NaN in
the update term leads to the point being atmosphere, causing
physical problems. To check if this is the case, try the parameter
mol::mol_nan_check =
"true".
This will check the update terms for NaNs, halting the code if any
are found.
In an evolution, suddenly large parts of the domain are set to the
atmosphere unphysically.
This probably indicates that a NaN has occured in the update
terms. The atmosphere condition forces this point to be reset, so the
NaN is "quietly lost". Why a NaN should be produced is more
complicated. Favourite possibilities are
-
the calculation of a zero speed of sound (check your equation of
state thorn) leading to a divide by zero error calculating the left
eigenvectors
-
a zero or NaN calculating the determinant of the spatial
3-metric. This seems to be machine / compiler dependent (where it
is unphysical).
|