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

[knarf at cct.lsu.edu]

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