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

[knarf at cct.lsu.edu]

User: knarf
Date: 2011/02/13 08:15 PM

Modified:
 /
  ET.tex

Log:
 updating/extending/shortening of various sections

File Changes:

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

File [modified]: ET.tex
Delta lines: +100 -106
===================================================================
--- ET.tex	2011-01-31 14:56:58 UTC (rev 23)
+++ ET.tex	2011-02-14 02:15:34 UTC (rev 24)
@@ -235,33 +235,45 @@
 
 
 \subsection{Academic and Social}
+A primary concern for research groups is securing reliable funding
+to maintain graduate students and postdoctoral researchers. This goal
+is easier to achieve if it can be shown that science goals can be
+attacked directly with less potential of infrastructure problems, one
+of the goals of the Einstein Toolkit.
 
-\begin{itemize}
-\item A primary concern for research groups is securing reliable funding
-      to maintain graduate students and postdoctoral researchers. 
-\item 
-\end{itemize}
+In addition, the toolkit provides computer scientists an ideal platform
+to perform state-of-the-art research, directly benefiting research in
+other areas of science and hereby providing an immediate application
+of their research.
 
 \section{Design and Strategy for the Einstein Toolkit}
 
-\todo{Overall design, strategy.}
-
 The mechanisms for the development and support of the Einstein Toolkit are
 designed to be open, transparent and community driven. All the source code,
 documentation and tools included in the Einstein Toolkit are distributed
 under open source licenses. The Einstein Toolkit maintains an SVN repository
 ({\tt svn.einsteintoolkit.org}) with open access which contains software
-supported by the Einstein Toolkit Maintainers, the toolkit web pages and
+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 through anonymous or personal authentication. All
+can contribute either anonymously or through personal authentication. All
 discussion about the toolkit takes place on an open mail list
 ({\tt users at einsteintoolkit.org}). The regular weekly meetings for the
-Einstein Toolkit Maintainers are open and the community are invited to
-participate, and minutes are recorded on the wiki.  The Einstein Toolkit
+Einstein Toolkit are open and the community is invited to
+participate, and minutes are recorded on the wiki\todo{check}.  The Einstein Toolkit
 blog requires users to first request a login, but then can be freely
 posted to. Any user can post comments to entries already on the blog. 
 
+Despite the open design, some actions 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 also to review and apply patches sent by users, to ensure
+a high software quality level. Every substancial change or addition to
+the toolkit has, by not enforced consensus, to be reviewed by another
+Einstein Toolkit Maintainer, and is generally open for discussion on the
+users mailing list.
+
 \section{Core Technologies}
 
 \subsection{Cactus Framework}
@@ -364,29 +376,29 @@
 \section{Components}
 
 \subsection{Base Modules}
+\label{sec:base_modules}
 \todo{1/3 page Frank}
-A modular design has many advantages for distributed development of a
-complex software system, but it also requires standards to be defined
-and followed. Low-level interoperability can be and is provided by
+Modular designs have proven to be essential for distributed development
+of complex software systems, and require the use of well defined interfaces.
+Low-level interoperability within the Einstein Toolkit is provided by
 the Cactus infrastructure. One example of this is using one module
 from within another, e.g. by calling a function within another thorn
-without the knowledge about the programming language this function
-is actually implemented in.
+independent of programming language used for both the calling and the
+called function.
 
 However, certain other standards are very hard or impossible to
-enforce on a technical level. Examples for this are the exact
+enforce on a technical level. Examples for these are the exact
 definitions of physical variables, their units, but also on the more
 technical level the variable names used for the physical quantities.
 The Einstein Toolkit provides modules with the sole purpose to
-declare variables which are commonly used in many modules, and to
-define their meaning and unit. The latter however, is not strictly
-enforced, and instead provided by the module documentation. Two
-of the those base modules are described in the following in more
-detail, because general relativistic codes use different conventions
-in especially those areas.
+declare commonly used variables, and to define their meaning and units.
+The latter is not strictly enforced, and instead documented as part of the
+module documentation. Two of the these base modules are described in the
+following in more detail, because especially these quantities might be
+defined differently in various simulation codes.
 
-Spacetime evolution methods used within the Cactus framework use
-different formulations, but all are based on the ADM
+Relativistic spacetime evolution methods used within the Cactus framework use
+different formulations, but essentially all are based on the ADM
 construction~\cite{Arnowitt:1962hi}. This makes this formulation the
 natural choice of a common denominator to exchange data between
 modules using different formulations. The following variables are
@@ -397,11 +409,11 @@
 both 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 at run-time.
+be setup or which evolution method should be used.
 
