User: knarf Date: 2011/11/14 01:02 AM
Modified: / ET.tex
Log: remove some commas
File Changes:
Directory: / ============
File [modified]: ET.tex Delta lines: +10 -10 =================================================================== --- ET.tex 2011-11-14 06:56:39 UTC (rev 204) +++ ET.tex 2011-11-14 07:02:46 UTC (rev 205) @@ -379,15 +379,15 @@
The structure of the {\tt Cactus} framework is completely modular, with only a very small core (the ``flesh'') which provides the interfaces between -modules, +modules both at compile- and run-time. The {\tt 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 +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) write their own modules -without the need to change the source code of other parts of a simulation, +all details of their implementation and 2) 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 {\tt Cactus} simulation ranges from tens to hundreds and often has an extensive set of inter-module @@ -455,7 +455,7 @@ conditions to a fine level requires interpolation in space and time from a coarser level. Outputting the solution at a time in between coarse grid time steps also requires interpolation. These parallel -interpolation operations are implemented efficiently in {\tt Carpet}, and +interpolation operations are implemented efficiently in {\tt Carpet} and are applied automatically as specified in the execution schedule, i.e.\ without requiring function calls in user code. Figure~\ref{fig:carpet-details} describes some details of the @@ -504,7 +504,7 @@ tasks related to online data analysis and other necessary tasks reduce scalability by up to a factor of ten.
-We estimate that, +We estimate that in 2010, about 7,000 core years of computing time (45 million core hours) will have been used via {\tt Carpet} by more than a dozen research groups world-wide. To date, more than 90 peer-reviewed publications and more @@ -616,8 +616,8 @@ using Kranc, and hence support all the above features.
\section{Components} -The Einstein Toolkit uses the {\tt Cactus} framework as underlying infrastructure, -which promotes a very modular design. A simulation within {\tt Cactus} could just +The Einstein Toolkit uses the modular {\tt Cactus} framework as its underlying infrastructure. +A simulation within {\tt Cactus} could just use one module, but in practice simulations are often composed from hundreds of components. Some of these modules provide common definitions and conventions (see section~\ref{sec:base_modules}). Others provide @@ -626,7 +626,7 @@ sections~\ref{sec:Kevol} and~\ref{sec:GRHydro}, respectively. The thermodynamic properties of fluids are encoded in equations of state (see section~\ref{sec:eoss}). -Finally, additional quantities besides those being directly evolved are often +Finally, additional quantities which are not directly evolved are often interesting for a detailed analysis of the simulation's results. Modules providing commonly used analysis methods are described in section~\ref{sec:analysis}. @@ -634,7 +634,7 @@ \subsection{Base Modules} \label{sec:base_modules} Modular designs have proven to be essential for distributed development -of complex software systems, and require the use of well-defined interfaces. +of complex software systems and require the use of well-defined interfaces. Low-level interoperability within the Einstein Toolkit is provided by the {\tt Cactus} infrastructure. One example of this is the usage of one module from within another, e.g., by calling a function within another thorn
commits@lists.einsteintoolkit.org