Quick Links
EU Network
Cactus

 

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
  1. Update your source tree (including BSSN_MoL, MoL and BAM if necessary) to see if the bug has already been fixed.
  2. If not, complain to me including as many details as possible (machine, error messages, particular thorns and/or parameters that cause the problem).

Compiling

When using the GetCactus script it puts the MoL directories in the wrong places.
This is a problem with old versions of the script. Download the latest version and it should be fixed.
When compiling on a Linux machine there are numerous errors in compiling a Fortran routine (favourites include NewRad.F or Sources.F in BSSN_MoL, or ADMConstraints.F in ADMConstraints). One of the first errors says invalid character in label field.
This is a problem (which isn't strictly a bug) with the C preprocessor. Two possible solutions are given on the Cactus web pages.
When compiling on a non-Linux machine there are numerous errors as above.
This usually indicates that I forgot to include a carriage return at the end of a file in Whisky. I hope that I've found all of these by now; if updating the distribution doesn't help then complain to me.

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
  1. 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
  2. a zero or NaN calculating the determinant of the spatial 3-metric. This seems to be machine / compiler dependent (where it is unphysical) and I'm not yet certain of the reason.
When restoring a saved model in RNSID it produces nonsense initial data.
There are two possibilities.
  1. A NaN is produced, or a spike at the center of the star. This is a known problem if there is a point lieing exactly on the origin. We hope to fix this soon. For the moment, ensure that the parameter driver::avoid_origin is either set to "yes" or unset.
  2. Something that looks like a smeared star appears. This is due to the model using a different size 2d grid to your currently defined grid size. Either alter the size of the 2d grid in RNSID (which means changing the constant SDIV and MDIV in Whisky_RNSID/src/include/consts.h and recompiling) or use your current version of RNSID to generate a new model. We hope to fix this as well.
When running on a DEC machine the code stops in Whisky_TOVSolver complaining that the grid is too small, giving a nonsense number, or core dumps.
This is a problem of the Digital Fortran 90 compiler; it's known to occur with version V5.2-705 which is installed on the holodec machines at the AEI. IH thinks that all the fixes are more dangerous than the current version, so this will not be changed. The thorn Whisky_TOVSolverC should be used instead.


This page is maintained by Ian Hawke.

Impressum.