-Similar to \codename{ADMBase}, a module called \codename{HydroBase} defines the common
-basis for interactions between modules dealing with relativistic
-hydrodynamics. It is using the conventions of the Valencia
+Similar to \codename{ADMBase}, the module \codename{HydroBase} defines the common
+basis for interactions between relativistic hydrodynamics modules.
+It is using the conventions of the Valencia
 formulation~\cite{Marti:1991wi,Banyuls:1997zz,Ibanez:2001:godunov}.
 In particular, it defines the rest-mass density $\varrho$, the gas
 pressure $p$, internal energy density $\epsilon$, the
@@ -412,93 +424,66 @@
 as $B^i = \frac{1}{\sqrt{4\pi}} n_{\nu} F^{*\nu i}$, in terms of the dual
 $F^{*\mu\nu} = \frac{1}{2}\varepsilon^{\mu\nu\alpha\beta}F_{\alpha\beta}$
 to the Faraday tensor and the unit normal of the foliation of spacetime
-$n^\mu$. \todo{FL: Is this too much information? Should we put some of the
-formulas into a separate eq environment?}
+$n^\mu$.
 
 \subsection{Initial Data}
 \todo{1/2 page Josh, Bruno}
 The Einstein Toolkit contains many modules used to generate initial data for 
-GR simulations, including both vacuum and hydrodynamical configurations.  
-These include modules used primarily for testing out various components of 
-the evolution scheme as well as physically motivated configurations that 
-describe single of binary blacks and/or neutron stars.  Many of the modules
+general relativistic simulations, including both vacuum and hydrodynamical
+configurations.  
+These include modules used primarily for testing of various components, as
+well as physically motivated configurations that e.g.
+describe single or binary black holes and/or neutron stars.  Many of the modules
 are self-contained, consisting of either all the code to generate exact 
 initial solutions or the numerical tools required to construct solutions 
 known semi-analytically. Others, though, require the installation of other 
-numerical software packages that are included in the toolkit as External 
-libraries.  The {\tt twopunctures} module \cite{Ansorg:2004ds}, commonly 
-used in numerical relativity to generate binary black hole data, invokes 
-the GNU Scientific Library [GSL; \cite{GSL:web,Galassi:2009}].  Several modules  
-have also been implemented to read in datafiles generated by the {\tt Lorene 
-code} \cite{Lorene:web,Gourgoulhon:2000nn}, including the BHBH, BHNS, and NSNS data 
-made publicly available through the Lorene website.
+numerical software packages that are included in the toolkit as external 
+libraries. One example is the {\tt TwoPunctures}
+module~\cite{Ansorg:2004ds}, commonly 
+used in numerical relativity to generate binary black hole data, which makes
+use of the GNU Scientific Library [GSL;~\cite{GSL:web,Galassi:2009}].
+Several modules have also been implemented to read in datafiles generated by
+the {\tt Lorene code}~\cite{Lorene:web,Gourgoulhon:2000nn}.
 
-Scheduling of initial data routines generally follows a standard format.  
-User-defined parameters are run through a parameter check designed to catch 
-obvious internal inconsistencies, in addition to any known incompatibilities 
-with other modules of the toolkit.  Initial data is then generated at the proper 
-stage within the Cactus framework, determined primarily by whether the 
-configuration in question represents vacuum or a hydrodynamical configuration.  
-Finally, any necessary cleanup is typically performed at the end of the initial 
-step, prior to the iterations forward in time.
-
-For vacuum initial data configurations, an initial data module must supply 
+Initial data setup is in most cases clearly separated by the following
+evolution. Typically, initial data routines provide the data in form of the
+quantities defined in the Base modules (see section~\ref{sec_base_modules}),
+while the evolution modules may convert these quantities to quantities
+used for the evolution later. For example, an initial data module must supply 
 $g_{ij}$, the spatial 3-metric, and $K_{ij}$, the extrinsic curvature.  
-While the evolution scheme typically makes use of the BSSN formalism,
-the conversion between the physical and conformal metric and extrinsic 
-curvature is handled solely within evolution modules, and is not referenced 
-by initial data ones.  Optionally, many initial data modules also supply values 
-for the lapse and shift vector, and in some cases time derivatives as well, 
-though these may be supplied by other routines depending on the freedom 
-to choose gauge conditions envisioned for a specific configuration.
+The evolution scheme however, typically makes use of the BSSN formalism.
+The conversion between the physical and conformal metric and extrinsic 
+curvature is handled solely within evolution modules. Optionally, many
+initial data modules also supply values 
+for the lapse and shift vector, and in some cases time derivatives as well.
+The initial data routines currently implemented include the following modules.
 
