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

knarf at cct.lsu.edu knarf at cct.lsu.edu
Mon Aug 1 08:21:13 CDT 2011


User: knarf
Date: 2011/08/01 08:21 AM

Modified:
 /
  ET.tex

Log:
 improvements/corrections/comments froom one pass of reading

File Changes:

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

File [modified]: ET.tex
Delta lines: +102 -68
===================================================================
--- ET.tex	2011-06-27 15:54:01 UTC (rev 93)
+++ ET.tex	2011-08-01 13:21:13 UTC (rev 94)
@@ -94,7 +94,7 @@
 %       to be used
     
 \begin{abstract}
-\todo{ADDME}
+\todo{ADDME, Frank}
 \end{abstract}
 
 \maketitle
@@ -102,10 +102,10 @@
 % We will remove this at the end, but we leave it in for ourselfes now
 \tableofcontents
 
-\section{Introduction\pages{1 Frank}}
+\section{Introduction\pagesdone{Frank}}
 
 Scientific progress in the field of numerical relativity has always
-been closely tied with the availability and ease-of-use of enabling
+been closely tied to the availability and ease-of-use of enabling
 software and computational infrastructure. This document describes
 the Einstein Toolkit, which aims at providing such an infrastructure,
 developed openly and available freely, and is directly supported by
@@ -141,8 +141,8 @@
 evolve binary BHs have proven to be equally applicable to merging BH-NS and
 NS-NS binaries, allowing for the first full GR simulations of these systems
 (e.g.,~\cite{Shibata:2006bs,Shibata:2006ks,Loeffler06a,Shibata:2007zm,
-Etienne:2007jg,Baiotti:2008ra,Duez:2008rb}), and spured a lot of activity
-also in this field~\todo{cite}.
+Etienne:2007jg,Baiotti:2008ra,Duez:2008rb}), and spurring a lot of activity
+also in this field~\todo{cite more}.
 
 General relativistic magneto-hydrodynamics (GRMHD) on fixed background
 spacetimes has been carried out in multi-dimensional
@@ -187,7 +187,7 @@
 computer science directly to problems in numerical relativity.
 
 This success spawned usage of the Cactus computational toolkit in other
-areas, such as hurricane forecast models. At the same time, the growing
+areas, such as hurricane forecast models~\todo{cite}. At the same time, the growing
 number of results in numerical relativity increased the need for commonly
 available utilities such as comparison and analysis tools, typically
 problem-specific to astrophysical problems. Including them within the
@@ -196,7 +196,7 @@
 presently do make use of the Cactus toolkit, this is not an requirement at all,
 and other contributions are welcome and have been accepted.
 
-\section{Requirements\pages{2 Frank}}
+\section{Requirements\pagesdone{Frank}}
 
 \subsection{Scientific}
 
@@ -302,7 +302,7 @@
 a framework developed by computer scientists and now used by researchers
 is many other fields.
 
-\section{Design and Strategy\pages{0.5 Frank}}
+\section{Design and Strategy\pagesdone{0.5 Frank}}
 
 The mechanisms for the development and support of the Einstein Toolkit are
 designed to be open, transparent and community-driven. The complete source code,
@@ -312,8 +312,8 @@
 supported by the Einstein Toolkit, the toolkit web pages and
 documentation. An open wiki for documentation
 ({\tt docs.einsteintoollkit.org}) has been established where the community
-can contribute either anonymously or through personal authentication. All
-discussion about the toolkit takes place on an open mail list
+can contribute either anonymously or through personal authentication. Almost
+all discussions about the toolkit take place on an open mail list
 ({\tt users at einsteintoolkit.org}). The regular weekly meetings for the
 Einstein Toolkit are open and the community is invited to
 participate. Meeting minutes are recorded and publicly available as well.
@@ -323,8 +323,8 @@
 The community heavily uses an issue tracking system
 ({\tt trac.einsteintoolkit.org}), with submissions also open to everyone.
 
-Despite this open design, some actions have to be restricted to a small
-group of maintainers. This is true for e.g.\ administrative tasks like the
+Despite this open design, some actions naturaly have to be restricted to a small
+group of maintainers. This is true for, e.g., administrative tasks like the
 setup and maintenance of the services itself, or to avoid large amounts
 of spam. However, one of the most important tasks of an Einstein Toolkit
 Maintainer is to review and apply patches sent by users in order to ensure
