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

[dealii.demon at gmail.com]

Revision 2008

Add a section on checkpoint/restart and postprocessors.

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


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

Diff:
Modified: trunk/aspect/doc/manual/manual.tex
===================================================================
--- trunk/aspect/doc/manual/manual.tex	2013-11-04 00:15:48 UTC (rev 2007)
+++ trunk/aspect/doc/manual/manual.tex	2013-11-04 00:53:27 UTC (rev 2008)
@@ -5745,7 +5745,46 @@
 implement a new one, it would be helpful to look at the existing ones to see
 how they implement their functionality.
 
+\paragraph{Postprocessors and checkpoint/restart.} Postprocessors have
+	exttt{save()} and 	exttt{load()} functions that are used to write the data
+a postprocessor has into a checkpoint file, and to load it again upon
+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. 
 
+The typical case is that this state is the same across all processors of a
+parallel computation. Consequently, what spect{} writes into the checkpoint
+file is only the state obtained from the postprocessors on processor 0 of a
+parallel computation. On restart, all processors read from the same file and
+the postprocessors on 	extit{all} processors will be initialized by what the
+same postprocessor on processor 0 wrote.
+
+There are situations where postprocessors do in fact store complementary
+information on different processors. At the time of writing this, one example
+is the postprocessor that supports advecting passive particles along the
+velocity field: on every processor, it handles only those particles that lie
+inside the part of the domain that is owned by this MPI rank. The
+serialization approach outlined above can not work in this case, for obvious
+reasons. In cases like this, one needs to implement the 	exttt{save()} and
+	exttt{load()} differently than usual: one needs to put all variables that
+are common across processors into the maps of string as usual, but one then
+also needs to save all state that is different across processors, from all
+processors. There are two ways: If the amount of data is small, you can use
+MPI communications to send the state of all processors to processor zero, and
+have processor zero store it in the result so that it gets written into the
+checkpoint file; in the 	exttt{load()} function, you will then have to
+identify which part of the text written by processor 0 is relevant to the
+current processor. Or, if your postprocessor stores a large amount of data, you
+may want to open a restart file specifically for this postprocessor, use MPI
+I/O or other ways to write into it, and do the reverse operation in
+	exttt{load()}.
+
+Note that this approach requires that spect{} actually calls the
+	exttt{save()} function on all processors. This in fact happens -- though
+spect{} also discards the result on all but processor zero.
+
+
 \subsubsection{Visualization postprocessors}
 \label{sec:viz-postpostprocessors}
 

Modified: trunk/aspect/doc/manual.pdf
===================================================================
(Binary files differ)