User: jfaber Date: 2011/11/14 11:52 AM

Modified: / ET.tex

Log: No "eq." in IOP journals, minor typos

File Changes:

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

File [modified]: ET.tex Delta lines: +22 -28 =================================================================== --- ET.tex 2011-11-14 17:35:13 UTC (rev 235) +++ ET.tex 2011-11-14 17:52:10 UTC (rev 236) @@ -576,30 +576,30 @@ \subsection{Kranc} \label{sec:kranc}

-Kranc\cite{Husa:2004ip,Lechner:2004cs,Kranc:web} is a Mathematica application which converts a high-level +\codename{Kranc}\cite{Husa:2004ip,Lechner:2004cs,Kranc:web} is a Mathematica application which converts a high-level continuum description of a PDE into a highly optimized module for {\tt Cactus}, suitable for running on anything from a laptop to the world's largest HPC systems. Many codes contain a large amount of complexity, including expanded tensorial expressions, numerical methods, and the large amount of ``glue'' code needed for interfacing a modern HPC -application with the underlying framework. Kranc absorbs this +application with the underlying framework. \codename{Kranc} absorbs this complexity, allowing the scientist to concentrate on writing only the -Kranc script which describes the continuum equations. +\codename{Kranc} script which describes the continuum equations.

This approach brings with it many advantages. With these complicated -elements factored out, a scientist can write many different Kranc -codes, all taking advantage of the features of Kranc and avoiding +elements factored out, a scientist can write many different \codename{Kranc} +codes, all taking advantage of the features of \codename{Kranc} and avoiding unnecessary or trivial but painstaking duplication. The codes might be variations on a theme, perhaps versions which use different sets of variables or formulations of the equations, or they could represent completely different physical systems. The use of a symbolic algebra package, Mathematica, enables high-level optimizations which are not performed by -the compiler to be implemented in Kranc. +the compiler to be implemented in \codename{Kranc}.

-Any enhancements to Kranc can be automatically applied to all codes -which are generated using Kranc. Existing codes have easily benefited -from the following features added to Kranc after the codes themselves +Any enhancements to \codename{Kranc} can be automatically applied to all codes +which are generated using \codename{Kranc}. Existing codes have easily benefited +from the following features added to \codename{Kranc} after the codes themselves were written: (i) OpenMP parallelization support, necessary for efficient use of modern multi-core processors; (ii) support for multipatch domains with the Llama~\cite{Pollney:2009yz} code; (iii) automatic generation of @@ -607,9 +607,9 @@ the processor for two grid points at the same time; and (iv) common sub-expression elimination, and various other optimization strategies.

-Within the Einstein Toolkit, the Einstein evolution thorn McLachlan, -as well as the wave extraction thorn WeylScal4, are both generated -using Kranc, and hence support all the above features. +Within the Einstein Toolkit, the Einstein evolution thorn \codename{McLachlan}, +as well as the wave extraction thorn \codename{WeylScal4}, are both generated +using \codename{Kranc}, and hence support all the above features.

\section{Components} The Einstein Toolkit uses the modular {\tt Cactus} framework as its underlying infrastructure. @@ -1193,7 +1193,7 @@ evolution of the shift $\beta^i$ and thus that of the spatial coordinates $x^i$ will be exponentially damped. This damping time scale is set by the gauge parameter $\eta$ -(see eq.~\eref{eq:eta}) which has dimension $1/T$ (inverse time). +(see~\eref{eq:eta}) which has dimension $1/T$ (inverse time). As described in~\cite{Muller:2009jx, Schnetter:2010cz}, this time scale may need to be adapted in different regions of the domain to avoid spurious high-frequency behavior in regions that otherwise @@ -1213,8 +1213,8 @@ \end{eqnarray} with a constant $R$ defining the transition radius between the interior, where $q\approx1$, and the exterior, where $q$ falls off as -$1/r$. Eq.~\eref{eq:eta} describes how $q$ appears in the gauge -parameters. +$1/r$. A description of how $q$ appears in the gauge +parameters may be found in~\eref{eq:eta}.

@@ -1517,8 +1517,8 @@ It is these flux terms that are then used to evolve the hydrodynamic quantities.

The Roe solver~\cite{Roe:1981ar} involves linearizing the evolution system -for the hydrodynamic evolution. Eq.~\eref{eq:Riemann}, defining -the Jacobian matrix $A\equiv \frac{\partial f}{\partial q}$, and +for the hydrodynamic evolution, defining +the Jacobian matrix $A\equiv \frac{\partial f}{\partial q}$ (see~\eref{eq:Riemann}), and working out the eigenvalues $\lambda^i$ and left and right eigenvectors, $l_i$ and $r^j$, assumed to be orthonormalized so that $l_i\cdot r^j=\delta_i^j$. Defining the characteristic variables @@ -1589,8 +1589,6 @@ \partial_t (DX)+\partial_i(\alpha \tilde{v}^iDX)=0. \end{equation}

-\todo{Christian: Temperature Evolution?} - \subsection{Equations of State} \label{sec:eoss} %%% Written by Christian Ott @@ -1761,7 +1759,7 @@ which \codename{EHFinder} is also based. Defining a surface as a level set $f(x^i)=r-h(\theta,\phi)=0$, and introducing an unphysical timelike parameter $\lambda$ to -parametrize the flow of $h$ towards a solution, Eq.~\eref{eq:ah_theta} +parametrize the flow of $h$ towards a solution, \eref{eq:ah_theta} can be rewritten \begin{equation} \partial_\lambda h = - \left( \frac{\alpha}{\ell_\mathrm{max} @@ -1783,9 +1781,9 @@ \end{equation}

The \codename{AHFinderDirect} module~\cite{Thornburg:2003sf} is a -faster alternative to \codename{AHFinder}. Its approach is to view -eq.~\eref{eq:ah_theta} as an elliptic PDE for $h(\theta,\phi)$ on $S^2$ -using standard finite differencing methods. Rewriting eq.~\eref{eq:ah_theta} +faster alternative to \codename{AHFinder}. Its approach is to +view~\eref{eq:ah_theta} as an elliptic PDE for $h(\theta,\phi)$ on $S^2$ +using standard finite differencing methods. Rewriting~\eref{eq:ah_theta} in the form \begin{equation} \Theta \equiv \Theta\left(h,\partial_u h,\partial_{uv}h; @@ -1962,9 +1960,6 @@ \end{equation} of a projection onto spin-weighted spherical harmonics ${}_s Y_{\ell m}$.

-%\todo{CCE} -% JF: are we discussing CCE in this paper? WE say not in the conclusions... - \subsubsection{Object tracking} \label{sec:object-tracking} We provide a module (\codename{PunctureTracker}) for tracking BH @@ -2191,7 +2186,6 @@ \end{figure}

\section{Examples} -\todo{Update if necessary}

To demonstrate the properties of the code and its capabilities, we have used it to simulate common astrophysical configurations of interest. Given the community-oriented direction of the project, the parameter files required to launch these simulations and a host of others are included and documented in the code releases, along with the data files produced by a representative set of simulation parameters to allow for code validation and confirmation of correct code performance on new platforms and architectures. As part of the internal validation process, nightly builds are checked against a set of benchmarks to ensure that consistent results are generated with the inclusion of all new commits to the code. @@ -2966,7 +2960,7 @@

\bibliographystyle{iopart-num-edit} %\bibliographystyle{amsplain-url} -% TODO: all references should be in manifest/einsteintoolkit +% all references should be in manifest/einsteintoolkit \bibliography{manifest/einsteintoolkit}

\end{document}