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

[roland.haas at physics.gatech.edu]

User: rhaas
Date: 2011/08/07 08:40 PM

Modified:
 /
  ET.tex

Log:
 remove duplicate text from components/AMR section, streamsline Boundary section
 
 originally the idea was to merge the AMR section into the core components AMR
 section. This would have increased the length of that section quite a bit and
 provided much more details than the current high level description.
 CarpetRegrid seems to be better off in the components sections rather than
 insdie the AMR section.

File Changes:

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

File [modified]: ET.tex
Delta lines: +28 -59
===================================================================
--- ET.tex	2011-08-05 17:54:46 UTC (rev 100)
+++ ET.tex	2011-08-08 01:40:52 UTC (rev 101)
@@ -459,6 +459,7 @@
 world-wide. To date, more than 90 peer-reviewed publication and more
 than 15 student theses are based on Carpet \cite{CarpetCode:web}.
 
+
 \subsection{Simulation Factory\pagesdone{1 Erik}}
 
 Today's supercomputers differ significantly in
@@ -1757,12 +1758,12 @@
 boundary or symmetry conditions.
 
 \subsubsection{Symmetries, Boundary Conditions.}
-The Einstein Toolkit includes a set of thorns, \codename{Boundary}
+The Einstein Toolkit includes two thorns, \codename{Boundary}
 and \codename{SymBase}, to provide a generic interface to specify and
 implement boundary and
 symmetry conditions.
 
-For symmetry conditions the toolkit includes built-in suppport for a 
+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
@@ -1770,10 +1771,10 @@
 directions
 (via the \codename{Periodic} module), reflections across the
 coordinate planes (via the \codename{Reflection} module), 
-$90^{\circ}$ and $180^{\circ}$ rotational
+$90^{\circ}$ and $180^{\circ}$ rotational symmetries
 (via the \codename{RotatingSymmetry90} and
 \codename{RotatingSymmetry180} modules respectively)
-symmetries about the $z$ axis, and a continuous rotational symmetry (via
+about the $z$ axis, and a continuous rotational symmetry (via
 the \codename{Cartoon2D} thorn)~\cite{Alcubierre:1999ab}. 
 \codename{Cartoon2D} allows fully
 three dimensional codes to be used in axissymmtric problems by evolving
@@ -1814,44 +1815,20 @@
     \label{fig:faces}
 \end{figure}
 
-Thorn \codename{Boundary} provides basic physical boundary conditions. 
-A boundary
-condition suitable for matter fields which approach a constant
-(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 (``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.
-\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{,}
-    \label{eqn:robin-falloff}
-\end{equation}
-for a given decay rate $n$, value at infinity $f_0$ and scaling constant
-$k$. $r$ is taken to be the coordinate distance perpendicular to the
-domain boundary under consideration when the boundary condition is
-applied. One example of this type of boundary condition is described
-in section~\ref{sec:curv_boundaries}.
-Radiative (Sommerfeld) and extrapolation
-boundary conditions are provided by thorn \codename{NewRad}.
+Thorn \codename{Boundary} serves as a registry for available boundary
+conditions and provides basic scheduling to enforce all requested
+boundary conditions at the proper times. It also provides a basic set of
+boundary conditions to be used by user thorn. The ``flat'' boundary
+conditions often used for hydrodynamic variables that approach an
+atmosphere value fall in this category. More complicated boundary
+conditions are often implemented as modifications to the evolution
+equations and are not handled directly by \codename{Boundary}. The
+radiative (Sommerfeld) and extrapolation boundary conditions provided by
+thorn \codename{NewRad} are of this kind.
 
 \subsubsection{Adaptive Mesh Refinement}
-\todo{Move this to 4.2 (and merge it with that)}
-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. 
-\codename{Carpet} supports feature-based mesh refinement, which is
+The Einstein toolkit currently 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
@@ -1863,7 +1840,8 @@
 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
+In order to fascilate the description of the mesh hierarchy the\
+Einstein toolkit 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
@@ -1884,19 +1862,20 @@
 \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.
+the refined regions, e.g. as a set of boxes centered around the origin
+or as an explicit list of regions 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
 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 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.
+other tracked objects. 
+Object coordinates are updated by 
+\codename{CarpetTracker} which provides a simple interface to
+the object trackers
+\codename{PunctureTracker} and \codename{NSTracker} (see
+section~\ref{sec:object-tracking}) to have the refined region follow
+the moving objects. 
 \codename{CarpetRegrid2} contains code to handle the $\pi$-symmetry
 provided by \codename{RotatingSymmetry180}, enforcing the symmetry on
 the resulting grid layout (see Figure~\ref{fig:rot180-grid}).
@@ -1920,16 +1899,6 @@
     \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 tracked 
-objects
-from a \codename{SphericalSurface} into
-\codename{CarpetRegrid2}. 
-
-
-
 \section{Examples\pages{0.5 Frank}}
 \todo{Will be written once we know which examples we have}