@@ -334,10 +334,20 @@
 despite not being technically enforced, works well in practice, and is at the
 same time promoting active development.
 
-\section{Core Technologies\pages{0.5 Frank}}
+\section{Core Technologies\pagesdone{Frank}}
 
-\subsection{Cactus Framework\pages{1 Frank}}
+The Einstein Toolkit consists of a lot of components which, combined by the
+user, are utilized together to perform a full simulation. While all of these
+components have important tasks, a few stand out. Of these, the following four
+are described in more detail below: the Cactus framework, providing the glue
+between a lot of the other components, the handling of adaptive mesh refinement
+without which most results could not have been obtained in reasonable time,
+the simulation factory, because it simplifies the necessary supercomputer usage,
+and Kranc, which can generate code in a computer language from a high-level
+description in Mathematica.
 
+\subsection{Cactus Framework\pagesdone{1 Frank}}
+
 The \textbf{Cactus
   Framework}~\cite{CS_cactus_web,CS_Goodale02a,CS_cactususersguide} is
 an open source, modular, portable programming environment for
@@ -374,7 +384,7 @@
 relativity, as part of the \texttt{CactusEinstein} arrangement. Over the
 last few years however, the relevance of many of the modules has declined,
 and more and more of the basic infrastructure for numerical relativity
-has been provided by open modules provided and distributed by research
+has been provided by open modules distributed by research
 groups in the community. 
 The Einstein Toolkit now collects the widely used parts of CactusEinstein,
 combined with contributions from the community.
@@ -523,7 +533,7 @@
 The above features make running simulations on supercomputers much
 safer and simpler.
 
-\subsection{Kranc\pages{1 Ian}}
+\subsection{Kranc\pages{1 Ian: expand - we could write so much more here}}
 \label{sec:kranc}
 
 Kranc\cite{Husa:2004ip,kranc04,krancweb} is a Mathematica application which converts a high-level
@@ -561,9 +571,24 @@
 as well as the wave extraction thorn WeylScal4, are both generated
 using Kranc, and hence support all the above features.
 
-\section{Components\pages{0.5 Frank}}
+\section{Components\pagesdone{Frank}}
+The Einstein Toolkit uses the Cactus framework as underlying infrastructure,
+which promotes a very modular design. A simulation within Cactus could just
+use one module, but in practice simulations are often composed from over
+one hundered components. Some of these modules provide common definitions
+and conventions (see section~\ref{sec:base_modules}). Others provide
+initial data (see section~\ref{sec:initial_data}). These initial data
+have to be evolved, using different evolution methods, described in
+sections~\ref{sec:Kevol} and~\ref{sec:GRHydro}.
+Simulations including
+matter require a description of the matter properties, encoded in equations
+of state (see section~\ref{sec:eoss}).
+Finally, other quantities besides the ones used for evolution are often
+interesting for a detailed analysis of the results of a simulation.
+Modules providing commonly used analysis methods are described in
+section~\ref{sec:analysis}.
 
-\subsection{Base Modules\pages{4 Frank}}
+\subsection{Base Modules\pagesdone{Frank}}
 \label{sec:base_modules}
 Modular designs have proven to be essential for distributed development
 of complex software systems, and require the use of well defined interfaces.
@@ -571,7 +596,8 @@
 the Cactus infrastructure. One example of this is using one module
 from within another, e.g., by calling a function within another thorn
 independent of programming language used for both the calling and the
-called function.
+called function. Technical challenges like this can be and are
+provided by the underlying framework, in this case by Cactus.
 
 However, certain other standards are very hard or impossible to
 enforce on a technical level. Examples for these are the exact
@@ -579,7 +605,8 @@
 technical level the variable names used for the physical quantities.
 In addition, even distinct simulation codes typically use very similar
 scheduling schemes. Conventions on the level of the scheduler can help
-coordinating the order different modules are called.
+coordinating the order in which functions in which different modules
+are called.
 
 The Einstein Toolkit provides modules with the sole purpose to
 declare commonly used variables, and to define their meaning and units.
@@ -598,58 +625,67 @@
 the three-metric $\gamma_ij$,
 the extrinsic curvature $K_ij$,
 the lapse function $\alpha$ and shift function $\beta^i$,
-both together with their first time derivatives.
+the latter two together with their first time derivatives.
 This base module also defines common parameters to manage interaction
-between different modules, like which type of initial data should
-be setup or which evolution method should be used.
+between different modules. Examples are the type of requested initial data
+or the used evolution method.
 
 The variables provided by {\tt ADMBase} are:
 
 \begin{itemize}
  \item
