$$Date$$

Abstract

The Cartoon2D thorn allows fully 3D codes to be used to model axisymmetric systems, by considering a 3D evolution which is only one plane thick and applying a rotational tensor transformation to the ﬂat faces of the plane as a boundary condition. This allows 3D codes to be tested eﬃciently on 2D problems, as well as providing a means of carrying out axisymmetric evolutions in cartesian coordinates without problems at the axis.

The Cartoon2D thorn is the implementation of an idea ﬁrst presented in [1]. The principle is to use a 3-dimensional Cartesian $\left(x,y,z\right)$ coordinate grid which covers the $y=0$ plane, but is only one ﬁnite diﬀerence molecule in width in the $y$-direction. The ﬁeld variables in the $y=0$ plane can be updated using standard 3D $\left(x,y,z\right)$ coordinate ﬁnite diﬀerencing, with oﬀ-plane derivatives calculated by performing appropriate rotations of ﬁeld variables using the axisymmetic assumption. This technique has the advantage of removing a number of the axis problems normally associated with axisymmetric codes.

The ‘cartoon’ method was ﬁrst implemented in Cactus3 by Steve Brandt and Bernd Brügmann, and was translated to Cactus4 by Sai Iyer. Details of the method can be found in [1]. This document provides a practical guide to using the thorn as it is currently implemented.

Only a small number of parameters need to be set to use Cartoon2D.

- cartoon_active
- A ﬂag which determines whether or not the cartoon boundary condition should be applied. This should be set to “yes” to use Cartoon2D, otherwise the evolution will be assumed to be standard 3D.
- order
- Determines the order of interpolations to be carried out. This will determine the number of ghost zones that you need to specify in the $y$-direction.
- allow_grid_resize
- When this ﬂag is set to “yes”, Cartoon2D is allowed to modify the grid sizes speciﬁed in the parameter ﬁle so that a cartoon-compatible grid is used. See below.
- verbose
- Causes Cartoon2D to print a lot of messages.

For example, the following is a section of a parameter ﬁle which sets up a cartoon-style grid in bitant mode.

activethorns = "cartoon2d cartgrid3d pugh"

cartoon2d::cartoon_active = "yes"

cartoon2d::order = 3

cartoon2d::allow_grid_resize = "yes"

grid::type = "byspacing"

grid::domain = "bitant"

grid::bitant_plane = "xy"

grid::dxyz = 0.2

driver::global_nx = 16

driver::global_ny = 3

driver::global_nz = 16

driver::ghost_size_x = 2

driver::ghost_size_y = 1

driver::ghost_size_z = 2

driver::processor_topology = "manual"

driver::processor_topology_3d_x = 1

driver::processor_topology_3d_y = 1

driver::processor_topology_3d_z = 2

grid::avoid_originy = "no"

The following features are worth noting:

- The order parameter speciﬁes that 3rd order interpolation is to be used. This requires that only one ghost zone is required in the y direction (ghost_size_y). If 4th order interpolation was speciﬁed, then two ghost zones would be required.
- The allow_grid_resize ﬂag has been set, allowing Cartoon2D to modify the grid appropriately so that, for instance, it only extends a given number of ghost zones beyond the $z$-axis.
- The bitant plane should always be “xy”, which means that only the positive $z$-axis is evolved and a reﬂection boundary is imposed along $z=0$.
- Though not necessary, it is often helpful to specify the processor topology explicitly to ensure that that only one processor is allocated to the $y$ direction, and that the processors in the $x$ and $z$ directions reﬂect the relative lengths of these axes (though in this example it doesn’t matter which of these axes gets two processors).
- The avoid_originy parameter needs to be turned oﬀ so that the cartoon plane corresponds to $y=0$.

Also, it is important to keep in mind that other thorns may also require their own parameters to be set in order to interact appropriately with Cartoon2D. For instance, see Section 4. Examples of working parameter ﬁles can be found in the Cartoon2D/test/ directory.

The Cartoon2D thorn has some non-standard requirements of the grid which is normally set up by the grid implementation (for instance, by CartGrid3D). In particular,

- the grid in the $y$ direction should be exactly one plane in width, plus twice the number of $y$ ghost zones.
- the grid in the $x$ direction only needs to extend to the $z$-axis, plus a few extra hang-overs. The number of extra points is determined by the number of $y$ ghost zone points.

These requirements (in particular the second) can not be met if the grid is speciﬁed byspacing (ie. by giving a $dx$ value), since in this case the grid is set up assuming that the axes should be centred in each grid direction.

One way to get around this is to specify the grid byrange, giving minimum and maximum coordinate values for each axis so that the $\left(dx,dy,dz\right)$ values are determined by dividing the range by the number of grid points. However, using this method it can be quite complicated to ensure that the grid spacing is even in each direction and that an appropriate number of ghost points extend past the $z$ axis.

A simple hack to get around this complication is to specify the grid byspacing, but to set the allow_grid_resize parameter. In this case, the $\left(dx,dy,dz\right)$ values can be set in the parameter ﬁle, and the grid ranges will be calculated based on the above criteria. Note that this involves modifying the “standard” behaviour of the CartGrid3D thorn (to place the $z$-axis along one edge of the grid). This is accomplished by internally resetting the grid type to byrange, and then specifying ranges which are compatible with the cartoon conditions and with the appropriate number of grid points and ghost zones. Note that this involves a reset of otherwise non-steerable parameters, and so must be scheduled at CCTK_RECOVER_PARAMETERS and before the grid is set up.

Some thorns will need to know that a cartoon grid is being used in order to function properly. In principle, they should use the cartoon_active parameter to check whether a cartoon grid is in use.

In practice, however, to avoid dependencies on Cartoon2D, it is often the case that the source code for such thorns make use of #ifdef statements to check whether Cartoon2D has been compiled in. Then, to check whether a cartoon grid is active, other thorn-speciﬁc parameters need to be set. For instance, if the ADM_BSSN thorn is being used for evolution, then the parameter

adm_bssn::cartoon = "yes"

must be set. Similarly, the ADM evolution system requires adm::cartoon to be set. The AHFinder thorn requires that the parameter

ahfinder::ahf_cartoon = "yes"

be set in order to use a cartoon grid.

Note that many thorns will require cartoon-speciﬁc modiﬁcations in order to be used with the Cartoon2D thorn. It should not be assumed that a given thorn will work with Cartoon2D unless it is speciﬁcally mentioned in the documentation or source code.

The interface to the Cartoon2D thorn is through the routines contained in the Cartoon2DBC.c source ﬁle. These routines can be used by other thorns (eg. evolution thorns) to apply cartoon boundary conditions to grid functions whenever it is appropriate to do so. The three interface functions are:

- BndCartoon2DGN(cGH *GH, int tensortype, const char* group)
- This function applies the cartoon
boundary condition to the grid functions in the group speciﬁed by the group parameter. The tensortype
argument parameter should be one of
- TENSORTYPE_SCALAR
- a scalar;
- TENSORTYPE_U
- a vector (single, upper index);
- TENSORTYPE_DDSYM
- a symmetric tensor with two lower indices.

- BndCartoon2DVN(cGH *GH, int tensortype, const char *impvarname)
- This function is like BndCartoon2DGN(), but operates on individual grid functions rather than groups.
- BndCartoon2DVI(cGH *GH, int tensortype, int vi)
- This function is like BndCartoon2DGN(), but operates takes a grid function index to indicate the grid function to which the condition should be applied.