Frequently Asked Questions

Is the new version of BOUT++ ready?

Yes; the new version is pretty stable now, and the examples compile and run. To get a copy run:

git clone git://github.com/boutproject/BOUT.git

and see how it differs from your current version. Probably the most
noticeable changes are:

1. You no longer need to create a second variable like F_Ni to store the
time-derivative: If you have a derivative Ni then the time derivative is
ddt(Ni) which is handled automagically. The equations now look like

ddt(rho) -= vE_Grad(rho, phi);

2. The communication: You no longer need to create a Communicator object
then run it later. Instead, you can just call mesh→communicate with one or
more fields as argument e.g.

mesh->communicate(jpar);

If you want to communicate lots of variables then the old functionality is
now done by creating a FieldGroup, adding fields to it then calling
mesh->communicate with the FieldGroup object.

3. The boundary conditions are now handled completely differently. You’ll
see in the BOUT.inp file that the boundaries are now specified by strings
like

bndry_all = relax(neumann)

which produces a boundary which relaxes to a Neumann condition. If you want
to just write your own custom boundary conditions then that’s still fine
too and you can just set the boundary condition in BOUT.inp to “none”.

There’s quite a bit of detail on these changes in the user and developer
manuals, but as always there’s still lots to add

What do UDATA_XSPLIT, DDATA_XSPLIT do?

The variables UDATA_* and DDATA_* specify the communication topology: Each
processor can be connected to up to 2 neighbours on the lower and upper Y
boundaries. UDATA_* refer to the boundary going Up in Y, and DDATA_* to the
boundary going Down in Y. _XSPLIT gives the number of points in the inner X
part of the boundary, whilst the _*DEST is the procesor to send to:

On the upper boundary:

Send data for x < UDATA_XSPLIT to processor UDATA_INDEST
Send data for x >= UDATA_XSPLIT to processor UDATA_OUTDEST

and similarly for DDATA*

When there is no processor to send to then it means we’re on a boundary and
hence why there are lines like “if(UDATA_INDEST < 0)” which should ensure
that boundary conditions are only applied on the actual boundaries.

What is time normalised to?

BOUT++ is a framework for writing simulations, not a single simulation.
It is divided into two components: A core library and physics models. The core library doesn’t know
or care what the quantities it’s manipulating mean physically, but just treats them as numbers to be manipulated.

What this means is that the normalisation used for lengths, time etc. depend on the physics model code,
the equations coded up in the physics_run() function. Each example simulation should document the normalisations
used, either in a manual or the source code. Currently this is a little patchy, but improving.

Common choices are to normalise to the ion cyclotron frequency wci (2fluid.cpp and cousins), or to an Alfven time (Length scale / Alfven speed)