-  The 3-metric tensor, $g_{ij}$
+  The 3-metric tensor, $g_{ij}$:
   {\tt gxx}, {\tt gxy}, {\tt gxz},{\tt gyy}, {\tt gyz},{\tt gzz}
- \item The extrinsic curvature tensor, $K_{ij}$
+ \item The extrinsic curvature tensor, $K_{ij}$:
   {\tt kxx}, {\tt kxy}, {\tt kxz},{\tt kyy},{\tt kyz},{\tt kzz}
- \item The lapse function, $\alpha$
+ \item The lapse function, $\alpha$:
   {\tt alp}
- \item The shift vector $\beta^i$
+ \item The shift vector $\beta^i$:
   {\tt betax}, {\tt betay},{\tt betaz}
 \end{itemize}
 
-The type of chosen initial data for a simulation is specified by the {\tt
-initial\_data} (3-metric and extrinsic curvature),
-{\tt initial\_lapse}, {\tt initial\_shift} parameters, and
-parameters for their first time derivatives {\tt initial\_dtlapse} and
+The type of chosen initial data for a simulation is specified by the 
+parameters{\tt initial\_data} (3-metric and extrinsic curvature),
+{\tt initial\_lapse}, {\tt initial\_shift}, and by
+parameters for their first time derivatives, {\tt initial\_dtlapse} and
 {\tt initial\_dtshift} respectively.
 By default, {\tt ADMBase} initialises the 3-metric and extrinsic
 curvature to Minkowski and the lapse to one. Initial data thorns
 override these defaults by extending the parameters.
 
 Analogous to specifying initial data, evolution methods are chosen by
-the {\tt evolution\_method} (3-metric and extrinsic curvature),
+the parameters {\tt evolution\_method} (3-metric and extrinsic curvature),
 {\tt lapse\_evolution\_method}, {\tt shift\_evolution\_method},
-{\tt dtlapse\_evolution\_method} and {\tt dtshift\_evolution\_method}
-parameters. {\tt ADMBase} does not evolve the
+{\tt dtlapse\_evolution\_method} and {\tt dtshift\_evolution\_method}.
+{\tt ADMBase} does not evolve the
 3-metric or extrinsic curvature, and holds the lapse and shift static.
-Evolution thorns typically extend the ranges of these parameters and
+Evolution thorns extend the ranges of these parameters and
 contain the evolution code.
 
+The variables defined in ADMBase are typically not used for the actual
+evolution of the curvature. ADMBase does not restrict that coice. However,
+it is expected that every evolution module converts its internal representation
+to the form defined in ADMBase after each evolution step. This procedure
+enables modules performing analysis on the spacetime variables to use
+the ADMBase variables without direct dependency on any of the existing
+curvature evolution methods.
+
 \subsubsection{HydroBase}
-Similar to \codename{ADMBase}, the module \codename{HydroBase} defines the common
-basis for interactions between relativistic hydrodynamics modules.
-HydroBase extends the CactusEinstein framework to include an interface for magnetohydrodynamics to
-work within.  HydroBase's main function is to store the primitive variables, common among
-hydrodynamic simulations, commonly needed parameters, and schedule groups for the main
-functions of a hydrodynamics code.
-HydroBase only stores variables which
-are common to most if not all hydrodynamics codes solving the Euler
-equations, the so called primitive variables. These are also the variables which are needed
-to couple to a spacetime solver and which are usually needed by analysis thorns. The usage of
-a common set of variables by different hydrodynamics codes creates the possibility to share
-parts of the code, e.g.\ initial data solvers or analysis routines.
+Similar to \codename{ADMBase}, the module \codename{HydroBase} defines common
+basis for interactions between modules of a given evolution problem, in this
+case relativistic hydrodynamics.  HydroBase extends the Einstein Toolkit to
+include an interface for magnetohydrodynamics to work within. HydroBase's main
+function is to store variables which are common to most if not all
+hydrodynamics codes solving the Euler equations, the so called primitive
+variables.  These are also the variables which are needed to couple to a
+spacetime solver and which are usually needed by analysis thorns. Like for
+ADMBase, the usage of a common set of variables by different hydrodynamics
+codes creates the possibility to share parts of the code, e.g.\ initial data
+solvers or analysis routines.
+HydroBase also defines commonly needed parameters, and schedule
+groups for the main functions of a hydrodynamics code.
 
