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}