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@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 ___________________________________________________________________