xx Coordinate Base Thorn

Coordinate Base Thorn

Cactus Maintainers <cactusmaint@cactuscode.org>

Date

Abstract

CoordBase provides a mechanism for registering coordinate systems, and maintaining a database of coordinate systems and their coordinates, using key-value tables.

CoordBase also provides a way for specifying the extent of the simulation domain that is independent of the actual coordinate and symmetry thorns, and for specifying the discretisation of the boundary that is independent of the actual boundary thorns.

1 Introduction

Many applications which use Cactus will want to make use of coordinate systems. The CoordBase thorn provides a method of registering coordinate systems and their properties. Thorns which implement coordinate systems will register the systems they provide with CoordBase. Since coordinate systems are composed of a collection of coordinates, the coordinates which comprise the systems are registered with CoordBase as well. The data describing coordinate systems are held on Cactus key-value tables. A schema for the format of these tables is provided in section 6. Developers are free to compose and use their own schema, but are encouraged to use the one detailed here, as this will be the standard for all of the core Cactus thorns.

CoordBase specifies an extensible set of coordinate properties. The use of key-value tables to hold these properties makes CoordBase flexible and configurable. The coordinate values themselves can be specified in a number of ways, depending on the nature of the coordinate system. This way symmetries of the coordinates on the computational grid can be exploited to minimize memory consumption. Via a function call, one can easily ascertain what coordinate system is associated with any given grid variable, which is convenient for e.g.xI/O. A method of registering default coordinates for all grid variables of a certain dimension makes it simple to specify which coordinate systems should be associated with which grid variables.

The coordinate infrastructure provided by CoordBase will work seamlessly with AMR and multi-model codes.

Thorns which provide coordinates will inherit from CoordBase, and register both the coordinate systems they provide, and the default coordinate systems for the appropriate dimension of grid variables. In addition, one can associate a coordinate with any Cactus grid variable, within a thorn’s interface.ccl. Coordinate systems specified in the interface.ccl override defaults for the dimension.

The coordinate functions in the Cactus flesh are deprecated with the introduction of this thorn. Please use the functions provided here in preference to those in the flesh.

2 Coordinate system symmetries

Since computations performed with Cactus are done on a discrete lattice, only a discrete set of coordinate values are used for any coordinate system. The symmetries of how the coordinate values vary on the grid points make coordinates fall into three types: uniform, nonuniform, and warped. (At least these are the three cases that the CoordBase schema considers.) A uniform coordinate varies from each of its neighbors by a constant. i.e.xits value can be determined from the index of the grid point from simply an origin and constant ‘delta’. A nonuniform coordinate has a spatially varying ‘delta’. For both uniform and nonuniform coordinates, the coordinate values do not vary along the other directions of the grid. (e.g.xthe coordinate will be the same regardless of the ‘j’ index of the grid point.) Thus one could completely determine the coordinate values of a 3D system of nonuniform coordinates by providing three 1D arrays. This later assumption is relaxed for a warped coordinate; a warped coordinate will vary across the entire grid. Recall that ‘coordinate lines’ (lines of constant coordinate value) cannot cross (because one n-tuple of coordinate values would specify muliple points in space), so this places a ‘bound’ of sorts on the possible ‘warping’ of the coordinates.

The type of a coordinate system will be the same as that of its coordinates. If there are different types of coordinates within the same system, then the coordinate system is mixed. Note that a warped coordinate system is the most general possible, so any coordinate system could be regarded as warped if one wishes.

2.1 Specifying coordinate values

As mentioned above, for a uniform coordinate system, it is sufficient to specify the origin and spacing for a uniform coordinate. One may also specify a grid variable to hold the coordinate values, if desired. See section 6. A nonuniform coordinate can be specified with a 1D grid variable, if desired, or an nD variable. A warped coordinate system will always need a nD grid variable. FMR and AMR will need an nD grid variable to specify the coordinate values. A mixed coordinate system can use some combination of the above, or simply an nD grid variable.

