Changeset 2906 for inundation/parallel/documentation/parallel.tex

Timestamp:

May 18, 2006, 11:45:48 AM (18 years ago)

Author:

linda

Message:

Made correction to the parallel report

File:

• inundation/parallel/documentation/parallel.tex (modified) (12 diffs)

inundation/parallel/documentation/parallel.tex

@@ -27 +27 @@
 
 The first step in parallelising the code is to subdivide the mesh
-into, roughly, equally sized partitions. On a rectangular domain this may be
+into, roughly, equally sized partitions. On a rectangular mesh this may be
 done by a simple co-ordinate based dissection, but on a complicated
-domain such as the Merimbula grid shown in Figure \ref{fig:mergrid}
+domain such as the Merimbula mesh shown in Figure \ref{fig:mergrid}
 a more sophisticated approach must be used.  We use pymetis, a
 python wrapper around the Metis
@@ -40 +40 @@
 \begin{figure}[hbtp]
   \centerline{ \includegraphics[scale = 0.75]{figures/mermesh.eps}}
-  \caption{The Merimbula grid.}
+  \caption{The Merimbula mesh.}
  \label{fig:mergrid}
 \end{figure}
@@ -87 +87 @@
 setting up the communication pattern as well as assigning the local numbering scheme for the submeshes.
 
-Consider the example subpartitioning given in Figure \ref{fig:subdomain}. During the \code{evolve} calculations Triangle 3 in Submesh 0 will need to access its neighbour Triangle 4 stored in Submesh 1. The standard approach to this problem is to add an extra layer of triangles, which we call ghost triangles. The ghost triangles
+Consider the example subpartitioning given in Figure \ref{fig:subdomain}. During the \code{evolve} calculations Triangle 2 in Submesh 0 will need to access its neighbour Triangle 3 stored in Submesh 1. The standard approach to this problem is to add an extra layer of triangles, which we call ghost triangles. The ghost triangles
 are read-only, they should not be updated during the calculations, they are only there to hold any extra information that a processor may need to complete its calculations. The ghost triangle values are updated through communication calls. Figure \ref{fig:subdomaing} shows the submeshes with the extra layer of ghost triangles.
 
 \begin{figure}[hbtp]
   \centerline{ \includegraphics[scale = 0.6]{figures/subdomain.eps}}
-  \caption{An example subpartioning.}
+  \caption{An example subpartioning of a mesh.}
  \label{fig:subdomain}
 \end{figure}
@@ -99 +99 @@
 \begin{figure}[hbtp]
   \centerline{ \includegraphics[scale = 0.6]{figures/subdomainghost.eps}}
-  \caption{An example subpartioning with ghost triangles.}
+  \caption{An example subpartioning with ghost triangles. The numbers in brackets shows the local numbering scheme that is calculated and stored with the mesh, but not implemented until the local mesh is built. See Section \ref{sec:part4}. }
  \label{fig:subdomaing}
 \end{figure}
 
-When partitioning the mesh we introduce new, dummy, boundary edges. For example, Triangle 3 in Submesh 1, from Figure \ref{fig:subdomaing}, originally shared an edge with Triangle 2, but after partitioning that edge becomes a boundary edge. These new boundary edges are are tagged as \code{ghost} and should, in general, be assigned a type of \code{None}. The following piece of code taken from {\tt run_parallel_advection.py} shows an example.  
- 
+When partitioning the mesh we introduce new, dummy, boundary edges. For example, Triangle 2 in Submesh 1 from Figure \ref{fig:subdomaing} originally shared an edge with Triangle 1, but after partitioning that edge becomes a boundary edge. These new boundary edges are are tagged as \code{ghost} and should, in general, be assigned a type of \code{None}. The following piece of code taken from {\tt run_parallel_advection.py} shows an example.  
 {\small \begin{verbatim}  
 T = Transmissive_boundary(domain)
@@ -112 +111 @@
 \end{verbatim}}
 
