User: rhaas Date: 2011/03/28 09:54 AM
Modified: / ET.tex
Log: add some text to Simulation Domain section
mostly only name the thorns involved, what services they offer
File Changes:
Directory: / ============
File [modified]: ET.tex Delta lines: +38 -5 =================================================================== --- ET.tex 2011-03-28 13:38:16 UTC (rev 39) +++ ET.tex 2011-03-28 14:54:05 UTC (rev 40) @@ -903,9 +903,12 @@
-\subsection{Simulation Domain, Symmetries, Boundaries\pages{3 Roland?}} - +\subsection{Simulation Domain, Symmetries, Boundaries\pages{3 Roland}} +\unknowasdag \paragraph{Domains and Coordinates.} +The Einstein Toolkit provides a module \codename{CoordBase} to facilate +the specification of the simulation domain independend from the actual +evolution module used. The simulation domain is specified via the parameter file \todo{ES: ensure this has been defined above}. Cactus distinguishes between the \emph{physical} domain, which lives in the continuum, and @@ -924,23 +927,53 @@ the numerical resolution do not affect the extent of the physical domain, i.e.\ that the discrete domains converge to the physical domain in the limint of infinite resolution. +\codename{CoordBase} exposes a public interface that allows other +modules to query the domain and description in a uniform way. This +information is used e.g.\ by modules computing the total barionic mass of +the system to determine the region over which to intergrate the mass +density. Evolution modules use this information to decide which points +are evolved and therefore require the evaluation of the righ-hand-side +expression and which ones are set via boundary or symmetry conditions.
\paragraph{Symmetries, Boundary Conditions.} +The Einstein Toolkit includes a set of modules, \codename{Boundary} +and \codename{SymBase}, to provide a generic interface to boundary and +symmetry conditions. The Einstein Toolkit offers a set of reflecting or rotating symmetry conditions that can be used to reduce the size of the simulation -domain. These symmetries include periodicity, reflections about the -coordinate planes, and $90^{\circ}$ and $180^{\circ}$ rotational +domain. These symmetries include periodicity +(via the \codename{Periodic} module), reflections about the +coordinate planes (via the \codename{Reflection} module), +and $90^{\circ}$ and $180^{\circ}$ rotational +(via the \codename{RotatingSymmetry90} and +\codename{RotatingSymmetry180} modules respectively) symmetries about the $z$ axis. In applying these symmetries, the transformation behaviour of tensorial quantities (including tensor densities and non-tensors such as Christoffel symbols) is correctly taken into account. - +The interpolation routines present in \codename{Cactus} automatically +take the existing symmetries into account, transparently mapping points +to the numerical domain and respecting the transformation behaviour of +tensorial quantities. Symmetries therefore are handled transparently +from the point of view of user modules. The Einstein Toolkit also offers a set of boundary conditions, including Dirichlet, von Neumann, and Robin (fall-off) boundary conditions, as well as extrapolation and radiative boundary conditions. +\comment{RH: Christian already describes NewRad's boundary conditions in +his section (these should be used for extrapolation and radiative +boundary conditions I think). Should they eventually be moved here (once +the paper is almost ready)?}
\paragraph{Adaptive Mesh Refinement} +The \codename{Carpet} driver module provides adaptive mesh refinement and +Multi-Block capabilities to modules in the Einstein Toolkit. As in most +adaptive mesh refinement frameworks, care has been taken to separate +driver related code from physics codes. A typical evolution or analysis +code like \codename{McLachlan} or \codename{WeylScal4} is agnostic to +the mesh refinement. +\todo{RH: add description and motivation of/for Berger-Rigoustos scheme?} +\todo{RH: add interaction with MoL?} Carpet supports feature-based mesh refinement, which is based on extracting e.g.\ the locations of black holes or neutron stars, and then constructing a mesh hierarchy (stacks of refined regions) based
commits@lists.einsteintoolkit.org