-For hydrodynamic configurations, assuming that an equation of state has been 
-specified, the user must also supply the values of hydrodynamic variables 
-at all grid locations, in particular the primitive variables $\rho$, $v_i$ and 
-the energy variable $\epsilon$ for all cases where we don't have a polytype EOS 
-in the form $P=P(\rho)$ (see Sec.~\ref{???} for a discussion of the use of EOS 
-in the ET).  For an MHD configuration, one must supply all of these along with 
-the initial magnetic field $B^i$ as well.
+Vacuum spacetime tests can be provided by \codename{IDConstraintViolate}, which
+provides a vacuum spacetime explicitly violating the constraint equations, and
+\codename{Exact}, a set of exact, and possibly Lorentz-boosted spacetimes in
+various coordinates.
+Vacuum gravitational wave configurations can be obtained by using either
+\codename{IDBrillData}, providinga Brill wave spacetime~\cite{Brill:1959zz},
+or \codename{IDLinearWaves}, for a spacetime containing a linear gravitational
+wave.
+Possible black hole configurations include \codename{IDAnalyticBH}, generating
+various analyticly known black hole configurations, as well as
+\codename{IDAxibrillBH}, \codename{IDAxiOddBrillBH}, \codename{DistortedBHIVP}
+and \codename{RotatingDBHIVP}, generating single black hole systems, distorted in
+various different ways. \codename{Meudon\_Bin\_BH} can read in binary black hole
+initial data computed by the Lorene~\cite{TODO} code.
+Finally, the most used type of black hole initial data is provided by the module
+\codename{TwoPunctures}, which generates accurate binary black-hole initial data.
 
-The initial data routines currently implemented include the following:
-\begin{itemize}
-\item Vacuum spacetime tests:
-\begin{enumerate}
-\item {\tt IDConstraintViolate}: A vacuum spacetime in which the diagonal terms 
-in the spatial metric are modified by a spatial deformation to explicitly 
-violate the Hamiltonian constraint.
-\item {\tt Exact}: A set of exact spacetimes in various coordinates, along with 
-tools to Lorentz boost those configurations.
-\end{enumerate}
-\item Vacuum gravitational wave configurations:
-\begin{enumerate}
-\item  {\tt IDBrillData}: A Brill wave spacetime \cite{Brill:1959zz}.
-\item {\tt IDLinearWaves}: A spacetime containing a linear gravitational wave.
-\end{enumerate}
-\item Black Hole configurations:
-\begin{enumerate}
-\item {\tt IDAnalyticBH}: This module can generate Schwarzchild black holes, 
-as well as the Misner solution for multiple BHs and the brill-Lindquist binary 
-BH solution.
-\item {\tt IDAxibrillBH,~IDAxiOddBrillBH}: These modules generate single 
-black holes deformed by even and odd parity axisymmetric perturbations, 
-respectively.
-\item {\tt DistortedBHIVP,~RotatingDBHIVP}: These modules generate single 
-black holes distorted by even and odd-parity non-axisymmetric perturbation, 
-respectivey.
-\item {\tt TwoPunctures}: This module generates accurate binary black-hole 
-initial data.
-\end{enumerate}
-\end{itemize}
+Initial data to test different parts of hydrodynamics evolution systems can
+be provided by \codename{GRHydro\_InitData}, e.g. for shock tests,
+\codename{Hydro\_InitExcision} for tests involving hydro-excision,
+\codename{TOVSolver} for Tolman-Oppenheimer-Volkov type neutron star initial data,
+\codename{Meudon\_Bin\_NS} and \codename{Meudon\_Mag\_NS} read in binary and
+magnetized neutron star data computed using Lorene, respectively. Finally,
+the \codename{TwoPunctures} module can also be used to construct neutron star
+black hole binary initial data, when being coupled with \codename{TOVSolver}.
 
-
-\paragraph{Gravitational Waves}
-
-\paragraph{Black Holes}
-
-\paragraph{Neutron Stars}
-
-
 \subsection{Evolution Methods}
 \todo{1/2 page Christian}
 
@@ -591,7 +576,7 @@
 spectrum of the ringdown of a perturbation?
 
 \paragraph{BH-binary}
-\todo{1/2 page, Peter?}
+\todo{1/2 page, Peter}
 Show binary merger and plot of waveform in either time or frequency domain.
 
 \paragraph{TOV+mEOS}
@@ -606,10 +591,19 @@
 
 \section{Future Work}
 \todo{Frank}
+- MHD
+- massively parallel AMR
+- radiation transport
+- advanced wave extraction
 
-
 \section*{Acknowledgments}
 \todo{Frank, ADDME}
+The Einstein Toolkit is directly supported by the National Science Foundation
+under the grant numbers 0903973/0903782/0904015 (CIGR).
+Results presented
+in this article were obtained through computations on the Louisiana Optical
+Network Initiative under grant LONI\_CACTUS05, as well as the NSF Teragrid
+under grant \todo{?}.
 
 
 \bibliographystyle{amsplain-url}