diff options
Diffstat (limited to 'doc/documentation.tex')
| -rw-r--r-- | doc/documentation.tex | 103 |
1 files changed, 63 insertions, 40 deletions
diff --git a/doc/documentation.tex b/doc/documentation.tex index 9efc3ad..1fe87a2 100644 --- a/doc/documentation.tex +++ b/doc/documentation.tex @@ -118,6 +118,28 @@ query this thorn about the set of faces that have symmetry boundary conditions and should not apply the physical boundary condition there. +\begin{figure}[tb] +\begin{center} +\includegraphics[scale=.833,clip=true]{fig/faces.eps} +\end{center} +\caption[Symmetry transformations across faces] { + A SymBase symmetry transformation can incorporate multiple + geometric symetry transformations, one for each registered + symmetry face. + + In cases of a reflection symmetry across a component face, + the data may be stored only on one side of the face. + To get data values at a point on the other side of the face, the + point is transformed (reflected, in this case) across the face. + + Here, a point $x$ is transformed to point $x'$ by transformation + $A$, and then to point $x''$ by transformation $B$. Data is + only actually stored for point $x''$. +} +\label{SymBase.faces} +\end{figure} + + \section{Registering Symmetry Conditions} @@ -327,54 +349,55 @@ works as follows: \item If no faces are flagged, SymBase calls the driver's aliased function \texttt{DriverInterpolate}, which performs the actual interpolation. This ends the chain of recursive calls. -\item If there are faces with symmetry conditions flagged, SymBase - chooses one such face, and then calls this face's symmetry - condition's ``symmetry interpolation'' routine, passing along all - arguments. -\item The ``symmetry interpolation'' routine maps the coordinates into - the domain by applying the symmetry condition for this face. It - then removes the flag for the corresponding face, and calls - \texttt{SymmetryInterpolateFaces}, passing along the arguments with - the changed interpolation locations. -\item After the actual interpolation has happened in the driver, the - recursive call will return. The ``symmetry interpolation'' routine - then examines the tensor types of the interpolated quantities and - un-maps the values back onto their original locations. That is, - e.g., after a reflection on the lower $x$-boundary, $x$-components - of vectors need their sign changed. -\item The chain of recursive calls unravels until the call to - \texttt{CCTK\_InterpGridArrays} returns. -\end{enumerate} + \item If there are faces with symmetry conditions flagged, SymBase + chooses one such face, and then calls this face's symmetry + condition's ``symmetry interpolation'' routine, passing along all + arguments. + \item The ``symmetry interpolation'' routine maps the coordinates into + the domain by applying the symmetry condition for this face. It + then removes the flag for the corresponding face, and calls + \texttt{SymmetryInterpolateFaces}, passing along the arguments with + the changed interpolation locations. + \item After the actual interpolation has happened in the driver, the + recursive call will return. The ``symmetry interpolation'' routine + then examines the tensor types of the interpolated quantities and + un-maps the values back onto their original locations. That is, + e.g., after a reflection on the lower $x$-boundary, $x$-components + of vectors need their sign changed. + \item The chain of recursive calls unravels until the call to + \texttt{CCTK\_InterpGridArrays} returns. + \end{enumerate} + This mechanism has thus four players: + \begin{itemize} + \item The driver forwards the call to SymBase so that the list of + interpolation points can be mapped into the domain. + \item Thorn SymBase controls which symmetry conditions perform this + mapping on which faces. +\item Each symmetry boundary condition has to register a ``symmetry + interpolation'' routine that first maps the points into the domain, + then calls SymBase recursively, and finally corrects the tensor + types of the interpolated quantities. +\item Finally, the user calls \texttt{CCTK\_InterpGridArrays} as before, and + everything happens transparently for her. +\end{itemize} + \begin{figure}[tb] \begin{center} \includegraphics[scale=.833,clip=true]{fig/recursion.eps} \end{center} \caption[Symmetry interpolation] { - The recursive calls involved in symmety interpolation. - Values of grid functions $a$ at global cartesian coordinates $x$ are - calculated by nested calls to the symmetry interpolators, which first - apply the symmetry transformation to the coordinates. When all - the symmetries have been applied, the local interpolator is called, - producing the interpolation of grid function values in the local basis. - As the symmetry interpolators return, they apply the inverse basis - transformation to the interpolated grid function values. + The recursive calls involved in symmety interpolation. + Values of grid functions $a$ at global cartesian coordinates $x$ are + calculated by nested calls to the symmetry interpolators, which first + apply the symmetry transformation to the coordinates. When all + the symmetries have been applied, the local interpolator is called, + producing the interpolation of grid function values in the local basis. + As the symmetry interpolators return, they apply the inverse basis + transformation to the interpolated grid function values. } -\label{SymBase_recursion} +\label{SymBase.recursion} \end{figure} -This mechanism has thus four players: -\begin{itemize} -\item The driver forwards the call to SymBase so that the list of - interpolation points can be mapped into the domain. -\item Thorn SymBase controls which symmetry conditions perform this - mapping on which faces. -\item Each symmetry boundary condition has to register a ``symmetry - interpolation'' routine that first maps the points into the domain, - then calls SymBase recursively, and finally corrects the tensor - types of the interpolated quantities. -\item Finally, the user calls \texttt{CCTK\_InterpGridArrays} as before, and - everything happens transparently for her. -\end{itemize} |