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

knarf at cct.lsu.edu knarf at cct.lsu.edu
Mon Apr 11 00:05:01 CDT 2011


User: knarf
Date: 2011/04/11 12:05 AM

Added:
 /figures/
  TwoPunctures_grid_BHNS.pdf

Modified:
 /
  ET.tex

Log:
 work on several sections, especially 2-4

Directory Changes:

Directory: /svn:mime-type/
==========================

   + application/pdf

File Changes:

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

File [modified]: ET.tex
Delta lines: +108 -62
===================================================================
--- ET.tex	2011-04-09 21:11:24 UTC (rev 48)
+++ ET.tex	2011-04-11 05:05:01 UTC (rev 49)
@@ -118,7 +118,7 @@
 \cite{Baker:2006vn,Campanelli:2007ew,HolleyBockelmann:2007eh,
   Pollney:2007ss,Lousto:2007db,Lousto:2008dn} and references therein),
 post-Newtonian (PN) and numerical waveform comparisons and waveform
-template generation~(e.g., \cite{Baker:2006ha,
+template generation~(e.g.,~\cite{Baker:2006ha,
   Husa:2007rh,Baumgarte:2006en,Buonanno:2006ui,
   Hannam:2007wf,Gopakumar:2007vh, Campanelli:2008nk, Buonanno:2007pf, 
   Ajith:2007kx} and references
@@ -133,8 +133,8 @@
 
 It is remarkable that many of the successful techniques used to
 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,
+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}.
 
@@ -142,7 +142,7 @@
 spacetimes has been carried out in multi-dimensional
 settings, focusing on BH accretion processes and relativistic jet
 production and evolution, and has yielded results since the mid 1990s
-(e.g., \cite{font:08}\todo{cite more}). On the other hand, GRMHD coupled with
+(e.g.,~\cite{font:08}\todo{cite more}). On the other hand, GRMHD coupled with
 curvature evolution, crucial for modeling large-scale bulk
 dynamics in compact binary or single-star collapse scenarios, has
 started to produce astrophysically interesting results only in the
@@ -152,10 +152,9 @@
 
 The first full GR simulations of merging NS-NS and/or BH-NS binaries
 have recently been carried out by groups at Tokyo University
-(Shibata~et~al., GRHD and GRMHD e.g.,
-\cite{Shibata:2006bs,Shibata:2007zm,Shibata:2003ga,Shibata:2005ss,Shibata:2006nm,Yamamoto:2008js}), at UIUC (Shapiro and
-collaborators, including co-PI Faber, e.g.,
-\cite{Etienne:2007jg,Liu:2008xy}), LSU (Lehner et al.,
+(Shibata~et~al., GRHD and GRMHD
+e.g.,~\cite{Shibata:2006bs,Shibata:2007zm,Shibata:2003ga,Shibata:2005ss,Shibata:2006nm,Yamamoto:2008js}), at UIUC (Shapiro and
+collaborators, including co-PI Faber, e.g.,~\cite{Etienne:2007jg,Liu:2008xy}), LSU (Lehner et al.,
 \cite{Anderson:2007kz,Anderson:2008zp}), Caltech-Cornell (Duez et
 al.~\cite{Duez:2008rb}), and at the AEI and Sissa~(Rezzolla and collaborators,
 \cite{Baiotti:2008ra,Loeffler06a}).  The first simulations in 3D GRHD
@@ -163,10 +162,9 @@
 by co-PI Ott and collaborators \cite{ott:07prl,ott:07cqg} and by
 Shibata~et~al.~\cite{shibata:053D}. The collapse of rotating,
 hypermassive NSs to \bh{s} has been studied in 2D and 3D GR by
-Shibata~et~al.~(GRHD/GRMHD, Tokyo, e.g.,
-\cite{shibata:06,shibata:00}), Shapiro, Duez, and collaborators (GRMHD,
-UIUC, e.g., \cite{Duez:2005sf,duez:06}), and by Baiotti, Rezzolla~et~al.
-(GRHD, AEI/LSU, e.g., \cite{Baiotti04,baiotti:05,
+Shibata~et~al.~(GRHD/GRMHD, Tokyo, e.g.,~\cite{shibata:06,shibata:00}), Shapiro, Duez, and collaborators (GRMHD,
+UIUC, e.g.,~\cite{Duez:2005sf,duez:06}), and by Baiotti, Rezzolla~et~al.
+(GRHD, AEI/LSU, e.g.,~\cite{Baiotti04,baiotti:05,
 baiotti:07}). Simulations of nonaxisymmetric instabilities in
 rapidly rotating polytropic \ns{} models have been carried out
 in full GR by Shibata~et~al.~\cite{shibata:00},
@@ -196,31 +194,36 @@
 
 \subsection{Scientific}
 
-While the above list of studies represents an ensemble of breakthrough
+While the list of studies mentioned in the introduction represent
+an ensemble of breakthrough
 simulations that have significantly advanced the modeling of
 relativistic astrophysical systems, all simulations are presently
 missing one or multiple physical ingredients or are lacking the
 numerical precision to accurately and realistically model the
 large-scale and small-scale dynamics of their target systems.
 
+One of the aims of the Einstein Toolkit is to provide or extend
+some of these missing ingredients in the course of its development.
+The three most important of all possible additions, as deemed by
+the Einstein Toolkit members, are listed below.
 
-{\bf MHD} Many studies, in particular those concerned with
+\begin{itemize}
+ \item{\bf MHD}. Many studies, in particular those concerned with
   massive star collapse, binary NS-NS or BH-NS, and rotational
-  nonaxisymmetric instabilities are still performed in pure GRHD\@.
+  nonaxisymmetric instabilities, are still performed in pure GRHD\@.
   Without doubt, these systems must be simulated with GRMHD to capture
   the effects of magnetic fields that in many cases will
   alter the simulation outcome on a qualitative level and may be 
   the driving mechanisms behind much of the observable EM signature
-  from GRBs (e.g., \cite{wb:06}) 
-  and magneto-rotationally exploding core-collapse supernovae (e.g.,
-  \cite{Burrows:2007yx}). In addition, all simulations that have
+  from GRBs (e.g.,~\cite{wb:06}) 
+  and magneto-rotationally exploding core-collapse supernovae
+  (e.g.,~\cite{Burrows:2007yx}). In addition, all simulations that have
   taken into account magnetic fields are still limited to the
   ideal MHD approximation (perfect conductivity). 
   Non-ideal GRMHD schemes are just becoming 
-  available~(e.g., \cite{Palenzuela:2008sf,DelZanna:2007pk}).
+  available~(e.g.,~\cite{Palenzuela:2008sf,DelZanna:2007pk}).
 
-
- {\bf Equation of state (EOS), microphysics, and radiation
+ \item {\bf Equation of state (EOS), microphysics, and radiation
   transport}. All presently published 3D GR(M)HD simulations, with the
   sole exception of the work by co-PI Ott on massive star collapse,
   relied on a simple zero-temperature polytropic description of
@@ -230,8 +233,8 @@
   relativistic astrophysical systems. The inclusion of 
   finite-temperature EOS, derived from the microphysical descriptions of
   high-density matter, will lead to qualitatively different and much
-  more astrophysically reliable results (see, e.g.,
-  \cite{ott:07prl}). In addition, most GR(M)HD studies are
+  more astrophysically reliable results (see, e.g.,~\cite{ott:07prl}).
+  In addition, most GR(M)HD studies are
   neglecting transport of neutrinos and photons
   and their interactions with matter. Neutrinos in
   particular play a crucial role in core-collapse supernovae and in
@@ -240,43 +243,66 @@
   incorporating neutrino and/or photon transport and interactions in
   approximate ways \cite{ott:07prl,Farris:2008fe}.
 
- {\bf High-order schemes and AMR\@}. Numerical accuracy is a
+ \item {\bf High-order schemes and AMR\@}. Numerical accuracy is a
   central issue in long-term GR(M)HD simulations and must be addressed
   by a combination of (1) adaptive mesh refinement (AMR), focusing
   grid points to regions where most resolution is needed, and (2),
-  high-order numerical techniques. Presently, a large number of GRMHD
-  calculations are still performed without AMR and, due to physically
-  limited computational resources, may be underresolving the dynamics
-  in the systems under investigation.  In addition, most GRMHD
-  schemes, while implementing high-resolution shock-capturing methods,
+  high-order numerical techniques.
+
+  AMR codes, e.g., the Carpet driver,
+  are available and coupling of existing and future GRMHD codes
+  with AMR must be facilitated in order to avoid underresolving the
+  dynamics in the systems under investigation. AMR methods are,
+  on the other hand, much more complicated than uniformly distributed
+  mesh methods, and require sophisticated algorithms to make use of
+  massively parallel systems efficiently.
+
+  While AMR can increase resolution near regions of interest within
+  the computational domain, it does not increase the convergence
+  order of the underlying numerical methods. Simulations of black holes
+  can easily make use of high-order numerical methods, with 8th order
+  of convergence being not uncommon presently. However,
+  most GRMHD schemes, while implementing high-resolution shock-capturing methods,
   are still limited to 2nd-order numerical accuracy while performing
   curvature evolution typically with 4th-order accuracy. Higher order
-  GRMHD schemes are in use in fixed-background simulations (e.g.,
-  \cite{Tchekhovskoy:2007zn}), but still await implementation in 
-  fully dynamical simulations. AMR codes, e.g., the Carpet driver,
-  are available and coupling of existing and future GRMHD codes
-  with AMR must be facilitated.
+  GRMHD schemes are in use in fixed-background simulations
+  (e.g.,~\cite{Tchekhovskoy:2007zn}), but still await implementation in 
+  fully dynamical simulations.
+\end{itemize}
 
 
 \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.
 
-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.
+While the Einstein Toolkit does have a large group of users, many of them
+are not directly collaborating on science problems, and some can even be
+seen as competitors. However, all groups agree that sharing the development
+of the underlying infrastructure is benefitial for every group and the
+progress in science in general. This is achieved by lifting much of the
+otherwise necessary burden of creating such an infrastructure off the
+research groups' shoulders, while at the same time increasing the amount
+of code-review, and by this, code quality.
 
+In addition, the Einstein Toolkit provides computer scientists an
+ideal platform to perform state-of-the-art research, which is directly
+benefiting research in other areas of science and hereby providing an
+immediate application of their research. One of the most prominent
+examples within the Einstein Toolkit is the Cactus Computational Toolkit,
+a framework developed by computer scientists and now used by researchers
+is many other fields.
+
 \section{Design and Strategy\pages{0.5 Frank}}
 
 The mechanisms for the development and support of the Einstein Toolkit are
-designed to be open, transparent and community driven. All the source code,
+designed to be open, transparent and community-driven. The complete 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
+under open-source licenses. The Einstein Toolkit maintains an version
+control system ({\tt svn.einsteintoolkit.org}) with open access which contains software
 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
@@ -284,45 +310,55 @@
 discussion about the toolkit takes 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, and minutes are recorded and publicly available.  The Einstein Toolkit
+participate. Meeting minutes are recorded and publicly available as well.
+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. 
 The community heavily uses an issue tracking system
-({\tt trac.einsteintoolkit.org}), with submissions open to everyone.
+({\tt trac.einsteintoolkit.org}), with submissions also open to everyone.
 
-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
+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
 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
+Maintainer is to review and apply patches sent by users in order to ensure
 a high software quality level. Every substancial change or addition to
 the toolkit has to be reviewed by another Einstein Toolkit Maintainer,
-and is generally open for discussion on the users mailing list. Despite this
-not being enforced by technically it seems to work pretty well while at the
-same time promoting development.
+and is generally open for discussion on the users mailing list. This convention,
+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}}
 
-\subsection{Cactus Framework\pages{1 Gab}}
+\subsection{Cactus Framework\pages{1 Gab/Frank}}
 
 The \textbf{Cactus
   Framework}~\cite{CS_cactus_web,CS_Goodale02a,CS_cactususersguide} is
 an open source, modular, portable programming environment for
 collaborative HPC computing, primarily developed at LSU\@. Cactus has
 a generic parallel computational toolkit with modules providing
-parallel drivers, coordinates, boundary conditions, interpolators,
+e.g.\ parallel drivers, coordinates, boundary conditions, interpolators,
 reduction operators, and efficient I/O in different data
 formats. Generic interfaces are used, making it possible to use
 external packages and improved modules which are immediately available
 to its users.  Cactus is involved in the NSF Blue Waters consortium
 for petascale computing, has funding from NSF SDCI to
-develop new application level tools for performance and correctness,
-as well as the current NSF XiRel award for scalable AMR\@.
-\S\ref{broader} describes the growing impact of Cactus in other
-application domains.
+develop new application level tools for performance and correctness.
 
-\todo{ES: Say something about component structure and component
-  interfaces; I refer to this in the Carpet subsection below.}
+The structure of the Cactus framework is completely modular, with
+only a very small core proving the interfaces between modules,
+both at compile- and run-time. The Cactus modules, called ``thorns'',
+may, and typically do, specify inter-module dependencies, e.g., to share or
+extend configuration information, common variables or runtime parameters.
+Modules compiled into an executable can remain dormant at run-time.
+This usage of modules and a common interface between them, enables researchers
+to 1) easily use modules written by others without the need to understand
+all details of their implementation, and 2) to write their own modules
+without the need to change the source code of other parts of a simulation,
+in the (supported) programming language of their choice.
+The number of active modules within a typical Cactus simulation ranges
+from a few ten to hundereds, often with an extensive set of inter-module
+dependencies.
 
 The Cactus Framework was developed by the
 numerical relativity community, and although it is a general component
@@ -488,7 +524,7 @@
 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
+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.
 
@@ -595,6 +631,11 @@
   $n^\mu$.
 \end{itemize}
 
+Note that, while this includes definitions for variables used to store information
+about magnetic fields, the implementation of an evolution system for magnetic fields
+within the Einstein Toolkit is at the time of this publication still in development, and
+not yet officially released.
+
 HydroBase also sets up scheduling blocks that organize the main functions which modules of a
 hydrodynamics code may need. All of those scheduling blocks are optional, however if used,
 they might simplify existing codes and make them more interoperable. HydroBase itself does
@@ -618,8 +659,8 @@
 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
+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 
@@ -662,13 +703,18 @@
 \codename{TwoPunctures}, which generates accurate binary black-hole initial data.
 
 Initial data to test different parts of hydrodynamics evolution systems can
-be provided by \codename{GRHydro\_InitData}, e.g. for shock tests,
+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}.
+\begin{figure}
+ \label{fig:TP_BHNS_coordinates}
+ \centering\includegraphics[width=0.5\textwidth]{TwoPunctures_grid_BHNS}\\
+ \caption{Example of a TwoPunctures coordinate system for BH-NS binary initial data}
+\end{figure}
 
 \subsection{Equation of States}\pages{1 Christian}
 
@@ -989,7 +1035,7 @@
 
 % Event horizon
 The event horizon module \codename{EHFinder}~\cite{Diener:2003jc} 
-evolves a null surface backwards in time given an initial guess (e.g.
+evolves a null surface backwards in time given an initial guess (e.g.,
 the last apparent horizon) which will, in the vicinity of an event 
 horizon, converge exponentially to that event horizon. This has to be 
 done after a simulation has already evolved the initial data forward 

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

File [added]: TwoPunctures_grid_BHNS.pdf
Delta lines: +0 -0
===================================================================
(Binary files differ)



Property changes on: figures/TwoPunctures_grid_BHNS.pdf
___________________________________________________________________



More information about the Commits mailing list