tΩqdΩ=Ωf(q)ndΩΩhgzb q=(hhuxhuy),f(q)=(huxhuyhux2+12gh2huxuyhuxuyhuy2+12gh2)


  • Green-Naghdi tΩqdΩ=Ωf(q)ndΩΩhgzb+h(gαηD) αh𝒯(D)+hD=b b=[gαη+𝒬1(u)]

Systems of conservation laws


tq+(qu)=p+(μu)+ρa tp+up=ρc2u


Other equations

General orthogonal coordinates

When not written in vector form, some of the equations above will change depending on the choice of coordinate system (e.g. polar rather than Cartesian coordinates). In addition, extra terms can appear due to the geometric curvature of space (e.g. equations on the sphere). An important simplification is to consider only orthogonal coordinates. In this case, consistent finite-volume discretisations of standard operators (divergence etc…) can be obtained, for any orthogonal curvilinear coordinate system, using only a few additional geometric parameters.

Metric scale factors

Metric scale factors

The face vector fm is the scale factor for the length of a face i.e. the physical length is fmΔ and the scalar field cm is the scale factor for the area of the cell i.e. the physical area is cmΔ2. By default, these fields are constant and unity (i.e. the Cartesian metric).

Several metric spaces/coordinate systems are predefined:

Output functions

Input functions

Tracking floating-point exceptions

On systems which support signaling NaNs (such as GNU/Linux), Basilisk is set up so that trying to use an unitialised value will cause a floating-point exception to be triggered and the program to abort. This is particularly useful when developing adaptive algorithms and/or debugging boundary conditions.

To maximise the “debugging potential” of this approach it is also recommended to use the trash() function to reset any field prior to updates. This will guarantee that older values are not mistakenly reused. Note that this call is quite expensive and needs to be turned on by adding -DTRASH=1 to the compilation flags (otherwise it is just ignored).


ulimit -c unlimited

before running the code will allow generation of core files which can be used for post-mortem debugging (e.g. with gdb).

Visualising stencils

It is often useful to visualise the values of fields in the stencil which triggered the exception. This can be done using the -catch option of qcc.

We will take this code as an example:

#include "utils.h"

int main()
  init_grid (16);
  scalar a[];
  trash ({a});
    a[] = x;
  vector ga[];
  gradients ({a}, {ga});

Copy and paste this into test.c, then do

ulimit -c unlimited
qcc -DTRASH=1 -g -Wall test.c -o test -lm

you should get

Floating point exception (core dumped)

Then do

gdb test core

you should get

Core was generated by `./test'.
Program terminated with signal 8, Arithmetic exception.
#0  0x0000000000419dbe in gradients (f=0x7fff5f412430, g=0x7fff5f412420)
    at /home/popinet/basilisk/wiki/src/utils.h:203
203		  v.x[] = (s[1,0] - s[-1,0])/(2.*Delta);

i.e. the exception occured in the gradients() function of utils.h.

To visualise the stencil/fields which lead to the exception do

qcc -catch -g -Wall test.c -o test -lm

you should now get

Caught signal 8 (Floating Point Exception)
Caught signal 6 (Aborted)
Last point stencils can be displayed using (in gnuplot)
  set size ratio -1
  set key outside
  plot 'cells' w l lc 0, 'stencil' u 1+3*v:2+3*v:3+3*v w labels tc lt 1 title columnhead(3+3*v), 'coarse' u 1+3*v:2+3*v:3+3*v w labels tc lt 3 t ''
Aborted (core dumped)

Follow the instructions i.e.

gnuplot> set size ratio -1
gnuplot> set key outside
gnuplot> v=0
gnuplot> plot 'cells' w l lc 0, 'stencil' u 1+3*v:2+3*v:3+3*v w labels tc lt 1 title columnhead(3+3*v), 'coarse' u 1+3*v:2+3*v:3+3*v w labels tc lt 3 t ''

With some zooming and panning, you should get this picture

Example of stencil/field causing an exception

Example of stencil/field causing an exception

The red numbers represent the stencil the code was working on when the exception occured. It is centered on the top-left corner of the domain. Cells both inside the domain and outside (i.e. ghost cells) are represented. While the field inside the domain has been initialised, ghost cell values have not. This causes the gradients() function to generate the exception when it tries to access ghost cell values.

To initialise the ghost-cell values, we need to apply the boundary conditions i.e. add

  boundary ({a});

after initialisation. Recompiling and re-running confirms that this fixes the problem.

Note that the blue numbers are the field values for the parent cells (in the quadtree hierarchy). We can see that these are also un-initialised but this is not a problem since we don’t use them in this example.

The v value in the gnuplot script is important. It controls which field is displayed. v=0 indicates the first field allocated by the program (i.e. a[] in this example), accordingly ga.x[] and ga.y[] have indices 1 and 2 respectively.

See also