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

[roland.haas at physics.gatech.edu]

User: rhaas
Date: 2011/05/08 12:23 AM

Modified:
 /
  ET.tex

Log:
 work a bit on language in simulation domain section

File Changes:

Directory: /
============

File [modified]: ET.tex
Delta lines: +57 -36
===================================================================
--- ET.tex	2011-04-28 19:13:37 UTC (rev 81)
+++ ET.tex	2011-05-08 05:23:51 UTC (rev 82)
@@ -1597,11 +1597,12 @@
 
 \subsection{Simulation Domain, Symmetries, Boundaries\pages{3 Roland}}
 \subsubsection{Domains and Coordinates.}
-The Einstein Toolkit provides a module \codename{CoordBase} to facilate
+The Einstein Toolkit provided thorn \codename{CoordBase} facilates
 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
+evolution thorn used. 
+The simulation domain is specified at run time via a parameter file at the
+same time as parameters describing the physical system are specified.
+Cactus distinguishes between
 the \emph{physical} domain, which lives in the continuum, and
 \emph{discrete} domain, which consists of a discrete set of grid
 points. The physical domain is defined via its coordinate extent and
@@ -1618,33 +1619,39 @@
 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. 
-\codename{Carpet} queries \codename{CoordBase} for the discrete
-grid when creating the hierarchy of grids. Evolution modules use this
+\codename{CoordBase} exposes a public runtime interface that allows 
+other
+thorns to query the domain description in a uniform way. This is used
+by 
+\codename{Carpet} to query \codename{CoordBase} for the discrete
+grid when creating the hierarchy of grids, automatically ensuring a
+consistent grid description between the two thorns. 
+Evolution thorns such as \codename{McLachlan} use the domain 
+information
 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.
 
 \subsubsection{Symmetries, Boundary Conditions.}
-The Einstein Toolkit includes a set of modules, \codename{Boundary}
-and \codename{SymBase}, to provide a generic interface to boundary and
+The Einstein Toolkit includes a set of thorns, \codename{Boundary}
+and \codename{SymBase}, to provide a generic interface to specify and
+implement boundary and
 symmetry conditions.
 
-The toolkit includes built-in suppport for a set of reflecting or 
+For symmetry conditions the toolkit includes built-in suppport for a 
+set of reflecting or 
 rotating symmetry
 conditions that can be used to reduce the size of the simulation
 domain. These symmetries include periodicity in any of the coordinate
 directions
-(via the \codename{Periodic} module), reflections about the
+(via the \codename{Periodic} module), reflections across the
 coordinate planes (via the \codename{Reflection} module), 
-and $90^{\circ}$ and $180^{\circ}$ rotational
+$90^{\circ}$ and $180^{\circ}$ rotational
 (via the \codename{RotatingSymmetry90} and
 \codename{RotatingSymmetry180} modules respectively)
-symmetries about the $z$ axis. 
-\codename{Cartoon2D} provides a continuous
-rotational symmetry rather than a discrete
-symmetry~\cite{Alcubierre1999ab}. \codename{Cartoon2D} allows fully
+symmetries about the $z$ axis, and a continuous rotational symmetry (via
+the \codename{Cartoon2D} thorn)~\cite{Alcubierre1999ab}. 
+\codename{Cartoon2D} allows fully
 three dimensional codes to be used in axissymmtric problems by evolving
 a slice in the $y=0$ plane and using the rotational symmetry to populate
 ghost points off the plane (see Figure~\ref{fig:cartoon-plane}). 
@@ -1658,15 +1665,16 @@
     \label{fig:cartoon-plane}
 \end{figure}
 
-In applying symmetries, the
+In applying symmetries to populate ghost zones, 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
+Similarly 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 are handled transparently
+tensorial quantities. Thus symmetries are handled transparently
 from the point of view of user modules (see Figure~\ref{fig:faces} for an
 illustration).
 \begin{figure}[htbp]
@@ -1682,16 +1690,20 @@
     \label{fig:faces}
 \end{figure}
 
-Thorn \codename{Boundary} provides basic boundary conditions. A boundary
+Thorn \codename{Boundary} provides basic physical boundary conditions. 
+A boundary
 condition suitable for matter fields which approach a constant