-It is using the conventions of the Valencia
+HydroBase is using the conventions of the Valencia
 formulation~\cite{Marti:1991wi,Banyuls:1997zz,Ibanez:2001:godunov}.
 In particular, HydroBase defines the primitive variables (see~\cite{livrevgrfd} for
 details):
@@ -699,7 +735,7 @@
 variables, and basic atmosphere handling can be implemented in different thorns while allowing
 a central access point for analysis thorns.
 
-\subsection{Initial Data\pages{4 Josh/Bruno}}
+\subsection{Initial Data\pagesdone{Josh/Bruno}}
 \label{sec:initial_data}
 
 The Einstein Toolkit contains many modules used to generate initial data for 
@@ -928,10 +964,8 @@
 one may also apply a uniform velocity to the neutron star, though this does not affect 
 the ODE solution nor the resulting density profile.
 
-
-\subsection{Equations of State}\pages{1 Christian}
-
 \subsection{Spacetime Curvature and Hydrodynamics Evolution}
+\label{sec:Kevol}
 \todo{Christian in charge}
 
 In the following, we assume that the reader is familiar with the
@@ -1160,6 +1194,7 @@
 calculated layers.
 
 \subsubsection{Boundary Conditions}
+\label{sec:curv_boundaries}
 
 During time evolution, a Sommerfeld-type radiative boundary condition
 is applied to all components of the evolved BSSN variables as
@@ -1227,16 +1262,16 @@
  gauge conditions used in \codename{McLachlan}.
 
 
+\subsection{Hydrodynamics: \codename{GRHydro}}
+\label{sec:GRHydro}
 
 
 
+\subsection{Equations of State}\pages{1 Christian}
+\label{sec:eoss}
 
-\subsubsection{Hydrodynamics: \codename{GRHydro}}
-\label{sec:GRHydro}
-
-
-
-\subsection{Analysis\pages{4 Tanja}}
+\subsection{Analysis\pagesdone{Tanja}}
+\label{sec:analysis}
 It is often beneficial and sometimes necessary to evaluate analysis quantities
 during the simulation rather than post-processing variable output. Beyond
 extracting physics, these quantities are often used as measures of how
@@ -1661,7 +1696,7 @@
 ghost points off the plane (see Figure~\ref{fig:cartoon-plane}). 
 \begin{figure}[htbp]
     \begin{center}
-        \includegraphics[width=0.25\textwidth]{cartoon_plane}
+        \includegraphics[width=0.2\textwidth]{cartoon_plane}
     \end{center}
     \caption{Grid layout of a simulation using \codename{Cartoon2D}. The
     $z$-axis is the axis of rotational symmetry. Image courtesy of
@@ -1716,15 +1751,13 @@
 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. 
+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}.
-\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)?}
 
 \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
@@ -1813,6 +1846,7 @@
 
 
 \section{Examples\pages{0.5 Frank}}
+\todo{Will be written once we know which examples we have}
 
 \subsection{Spinning BH\pages{2 Peter}}
 
@@ -1825,7 +1859,7 @@
 \subsection{Collapse\pages{2 Christian}}
 Show TOV collapse and BH formation
 
-\subsection{Cosmology}
+\subsection{Cosmology\pagesdone{1}}
 The Einstein Toolkit is not only designed to evolve compact-object
 spacetimes, but it is also capable of solving the initial-value
 problem for spacetimes with radically different topology and global
@@ -1875,7 +1909,7 @@
 
 
 \section{Future Work\pages{1 Frank}}
-This paper illustrated the current state of the ``Einstein Toolkit'',
+In this paper we illustrated the current state of the ``Einstein Toolkit'',
 a collection of freely available and easy to use computational codes
 for numerical relativity. However, there is room for improvement on both
 the underlying infrastructure and the included physics.
@@ -1884,9 +1918,9 @@
 radiation, in particular neutrinos, but possibly even some approximation
 of emmission of electro-magnetic waves. Radiation transport is, even compared
 to the full GRMHD problem, computationally very expensive, especially in
-three dimensions. \todo{mention PetaCactus}
+three dimensions. \todo{Erik: mention PetaCactus}
 
-\todo{mention advanced wave extraction}
+\todo{CCE people: mention advanced wave extraction}
 
 Another important goal is to increase the scalability of the Carpet AMR
 infrastructure. It has been shown that good scaling is limited to less than



More information about the Commits mailing list