From 9a9bda666311e16ca27759ccfd4659cd1df21f9a Mon Sep 17 00:00:00 2001 From: schnetter Date: Wed, 18 Aug 2004 21:08:08 +0000 Subject: Spell e.g. and i.e. as such. Small wording and fonting improvements. git-svn-id: http://svn.cactuscode.org/arrangements/CactusPUGH/PUGHSlab/trunk@127 10716dce-81a3-4424-a2c8-48026a0d3035 --- doc/documentation.tex | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/documentation.tex b/doc/documentation.tex index 1c1f70d..6eeb349 100644 --- a/doc/documentation.tex +++ b/doc/documentation.tex @@ -39,7 +39,7 @@ or hyperslab selections. A hyperslab is defined in this context a subset of a global CCTK array, with its own dimension, origin, direction, and extents.\\ Another possible use of hyperslabs is the implementation of certain boundary -conditions (eg. reflection). By having the boundary condition code calling +conditions (e.g.\ reflection). By having the boundary condition code calling generic hyperslab get/put calls, it can be written without special knowledge about driver specifics.\\ @@ -98,13 +98,13 @@ In general, a hyperslab get/put operation is done in a three-level scheme: If the {\tt Hyperslab\_Get*()/Hyperslab\_Put*()} get passed a mapping for a global hyperslab, a global, synchronuous operation will be performed -(ie. it must be called in sync by every processor). All input arguments must be +(i.e., it must be called in sync by every processor). All input arguments must be consistent between processors. \subsection{Defining a hyperslab mapping} -An M-dimensional hyperslab subspace mapped into an N-dimensional space +An $M$-dimensional hyperslab subspace mapped into an $N$-dimensional space can be specified either by coordinates on the physical grid or by index points on the underlying computational grid. @@ -199,12 +199,12 @@ CTK_INT Hyperslab_LocalMappingByPhys ( The hyperslab location is identified by its origin (lower left corner), the direction vectors starting from the origin and spanning the hyperslab - in the N-dimensional space, and its extents (size of the hyperslab in + in the $N$-dimensional space, and its extents (size of the hyperslab in each direction). There are {\tt hdim} direction vectors (one for each hyperslab axis) with {\tt vdim} elements. The direction vectors are given in grid index points and must - not be a linear combination of each other. The {\tt direction} argument must + be linearly independent. The {\tt direction} argument must be passed as an array {\tt direction[vdim\_index + hdim\_index*vdim]} ({\tt vdim} is the fastest changing dimension). @@ -382,7 +382,7 @@ CCTK_INT Hyperslab_PutList (CCTK_POINTER_TO_CONST GH, For {\tt Hyperslab\_GetXXX()}, there may be either exactly one processor providing the hyperslab data (in this case, its processor ID must be given in {\tt proc}), or all all processors will get the extracted hyperslab data - (an invalid (ie. negative) processor ID should be given as {\tt proc}, or + (an invalid (i.e., negative) processor ID should be given as {\tt proc}, or {\tt procs} is passed as a NULL pointer). For {\tt Hyperslab\_PutXXX()}, there may only be one processor providing the hyperslab data to be distributed to all others. @@ -478,7 +478,7 @@ CCTK hyperslab API as described in section \ref{specification}: Local hyperslabs will always include processor-boundary ghostzones. The {\tt hsize\_local, hoffset\_local} information returned by the hyperslab mapping routines should be used to locate the locate hyperslab - within the global grid (eg. during a recombination of several local + within the global grid (e.g.\ during a recombination of several local hyperslabs into a single global one). \end{enumerate} -- cgit v1.2.3