-(atmosphere) value is provided via either the ``flat'' or ``scalar''
+(atmosphere) value on the boundary is provided via either the ``flat'' 
+or ``scalar''
 (Dirichlet) boundary conditions. These boundary conditions set the
 values on the boundary to either those close by in the direction of the
-normal to the boundary or to a fixed given value, respectively.
+normal to the boundary (``flat'') or to a fixed given value 
+(``scalar'').
 The ``copy'' boundary condition uses a secondary grid variable to fill
 in the boundary values, allowing arbitrary boundary conditions to be
 imposed.
-A fall-off (``Robin'') boundary condition is provided suitable for field
+\codename{Boundary} provides a fall-off (``Robin'') boundary condition
+suitable for fields
 whose behaviour near the boundary is described by
 \begin{equation}
     f(r) = f_0 + \frac{k}{r^n}\text{,}
@@ -1709,25 +1721,31 @@
 the paper is almost ready)?}
 
 \subsubsection{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
+The \codename{Carpet} driver thorn provides adaptive mesh refinement
+optionally using subcycling in time and level-dependend spatial
+refinement factors as well as
+Multi-Block capabilities to thorns 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. 
-Carpet supports feature-based mesh refinement, which is based on
+\codename{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
 on the locations, sizes, and speeds of these objects. This allows
 tracking objects as they move through the domain. One can also add or
-remove stacks if e.g.\ the number of objects changes. If initial
+remove stacks if e.g.\ the number of objects changes. Fully AMR based on
+a local error estimate is supported by \codename{Carpet} however the
+Einstein Toolkit does not provide a suitable redgridding thorn to create
+such a grid. If initial
 conditions are constructed outside of Carpet (which is often the
 case), then the initial mesh hierarchy has to be defined manually.
-The Einstein toolkit currently provides two ``regridding'' modules in
+The Einstein toolkit currently provides two regridding modules in
 the \codename{CarpetRegrid} and \codename{CarpetRegrid2} thorns.
 Both thorns primarily support box-in-box type refined meshes, which is
 well suited to current binary black hole simulations in which the
-high-resolution region is centered on the individual black holes.
+high-resolution regions are centered on the individual black holes.
 Figure~\ref{fig:bbh-boxes} shows a typical set of nested boxes during
 the inspiral phase of a binary black hole merger simulation.
 \begin{figure}[htbp]
@@ -1742,18 +1760,20 @@
     \codename{RotatingSymmetry180} to reduce the computational domain.}
     \label{fig:bbh-boxes}
 \end{figure}
+
 \codename{CarpetRegrid} provides a number of different ways to specify
 the refined regions, either as a set of boxes centered around the origin
 or as an explicit list of boxes that make up the grid hierarchy.
 Traditionally groups using \codename{CarpetRegrid} have employed
 auxiliary thorns, that are not part of the Einstein Toolkit, to create
-the list of boxes based on information obtained e.g. from apparent
+this list of boxes based on information obtained e.g.\ from apparent
 horizon tracking. \codename{CarpetRegrid2} provides a user friendly
 interface to define sets of nested boxes that follow black holes or
 other tracked objects. \codename{CarpetRegrid2} supports up to 10 sets
-of nested regions which can be either moving or stationary. The number
-of refinement levels in each region as well as the radii of each nested
-box are allowed to change during runtime, making it possible to e.g.
+of nested boxes which can be either moving or stationary. The number
+of refinement levels in each set of boxes as well as the radii of each
+nested
+box are allowed to change during runtime, making it possible to e.g.\ 
 adapt the shape of the refined region to the surface of a star.
 \codename{CarpetRegrid2} contains code to handle the $\pi$-symmetry
 provided by \codename{RotatingSymmetry180}, enforcing the symmetry on
@@ -1777,12 +1797,13 @@
     only as a source for the boundary condition.}
     \label{fig:rot180-grid}
 \end{figure}
+
 \codename{CarpetTracker} provides a simple interface to slave
 \codename{CarpetRegrid2}'s regions to the object trackers
 \codename{PunctureTracker} and \codename{NSTracker} (see
-section~\ref{sec:object-tracking}) by copying the position of tracker 
+section~\ref{sec:object-tracking}) by copying the position of tracked 
 objects
-positions out of a \codename{SphericalSurface} into
+from a \codename{SphericalSurface} into
 \codename{CarpetRegrid2}.