[Commits] [svn:einsteintoolkit] Paper_EinsteinToolkit_2010/ (Rev. 40)

[roland.haas at physics.gatech.edu]

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