-
-Looking at Figure \ref{fig:subdomaing} we see that after each \code{evolve} step Processor 0  will have to send the updated values for Triangle 3 and Triangle 5 to Processor 1, and similarly Processor 1 will have to send the updated values for triangles 4, 7 and 6 (recall that Submesh $p$ will be assigned to Processor $p$). The \code{build_submesh} function builds a dictionary that defines the communication pattern.
-
-Finally, the ANUGA code assumes that the triangles (and nodes etc.) are numbered consecutively starting from 1 (FIXME (Ole): Isn't it 0?). Consequently, if Submesh 1 in Figure \ref{fig:subdomaing} was passed into the \code{evolve} calculations it would crash due to the 'missing' triangles. The \code{build_submesh} function determines a local numbering scheme for each submesh, but it does not actually update the numbering, that is left to the function \code{build_local}.
+Looking at Figure \ref{fig:subdomaing} we see that after each \code{evolve} step Processor 0  will have to send the updated values for Triangle 2 and Triangle 4 to Processor 1, and similarly Processor 1 will have to send the updated values for Triangle 3 and Triangle 5 (recall that Submesh $p$ will be assigned to Processor $p$). The \code{build_submesh} function builds a dictionary that defines the communication pattern.
+
+Finally, the ANUGA code assumes that the triangles (and nodes etc.) are numbered consecutively starting from 0. Consequently, if Submesh 1 in Figure \ref{fig:subdomaing} was passed into the \code{evolve} calculations it would crash. The \code{build_submesh} function determines a local numbering scheme for each submesh, but it does not actually update the numbering, that is left to \code{build_local}.
+
 
 \subsection {Sending the Submeshes}\label{sec:part3}
@@ -121 +120 @@
 All of functions described so far must be run in serial on Processor 0. The next step is to start the parallel computation by spreading the submeshes over the processors. The communication is carried out by
 \code{send_submesh} and \code{rec_submesh} defined in {\tt build_commun.py}.
-The \code{send_submesh} function should be called on Processor 0 and sends the Submesh $p$ to Processor $p$, while \code{rec_submesh} should be called by Processor $p$ to receive Submesh $p$ from Processor 0. Note that the order of communication is very important, if any changes are made to the \code{send_submesh} function the corresponding change must be made to the \code{rec_submesh} function.
+The \code{send_submesh} function should be called on Processor 0 and sends the Submesh $p$ to Processor $p$, while \code{rec_submesh} should be called by Processor $p$ to receive Submesh $p$ from Processor 0. 
+
+As an aside, the order of communication is very important. If someone was to modify the \code{send_submesh} routine the corresponding change must be made to the \code{rec_submesh} routine.
 
 While it is possible to get Processor 0 to communicate it's submesh to itself, it is an expensive and unnecessary communication call. The {\tt build_commun.py} file also includes a function called \code{extract_hostmesh} that should be called on Processor 0 to extract Submesh 0.
 
 
-\subsection {Building the Local Mesh}
+\subsection {Building the Local Mesh}\label{sec:part4}
 After using \code{send_submesh} and \code{rec_submesh}, Processor $p$ should have its own local copy of Submesh $p$, however as stated previously the triangle numbering will be incorrect on all processors except number $0$. The \code{build_local_mesh} function from {\tt build_local.py} primarily focuses on renumbering the information stored with the submesh; including the nodes, vertices and quantities. Figure \ref{fig:subdomainf} shows what the mesh in each processor may look like.
 
@@ -147 +148 @@
 \begin{verbatim}
 #######################
-# Partition the domain
+# Partition the mesh
 #######################
 
@@ -157 +158 @@
 \end{verbatim}
 
-This rectangular mesh is artificial, and the approach to subpartitioning the mesh is different to the one described above, however this example may be of interest to those who want to measure the parallel efficiency of the code on their machine. A rectangular mesh should give a good load balance and is therefore an important first test problem.  
-
-
-A more \lq real life\rq\ mesh is the Merimbula mesh used in the code shown in Section \ref{sec:codeRPMM}. This example also solves the advection equation. In this case the techniques described in Section \ref{sec:part} must be used to partition the mesh. Figure \ref{fig:code} shows the part of the code that is responsible for spreading the domain over the processors. We now look at the code in detail.
+Most simulations will not be done on a rectangular mesh, and the approach to subpartitioning the mesh is different to the one described above, however this example may be of interest to those who want to measure the parallel efficiency of the code on their machine. A rectangular mesh should give a good load balance and is therefore an important first test problem.  
+
+
+A more \lq real life\rq\ mesh is the Merimbula mesh used in the code shown in Section \ref{sec:codeRPMM}. This example also solves the advection equation. In this case the techniques described in Section \ref{sec:part} must be used to partition the mesh. Figure \ref{fig:code} shows the part of the code that is responsible for spreading the mesh over the processors. We now look at the code in detail.
 
 \begin{figure}[htbp]
@@ -170 +171 @@
     filename = 'merimbula_10785.tsh'
 
-    domain_full = pmesh_to_domain_instance(filename, Advection_Domain)
-    domain_full.set_quantity('stage', Set_Stage(756000.0,756500.0,4.0))
-
-    # Define the domain boundaries for visualisation
-   
-    rect = array(domain_full.xy_extent, Float)
+    mesh_full = pmesh_to_domain_instance(filename, Advection_Domain)
+    mesh_full.set_quantity('stage', Set_Stage(756000.0,756500.0,4.0))
 
     # Subdivide the mesh
 
     nodes, triangles, boundary, triangles_per_proc, quantities  =\
-            pmesh_divide_metis(domain_full, numprocs)
+            pmesh_divide_metis(mesh_full, numprocs)
 
     # Build the mesh that should be assigned to each processor.
@@ -195 +192 @@
     # Build the local mesh for processor 0
 
-    hostmesh = extract_hostmesh(submesh)
-    points, vertices, boundary, quantities, ghost_recv_dict, full_send_dict = \
-             build_local_mesh(hostmesh, 0, triangles_per_proc[0], numprocs)
+     points, vertices, boundary, quantities, ghost_recv_dict, full_send_dict =\
+              extract_hostmesh(submesh, triangles_per_proc)
 
 else:
@@ -213 +209 @@
 \begin{itemize}
 \item 
-These first few lines of code read in and define the (global) mesh.
+These first few lines of code read in and define the (global) mesh. The \code{Set_Stage} function sets the initial conditions. See the code in \ref{sec:codeRPMM} for the definition of \code{Set_Stage}.
 \begin{verbatim}
     filename = 'merimbula_10785.tsh'
-    domain_full = pmesh_to_domain_instance(filename, Advection_Domain)
-    domain_full.set_quantity('stage', Set_Stage(756000.0,756500.0,4.0))
-\end{verbatim}
-
-\item
-The \code{rect} array is used by the visualiser and records the domain size.
+    mesh_full = pmesh_to_domain_instance(filename, Advection_Domain)
+    mesh_full.set_quantity('stage', Set_Stage(756000.0,756500.0,4.0))
+\end{verbatim}
+
 \item \code{pmesh_divide_metis} divides the mesh into a set of non-overlapping subdomains as described in Section \ref{sec:part1}.
 \begin{verbatim}
     nodes, triangles, boundary, triangles_per_proc, quantities  =\
-            pmesh_divide_metis(domain_full, numprocs)
-\end{verbatim}
-
-\item The next step is to build a boundary layer of ghost triangles and define the communication pattern. This step is implemented by \code{build_submesh} as discussed in Section \ref{sec:part2}. 
+            pmesh_divide_metis(mesh_full, numprocs)
+\end{verbatim}
+
+\item The next step is to build a boundary layer of ghost triangles and define the communication pattern. This step is implemented by \code{build_submesh} as discussed in Section \ref{sec:part2}. The \code{submesh} variable contains a copy of the submesh for each processor. 
 \begin{verbatim}        
     submesh = build_submesh(nodes, triangles, boundary, quantities, \
@@ -240 +234 @@
 \end{verbatim}
 
-The processors receive a given subpartition by calling \code{rec_submesh}. The \code{rec_submesh} routine also calls \code{build_local_mesh}. The \code{build_local_mesh} routine described in Section \ref{sec:part4} ensures that the information is stored in a way that is compatible with the Domain datastructure. This means, for example, that the triangles and nodes must be numbered consecutively starting from 1 (FIXME (Ole): or is it 0?).
-\begin{verbatim}
-    points, vertices, boundary, quantities, ghost_recv_dict, full_send_dict = \
+
+The processors receives a given subpartition by calling \code{rec_submesh}. The \code{rec_submesh} routine also calls \code{build_local_mesh}. The \code{build_local_mesh} routine described in Section \ref{sec:part4} ensures that the information is stored in a way that is compatible with the Domain datastructure. This means, for example, that the triangles and nodes must be numbered consecutively starting from 0.
+
+\begin{verbatim}
+    points, vertices, boundary, quantities, ghost_recv_dict, full_send_dict=\
              rec_submesh(0)
 \end{verbatim}
 
-Note that the submesh is not received by, or sent to, Processor 0. Rather     \code{hostmesh = extract_hostmesh(submesh)} extracts the appropriate information. This saves the cost of an unnecessary communication call. It is described further in Section \ref{sec:part3}.
-\begin{verbatim}
-    hostmesh = extract_hostmesh(submesh)
-    points, vertices, boundary, quantities, ghost_recv_dict, full_send_dict = \
-             build_local_mesh(hostmesh, 0, triangles_per_proc[0], numprocs)
+Note that the submesh is not received by, or sent to, Processor 0. Rather     \code{hostmesh = extract_hostmesh(submesh)} simply extracts the mesh that has been assigned to Processor 0. Recall \code{submesh} contains the list of submeshes to be assigned to each processor. This is described further in Section \ref{sec:part3}. The \code{build_local_mesh} renumbers the nodes
+\begin{verbatim}
+    points, vertices, boundary, quantities, ghost_recv_dict, full_send_dict)=\
+              extract_hostmesh(submesh, triangles_per_proc)
 \end{verbatim}