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(a)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
___________________________________________________________________
