... point.part11
It is possible that one may wish to modify the value of the field at the boundary, after a physical boundary condition has already been applied. For example, one may wish to add a small amount of noise at the boundary to test code stability. This added `term' is not a physical boundary condition in itself, however, and this cannot be registered as such. To implement such a scheme one would treat the noise in a manner similar to symmetry boundary conditions, scheduling a routine during BoundaryConditions (see below), after Boundary_ApplyPhysicalBCs, which gets the list of selected variables and adds noise to their boundaries as desired.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... variablespart12
The consistency of the symmetry conditions scheduled in BoundaryConditions will be treated in an upcoming ``Symmetry'' implementation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...part21
If you're AMR-ing, this all refers to the coarsest or base grid.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...part71
Note that this means that different axes are treated slightly differently by the interpolator. In other words, at the level of finite differencing errors, interpolation does not commute with permuting the axes. However, in practice the differences are likely to be small, at least for smooth input data.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... conditionspart91
It is possible to alter the calculation of L so that boundary conditions are automatically updated and do not need setting. This is slightly tricksy. For an example of how this would work see the new radiative boundary condition in ADM_BSSN. For more on this see section 7.3.4 of [3].
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... variablepart92
Note that this is actually a bit of a hack. The rational for Save and Restore variables was to deal with maximal slicing. However it turned out that I hadn't thought it through correctly and that the treatment for constrained variables was required.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... filespart241
There used to be a third, CalcTmunu_rfr.inc, which was a Cactus 3 legacy having to do with the rfr scheduling mechanism. You may safely delete any reference to this file.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... point.part381
The original implementation of these functions used a CCTK_INT8 for 64 bits, however this data type is not supported by some Fortran compilers.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... boxpart641
Note that because the query is done with extreme interpolation points coordinates, the interpolation call may fail even if all the user-supplied interpolation points are well within each processor's local patch. The reason for this implementation behaviour is that we safely want to catch all errors caused by a too small ghostzone size.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...CCTK_InterpGridArrays()part642
In C the return code is the CCTK_InterpGridArrays() function result; in Fortran it's returned through the first (status) argument.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... HDF5part691
Hierarchical Data Format version 5, see http://hdf.ncsa.uiuc.edu/whatishdf5.html for details
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... normspart861
We use both RMS-norms and $\infty$-norms. We define the RMS-norm of a set of $N$ numbers $\{a_i\}$ is defined to be the square root of their mean square, $\sqrt{(\sum_i a_i{}^2)/N}$.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... epsilonpart862
``Machine epsilon'' $\epsilon$ is defined to be the smallest positive floating-point number such that $1.0 + \epsilon$ compares ``not equal to'' 1.0 in floating-point arithmetic. Machine epsilon values can be found in the standard header file <float.h>; for IEEE single and double precision they are about $1.19{\times}10^{-7}$ and $2.22{\times}10^{-16}$ respectively.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.