Quick Links


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, the other Cactus thorns your are using, and Carpet, if necessary) to see if the bug has already been fixed.
  2. 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).



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).

This page is maintained by Bruno Giacomazzo, Frank Löffler, and Luciano Rezzolla.