[cig-commits] commit 2267 by bangerth to /var/svn/dealii/aspect

dealii.demon at gmail.com dealii.demon at gmail.com
Thu Jan 9 09:19:19 PST 2014


Revision 2267

Mention that others have also contributed to the manual.

U   trunk/aspect/doc/manual/manual.tex


http://www.dealii.org/websvn/revision.php?repname=Aspect+Repository&path=%2F&rev=2267&peg=2267

Diff:
Modified: trunk/aspect/doc/manual/manual.tex
===================================================================
--- trunk/aspect/doc/manual/manual.tex	2014-01-08 18:50:21 UTC (rev 2266)
+++ trunk/aspect/doc/manual/manual.tex	2014-01-09 17:19:16 UTC (rev 2267)
@@ -210,14 +210,14 @@
 @Manual{aspectmanual,
         title = 	 {	extsc{ASPECT}: Advanced Solver for Problems in Earth's
           ConvecTion},
-        author = 	 {W. Bangerth and T. Heister},
+        author = 	 {W. Bangerth and T. Heister and others},
         organization = {Texas A\&M University/Computational
                            Infrastructure in Geodynamics},
         year = 	 2013
       }
 \end{lstlisting}
-      
 
+
 \subsection{Acknowledgments}
 
 The development of spect{} has been funded
@@ -1206,7 +1206,7 @@
     this would be adding the line {	t{export DEAL\_II\_DIR=/path/to/deal-installed/}} to
     the file {	t{\~{}/.bashrc}}.}
 {	t{DEAL\_II\_DIR}} to the directory where you 	extit{installed} \dealii.
-  
+
 \end{enumerate}
 
 
@@ -1273,7 +1273,7 @@
 to run with 32 processors. In either case, the argument denotes the (path and)
 name of a file that contains input parameters. When you download spect{},
 there are a number of sample input file in the 	exttt{cookbooks} directory,
-corresponding to the examples discussed in Section~
ef{sec:cookbooks}. 
+corresponding to the examples discussed in Section~
ef{sec:cookbooks}.
 A full description of all
 parameters one can specify in these files is given in
 Section~
ef{sec:parameters}.
@@ -1449,9 +1449,9 @@
   The final two files of this kind, 	exttt{solution.pvd} and
   	exttt{solution.visit}, are files that
   describes to Paraview and Visit, respectively, which
-  	exttt{solution-xxxx.pvtu} and 	exttt{solution-xxxx.yyyy.vtu} jointly form 
+  	exttt{solution-xxxx.pvtu} and 	exttt{solution-xxxx.yyyy.vtu} jointly form
   a complete simulation. In the former case, the file lists the 	exttt{.pvtu}
-  files of all 
+  files of all
   timesteps together with the simulation time to which they correspond. In the
   latter case, it actually lists all 	exttt{.vtu} that belong to one
   simulation, grouped by the timestep they correspond to.
@@ -2125,7 +2125,7 @@
 we use this determine this by testing after every iteration whether the
 	extit{residual}, $r^{(k)}=A(x-x^{(k)})=b-Ax^{(k)}$, satisfies
 $\|r^{(k)}\|\learepsilon\|r^{(0)}\|$ where $arepsilon$ is called the
-(relative) 	extit{tolerance}. 
+(relative) 	extit{tolerance}.
 
 Obviously, the smaller we choose $arepsilon$, the more accurate the
 approximation $x^{(k)}$ will be. On the other hand, it will also take more
@@ -2207,7 +2207,7 @@
 actual value of it. However, unlike this ``mathematical'' pressure, we have a
 very specific notion of the ``physical'' pressure: namely a well-defined
 quantity that at the surface of Earth equals the air pressure, which compared to
-the hydrostatic pressure inside Earth is essentially zero. 
+the hydrostatic pressure inside Earth is essentially zero.
 
 As a consequence, the default in spect{} is to normalize the computed
 ``mathematical'' pressure in such a way that either the mean pressure at the
@@ -4896,7 +4896,7 @@
   of the class you want to implement. This class must be derived from one of the
   	exttt{Interface} classes we will discuss below. The file also needs to
   contain the implementation of all member functions of your class.
-  
+
   As discussed above, it is possible -- but not necessary -- to split this file
   into two: a header file, say 	exttt{my\_plugin.h}, and the
   	exttt{my\_plugin.cc} file. We do this for all the existing plugins in
@@ -4916,7 +4916,7 @@
   	exttt{ASPECT\_REGISTER\_*} macros that will be discussed in the next
   subsections; take a look at how they are used in the existing plugins in the
   spect{} source files.
-  
+
   \item You need to compile the file. There are two ways by which this can be
   achieved:
   egin{itemize}
@@ -4928,7 +4928,7 @@
     not only compiling this one file, but also link spect{}. Furthermore, when
     you upgrade from one version of spect{} to another, you need to remember
     to copy the 	exttt{my\_plugin.cc} file.
-    
+
     \item Put the  	exttt{my\_plugin.cc} file into a directory of your choice
     and compile it into a shared library yourself. This may be as easy as
     calling
@@ -4951,7 +4951,7 @@
     approach.
   \end{itemize}
 \end{itemize}
- 
+
 
ote{If you choose to compile your plugins into a shared library yourself, you
   will need to recompile them every time you upgrade your spect{} installation
   since we do not guarantee that the spect{} application binary interface
@@ -5010,7 +5010,7 @@
 
         virtual double reference_thermal_expansion_coefficient () const = 0;
 
-        
+
         // Auxiliary material properties used for postprocessing
         virtual double
         seismic_Vp (const double      temperature,
@@ -5037,7 +5037,7 @@
         virtual void
         parse_parameters (ParameterHandler &prm);
 
-        
+
         // Optional:
         virtual void initialize ();
 
@@ -5753,7 +5753,7 @@
 restart. This is important since many postprocessors store some state -- say,
 a temporal average over all the time steps seen so far, or the number of the
 last graphical output file generated so that we know how the next one needs
-to be numbered. 
+to be numbered.
 
 The typical case is that this state is the same across all processors of a
 parallel computation. Consequently, what spect{} writes into the checkpoint
@@ -6008,7 +6008,7 @@
 The first of these functions computes the set of refinement criteria (one per
 cell) and returns it in the given argument. Typical examples can be found in the
 existing implementations in the 	exttt{source/mesh\_refinement} directory. As usual, your termination
-criterion implementation will likely need to be derived from the 
+criterion implementation will likely need to be derived from the
 	exttt{SimulatorAccess} to get access to the current state of the simulation.
 
 The
@@ -6066,7 +6066,7 @@
 simulation should be terminated.
 Typical examples can be found in the existing implementations in the
 	exttt{source/termination\_criteria} directory. As usual, your termination
-criterion implementation will likely need to be derived from the 
+criterion implementation will likely need to be derived from the
 	exttt{SimulatorAccess} to get access to the current state of the simulation.
 
 The remaining functions are


More information about the CIG-COMMITS mailing list