See function aliasing.
Automatic Mesh Refinement
Applications Programming Interface, the interface provided by some software component to programmers who use the component. An API usually consists of subroutine/function calls, but may also include structure definitions and definition of constant values. The Cactus Reference Manual documents most of the Cactus flesh APIs.
A collection of thorns, stored in a subdirectory of the Cactus arrangements directory. See Section C1.1.2.
A GNU program which builds a configuration script which can be used to make a Makefile.
A boundary zone is a set of points at the edge of a grid, interpreted as the boundary of the physical problem, and which contains boundary data, e.g. Dirichlet conditions or von Neumann conditions. (See also symmetry zone, ghost zone.)
Distinctive and unusual plant, which is adapted to extremely arid and hot environments, showing a wide range of anatomical and physiological features which conserve water. Cacti stems have expanded into green succulent structures containing the chlorophyll necessary for life and growth, while the leaves have become the spines for which cacti are so well known.1
Cactus Computational Tool Kit (The Cactus flesh and computational thorns).
The Cactus Configuration Language, this is the language that the thorn configuration files are written in. See Section D2.
The combination of a set of thorns, and all the Cactus configure options which affect what binary will be produced when compiling Cactus. For example, the choice of compilers (Cactus CC, CXX, CUCC, and F90 configure options) and the compiler optimization settings (OPTIMISE/OPTIMIZE and *_OPTIMISE_FLAGS configure options) are part of a configuration (these flags change what binary is produced), but the Cactus VERBOSE and WARN configure options aren’t part of a configuration (they don’t change what binary will be produced). See Section A1.2.1.
Get a copy of source code from SVN. See Section A1.1.
Save the entire state of a Cactus run to a file, so that the run can be restarted at a later time. See Sections A3, C2.8.
A discrete finite set of spatial points in ℜn (typically, 1 ≤ n ≤ 3). Historically, Cactus has required these points to be uniformly spaced (uniformly spaced grid), but now, Cactus supports non-uniform spacings (non-uniformly spaced grid), and mesh refinement.
The grid consists of the physical domain and the boundary and symmetry points.
See grid functions for the typical use of grid points.
Important, but often neglected.
The Cactus Specification Tool, which is the set of Perl scripts which parse the thorns’ .ccl files, and generates the code that binds the thorn source files with the flesh.
Subversion is the favoured code distribution system for Cactus. See Sections A1.1,D7.
The technique of breaking up a large computational problem into parts that are easier to solve. In Cactus, it refers especially to a decomposition wherein the parts are solved in parallel on separate computer processors.
A special kind of thorn which creates and handles grid hierarchies and grid variables. Drivers are responsible for memory management for grid variables, and for all parallel operations, in response to requests from the scheduler. See Section C1.6.3.
An iteration interpreted as a step through time. Also, a particular Cactus schedule bin for executing routines when evolution occurs.
The Cactus routines which hold the thorns together, allowing them to communicate and scheduling things to happen with them. This is what you get if you check out Cactus from our SVN repository.
Interfaces that are friends, share their collective set of protected grid variables. See Section D2.2 C1.2.3.
The process of referring to a function to be provided by an interface independently of which thorn actually contains the function, or what language the function is written in. The function is called an alias function. See Section C1.9.5, D2.2.3.
Shorthand for a grid array.
Shorthand for a grid function.
GNU version of the make utility.
A set of points added for parallelisation purposes to a block of a grid lying on one processor, corresponding to points on the boundary of an adjoining block of the grid lying on another processor. Points from the boundary of the one block are copied (via an inter-processor communication mechanism) during synchronisation to the corresponding ghost zone of the other block, and vice versa. In single processor runs there are no ghost zones. Contrast with symmetry or boundary zones. See Section C1.3.5.
Short for computational grid.
A grid variable whose global size need not be that of the computational grid; instead, the size is declared explicitly in an interface.ccl file.
A grid variable whose global size is the size of the computational grid. (See also local array.) From another perspective, grid functions are functions (of any of the Cactus data types (see Section C1.9.8) defined on the domain of grid points. Typically, grid functions are used to discretely approximate functions defined on the domain ℜn, with finite differencing used to approximate partial derivatives.
A computational grid, and the grid variables associated with it.
A spatial point in the computational grid.
A grid variable with index zero, i.e. just a number on each processor.
A variable which is passed through the flesh interface, either between thorns or between routines of the same thorn. This implies the variable is related to the computational grid, as opposed to being an internal variable of the thorn or one of its routines. grid scalar, grid function, and grid array are all examples of grid variables. See Sections C1.3.2, D2.2.4
The GNU program we use for reporting and tracking bugs, comments and suggestions.
GNU’s Not Unix: a freely-distributable code project. See http://www.gnu.org/.
Shorthand for grid variable.
A signed integer value >= 0 passed by many Cactus routines and used to represent a dynamic data or code object.
Hierarchical Data Format version 5, an API, subroutine library, and file format for storing structured data. An HDF5 file can store both data (for example, Cactus grid variables), and meta data (data describing the other data, for example, Cactus coordinate systems). See Section B2.2, also https://www.hdfgroup.org/HDF5/.
Defines the interface that a thorn presents to the rest of a Cactus program. See Section C1.1.3.
A thorn that inherits from another implementation can access all the other implementation’s public variables. See Section D2.2, C1.2.3.
Given a set of grid variables and interpolation points (points in the grid coordinate space, which are typically distinct from the grid points), interpolation is the act of producing values for the grid variables at each interpolation point over the entire grid hierarchy. (Contrast with local interpolation.)
An array that is declared in thorn code, but not declared in the thorn’s interface.ccl, as opposed to a grid array.
Given a set of grid variables and interpolation points (points in the grid coordinate space ,which are typically distinct from the grid points), interpolation is the act of producing values for the grid variables at each interpolation point on a particular grid. (Contrast with interpolation.)
The default input file for make (or gmake). Includes rules for building targets.
A system for building software. It uses rules involving dependencies of one part of software on another, and information of what has changed since the last build, to determine what parts need to be built.
Message Passing Interface, an API and software library for sending messages between processors in a multiprocessor system. See Section B2.2.
See recursion, mutual.
The C programming language uses a “NUL character” to terminate character strings. A NUL character has the integer value zero, but it’s useful to write it as ’\0’, to emphasize to human readers that this has type char rather than int.
C defines a “null pointer”, often (slightly incorrectly) called a “NULL pointer”, which is guaranteed not to point to any object. You get a null pointer by converting the integer constant 0 to a pointer type, e.g. int* ptr = 0;.2
Many programmers prefer to use the predefined macro NULL (defined in <stdlib.h>, <stdio.h>, and possibly other system header files) to create null pointers, e.g. int* ptr = NULL;, to emphasize to human readers that this is a null pointer rather than “just” the integer zero.
Note that it is explicitly not defined whether a null pointer is represented by a bit pattern of all zero bits—this varies from system to system, and there are real-world systems where null pointers are, in fact, not represented this way.
For further information, see the section “Null pointers” in the (excellent) comp.lang.c FAQ, available online at http://www.eskimo.com/~scs/C-_faq/top.html.
The process of utilising multiple computer processors to work on different parts of a computational problem at the same time, in order to obtain a solution of the problem more quickly. Cactus achieves parallelisation by means of domain decomposition.
A variable that controls the run time behaviour of the Cactus executable. Parameters have default values which can be set in a parameter file. (See Chapter C1.4). The flesh has parameters; thorn parameters are made available to the rest of Cactus by describing them in the thorn’s param.ccl file (See Appendix D2.3).
(Also called par file.) A text file used as the input of a Cactus program, specifying initial values of thorn parameters. See Section B3.2.
The default driver thorn for Cactus which uses MPI. See Section B1.1.
Parallel Virtual Machine, provides interprocessor communication. See Section B1.1.
See mutual recursion.
Given a set of grid variables on a computational grid, reduction is the process of producing values for the variables on a proper subset of points from the grid.
The part of the Cactus flesh that determines the order and circumstances in which to execute Cactus routines. Thorn functions and schedule groups are registered with the flesh via the thorn’s schedule.ccl file to be executed in a certain schedule bin, before or after another function or group executes, and so forth. See section D2.4 C1.5,
One of a set of special timebins pre-defined by Cactus. See Section D4 for a list.
A timebin defined by a thorn, in its schedule.ccl file (see Appendix D2.4). Each schedule group must be defined to occur in a Cactus schedule bin or another schedule group. See Chapter C1.5, C1.5.1.
An implementation may share restricted parameters with another implementation, which means the other implementation can get the parameter values, and if the parameters are steerable, it can change them. See Section D2.3 C1.2.3.
A parameter which can be changed at any time after the program has been initialised. See Section C1.4.3.
A grid operation that is a manifestation of a geometrical symmetry, especially rotation or reflection.
A set of points laying at the edge of the computational grid and containing data obtained by some symmetry operation from another part of the same grid. (Contrast with boundary zone, ghost zone.)
The process of copying information from the outer part of a computational interior on one processor to the corresponding ghost zone (see) on another processor. Also refers to a special Cactus timebin corresponding to the occurrence of this process. See Section C1.3.5.
See Section D8.
A make target is the name of a set of rules for make (or gmake). When the target is included in the command line for make, the rules are executed, usually to build some software.
See Sections B2.6, C1.8.5.
A collection of subroutines defining a Cactus interface. See Chapters C1.1, C1.2.
A file used by the Cactus CST to determine which thorns to compile into a Cactus executable (see Section B2.4.1, B2.4.2). Can also be used to determine which thorns to check out from SVN. (see Section A1.1). A ThornList for each Cactus configuration lies in the configuration subdirectory of the Cactus configs directory.
A time interval in the duration of a Cactus run wherein the flesh runs specified routines. See scheduler, schedule bin.
A Cactus API for reporting time. See Section C1.9.1.
2Note that if you have an expression which has the value zero, but which isn’t an integer constant, converting this to a
pointer type is not guaranteed to give a NULL pointer, e.g.:
int i = 0;
int* ptr = i; /* ptr is NOT guaranteed to be a NULL pointer! */