3 Coordinate Thorns

Generally coordinate thorns will allow the declaration of default coordinate systems for a dimension to be controled by parameters.

If a thorn attempts to register a default for a dimension which already has a default registered, a level 1 warning will result, and the default will be overwritten with the new default. Since the order of execution of the registration calls will in general not be specified, one must be careful when activating more than one coordinate thorn.

Coordinate systems and defaults can be changed at any time throughout a run, as can coordinate properties. In general these are set at CCTKxWRAGHxand CCTKxBASEGRID, respectively.

The coordinate thorns are responsible for filling out the portions of the coordinate and coordinate system tables that are not written by the registration routines. See sections 6.1 and 6.2.

4 Application thorns

Application thorns should check at CCTKxPARAMCHECK to see if the correct coordinate system is being used for each relevant grid variable. While the old flesh API is still being used you may want to make this merely a warning. Use CoordxGroupSystem() to find the coordinate system for groups (see section 5 Coordinate APIs

CCTK_INTxsystemhandlex=xCoord_SystemRegister(CCTK_POINTER_TO_CONSTxGH,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_INTxdim,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_STRINGxsystemname)

registers a coordinate system, along with its dimension, with the CoordBase thorn. This will create a coordinate system table, and return the handle of the table for success, or a negative error code upon error. The possible errors are:

11COORDERRORxINVALIDDIM 11invalid dimension passed in
11COORDERRORxINVALIDNAME 11invalid name passed in
11COORDERRORxTABLEERROR 11error from key-value or hash tables in flesh
11COORDERRORxSYSTEMEXISTS11coordinate system of this name already exists

11

These error codes are defined in CoordBase.h. CoordBase holds the table handles on a GH extension, under the name “CoordBase”.

CCTK_INTxsystemhandlex=xCoord_SystemHandle(CCTK_POINTER_TO_CONSTxGH,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_STRINGxsystemname)

returns the handle for a given coordinate system, or negative on error:

11COORDERRORxTABLEERROR11error from hash table
11COORDERRORxNOSYSTEM 11no coordinate system of this name is registered

CCTK_INTxcoordhandlex=xCoord_CoordRegister(CCTK_POINTER_TO_CONSTxGH,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_INTxsystemhandle,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_INTxdirection,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_STRINGxcoordname)

registers a coordinate within a coordinate system, in the specified ‘direction’. (Direction in this context means the index in the coordinate basis, which ranges from 1 to the dimension of the system.) CoordxCoordRegister() returns the coordinate handle, or negative for an error:

11COORDERRORxINVALIDDIM  11invalid ‘direction’
11COORDERRORxINVALIDHANDLE  11invalid handle passed in / coordinate system does not exist
11COORDERRORxTABLEERROR  11error from hash or key-value tables in flesh
11COORDERRORxCOORDINATEEXISTS11coordinate already exists for this ‘direction’
11COORDERRORxDUPLICATENAME 11coordinate of this name already exists in this system

CCTK_INTxcoordhandlex=xCoord_CoordHandle(CCTK_POINTER_TO_CONSTxGH,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_STRINGxcoordname,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_STRINGxsystemname)

returns the coordinate handle for a given coordinatate in a coordinate system, or negative on error:

11COORDERRORxNOSYSTEM  11no coordinate system of this name is registered
11COORDERRORxTABLEERROR 11error from hash table
11COORDERRORxNOSUCHCOORD11no coordinate of the name is registered for this system

intxsystemhandlex=xCoord_GroupSystem(constxcGHx*GH,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxconstxcharx*groupname)

returns the handle for the coordinate system associated with a group of grid variables, or negative on error. This can either be the default for coordinate systems of this dimension, or the coordinate system that is specified in the interface.ccl. Coordinate systems specified in interface.ccl will override any defaults. The possible error codes are:

11COORDERRORxINVALIDGROUPNAME11no such group exists
11COORDERRORxNOCOORDSYS  11no coordinate system is associated with the group

CCTK_INTxsystemhandlex=xCoord_SetDefaultSystem(CCTK_POINTER_TO_CONSTxGH,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_STRINGxsystemname)

sets this coordinate system to be the default for grid variables of the same dimension. It returns the handle of the system, or negative for errors:

11COORDERRORxINVALIDNAME 11no coordinate system of this name has been registered
11COORDERRORxNODIMENSION 11coordinate system does not have a valid dimension
11COORDERRORxDEFAULTEXISTS11grid variables of this dimension already have a
11                               11default coordinate system registered

11

There can be a default coordinate system for each grid dimension. The default system will apply for each grid variable of that dimension, unless it is overridden.

CCTK_INTxsystemhandlex=xCoord_GetDefaultSystem(CCTK_POINTER_TO_CONSTxGH,
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCCTK_INTxdim)

gets the default coordinate system for grid variables of dimension dim (ranging from 1 to the maximum number of dimensions registered). It returns the handle of the system, or negative for errors:

11COORDERRORxINVALIDDIM11given dimension is invalid
11COORDERRORxNOSYSTEM 11given dimension does not have a default coordinate system associated

6 Coordinate Schema

6.1 Coordinate System Tables

Associated with each coordinate system is a table, which should have the following entries:

11key  11data type  11value

11NAME  11CCTKxSTRING 11Cart3d|Spher3d|....

11DIMENSION 11CCTKxINT  111,2,3,...

11TYPE  11CCTKxSTRING 11uniform|nonuniform|warped|mixed
11COORDINATES11CCTKxINT array11<coord1>,...<coord_dimension>

11

The values for the coordinates array are the handles for the coordinate tables (see section 6.2). The NAME and DIMENSION fields are filled out when CoordxSystemRegister() is called. The COORDINATES field is filled out by CoordxCoordRegister(). It is left for the coordinate thorn to fill out the TYPE field.

6.2 Coordinate Tables

Associated with each coordinate of each coordinate system is another table, which should have the following entries:

11key  11data type  11values

11SYSTEM  11CCTKxINT  11<handle>

11NAME  11CCTKxSTRING11x
11DIRECTION 11CCTKxINT 112
11PHYSICALMIN 11CCTKxINT  110
11COMPMIN  11CCTKxREAL 11
11PHYSICALMAX 11CCTKxINT  11
11COMPMAX  11CCTKxREAL 11

11TYPE  11CCTKxSTRING11uniform|non-uniform|warped
11TIMEDEPENDENT11CCTKxINT  11<yesx(1)|nox(0)>

11DATATYPE  11CCTKxSTRING11
11GAINDEX  11CCTKxINT  11

11DELTA1  11CCTKxREAL 11147.372e16

11

1only for type=uniform

CoordxCoordRegister() fills out the SYSTEM, NAME, and DIRECTION fields, and the COORDINATES field of the system table. The remaining fields are the responsibility of the coordinate thorn.

7 Specifying coordinate systems in the interface.ccl

Coordinate systems associated with grid variable groups can be specified in the group’s tags table, using the key COORDSYSTEM. Below is a grid array which could represent a vector field on a 2-sphere.

CCTK_REALxSphericalVectorFieldxTYPE=ARRAYxDIM=2xTAGS='COORDSYSTEM="sphere2d"xTENSORTYPE="vector"'
{
xxfield_theta,xfield_phi
}

Even though another thorn has set a default for all 2D grid variables to something else, CoordxGroupSystem() will always return the handle for sphere2d when called on this group.

8 Specifying the extent of the physical domain

CoordBase provides a way for specifying the extent of the simulation domain that is independent of the actual coordinate and symmetry thorns. This is necessary because the size of the physical domain is not necessarily the same as the size of the computational grid, which is usually enlarged by symmetry zones and/or boundary zones.

The physical domain is characterised by the location of its lower and upper boundary and by its grid spacing. These quantities are related to the extent and the number of grid cells that span the domain. The relation between the size of the domain and the size of the computational grid is defined in section 8 below. The domain extent as defined in this section is the continuum extent and is independent of the actual discretisation. This makes it possible to adapt the same domain specification for different resolutions by changing only a single parameter.

The domain is specified in one of the following ways, which is selected by the keyword parameter

domainsize:

minmax:

by the location of its lower and upper boundary

extent:

by its extent, i.e.xits width

spacing:

by grid spacing and the number of grid cells

The domain specification uses the number of grid cells instead of the number of grid points because the latter can easily lead to one-off errors.

The domain size in each dimension is specificied in equivalent ways. For example, the -dimension is specified by a set of some of the following parameters:

zeroxoriginxx (boolean):

When the domain size is specified by extent or by spacing, then the origin (lower boundary) can either be located at , which leads to the domain with the extent , or the domain can be symmetric with respect to , which leads to .

xmin and xmax:

When the domain is specified by the location of its lower and upper boundary, then these specify the locations.

xextent:

When the domain is specified by its extent, then this specifies the extent.

dx (real) and ncellsxx (int):

When the domain is specified by grid spacing and the number of grid cells, then these specify the grid spacing and the number of grid cells.

9 Specifying the location of the boundary points

CoordBase also provides a way for specifying the discretisation of the boundary that is independent of the actual boundary thorns. This defines the locations of the boundary points and thus the extent of the computational grid.

Each face of the grid is specified independently. The specification does not depend on the resolution, so that it need not be adapted when the resolution is changed. Figure 1 shows a domain with several interior grid points and one boundary point.

PIC Figurex1: A domain (rectangle) with three interior points (empty circles) and one boundary point (full circle).

While the physical boundary has a width of zero, the computational grid can have more than one boundary points. This boundary size is defined by the integer parameter boundaryxsizexxxlower for the lower boundary (and similarly for the other boundaries). Figure 2 shows an example where there are two boundary points. When it is necessary to increase the number of boundary points (e.g., to accommodate a larger stencil), then this is the only parameter that needs to be changed.

PIC Figurex2: A domain (rectangle) with three interior points (empty circles) and two boundary points (full circles). This is an exterior boundary, i.e.xthe boundary points are located outside of the physical domain.

Depending on the physical setup — and depending on the personal taste — the boundary points should be located either inside or outside of the physical boundary. The boolean parameter boundaryxinternalxxxlower specifies whether the boundary points extend inwards at the lower face. Figure 3 shows the same example, but with internal boundary points.

PIC Figurex3: A domain (rectangle) with two interior points (empty circles) and two boundary points (full circles). This is an interior boundary, i.e.xthe boundary points are located inside of the physical domain.

Depending on the physical setup — and depending on the personal taste — the boundary points should either be staggered about the physical boundary, or the last boundary point should be located exactly on the physical boundary. This is specified by the boolean parameter boundaryxstaggeredxxxlower. Figures 4 and 5 show exampled of external and internal staggered boundary points.

PIC Figurex4: A domain (rectangle) with three interior points (empty circles) and two boundary points (full circles) which are staggered about the physical boundary. (This is an exterior boundary.)

PIC Figurex5: A domain (rectangle) with two interior points (empty circles) and two boundary points (full circles) which are staggered about the physical boundary. (This is an interior boundary.)

Finally, the integer parameter boundaryxshiftoutxxxlower can be used to shift the boundary points outwards (or inwards with negative values) by multiples of the grid spacing. Figure 6 shows an example of an exterior, non-staggered boundary with a shiftout of one.

PIC Figurex6: A domain (rectangle) with four interior points (empty circles) and two boundary points (full circles) which are shifted outwards by one grid point. (This is an exterior, non-staggered boundary.)

The following table gives examples for common situations:

11Boundary condition  11internal?11staggered?11shiftout11example
11reflection symmetry, not staggered11 no 11 no 11 1 11figure 6
11reflection symmetry, staggered 11 no 11 yes 11 0 11figure 4
11periodicity, closed boundary  11 no 11 no 11 1 11figure 6
11periodicity, open boundary  11 no 11 no 11 0 11figure 2
11periodicity, staggered boundary 11 no 11 yes 11 0 11figure 4

For other boundary conditions such as Dirichlet or Robin, one can choose these parameters freely. 10 Querying about boundary points When iterating over grid points, one usually needs to know about the boundary sizes and boundary types present. One convenient way is provided by the aliased function GetBoundarySizesAndTypes:

CCTK_INTxFUNCTIONxGetBoundarySizesAndTypes
xx(CCTK_POINTER_TO_CONSTxINxcctkGH,
xxxCCTK_INTxINxsize,
xxxCCTK_INTxOUTxARRAYxbndsize,
xxxCCTK_INTxOUTxARRAYxis_ghostbnd,
xxxCCTK_INTxOUTxARRAYxis_symbnd,
xxxCCTK_INTxOUTxARRAYxis_physbnd)

The input argument size describes the size of the four output arrays as allocated by the caller, and should be 2*cctkxdim. The output of this routine describes, for each of the faces of the domain:

bndsize

The number of boundary points

isxghostbnd

Whether this face is a ghost (inter-process) boundary

isxsymbnd

Whether this face is a symmetry boundary

isxphysbnd

Whether this face is a physical boundary

11 Driver Issues

When using the CoordBase domain and boundary parameters, the driver (PUGH, Carpet, etc) also needs to be kept informed.

Whichever driver you’re using, if you’re specifying the number of boundary zones using CoordBase, note that this does not automatically carry over to the driver::ghost_size_x, driver::ghost_size_y, and driver::ghost_size_z parameters. If you want the ghost sizes to be anything other than their defaults (currentlyx), you need to set them explicitly.

11.1 PUGH

If you’re using PUGH, you must still explicitly set the parameters driver::global_nx, driver::global_ny, and driver::global_nz. If you don’t set these parameters, PUGH will assume a default xgrid, which is almost certainly not what you want!

11.2 Carpet

If you’re using Carpet, things are nice: just set

Carpet::domain_from_coordbasex=xtrue

and Carpet will get all its grid information from CoordBase.

12 Parameters

11boundaryxinternalxxxlower 10Scope: privatex01  BOOLEAN

11Description: Do the boundary points extend inwards at the lower x face?

11                      10  x01  Default: no

11

11boundaryxinternalxxxupper 10Scope: privatex01  BOOLEAN

11Description: Do the boundary points extend inwards at the upper x face?

11                      10  x01  Default: no

11

11boundaryxinternalxyxlower 10Scope: privatex01  BOOLEAN

11Description: Do the boundary points extend inwards at the lower y face?

11                      10  x01  Default: no

11

11boundaryxinternalxyxupper 10Scope: privatex01  BOOLEAN

11Description: Do the boundary points extend inwards at the upper y face?

11                      10  x01  Default: no

11

11boundaryxinternalxzxlower 10Scope: privatex01  BOOLEAN

11Description: Do the boundary points extend inwards at the lower z face?

11                      10  x01  Default: no

11

11boundaryxinternalxzxupper 10Scope: privatex01  BOOLEAN

11Description: Do the boundary points extend inwards at the upper z face?

11                      10  x01  Default: no

11

11boundaryxshiftoutxxxlower 10Scope: privatex01  INT

11Description: Offset between the boundary location and the first boundary point at the lower x face

11 Range 10 x01 Default: (none)
11*:*  10when not staggered: use 0 for an open, 1 for a closed manifold

11

11boundaryxshiftoutxxxupper 10Scope: privatex01  INT

11Description: Offset between the boundary location and the first boundary point at the upper x face

11 Range 10 x01 Default: (none)
11*:*  10when not staggered: use 0 for an open, 1 for a closed manifold

11boundaryxshiftoutxyxlower 10Scope: privatex01  INT

11Description: Offset between the boundary location and the first boundary point at the lower y face

11 Range 10 x01 Default: (none)
11*:*  10when not staggered: use 0 for an open, 1 for a closed manifold

11

11boundaryxshiftoutxyxupper 10Scope: privatex01  INT

11Description: Offset between the boundary location and the first boundary point at the upper y face

11 Range 10 x01 Default: (none)
11*:*  10when not staggered: use 0 for an open, 1 for a closed manifold

11

11boundaryxshiftoutxzxlower 10Scope: privatex01  INT

11Description: Offset between the boundary location and the first boundary point at the lower z face

11 Range 10 x01 Default: (none)
11*:*  10when not staggered: use 0 for an open, 1 for a closed manifold

11

11boundaryxshiftoutxzxupper 10Scope: privatex01  INT

11Description: Offset between the boundary location and the first boundary point at the upper z face

11 Range 10 x01 Default: (none)
11*:*  10when not staggered: use 0 for an open, 1 for a closed manifold

11

11boundaryxsizexxxlower 10Scope: privatex01  INT

11Description: Boundary zones at the lower x face

11  Range  10  x01  Default: 1

110:*  10

11

11boundaryxsizexxxupper 10Scope: privatex01  INT

11Description: Boundary zones at the upper x face

11  Range  10  x01  Default: 1

110:*  10

11

11boundaryxsizexyxlower 10Scope: privatex01  INT

11Description: Boundary zones at the lower y face

11  Range  10  x01  Default: 1

110:*  10

11

11boundaryxsizexyxupper 10Scope: privatex01  INT

11Description: Boundary zones at the upper y face

11  Range  10  x01  Default: 1

110:*  10

11

11boundaryxsizexzxlower 10Scope: privatex01  INT

11Description: Boundary zones at the lower z face

11  Range  10  x01  Default: 1

110:*  10

11

11boundaryxsizexzxupper 10Scope: privatex01  INT

11Description: Boundary zones at the upper z face

11  Range  10  x01  Default: 1

110:*  10

11

11boundaryxstaggeredxxxlower 10Scope: privatex01  BOOLEAN

11Description: Is the boundary is staggered about the grid points at the lower x face?

11                      10  x01  Default: no

11boundaryxstaggeredxxxupper 10Scope: privatex01  BOOLEAN

11Description: Is the boundary is staggered about the grid points at the upper x face?

11                      10  x01  Default: no

11

11boundaryxstaggeredxyxlower 10Scope: privatex01  BOOLEAN

11Description: Is the boundary is staggered about the grid points at the lower y face?

11                      10  x01  Default: no

11

11boundaryxstaggeredxyxupper 10Scope: privatex01  BOOLEAN

11Description: Is the boundary is staggered about the grid points at the upper y face?

11                      10  x01  Default: no

11

11boundaryxstaggeredxzxlower 10Scope: privatex01  BOOLEAN

11Description: Is the boundary is staggered about the grid points at the lower z face?

11                      10  x01  Default: no

11

11boundaryxstaggeredxzxupper 10Scope: privatex01  BOOLEAN

11Description: Is the boundary is staggered about the grid points at the upper z face?

11                      10  x01  Default: no

11

11domainsize  10Scope: privatex01  KEYWORD

11Description: Domain size specification

11 Range 10 x01 Default: minmax
11minmax  10lower and upper boundary locations
11extent  10coordinate extent
11spacing  10grid spacing and number of grid cells

11

11dx  10Scope: privatex01  REAL

11Description: Grid spacing in x direction

11 Range 10 x01 Default: 1.0
11(0:*)  10

11

11dy  10Scope: privatex01  REAL

11Description: Grid spacing in y direction

11 Range 10 x01 Default: 1.0
11(0:*)  10

11

11dz  10Scope: privatex01  REAL

11Description: Grid spacing in z direction

11 Range 10 x01 Default: 1.0
11(0:*)  10

11

11ncellsxx  10Scope: privatex01  INT

11Description: Number of grid cells in x direction

11  Range  10  x01  Default: 1

110:*  10

11

11ncellsxy  10Scope: privatex01  INT

11Description: Number of grid cells in y direction

11  Range  10  x01  Default: 1

110:*  10

11ncellsxz  10Scope: privatex01  INT

11Description: Number of grid cells in z direction

11  Range  10  x01  Default: 1

110:*  10

11

11spacing  10Scope: privatex01  KEYWORD

11Description: Grid spacing specification

11 Range 10 x01 Default: gridspacing
11gridspacing  10grid spacing
11numcells  10number of grid cells

11

11xextent  10Scope: privatex01  REAL

11Description: Domain extent in x direction

11 Range 10 x01 Default: 1.0
11(0:*)  10

11

11xmax  10Scope: privatex01  REAL

11Description: Location of upper x boundary

11 Range 10 x01 Default: 1.0
11(*:*)  10

11

11xmin  10Scope: privatex01  REAL

11Description: Location of lower x boundary

11 Range 10 x01 Default: 0.0
11(*:*)  10

11

11yextent  10Scope: privatex01  REAL

11Description: Domain extent in y direction

11 Range 10 x01 Default: 1.0
11(0:*)  10

11

11ymax  10Scope: privatex01  REAL

11Description: Location of upper y boundary

11 Range 10 x01 Default: 1.0
11(*:*)  10

11

11ymin  10Scope: privatex01  REAL

11Description: Location of lower y boundary

11 Range 10 x01 Default: 0.0
11(*:*)  10

11

11zeroxoriginxx  10Scope: privatex01  BOOLEAN

11Description: Is the lower boundary located at x=0?

11                      10  x01  Default: no

11

11zeroxoriginxy  10Scope: privatex01  BOOLEAN

11Description: Is the lower boundary located at y=0?

11                      10  x01  Default: no

11

11zeroxoriginxz  10Scope: privatex01  BOOLEAN

11Description: Is the lower boundary located at z=0?

11                      10  x01  Default: no

11zextent  10Scope: privatex01  REAL

11Description: Domain extent in z direction

11 Range 10 x01 Default: 1.0
11(0:*)  10

11

11zmax  10Scope: privatex01  REAL

11Description: Location of upper z boundary

11 Range 10 x01 Default: 1.0
11(*:*)  10

11

11zmin  10Scope: privatex01  REAL

11Description: Location of lower z boundary

11 Range 10 x01 Default: 0.0
11(*:*)  10

11

13 Interfaces

General Implements: coordbase

Adds header: CoordBase.h

Provides: CoordxSystemRegister to CoordxSystemHandle to CoordxCoordRegister to CoordxCoordHandle to CoordxGroupSystem to CoordxSetDefaultSystem to CoordxGetDefaultSystem to GetBoundarySpecification to GetDomainSpecification to ConvertFromPhysicalBoundary to ConvertFromInteriorBoundary to ConvertFromExteriorBoundary to GetBoundarySizesAndTypes to 14 Schedule This section lists all the variables which are assigned storage by thorn CactusBase/CoordBase. Storage can either last for the duration of the run (Always means that if this thorn is activated storage will be assigned, Conditional means that if this thorn is activated storage will be assigned for the duration of the run if some condition is met), or can be turned on for the duration of a schedule function.

Storage NONE

Scheduled Functions

CCTKxSTARTUP x coordbasexstartup x register a gh extension to store the coordinate system handles x

11x11Language:11c
11 x 11Type: 11function