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

[schnetter at cct.lsu.edu]

User: eschnett
Date: 2011/02/14 10:36 AM

Modified:
 /
  ET.tex

Log:
 Describe simulation domains etc.

File Changes:

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

File [modified]: ET.tex
Delta lines: +57 -9
===================================================================
--- ET.tex	2011-02-14 15:35:14 UTC (rev 26)
+++ ET.tex	2011-02-14 16:36:41 UTC (rev 27)
@@ -331,8 +331,11 @@
   CarpetCode:web} provides multi-block methods and adaptive mesh
 refinement (AMR\@). Multi-block methods cover the domain with a set of
 distorted Cartesian blocks that exchange information e.g.\ via
-interpolation or penalty methods. The AMR capabilities employ the
-standard Berger-Oliger algorithm \todo{cite} with subcycling in time.
+interpolation or penalty methods.\footnote{Although multi-block
+  methods are supported by Carpet, the Einstein Toolkit does not yet
+  contain any multi-block coordinate systems.} The AMR capabilities
+employ the standard Berger-Oliger algorithm \todo{cite} with
+subcycling in time.
 
 Carpet is the main driver used today for Cactus-based astrophysical
 simulations. Carpet offers hybrid MPI/OpenMP parallelisation and is
@@ -340,10 +343,10 @@
 in 2010, about 7,000 core years of computing time (45 million core
 hours) were used via Carpet by more than a dozen research groups
 world-wide. To date, more than 90 peer-reviewed publication and more
-than 15 student theses are based on Carpet \todo{update these numbers}
+than 15 student theses are based on Carpet \todo{ES: update these numbers}
 \cite{CarpetCode:web}. Carpet's continued development is overseen by
-E. Schnetter \todo{do we want names here?} and is funded via several
-NSF awards \todo{list them somewhere}.
+E. Schnetter \todo{ES: do we want names here?} and is funded via several
+NSF awards \todo{ES: list them somewhere}.
 
 \subsection{Simulation Factory}
 
@@ -598,15 +601,60 @@
 Equation~(\ref{eq:puncturetracking}) is implemented with a simple first order
 Euler scheme, which seems to be accurate enough for controlling the mesh
 refinement grids.
+\todo{ES: I think this paragraph provides too much detail for this paper.}
+\todo{ES: Can also track objects via their maximum density or centre
+  of mass; I believe GRHydro does something like this}
 
-\subsection{Infrastructure and Numerical Methods}
-\todo{1/2 page Erik}
 
-\paragraph{Domains and Coordinates}
 
+%\subsection{Infrastructure and Numerical Methods}
+\subsection{Simulation Domain, Symmetries, Boundaries}
+
+\paragraph{Domains and Coordinates.}
+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
+\emph{discrete} domain, which consists of a discrete set of grid
+points. The physical domain is defined via its coordinate extent and
+is independent of the numerical resolution; in particular, the
+boundary of the physical domain has a width of zero (and is thus a set
+of measure zero). The discrete domain is defined indirectly via a
+discretisation procecure. This procedure specifies the number of
+boundary points, their location in respect to the physical boundary,
+and either the grid spacing or the number of grid points spanning the
+domain. This defines the discrete domain, i.e.\ the number and
+location of the discrete grid points. In particular, the discrete
+domain can have grid points outside of the physical domain, and can
+have a non-zero boundary width. This mechanism ensures that changes in
+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.
+
+\paragraph{Symmetries, Boundary 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
+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 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.
+
 \paragraph{Adaptive Mesh Refinement}
+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
+conditions are constructed outside of Carpet (which is often the
+case), then the initial mesh hierarchy has to be defined manually.
 
-\paragraph{Boundary Conditions}
 
 
 \section{Examples}