Manual Patch: Finish Concepts Chapter
Jeffrey Oldham
oldham at codesourcery.com
Thu Dec 13 05:05:31 UTC 2001
2001-Dec-12 Jeffrey D. Oldham <oldham at codesourcery.com>
This patch mainly finishes the first draft of the Pooma concepts
chapter.
* concepts.xml: New file containing the chapter describing the
Pooma concepts. Some of this material was moved out of
manual.xml. The "Computation Modes" and "Computation Environment"
material is new.
* glossary.xml: Added entries corresponding to concepts added to
concepts.xml.
* manual.xml: Concepts chapter moved into concepts.xml. Unused
material moved to "Writing Sequential Programs" chapter.
* figures/concepts.mp: Changed "geometric value" to "spatial
value".
Applied to mainline.
Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: concepts.xml
===================================================================
RCS file: concepts.xml
diff -N concepts.xml
*** /dev/null Fri Mar 23 21:37:44 2001
--- concepts.xml Wed Dec 12 21:02:05 2001
***************
*** 0 ****
--- 1,630 ----
+ <chapter id="concepts">
+ <title>Overview of &pooma; Concepts</title>
+
+ <para>FIXME: How does multi-threaded computation fit into the
+ model?</para>
+
+ <para>In the previous chapter, we presented several different
+ implementations of the &doof2d; simulation program. The
+ implementations illustrate the various containers, computation
+ modes, and computation environments that &pooma; supports. In this
+ chapter, we describe the concepts associated with each of these
+ three categories. Specific details needed by programmers are
+ deferred to later chapters.</para>
+
+ <table frame="none" colsep="0" rowsep="0" tocentry="1"
+ orient="port" pgwide="0" id="concepts-table">
+ <title>&pooma; Implementation Concepts</title>
+ <tgroup cols="3" align="center">
+ <thead>
+ <row>
+ <entry>Container</entry>
+ <entry>Computation Modes</entry>
+ <entry>Computation Environment</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>&array;</entry>
+ <entry>element-wise</entry>
+ <entry>sequential</entry>
+ </row>
+ <row>
+ <entry>&dynamicarray;</entry>
+ <entry>data-parallel</entry>
+ <entry>distributed</entry>
+ </row>
+ <row>
+ <entry>&field;</entry>
+ <entry>stencil-based</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>&tensor;</entry>
+ <entry>relational</entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>&matrix;</entry>
+ <entry></entry>
+ <entry></entry>
+ </row>
+ <row>
+ <entry>&vector;</entry>
+ <entry></entry>
+ <entry></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>The most important &pooma; concepts can be grouped into three
+ separate categories:
+ <variablelist>
+ <varlistentry>
+ <term>container</term>
+ <listitem>
+ <para>data structure holding one or more values and addressed
+ by indices</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>computation modes</term>
+ <listitem>
+ <para>styles of expressing computations</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>computation environment</term>
+ <listitem>
+ <para>description of resources for computing, e.g., single
+ processor or multi-processor</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ See <xref linkend="concepts-table"></xref>. Many &pooma; programs
+ select one possibility from each column. For example, <xref
+ linkend="tutorial-array_stencil-doof2d"></xref> used a &array;
+ container and stencils for sequential computation, while <xref
+ linkend="tutorial-field_distributed-doof2d"></xref> used a &field;
+ container and data-parallel statements with distributed
+ computation. A program may use multiple containers and various
+ computation modes, but the computation environment either has
+ distributed processors or not.</para>
+
+ <para>In the rest of this chapter, we explore these three
+ categories. First, we describe &pooma; containers, illustrating
+ the purposes of each, and explaining the concepts needed to declare
+ them. Then, we describe the different computation modes and
+ finally distributed computation concepts.</para>
+
+
+ <section id="concepts-containers">
+ <title>&pooma; Containers</title>
+
+ <para>Most &pooma; programs use <firstterm>containers</firstterm>
+ to store groups of values. &pooma; containers are objects that
+ store other objects. They control allocation and deallocation of
+ and access to these objects. They are a generalization of &c;
+ arrays, but &pooma; containers are first-class objects so they can
+ be used directly in expressions. They are similar to &cc;
+ containers such as <type>vector</type>, <type>list</type>, and
+ <type>stack</type>. See <xref
+ linkend="concepts-containers-table"></xref> for a summary of the
+ containers.</para>
+
+ <para>This chapter describes many concepts, not all of which are
+ needed to begin programming with the &pooma; Toolkit. Below we
+ introduce the different categories of concepts. After that, we
+ introduce the different &pooma;'s containers and describe how to
+ choose the appropriate one for a particular task. <xref
+ linkend="concepts-sequential_containers-declarations-dependences"></xref>
+ indicates which concepts must be understood when declaring a
+ particular container. All of these concepts are described in
+ <xref
+ linkend="concepts-containers-sequential_declarations"></xref> and
+ <xref
+ linkend="concepts-containers-distributed_declarations"></xref>.
+ Use this figure to decide which concepts in the former are
+ relevant. Reading the latter section is necessary only if
+ computing using multiple processors. The programs in the previous
+ chapter illustrate many of these concepts.</para>
+
+ <table frame="none" colsep="0" rowsep="0" tocentry="1"
+ orient="port" pgwide="0" id="concepts-containers-table">
+ <title>&pooma; Container Summary</title>
+ <tgroup cols="2" align="left">
+ <tbody>
+ <row>
+ <entry><glossterm
+ linkend="glossary-array">&array;</glossterm></entry>
+ <entry>container mapping indices to values and that may be
+ used in expressions</entry>
+ </row>
+ <row>
+ <entry><glossterm
+ linkend="glossary-dynamicarray">&dynamicarray;</glossterm></entry>
+ <entry>one-dimensional &array; whose <glossterm
+ linkend="glossary-domain">domain</glossterm> can be dynamically
+ resized</entry>
+ </row>
+ <row>
+ <entry><glossterm linkend="glossary-field">&field;</glossterm></entry>
+ <entry>container mapping indices to one or more values and
+ residing in multi-dimensional space</entry>
+ </row>
+ <row>
+ <entry><glossterm
+ linkend="glossary-tensor">&tensor;</glossterm></entry>
+ <entry>multi-dimensional mathematical tensor</entry>
+ </row>
+ <row>
+ <entry><glossterm
+ linkend="glossary-matrix">&matrix;</glossterm></entry>
+ <entry>two-dimensional mathematical matrix</entry>
+ </row>
+ <row>
+ <entry><glossterm
+ linkend="glossary-vector">&vector;</glossterm></entry>
+ <entry>multi-dimensional mathematical vector</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <!-- FIXME: Want firstterm around array. -->
+
+ <para>A &pooma; <glossterm
+ linkend="glossary-array">array;</glossterm>, generalizing a &c;
+ array, maps indices to values. Given a index or position in an
+ &array;'s domain, it returns the associated value, either by
+ returning a stored value or by computing it. The use of indices,
+ which are usually ordered tuples, permits constant-time access
+ although computing a particular value may require significant
+ time. In addition to the functionality provided by &c; arrays,
+ the &array; class automatically handles memory allocation and
+ deallocation, supports a wider variety of assignments, and can be
+ used in expressions. For example, the addition of two arrays can
+ be assigned to an array and the product of a scalar element and an
+ array is permissible.</para>
+
+ <!-- FIXME: Want firstterm around dynamicarray. -->
+
+ <para>A &pooma; <glossterm
+ linkend="glossary-dynamicarray">&dynamicarray;</glossterm> extends
+ &array; capabilities to support a dynamically-changing domain but
+ is restricted to only one dimension. When the &dynamicarray; is
+ resized, its values are preserved.</para>
+
+ <!-- FIXME: Want firstterm around field. -->
+
+ <para>A &pooma; <glossterm>&field;</glossterm> is an &array; with
+ spatial extent. Each domain consists of <glossterm
+ linkend="glossary-cell"><firstterm>cell</firstterm></glossterm>s
+ in one-, two-, or three-dimensional space. Although indexed
+ similarly to &array;s, each cell may contain multiple values and
+ multiple materials. A &field;'s <glossterm
+ linkend="glossary-mesh">mesh</glossterm> stores its spatial
+ characteristics and can map yield, e.g., a point contained in a
+ cell, the distance between two cells, and a cell's normals. A
+ &field; should be used whenever geometric or spatial computations
+ are needed, multiple values per index are desired, or a
+ computation involves more than one material.</para>
+
+ <!-- FIXME: Want firstterm around tensor. -->
+
+ <para>A <glossterm linkend="glossary-tensor">&tensor;</glossterm>
+ implements a multi-dimensional mathematical tensor. Since it is a
+ first-class type, it can be used in expressions such as
+ adding two &tensor;s.</para>
+
+ <!-- FIXME: Want firstterm around matrix. -->
+
+ <para>A <glossterm linkend="glossary-matrix">&matrix;</glossterm>
+ implements a two-dimensional mathematical matrix. Since it is a
+ first-class type, it can be used in expressions such as
+ multiplying matrices and assignments to matrices.</para>
+
+ <!-- FIXME: Want firstterm around vector. -->
+
+ <para>A <glossterm linkend="glossary-vector">&vector;</glossterm>
+ implements a multi-dimensional mathematical vector, which is an
+ ordered tuple of components. Since it is a first-class type, it
+ can be used in expressions such as adding two &vector;s and
+ multiplying a &matrix; and a &vector;.</para>
+
+ <para>The data of an &array;, &dynamicarray;, or &field; can be
+ viewed using more than one container by taking a view. A
+ <glossterm
+ linkend="glossary-view"><firstterm>view</firstterm></glossterm> of
+ an existing container &container; is a container whose domain
+ is a subset of &container;. The subset can equal the
+ original domain. A view acts like a reference in that changing
+ any of the view's values also changes the original container's and
+ vice versa. While users sometimes explicitly create views, they
+ are perhaps more frequently created as temporaries in expressions.
+ For example, if <varname>A</varname> is an &array; and
+ <varname>I</varname> is a domain, <statement>A(I) -
+ A(I-1)</statement> forms the difference between adjacent
+ values.</para>
+
+
+ <section id="concepts-containers-choosing">
+ <title>Choosing a Container</title>
+
+ <para>The two most commonly used &pooma; containers are &array;s
+ and &field;s. <xref
+ linkend="concepts-containers-choice_table"></xref> contains a
+ decision tree describing how to choose an appropriate
+ container.</para>
+
+ <table frame="none" colsep="0" rowsep="0" tocentry="1"
+ orient="port" pgwide="0" id="concepts-containers-choice_table">
+ <title>Choosing a &pooma; Container</title>
+ <tgroup cols="2" align="left">
+ <tbody>
+ <row>
+ <entry>If modeling mathematical entries,</entry>
+ <entry>use a &vector;, &matrix;, or &tensor;.</entry>
+ </row>
+ <row>
+ <entry>If indices and values reside in multi-dimensional space
+ &space;,</entry>
+ <entry>use a &field;.</entry>
+ </row>
+ <row>
+ <entry>If there are multiple values per index,</entry>
+ <entry>use a &field;.</entry>
+ </row>
+ <row>
+ <entry>If there are multiple materials participating in the same computation,</entry>
+ <entry>use a &field;.</entry>
+ </row>
+ <row>
+ <entry>If the domain's size dynamically changes and is one-dimensional,</entry>
+ <entry>use a &dynamicarray;.</entry>
+ </row>
+ <row>
+ <entry>Otherwise</entry>
+ <entry>use an &array;.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </section><!-- choosing among containers -->
+
+
+ <section id="concepts-containers-sequential_declarations">
+ <title>Declaring Sequential Containers</title>
+
+ <figure float="1" id="concepts-sequential_containers-declarations-dependences">
+ <title>Concepts For Declaring Containers</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="figures/concepts.111" format="EPS" align="center"></imagedata>
+ </imageobject>
+ <textobject>
+ <phrase>concepts involved in declaring containers</phrase>
+ </textobject>
+ </mediaobject>
+ </figure>
+
+ <para>In the previous sections, we introduced the &pooma;
+ containers and described how to choose one appropriate for a
+ given task. In this section, we describe the concepts involved
+ in declaring them. Concepts specific to distributed computation
+ are described in the next section.</para>
+
+ <para><xref
+ linkend="concepts-sequential_containers-declarations-dependences"></xref>
+ illustrates the containers and the concepts involved in their
+ declarations. The containers are listed in the top row. Lines
+ connect these containers to the components necessary for their
+ declarations. For example, an &array; declaration requires an
+ engine and a layout. These, in turn, depend on other &pooma;
+ concepts. Declarations necessary only for distributed, or
+ multiprocessor, computation are surrounded by dashed lines. You
+ can use these dependences to indicate the concepts needed for a
+ particular container.</para>
+
+ <para>An <glossterm
+ linkend="glossary-engine"><firstterm>engine</firstterm></glossterm>
+ stores and, if necessary, computes a container's values. A
+ container has one or more engines. The separation of a container
+ and its storage permits optimizing a program's space
+ requirements. For example, a container returning the same value
+ for all indices can use a constant engine, which need only store
+ one value for the entire domain. A &compressiblebrick; engine
+ reduces its space requirements to a constant whenever all its
+ values are the same. The separation also permits taking <link
+ linkend="glossary-view">view</link>s of containers without
+ copying storage.</para>
+
+ <figure float="1" id="concepts-containers-declarations-computational_implementation">
+ <title>&array; and &field; Mathematical and Computational Concepts</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="figures/concepts.101" format="EPS" align="center"></imagedata>
+ </imageobject>
+ <textobject>
+ <phrase>maps from indices to values</phrase>
+ </textobject>
+ </mediaobject>
+ </figure>
+
+ <para>A <glossterm
+ linkend="glossary-layout"><firstterm>layout</firstterm></glossterm>
+ maps <link linkend="glossary-domain">domain</link> indices to the
+ processors and computer memory used by a container's engines.
+ See <xref
+ linkend="concepts-containers-declarations-computational_implementation"></xref>.
+ A computer computes a container's values using a processor and
+ memory. The layout specifies the processor(s) and memory to use
+ for each particular index. A container's layout for a
+ uniprocessor implementation consists of its domain, the
+ processor, and its memory. For a multi-processor implementation,
+ the layout maps portions of the domain to (possibly different)
+ processors and memory.</para>
+
+ <para>A &field;'s <glossterm
+ linkend="glossary-mesh"><firstterm>mesh</firstterm></glossterm>
+ maps <link linkend="glossary-domain">domain</link> indices to
+ spatial values in &space; such as distance between cells, edge
+ lengths, and normals to cells. In other words, it provides a
+ &field;'s spatial extent. See also <xref
+ linkend="concepts-containers-declarations-computational_implementation"></xref>.
+ Different mesh types may support different spatial
+ values.</para>
+
+ <para>A mesh's <glossterm
+ linkend="glossary-corner_position"><firstterm>corner
+ position</firstterm></glossterm> specifies the <link
+ linkend="glossary-point">point</link> in &space; corresponding to
+ the lower, left corner of its <link
+ linkend="glossary-domain">domain</link>. Combining this, the
+ domain, and the cell size fully specifies the mesh's map from
+ indices to &space;.</para>
+
+ <para>A mesh's <glossterm
+ linkend="glossary-cell_size"><firstterm>cell
+ size</firstterm></glossterm> specifies the spatial dimensions of
+ a &field; <link linkend="glossary-cell">cell</link>, e.g., its
+ width, height, and depth, in &space;. Combining this, the
+ domain, and the corner position fully specifies the mesh's map
+ from indices to &space;.</para>
+
+ <para>A <glossterm
+ linkend="glossary-domain"><firstterm>domain</firstterm></glossterm>
+ is a set of points on which a container can define values. An
+ <glossterm
+ linkend="glossary-interval"><firstterm>interval</firstterm></glossterm>
+ consists of all integral points between two values. It is
+ frequently represented using mathematical interval notation [a,b]
+ even though it contains only the integral points, e.g., a, a+1,
+ a+2, …, b. The concept is generalized to multiple
+ dimensions by forming tensor product of intervals, i.e., all the
+ integral tuples in an &n;-dimensional space. For example, the
+ two-dimensional containers in the previous chapter are defined on
+ a two-dimensional domain with the both dimensions' spanning the
+ interval [0,n). A <glossterm
+ linkend="glossary-stride"><firstterm>stride</firstterm></glossterm>
+ is a subset of an interval consisting of regularly-spaced
+ points. A <glossterm
+ linkend="glossary-range"><firstterm>range</firstterm></glossterm>
+ is a subset of an interval formed by the tensor product of strides.
+ A <glossterm
+ linkend="glossary-region"><firstterm>region</firstterm></glossterm>
+ represents a continuous &n;-dimensional domain.</para>
+ </section>
+
+
+ <section id="concepts-containers-distributed_declarations">
+ <title>Declaring Distributed Containers</title>
+
+ <para>In the previous section, we introduced the concepts
+ important when declaring containers for use on uniprocessor
+ computers. When using multi-processor computers, we augment
+ these concepts with those for distributed computation. Reading
+ this section is important only for running the same program on
+ multiple processors. Many of these concepts were introduced in
+ <xref linkend="tutorial-array_distributed"></xref> and <xref
+ linkend="tutorial-field_distributed"></xref>. <xref
+ linkend="tutorial-array_distributed-doof2d-distributed_model"></xref>
+ illustrates the &pooma; distributed computation model. In this
+ section, we concentrate on the concepts necessary to declare a
+ distributed container.</para>
+
+ <para>As we noted in <xref
+ linkend="tutorial-array_distributed"></xref>, a &pooma;
+ programmer must specify how each container's domain should be
+ distributed among the available processors and memory spaces.
+ Using this information, the Toolkit automatically distributes the
+ data among the available processors and handles any required
+ communication among them. The three concepts necessary for
+ declaring distributed containers are a partition, a guard layer,
+ and a context mapper tag.</para>
+
+ <para>A <glossterm
+ linkend="glossary-partition"><firstterm>partition</firstterm></glossterm>
+ specified how to divide a container's domain into distributed
+ pieces. For example, the partition illustrated in <xref
+ linkend="tutorial-array_distributed-doof2d-distributed_model"></xref>
+ would divide a two-dimensional domain into three equally-sized
+ pieces along the x-dimension and two equally-sized pieces along
+ the y-dimension. Partitions can be independent of the size of
+ container's domain. The example partition will work on any
+ domain as long as the size of its x-dimension is a multiple of
+ three. A domain is separated into disjoint <link
+ linkend="glossary-patch">patch</link>es.</para>
+
+ <para>A <glossterm
+ linkend="glossary-guard_layer"><firstterm>guard
+ layer</firstterm></glossterm> is <quote>extra</quote> domain
+ surrounding each patch. This region has read-only values. An
+ <glossterm
+ linkend="glossary-external_guard_layer"><firstterm>external guard
+ layer</firstterm></glossterm> specifies values surrounding the
+ domain. Its presence eases computation along the domain's edges
+ by permitting the same computations as for more internal
+ computations. An <glossterm
+ linkend="glossary-internal_guard_layer"><firstterm>internal guard
+ layer</firstterm></glossterm> duplicates values from adjacent
+ patches so communication with adjacent patches need not occur
+ during a patch's computation. The use of guard layers is an
+ optimization; using external guard layers eases programming and
+ using internal guard layers reduces communication among
+ processors. Their use is not required.</para>
+
+ <para>A <glossterm
+ linkend="glossary-context_mapper"><firstterm>context
+ mapper</firstterm></glossterm> indicates how a container's
+ patches are mapped to processors and shared memory. For example,
+ the &distributedtag; indicates that the patches should be
+ distributed among the processors so each patch occurs once in the
+ entire computation. The &replicatedtag; indicates that the
+ patches should be replicated among the processors so each
+ processing unit has its own copy of all the patches. While it
+ could be wasteful to have different processors perform the same
+ computation, replicating a container can reduce possibly more
+ expensive communication costs.</para>
+ </section>
+ </section>
+
+
+ <section id="concepts-computation_modes">
+ <title>Computation Modes</title>
+
+ <para>&pooma; computations can be expressed using a variety of
+ modes. Most of &pooma; computations involve &array; or &field;
+ containers, but how their values are accessed and the associated
+ algorithms using them varies. Element-wise computation involves
+ explicitly accessing values. A data-parallel computation uses
+ expressions to represent larger subsets of a container's values.
+ Stencil-based computations write a computation as repeatedly
+ applying a local computation to each element of an array. A
+ relation among containers establishes a dependency between them so
+ the values of one container are updated whenever any other's
+ values change. A program may use any or all of these styles,
+ described below.</para>
+
+ <para><glossterm
+ linkend="glossary-element_wise"><firstterm>Element-wise</firstterm></glossterm>
+ computation accesses individual container values through explicit
+ notation. For example, values in a two-dimensional
+ container &container; might be referenced as
+ <statement>&container(3,4)</statement> or
+ <statement>&container(i,j+1)</statement>. This is the usual
+ notation for languages without objects such as &c;.</para>
+
+ <para><glossterm
+ linkend="glossary-data_parallel"><firstterm>Data-parallel</firstterm></glossterm>
+ computation uses expressions to access subsets of a container's
+ values. For example, in <xref
+ linkend="tutorial-array_parallel-doof2d"></xref>,
+ <statement>a(I,J)</statement> represents the subset of &array;
+ <varname>a</varname>'s values with coordinates in the domain
+ specified by the one-dimensional &interval;s <varname>I</varname>
+ and <varname>J</varname>. Using data-parallel expressions
+ frequently eliminates the need for writing explicit loops in
+ code.</para>
+
+ <para>A <glossterm
+ linkend="glossary-stencil"><firstterm>stencil</firstterm></glossterm>
+ computes a container's value using neighboring data values. Each
+ stencil consists of an indication of which neighboring values to
+ read and a function using those values. For example, an averaging
+ stencil may access all neighbors, averaging them. In &pooma;, we
+ represent a stencil using a function object having functions
+ indicating which neighboring values are used. Stencil
+ computations are frequently used in solving partial differential
+ equations, image processing, and geometric modeling.</para>
+
+ <para>A <glossterm
+ linkend="glossary-relation"><firstterm>relation</firstterm></glossterm>
+ is a dependence among containers so the dependent container's
+ values are updated when its values are needed and any of its
+ related containers' values have changed. A relation is specified
+ by a dependent container, independent containers, and a function
+ computing the dependent container's values using the independent
+ containers' values. To avoid excess computation, the dependent
+ container's values are computed only when needed, e.g., for
+ printing or for computing the values of another dependent
+ container. Thus, this computation is sometimes called <quote>lazy
+ evaluation</quote>.</para>
+ </section>
+
+
+ <section id="concepts-computation_environment">
+ <title>Computation Environment</title>
+
+ <para>A &pooma; program can execute on a wide variety of
+ computers. The default <glossterm
+ linkend="glossary-sequential"><firstterm>sequential computing
+ environment</firstterm></glossterm> consists of one processor and
+ associated memory, as found on a personal computer. In contrast,
+ a <glossterm
+ linkend="glossary-distributed"><firstterm>distributed computing
+ environment</firstterm></glossterm> may have multiple processors
+ and multiple distributed or shared memories. For example, some
+ desktop computers have dual processors and shared memory, while a
+ large supercomputer may have thousands of processors, perhaps
+ with groups of eight sharing the same memory.</para>
+
+ <para>Using distributed computation requires three things:
+ <orderedlist>
+ <listitem>
+ <para>the programmer must declare how container domains will
+ be distributed,</para>
+ </listitem>
+ <listitem>
+ <para>&pooma; must be configured to use a communications
+ library, and </para>
+ </listitem>
+ <listitem>
+ <para>the &pooma; executable must be run using the
+ library.</para>
+ </listitem>
+ </orderedlist>
+ All of these were illustrated in <xref
+ linkend="tutorial-array_distributed"></xref> and <xref
+ linkend="tutorial-field_distributed"></xref>. <xref
+ linkend="tutorial-array_distributed-doof2d-distributed_model"></xref>
+ illustrates the &pooma; distributed computation model. <xref
+ linkend="concepts-containers-distributed_declarations"></xref>
+ described how to declare containers with distributed domains.
+ Detailed instructions how to configure &pooma; for distributed
+ computation appear in <xref linkend="installation"></xref>.
+ Detailed instructions how to run distributed &pooma; executables
+ appear in <xref linkend="parallel"></xref>. Here we present
+ three concepts for distributed computation: patches, context, and
+ a communication library.</para>
+
+ <para>A partition divides a container's domain into disjoint
+ <glossterm
+ linkend="glossary-patch"><firstterm>patch</firstterm></glossterm>es.
+ For distributed computation, the patches are distributed among
+ various processors, which compute the associated values. As
+ illustrated in <xref
+ linkend="tutorial-array_distributed-doof2d-distributed_model"></xref>,
+ each patch can be surrounded by guard layers.</para>
+
+ <para>A <glossterm
+ linkend="glossary-context"><firstterm>context</firstterm></glossterm>
+ is a collection of shared memory and processors that can execute
+ a program of a portion of a program. It can have one or more
+ processors, but all these processors must access the same shared
+ memory. Usually the computer and its operating system, not the
+ programmer, determine the available contexts.</para>
+
+ <para>A <glossterm
+ linkend="glossary-communication_library"><firstterm>communication
+ library</firstterm></glossterm> passes messages among contexts.
+ &pooma; uses the communication library to copy information among
+ contexts, all of which is hidden from both the programmer and the
+ user. &pooma; works with the Message Passing Interface (&mpi;)
+ Communications Library (FIXME: xref linkend="mpi99", <ulink
+ url="http://www-unix.mcs.anl.gov/mpi/"></ulink>) and the &mm;
+ Shared Memory Library.</para>
+ </section>
+ </chapter>
Index: glossary.xml
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/glossary.xml,v
retrieving revision 1.1
diff -c -p -r1.1 glossary.xml
*** glossary.xml 2001/12/11 20:36:13 1.1
--- glossary.xml 2001/12/13 04:02:05
***************
*** 72,77 ****
--- 72,86 ----
</glossdef>
</glossentry>
+ <glossentry id="glossary-communication_library">
+ <glossterm>communication library</glossterm>
+ <glossdef>
+ <para>software library passing information among contexts, usually
+ using messages.</para>
+ <glossseealso otherterm="glossary-distributed">distributed computing environment</glossseealso>
+ </glossdef>
+ </glossentry>
+
<glossentry id="glossary-computing_environment">
<glossterm>computing environment</glossterm>
<glossdef>
***************
*** 137,142 ****
--- 146,165 ----
<glossdiv id="glossary-d">
<title>D</title>
+ <glossentry id="glossary-data_parallel">
+ <glossterm>data parallel</glossterm>
+ <glossdef>
+ <para>describes an expression representing a subset of a
+ container's values. For example,
+ <statement>sin(&container;)</statement> is an expression
+ indicating that the <function>sin</function> is applied to each
+ value in container &container;.</para>
+ <glossseealso otherterm="glossary-element_wise">element wise</glossseealso>
+ <glossseealso otherterm="glossary-relation">relation</glossseealso>
+ <glossseealso otherterm="glossary-stencil">stencil</glossseealso>
+ </glossdef>
+ </glossentry>
+
<glossentry id="glossary-distributed">
<glossterm>distributed computing environment</glossterm>
<glossdef>
***************
*** 166,176 ****
<glossterm>&dynamicarray;</glossterm>
<glossdef>
<para>a &pooma; container generalizing one-dimensional <link
! linkend="glossary-array">&array;</link>s by supporting domain
resizing at run-time. It maps indices to values in constant-time
access, ignoring the time to compute the values if applicable.
&dynamicarray;s are <link
! linkend="glossary-first_class">first-class object</link>s.</para>
<glossseealso otherterm="glossary-array">&array;</glossseealso>
<glossseealso otherterm="glossary-field">&field;</glossseealso>
</glossdef>
--- 189,199 ----
<glossterm>&dynamicarray;</glossterm>
<glossdef>
<para>a &pooma; container generalizing one-dimensional <link
! linkend="glossary-array">&array;</link>s by supporting domain
resizing at run-time. It maps indices to values in constant-time
access, ignoring the time to compute the values if applicable.
&dynamicarray;s are <link
! linkend="glossary-first_class">first-class object</link>s.</para>
<glossseealso otherterm="glossary-array">&array;</glossseealso>
<glossseealso otherterm="glossary-field">&field;</glossseealso>
</glossdef>
***************
*** 180,195 ****
<glossdiv id="glossary-e">
<title>E</title>
<glossentry id="glossary-engine">
<glossterm>engine</glossterm>
<glossdef>
<para>stores and, if necessary, computes a <link
! linkend="glossary-container">container</link>'s values. These
! can be specialized, e.g., to minimize storage when a domain has
! few distinct values. Separating a container and its storage also
! permits <link linkend="glossary-view">views</link> of a container.</para>
! <glossseealso otherterm="glossary-container">&engine;</glossseealso>
! <glossseealso otherterm="glossary-view">view of a container</glossseealso>
</glossdef>
</glossentry>
--- 203,232 ----
<glossdiv id="glossary-e">
<title>E</title>
+ <glossentry id="glossary-element_wise">
+ <glossterm>element wise</glossterm>
+ <glossdef>
+ <para>describes accesses to individual values within a container.
+ For example, <statement>&container(i,j)</statement> represents one
+ particular value in the container &container;.</para>
+ <glossseealso otherterm="glossary-data_parallel">data parallel</glossseealso>
+ <glossseealso otherterm="glossary-relation">relation</glossseealso>
+ <glossseealso otherterm="glossary-stencil">stencil</glossseealso>
+ </glossdef>
+ </glossentry>
+
<glossentry id="glossary-engine">
<glossterm>engine</glossterm>
<glossdef>
<para>stores and, if necessary, computes a <link
! linkend="glossary-container">container</link>'s values. These can
! be specialized, e.g., to minimize storage when a domain has few
! distinct values. Separating a container and its storage also
! permits <link linkend="glossary-view">views</link> of a
! container.</para> <glossseealso
! otherterm="glossary-container">&engine;</glossseealso>
! <glossseealso otherterm="glossary-view">view of a
! container</glossseealso>
</glossdef>
</glossentry>
***************
*** 221,227 ****
also supports geometric computations such as the distance between
two <link linkend="glossary-cell">cell</link>s and normals to a
cell. &field;s are <link
! linkend="glossary-first_class">first-class object</link>s.</para>
<glossseealso otherterm="glossary-array">&array;</glossseealso>
<glossseealso otherterm="glossary-dynamicarray">&dynamicarray;</glossseealso>
</glossdef>
--- 258,264 ----
also supports geometric computations such as the distance between
two <link linkend="glossary-cell">cell</link>s and normals to a
cell. &field;s are <link
! linkend="glossary-first_class">first-class object</link>s.</para>
<glossseealso otherterm="glossary-array">&array;</glossseealso>
<glossseealso otherterm="glossary-dynamicarray">&dynamicarray;</glossseealso>
</glossdef>
***************
*** 236,242 ****
may be declared anywhere, stored in automatic variables, accessed
anywhere, copied, and passed by both value and reference.
&pooma; <link linkend="glossary-array">&array;</link> and <link
! linkend="glossary-field">&field;</link> are first-class
types.</para>
</glossdef>
</glossentry>
--- 273,279 ----
may be declared anywhere, stored in automatic variables, accessed
anywhere, copied, and passed by both value and reference.
&pooma; <link linkend="glossary-array">&array;</link> and <link
! linkend="glossary-field">&field;</link> are first-class
types.</para>
</glossdef>
</glossentry>
***************
*** 373,380 ****
<glossentry id="glossary-patch">
<glossterm>patch</glossterm>
<glossdef>
! <para>
! ERE</para>
<glossseealso otherterm="glossary-partition">partition</glossseealso>
<glossseealso otherterm="glossary-guard_layer">guard layer</glossseealso>
<glossseealso otherterm="glossary-domain">domain</glossseealso>
--- 410,418 ----
<glossentry id="glossary-patch">
<glossterm>patch</glossterm>
<glossdef>
! <para>subset of a container's domain with values computed by a
! particular context. A partition splits a domain into patches. It
! may be surrounded by external and internal guard layers.</para>
<glossseealso otherterm="glossary-partition">partition</glossseealso>
<glossseealso otherterm="glossary-guard_layer">guard layer</glossseealso>
<glossseealso otherterm="glossary-domain">domain</glossseealso>
*************** ERE</para>
*** 417,422 ****
--- 455,475 ----
<glossseealso otherterm="glossary-interval">interval</glossseealso>
</glossdef>
</glossentry>
+
+ <glossentry id="glossary-relation">
+ <glossterm>relation</glossterm>
+ <glossdef>
+ <para>dependence between a dependent container and one or more
+ independent containers and an associated function. If a dependent
+ container's values are needed and one or more of the independent
+ containers' values have changed, the dependent container's values
+ are computed using the function and the independent containers'
+ values. Relations implement <quote>lazy evaluation</quote>.</para>
+ <glossseealso otherterm="glossary-data_parallel">data parallel</glossseealso>
+ <glossseealso otherterm="glossary-element_wise">element wise</glossseealso>
+ <glossseealso otherterm="glossary-stencil">stencil</glossseealso>
+ </glossdef>
+ </glossentry>
</glossdiv>
<glossdiv id="glossary-s">
*************** ERE</para>
*** 427,435 ****
<glossdef>
<para>a computing environment with one processor and associated
memory. Only one processor executes a program even if the
! conmputer itself has multiple processors.</para>
<glossseealso otherterm="glossary-computing_environment">computing environment</glossseealso>
<glossseealso otherterm="glossary-distributed">distributed computing environment</glossseealso>
</glossdef>
</glossentry>
--- 480,503 ----
<glossdef>
<para>a computing environment with one processor and associated
memory. Only one processor executes a program even if the
! computer itself has multiple processors.</para>
<glossseealso otherterm="glossary-computing_environment">computing environment</glossseealso>
<glossseealso otherterm="glossary-distributed">distributed computing environment</glossseealso>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id="glossary-stencil">
+ <glossterm>stencil</glossterm>
+ <glossdef>
+ <para>set of values neighboring a container value and a function
+ using those values to compute it. For example, the stencil in a
+ two-dimensional Conway game of life consists of a value's eight
+ neighbors and a function that sets the value to
+ <quote>live</quote> if it is already live or it has exactly three
+ live neighbors.</para>
+ <glossseealso otherterm="glossary-data_parallel">data parallel</glossseealso>
+ <glossseealso otherterm="glossary-element_wise">element wise</glossseealso>
+ <glossseealso otherterm="glossary-relation">relation</glossseealso>
</glossdef>
</glossentry>
Index: manual.xml
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/manual.xml,v
retrieving revision 1.1
diff -c -p -r1.1 manual.xml
*** manual.xml 2001/12/11 20:36:13 1.1
--- manual.xml 2001/12/13 04:02:07
***************
*** 154,159 ****
--- 154,161 ----
<!-- Field data-parallel Doof2d implementation -->
<!ENTITY doof2d-field-distributed SYSTEM "./programs/Doof2d-Field-distributed-annotated.cpp">
<!-- Field data-parallel distributed Doof2d implementation -->
+ <!ENTITY concepts-chapter SYSTEM "concepts.xml">
+ <!-- Pooma concepts chapter -->
<!ENTITY glossary-chapter SYSTEM "glossary.xml">
<!-- glossary -->
<!ENTITY tutorial-chapter SYSTEM "tutorial.xml">
***************
*** 345,1008 ****
</chapter>
- &tutorial-chapter;
-
-
- <chapter id="concepts">
- <title>Overview of &pooma; Concepts</title>
-
- <para>FIXME: How does multi-threaded computation fit into the
- model?</para>
-
- <para>In the previous chapter, we presented several different
- implementations of the &doof2d; simulation program. The
- implementations illustrate the various containers, computation
- syntaxes, and computation environments that &pooma; supports. In
- this chapter, we describe the concepts associated with each of
- these three categories. Specific details needed by programmers are
- deferred to later chapters.</para>
! <table frame="none" colsep="0" rowsep="0" tocentry="1"
! orient="port" pgwide="0" id="concepts-table">
! <title>&pooma; Implementation Concepts</title>
! <tgroup cols="3" align="center">
! <thead>
! <row>
! <entry>Container</entry>
! <entry>Computation Syntax</entry>
! <entry>Computation Environment</entry>
! </row>
! </thead>
! <tbody>
! <row>
! <entry>&array;</entry>
! <entry>element-wise</entry>
! <entry>sequential</entry>
! </row>
! <row>
! <entry>&dynamicarray;</entry>
! <entry>data-parallel</entry>
! <entry>distributed</entry>
! </row>
! <row>
! <entry>&field;</entry>
! <entry>stencil-based</entry>
! <entry></entry>
! </row>
! <row>
! <entry>&tensor;</entry>
! <entry>relational</entry>
! <entry></entry>
! </row>
! <row>
! <entry>&matrix;</entry>
! <entry></entry>
! <entry></entry>
! </row>
! <row>
! <entry>&vector;</entry>
! <entry></entry>
! <entry></entry>
! </row>
! </tbody>
! </tgroup>
! </table>
!
! <para>The most important &pooma; concepts can be grouped into three
! separate categories:
! <variablelist>
! <varlistentry>
! <term>container</term>
! <listitem>
! <para>data structure holding one or more values and addressed
! by indices</para>
! </listitem>
! </varlistentry>
! <varlistentry>
! <term>computation syntax</term>
! <listitem>
! <para>styles of expressing computations</para>
! </listitem>
! </varlistentry>
! <varlistentry>
! <term>computation environment</term>
! <listitem>
! <para>description of resources for computing, e.g., single
! processor or multi-processor</para>
! </listitem>
! </varlistentry>
! </variablelist>
! See <xref linkend="concepts-table"></xref>. Many &pooma; programs
! select one possibility from each column. For example, <xref
! linkend="tutorial-array_stencil-doof2d"></xref> used a &array;
! container and stencils for sequential computation, while <xref
! linkend="tutorial-field_distributed-doof2d"></xref> used a &field;
! container and data-parallel statements with distributed
! computation. A program may use multiple containers and various
! computation syntax, but the computation environment either has
! distributed processors or not.</para>
!
! <para>In the rest of this chapter, we explore these three
! categories. First, we describe &pooma; containers, illustrating
! the purposes of each, and explaining the concepts needed to declare
! them. Then, we describe the different computation syntaxes and
! finally distributed computation concepts.</para>
!
!
! <section id="concepts-containers">
! <title>&pooma; Containers</title>
!
! <para>Most &pooma; programs use <firstterm>containers</firstterm>
! to store groups of values. &pooma; containers are objects that
! store other objects. They control allocation and deallocation of
! and access to these objects. They are a generalization of &c;
! arrays, but &pooma; containers are first-class objects so they can
! be used directly in expressions. They are similar to &cc;
! containers such as <type>vector</type>, <type>list</type>, and
! <type>stack</type>. See <xref
! linkend="concepts-containers-table"></xref> for a summary of the
! containers.</para>
!
! <para>This chapter describes many concepts, not all of which are
! needed to begin programming with the &pooma; Toolkit. Below we
! introduce the different categories of concepts. After that, we
! introduce the different &pooma;'s containers and describe how to
! choose the appropriate one for a particular task. <xref
! linkend="concepts-sequential_containers-declarations-dependences"></xref>
! indicates which concepts must be understood when declaring a
! particular container. All of these concepts are described in
! <xref
! linkend="concepts-containers-sequential_declarations"></xref> and
! <xref
! linkend="concepts-containers-distributed_declarations"></xref>.
! Use this figure to decide which concepts in the former are
! relevant. Reading the latter section is necessary only if
! computing using multiple processors. The programs in the previous
! chapter illustrate many of these concepts.</para>
!
! <table frame="none" colsep="0" rowsep="0" tocentry="1"
! orient="port" pgwide="0" id="concepts-containers-table">
! <title>&pooma; Container Summary</title>
! <tgroup cols="2" align="left">
! <tbody>
! <row>
! <entry><glossterm
! linkend="glossary-array">&array;</glossterm></entry>
! <entry>container mapping indices to values and that may be
! used in expressions</entry>
! </row>
! <row>
! <entry><glossterm
! linkend="glossary-dynamicarray">&dynamicarray;</glossterm></entry>
! <entry>one-dimensional &array; whose <glossterm
! linkend="glossary-domain">domain</glossterm> can be dynamically
! resized</entry>
! </row>
! <row>
! <entry><glossterm linkend="glossary-field">&field;</glossterm></entry>
! <entry>container mapping indices to one or more values and
! residing in multi-dimensional space</entry>
! </row>
! <row>
! <entry><glossterm
! linkend="glossary-tensor">&tensor;</glossterm></entry>
! <entry>multi-dimensional mathematical tensor</entry>
! </row>
! <row>
! <entry><glossterm
! linkend="glossary-matrix">&matrix;</glossterm></entry>
! <entry>two-dimensional mathematical matrix</entry>
! </row>
! <row>
! <entry><glossterm
! linkend="glossary-vector">&vector;</glossterm></entry>
! <entry>multi-dimensional mathematical vector</entry>
! </row>
! </tbody>
! </tgroup>
! </table>
!
! <!-- FIXME: Want firstterm around array. -->
!
! <para>A &pooma; <glossterm
! linkend="glossary-array">array;</glossterm>, generalizing a &c;
! array, maps indices to values. Given a index or position in an
! &array;'s domain, it returns the associated value, either by
! returning a stored value or by computing it. The use of indices,
! which are usually ordered tuples, permits constant-time access
! although computing a particular value may require significant
! time. In addition to the functionality provided by &c; arrays,
! the &array; class automatically handles memory allocation and
! deallocation, supports a wider variety of assignments, and can be
! used in expressions. For example, the addition of two arrays can
! be assigned to an array and the product of a scalar element and an
! array is permissible.</para>
!
! <!-- FIXME: Want firstterm around dynamicarray. -->
!
! <para>A &pooma; <glossterm
! linkend="glossary-dynamicarray">&dynamicarray;</glossterm> extends
! &array; capabilities to support a dynamically-changing domain but
! is restricted to only one dimension. When the &dynamicarray; is
! resized, its values are preserved.</para>
!
! <!-- FIXME: Want firstterm around field. -->
!
! <para>A &pooma; <glossterm>&field;</glossterm> is an &array; with
! spatial extent. Each domain consists of <glossterm
! linkend="glossary-cell"><firstterm>cell</firstterm></glossterm>s
! in one-, two-, or three-dimensional space. Although indexed
! similarly to &array;s, each cell may contain multiple values and
! multiple materials. A &field;'s <glossterm
! linkend="glossary-mesh">mesh</glossterm> stores its spatial
! characteristics and can map yield, e.g., a point contained in a
! cell, the distance between two cells, and a cell's normals. A
! &field; should be used whenever geometric or spatial computations
! are needed, multiple values per index are desired, or a
! computation involves more than one material.</para>
!
! <!-- FIXME: Want firstterm around tensor. -->
!
! <para>A <glossterm linkend="glossary-tensor">&tensor;</glossterm>
! implements a multi-dimensional mathematical tensor. Since it is a
! first-class type, it can be used in expressions such as
! adding two &tensor;s.</para>
!
! <!-- FIXME: Want firstterm around matrix. -->
!
! <para>A <glossterm linkend="glossary-matrix">&matrix;</glossterm>
! implements a two-dimensional mathematical matrix. Since it is a
! first-class type, it can be used in expressions such as
! multiplying matrices and assignments to matrices.</para>
!
! <!-- FIXME: Want firstterm around vector. -->
!
! <para>A <glossterm linkend="glossary-vector">&vector;</glossterm>
! implements a multi-dimensional mathematical vector, which is an
! ordered tuple of components. Since it is a first-class type, it
! can be used in expressions such as adding two &vector;s and
! multiplying a &matrix; and a &vector;.</para>
!
! <para>The data of an &array;, &dynamicarray;, or &field; can be
! viewed using more than one container by taking a view. A
! <glossterm
! linkend="glossary-view"><firstterm>view</firstterm></glossterm> of
! an existing container &container; is a container whose domain
! is a subset of &container;. The subset can equal the
! original domain. A view acts like a reference in that changing
! any of the view's values also changes the original container's and
! vice versa. While users sometimes explicitly create views, they
! are perhaps more frequently created as temporaries in expressions.
! For example, if <varname>A</varname> is an &array; and
! <varname>I</varname> is a domain, <statement>A(I) -
! A(I-1)</statement> forms the difference between adjacent
! values.</para>
!
!
! <section id="concepts-containers-choosing">
! <title>Choosing a Container</title>
!
! <para>The two most commonly used &pooma; containers are &array;s
! and &field;s. <xref
! linkend="concepts-containers-choice_table"></xref> contains a
! decision tree describing how to choose an appropriate
! container.</para>
!
! <table frame="none" colsep="0" rowsep="0" tocentry="1"
! orient="port" pgwide="0" id="concepts-containers-choice_table">
! <title>Choosing a &pooma; Container</title>
! <tgroup cols="2" align="left">
! <tbody>
! <row>
! <entry>If modeling mathematical entries,</entry>
! <entry>use a &vector;, &matrix;, or &tensor;.</entry>
! </row>
! <row>
! <entry>If indices and values reside in multi-dimensional space
! &space;,</entry>
! <entry>use a &field;.</entry>
! </row>
! <row>
! <entry>If there are multiple values per index,</entry>
! <entry>use a &field;.</entry>
! </row>
! <row>
! <entry>If there are multiple materials participating in the same computation,</entry>
! <entry>use a &field;.</entry>
! </row>
! <row>
! <entry>If the domain's size dynamically changes and is one-dimensional,</entry>
! <entry>use a &dynamicarray;.</entry>
! </row>
! <row>
! <entry>Otherwise</entry>
! <entry>use an &array;.</entry>
! </row>
! </tbody>
! </tgroup>
! </table>
!
! </section><!-- choosing among containers -->
- <section id="concepts-containers-sequential_declarations">
- <title>Declaring Sequential Containers</title>
! <figure float="1" id="concepts-sequential_containers-declarations-dependences">
! <title>Concepts For Declaring Containers</title>
! <mediaobject>
! <imageobject>
! <imagedata fileref="figures/concepts.111" format="EPS" align="center"></imagedata>
! </imageobject>
! <textobject>
! <phrase>concepts involved in declaring containers</phrase>
! </textobject>
! </mediaobject>
! </figure>
!
! <para>In the previous sections, we introduced the &pooma;
! containers and described how to choose one appropriate for a
! given task. In this section, we describe the concepts involved
! in declaring them. Concepts specific to distributed computation
! are described in the next section.</para>
!
! <para><xref
! linkend="concepts-sequential_containers-declarations-dependences"></xref>
! illustrates the containers and the concepts involved in their
! declarations. The containers are listed in the top row. Lines
! connect these containers to the components necessary for their
! declarations. For example, an &array; declaration requires an
! engine and a layout. These, in turn, depend on other &pooma;
! concepts. Declarations necessary only for distributed, or
! multiprocessor, computation are surrounded by dashed lines. You
! can use these dependences to indicate the concepts needed for a
! particular container.</para>
!
! <para>An <glossterm
! linkend="glossary-engine"><firstterm>engine</firstterm></glossterm>
! stores and, if necessary, computes a container's values. A
! container has one or more engines. The separation of a container
! and its storage permits optimizing a program's space
! requirements. For example, a container returning the same value
! for all indices can use a constant engine, which need only store
! one value for the entire domain. A &compressiblebrick; engine
! reduces its space requirements to a constant whenever all its
! values are the same. The separation also permits taking <link
! linkend="glossary-view">view</link>s of containers without
! copying storage.</para>
!
! <figure float="1" id="concepts-containers-declarations-computational_implementation">
! <title>&array; and &field; Mathematical and Computational Concepts</title>
! <mediaobject>
! <imageobject>
! <imagedata fileref="figures/concepts.101" format="EPS" align="center"></imagedata>
! </imageobject>
! <textobject>
! <phrase>maps from indices to values</phrase>
! </textobject>
! </mediaobject>
! </figure>
!
! <para>A <glossterm
! linkend="glossary-layout"><firstterm>layout</firstterm></glossterm>
! maps <link linkend="glossary-domain">domain</link> indices to the
! processors and computer memory used by a container's engines.
! See <xref
! linkend="concepts-containers-declarations-computational_implementation"></xref>.
! A computer computes a container's values using a processor and
! memory. The layout specifies the processor(s) and memory to use
! for each particular index. A container's layout for a
! uniprocessor implementation consists of its domain, the
! processor, and its memory. For a multi-processor implementation,
! the layout maps portions of the domain to (possibly different)
! processors and memory.</para>
!
! <para>A &field;'s <glossterm
! linkend="glossary-mesh"><firstterm>mesh</firstterm></glossterm>
! maps <link linkend="glossary-domain">domain</link> indices to
! geometric values in &space; such as distance between cells, edge
! lengths, and normals to cells. In other words, it provides a
! &field;'s spatial extent. See also <xref
! linkend="concepts-containers-declarations-computational_implementation"></xref>.
! Different mesh types may support different geometric
! values.</para>
!
! <para>A mesh's <glossterm
! linkend="glossary-corner_position"><firstterm>corner
! position</firstterm></glossterm> specifies the <link
! linkend="glossary-point">point</link> in &space; corresponding to
! the lower, left corner of its <link
! linkend="glossary-domain">domain</link>. Combining this, the
! domain, and the cell size fully specifies the mesh's map from
! indices to &space;.</para>
!
! <para>A mesh's <glossterm
! linkend="glossary-cell_size"><firstterm>cell
! size</firstterm></glossterm> specifies the spatial dimensions of
! a &field; <link linkend="glossary-cell">cell</link>, e.g., its
! width, height, and depth, in &space;. Combining this, the
! domain, and the corner position fully specifies the mesh's map
! from indices to &space;.</para>
!
! <para>A <glossterm
! linkend="glossary-domain"><firstterm>domain</firstterm></glossterm>
! is a set of points on which a container can define values. An
! <glossterm
! linkend="glossary-interval"><firstterm>interval</firstterm></glossterm>
! consists of all integral points between two values. It is
! frequently represented using mathematical interval notation [a,b]
! even though it contains only the integral points, e.g., a, a+1,
! a+2, …, b. The concept is generalized to multiple
! dimensions by forming tensor product of intervals, i.e., all the
! integral tuples in an &n;-dimensional space. For example, the
! two-dimensional containers in the previous chapter are defined on
! a two-dimensional domain with the both dimensions' spanning the
! interval [0,n). A <glossterm
! linkend="glossary-stride"><firstterm>stride</firstterm></glossterm>
! is a subset of an interval consisting of regularly-spaced
! points. A <glossterm
! linkend="glossary-range"><firstterm>range</firstterm></glossterm>
! is a subset of an interval formed by the tensor product of strides.
! A <glossterm
! linkend="glossary-region"><firstterm>region</firstterm></glossterm>
! represents a continuous &n;-dimensional domain.</para>
! </section>
!
!
! <section id="concepts-containers-distributed_declarations">
! <title>Declaring Distributed Containers</title>
!
! <para>In the previous section, we introduced the concepts
! important when declaring containers for use on uniprocessor
! computers. When using multi-processor computers, we augment
! these concepts with those for distributed computation. Reading
! this section is important only for running the same program on
! multiple processors. Many of these concepts were introduced in
! <xref linkend="tutorial-array_distributed"></xref> and <xref
! linkend="tutorial-field_distributed"></xref>. <xref
! linkend="tutorial-array_distributed-doof2d-distributed_model"></xref>
! illustrates the &pooma; distributed computation model. In this
! section, we concentrate on the concepts necessary to declare a
! distributed container.</para>
!
! <para>As we noted in <xref
! linkend="tutorial-array_distributed"></xref>, a &pooma;
! programmer must specify how each container's domain should be
! distributed among the available processors and memory spaces.
! Using this information, the Toolkit automatically distributes the
! data among the available processors and handles any required
! communication among them. The three concepts necessary for
! declaring distributed containers are a partition, a guard layer,
! and a context mapper tag.</para>
!
! <para>A <glossterm
! linkend="glossary-partition"><firstterm>partition</firstterm></glossterm>
! specified how to divide a container's domain into distributed
! pieces. For example, the partition illustrated in <xref
! linkend="tutorial-array_distributed-doof2d-distributed_model"></xref>
! would divide a two-dimensional domain into three equally-sized
! pieces along the x-dimension and two equally-sized pieces along
! the y-dimension. Partitions can be independent of the size of
! container's domain. The example partition will work on any
! domain as long as the size of its x-dimension is a multiple of
! three. A domain is separated into disjoint <link
! linkend="glossary-patch">patch</link>es.</para>
!
! <para>A <glossterm
! linkend="glossary-guard_layer"><firstterm>guard
! layer</firstterm></glossterm> is <quote>extra</quote> domain
! surrounding each patch. This region has read-only values. An
! <glossterm
! linkend="glossary-external_guard_layer"><firstterm>external guard
! layer</firstterm></glossterm> specifies values surrounding the
! domain. Its presence eases computation along the domain's edges
! by permitting the same computations as for more internal
! computations. An <glossterm
! linkend="glossary-internal_guard_layer"><firstterm>internal guard
! layer</firstterm></glossterm> duplicates values from adjacent
! patches so communication with adjacent patches need not occur
! during a patch's computation. The use of guard layers is an
! optimization; using external guard layers eases programming and
! using internal guard layers reduces communication among
! processors. Their use is not required.</para>
!
! <para>A <glossterm
! linkend="glossary-context_mapper"><firstterm>context
! mapper</firstterm></glossterm> indicates how a container's
! patches are mapped to processors and shared memory. For example,
! the &distributedtag; indicates that the patches should be
! distributed among the processors so each patch occurs once in the
! entire computation. The &replicatedtag; indicates that the
! patches should be replicated among the processors so each
! processing unit has its own copy of all the patches. While it
! could be wasteful to have different processors perform the same
! computation, replicating a container can reduce possibly more
! expensive communication costs.</para>
! </section>
!
!
! <section>
! <title>????Computation Syntax????</title>
!
! <para>UNFINISHED</para>
! </section>
!
!
! <section id="concepts-computation_environment">
! <title>Computation Environment</title>
!
! <para>A &pooma; program can execute on a wide variety of
! computers. The default <glossterm
! linkend="glossary-sequential"><firstterm>sequential computing
! environment</firstterm></glossterm> consists of one processor and
! associated memory, as found on a personal computer. In contrast,
! a <glossterm
! linkend="glossary-distributed"><firstterm>distributed computing
! environment</firstterm></glossterm> may have multiple processors
! and multiple distributed or shared memories. For example, some
! desktop computers have dual processors and shared memory. A
! large supercomputer may have thousands of processors, perhaps
! with groups of eight sharing the same memory.</para>
!
! <para>Using distributed computation requires three things: the
! programmer must declare how container domains will be
! distributed, &pooma; must be configured to use a communications
! library, and the &pooma; executable must be run using the
! library. All of these were illustrated in <xref
! linkend="tutorial-array_distributed"></xref> and <xref
! linkend="tutorial-field_distributed"></xref>. <xref
! linkend="tutorial-array_distributed-doof2d-distributed_model"></xref>
! illustrates the &pooma; distributed computation model. <xref
! linkend="concepts-containers-distributed_declarations"></xref>
! described how to declare containers with distributed domains.
! Detailed instructions how to configure &pooma; for distributed
! computation appear in <xref linkend="installation"></xref>. More
! detailed instructions how to run distributed &pooma; executables
! appear in <xref linkend="parallel"></xref>. Here we present
! three concepts for distributed computation: context, layout, and
! a communication library.
!
! A <glossterm
! linkend="glossary-context"><firstterm>context</firstterm></glossterm>
! is a collection of shared memory and processors that can execute
! a program of a portion of a program. It can have one or more
! processors, but all these processors must access the same shared
! memory. Usually the computer and its operating system, not the
! programmer, determine the available contexts.</para>
! <para>
! HERE</para>
<!-- HERE -->
- </section>
-
- </section>
-
- <section>
- <title>Extraneous Material</title>
-
- <para>Describe the software application layers similar to
- <filename>papers/SCPaper-95.html</filename> and "Short Tour of
- &pooma;" in <filename>papers/SiamOO98_paper.ps</filename>.
- Section 2.2, "Why a Framework?," of
- <filename>papers/pooma.ps</filename> argues why a layered approach
- eases use. Section 3.1, "Framework Layer Description,"
- describes the five layers.</para>
! <para>FINISH: Write short glossary entries for each of these.</para>
!
! <para>FINISH: Look through the source code to ensure all main
! concepts are listed.</para>
!
! <para>Here are (preliminary) &pooma; equations:</para>
! <table frame="none" colsep="0" rowsep="0" tocentry="1"
! orient="port" pgwide="0">
! <title>&pooma; <quote>Equations</quote></title>
! <tgroup cols="1" align="center">
! <tbody>
! <row>
! <entry><para>field = data + materials + centering + layout + mesh</para></entry>
! </row>
! <row>
! <entry><para>map from space to values</para></entry>
! </row>
! <row>
! <entry><para>array = data + layout</para></entry>
! </row>
! <row>
! <entry><para>map from indices to values</para></entry>
! </row>
! <row>
! <entry><para>mesh = layout + origin + spacings</para></entry>
! </row>
! <row>
! <entry><para>distribute domain through physical space</para></entry>
! </row>
! <row>
! <entry><para>layout = domain + partition + context_mapper_tag (distributed/replicated)</para></entry>
! </row>
! <row>
! <entry><para>distribute domain's blocks among processors/contexts</para></entry>
! </row>
! <row>
! <entry><para>partition = blocks + guard layers</para></entry>
! </row>
! <row>
! <entry><para>split domain into blocks</para></entry>
! </row>
! <row>
! <entry><para>domain = newDomain</para></entry>
! </row>
! <row>
! <entry><para>space of permissible indices</para></entry>
! </row>
! </tbody>
! </tgroup>
! </table>
- <para>FINISH: Following is a first try at describing the &pooma;
- abstraction layers. See also paper illustration.</para>
! <table frame="none" colsep="0" rowsep="0" tocentry="1"
! orient="port" pgwide="0">
! <title>&pooma; Abstraction Layers</title>
! <tgroup cols="1" align="center">
! <tbody>
! <row>
! <entry><para>application program</para></entry>
! </row>
! <row>
! <entry><para>&array; &field; (should have
! <type>FieldEngine</type> under it)</para></entry>
! </row>
! <row>
! <entry><para>&engine;</para></entry>
! </row>
! <row>
! <entry><para>evaluators</para></entry>
! </row>
! </tbody>
! </tgroup>
! </table>
- <para>FINISH: How does parallel execution fit in?</para>
! <para>FINISH: Should we also name and describe each layer?</para>
! </section>
! <section id="concepts-data_parallel">
! <title>Data-Parallel Statements</title>
! <para>Can we use "An Overview of &pete;" from
<filename>papers/PETE_DDJ/ddj_article.html</filename> or is this
too low-level?</para>
! <para>Section 3.2.1 of <filename>papers/pooma.ps</filename>
gives a simple example of data-parallel expression. It also has a
paragraph introducing data-parallel operations and selecting
subsets of domains. Section 3.4 describes the Chained
--- 347,424 ----
</chapter>
! &tutorial-chapter;
+ &concepts-chapter;
! <chapter id="sequential">
! <title>Writing Sequential Programs</title>
! <para>QUESTIONS: How do I arrange this section? What material do I
! include? What other books or models can I follow?</para>
<!-- HERE -->
! <para>&pooma; can reorder computations to permit more efficient
! computation. When running a sequential program, reordering may
! permit omission of unneeded computations. For example, if only
! values from a particular field are printed, only computations
! involving the field and containers dependent on it need to occur.
! When running a distributed program, reordering may permit
! computation and communication among processors to overlap. &pooma;
! automatically tracks dependences between data-parallel expressions,
! ensuring correct ordering. It does not track statements accessing
! particular &array; and &field; values so the programmer must
! precede these statements with calls to
! <function>Pooma::blockAndEvaluate()</function>. Each call forces
! the executable to wait until all computation has completed. Thus,
! the desired values are known to be available. In practice, some
! calls to <function>Pooma::blockAndEvaluate</function> may not be
! necessary, but omitting them requires knowledge of &pooma;'s
! dependence computations, so the &author; recommends calling
! <function>Pooma::blockAndEvaluate</function> before each access to
! a particular value in an &array; or &field;. Omitting a necessary
! call may lead to a race condition. See <xref
! linkend="debugging_profiling-missing_blockandevaluate"></xref> for
! instructions how to diagnose and eliminate these race conditions.</para>
! <para>UNFINISHED</para>
! <section id="sequential-benchmarks">
! <title>&benchmark; Programs</title>
+ <para>Define a &benchmark; program vs. an example or an
+ executable. Provide a short overview of how to run these
+ programs. Provide an overview of how to write these programs.
+ See <filename
+ class="headerfile">src/Utilities/Benchmark.h</filename>.</para>
+ </section>
! <section id="sequential-inform">
! <title>Using <type>Inform</type>s for Output</title>
! <para>UNFINISHED</para>
! </section>
! <section>
! <title>Miscellaneous</title>
+ <para>Section 3, "Domains and Views," of
+ <filename>papers/iscope98.pdf</filename> describes five types of
+ domains.</para>
! <section id="concepts-data_parallel">
! <title>Data-Parallel Statements</title>
! <para>Can we use "An Overview of &pete;" from
<filename>papers/PETE_DDJ/ddj_article.html</filename> or is this
too low-level?</para>
! <para>Section 3.2.1 of <filename>papers/pooma.ps</filename>
gives a simple example of data-parallel expression. It also has a
paragraph introducing data-parallel operations and selecting
subsets of domains. Section 3.4 describes the Chained
*************** HERE</para>
*** 1013,1019 ****
<para>From Section 4 of
<filename>papers/SiamOO98_paper.ps</filename>:</para>
! <para>This version of &pete; reduces compile time of user codes
and utilizes compile-time knowledge of expression &domain;s for
better optimization. For example, more efficient loops for
evaluating an expression can be generated if &pete; knows that the
--- 429,435 ----
<para>From Section 4 of
<filename>papers/SiamOO98_paper.ps</filename>:</para>
! <para>This version of &pete; reduces compile time of user codes
and utilizes compile-time knowledge of expression &domain;s for
better optimization. For example, more efficient loops for
evaluating an expression can be generated if &pete; knows that the
*************** HERE</para>
*** 1028,1044 ****
&pete; material.</para>
</section>
<section>
! <title>Containers</title>
! <section id="concepts-containers-array">
<title>&array;</title>
<blockquote>
! <attribution>Section 4 "Future Improvements in
&pooma; II" of
<filename>papers/SiamOO98_paper.ps</filename></attribution>
! <para>
An &array; can be thought of as a map from one &domain; to
another.… &array;s depend only on the interface of
&domain;s. Thus, a subset of view of an &array; can be
--- 444,461 ----
&pete; material.</para>
</section>
+
<section>
! <title>Containers</title>
! <section id="concepts-containers-array">
<title>&array;</title>
<blockquote>
! <attribution>Section 4 "Future Improvements in
&pooma; II" of
<filename>papers/SiamOO98_paper.ps</filename></attribution>
! <para>
An &array; can be thought of as a map from one &domain; to
another.… &array;s depend only on the interface of
&domain;s. Thus, a subset of view of an &array; can be
*************** HERE</para>
*** 1058,1064 ****
code. An Array maps a fairly arbitrary input domain to an
arbitrary range of outputs. When used by itself, an &array;
object <varname>A</varname> refers to all of the values in its
! domain. Element-wise mathematical operations or functions can be
applied to an array using straightforward notation, like A + B
or sin(A). Expressions involving Array objects are themselves
Arrays. The operation A(d), where d is a domain object that
--- 475,481 ----
code. An Array maps a fairly arbitrary input domain to an
arbitrary range of outputs. When used by itself, an &array;
object <varname>A</varname> refers to all of the values in its
! domain. Element-wise mathematical operations or functions can be
applied to an array using straightforward notation, like A + B
or sin(A). Expressions involving Array objects are themselves
Arrays. The operation A(d), where d is a domain object that
*************** HERE</para>
*** 1084,1090 ****
indexed.</para>
<para>Fortran arrays are dense and the elements are arranged
! according to column-major conventions. Therefore, X(i1,i2)
refers to element number i1-1+(i2-1)*numberRowsInA. However, as
Fig. 1 shows, Fortran-style "Brick" storage is not the only
storage format of interest to scientific programmers. For
--- 501,507 ----
indexed.</para>
<para>Fortran arrays are dense and the elements are arranged
! according to column-major conventions. Therefore, X(i1,i2)
refers to element number i1-1+(i2-1)*numberRowsInA. However, as
Fig. 1 shows, Fortran-style "Brick" storage is not the only
storage format of interest to scientific programmers. For
*************** HERE</para>
*** 1103,1116 ****
<para>The &pooma; &array; Class Template</para>
! <para>Next we describe &pooma;'s model of the Array concept, the
Array class template. The three most important requirements from
the point of view of overall design are: (1) arbitrary domain,
(2) arbitrary range, and (3) polymorphic indexing. These express
themselves in the template parameters for the &pooma; Array
class. The template
<programlisting>
! template <int Dim, class T = double, class EngineTag = Brick>
class Array;
</programlisting>
is a specification for creating a set of classes all named
--- 520,533 ----
<para>The &pooma; &array; Class Template</para>
! <para>Next we describe &pooma;'s model of the Array concept, the
Array class template. The three most important requirements from
the point of view of overall design are: (1) arbitrary domain,
(2) arbitrary range, and (3) polymorphic indexing. These express
themselves in the template parameters for the &pooma; Array
class. The template
<programlisting>
! template <int Dim, class T = double, class EngineTag = Brick>
class Array;
</programlisting>
is a specification for creating a set of classes all named
*************** HERE</para>
*** 1150,1186 ****
<section id="concepts-containers-field">
<title>&field;</title>
! <para>QUESTION: Do we include boundary conditions here?
FINISH: Do we have an example that shows something not possible
with &array;?</para>
! <para>Describe and illustrate multi-material and
multivalue?</para>
-
- <para>ADD: description of meshes and guard layers.</para>
! </section>
!
! </section>
! <section id="concepts-engines">
! <title>Engines</title>
! <para>(unformatted) From
<filename>papers/GenericProgramming_CSE/dubois.html</filename>:</para>
! <para>The Engine Concept</para>
! <para>To implement polymorphic indexing, the Array class defers
data storage and data lookup to an engine object. The requirements
that the Array template places on its engine provide the
definition for the Engine concept. We'll describe these by
examining a simplified version of the Array template, shown in
Fig. 2.</para>
! <para>First, the Array class determines and exports (makes
Engine_t part of Array's public interface) the type of the engine
class that it will use:
<programlisting>
--- 567,601 ----
<section id="concepts-containers-field">
<title>&field;</title>
! <para>QUESTION: Do we include boundary conditions here?
FINISH: Do we have an example that shows something not possible
with &array;?</para>
! <para>Describe and illustrate multi-material and
multivalue?</para>
! <para>ADD: description of meshes and guard layers.</para>
! </section>
! </section>
! <section id="concepts-engines">
! <title>Engines</title>
! <para>(unformatted) From
<filename>papers/GenericProgramming_CSE/dubois.html</filename>:</para>
! <para>The Engine Concept</para>
! <para>To implement polymorphic indexing, the Array class defers
data storage and data lookup to an engine object. The requirements
that the Array template places on its engine provide the
definition for the Engine concept. We'll describe these by
examining a simplified version of the Array template, shown in
Fig. 2.</para>
! <para>First, the Array class determines and exports (makes
Engine_t part of Array's public interface) the type of the engine
class that it will use:
<programlisting>
*************** HERE</para>
*** 1215,1221 ****
concept: it must provide a version of operator() that takes Dim
values of type Index_t.</para>
! <para>Simply passing the indices on to the engine object may seem
odd. After all, engine(i,j) looks like we're just indexing another
array. There are several advantages to this extra level of
indirection. The Array class is as faithful a model of the Array
--- 630,636 ----
concept: it must provide a version of operator() that takes Dim
values of type Index_t.</para>
! <para>Simply passing the indices on to the engine object may seem
odd. After all, engine(i,j) looks like we're just indexing another
array. There are several advantages to this extra level of
indirection. The Array class is as faithful a model of the Array
*************** HERE</para>
*** 1386,1497 ****
</variablelist>
</section>
-
- <section id="concepts-relations">
- <title>Relations</title>
-
- <para>UNFINISHED</para>
- </section>
-
-
- <section id="concepts-stencils">
- <title>Stencils</title>
-
- <para>Section 3.5.4, "Stencil Objects," of
- <filename>papers/pooma.ps</filename> provides a few uses of
- stencils.</para>
-
- <para>Section 5, "Performance," of
- <filename>papers/iscope98.pdf</filename> motivates and explains
- stencils.</para>
- </section>
-
-
- <section id="concepts-contexts">
- <title>Contexts</title>
-
- <blockquote>
- <attribution><filename
- class="libraryfile">background.html</filename></attribution>
- <para>In order to be able to cope with the variations in machine
- architecture noted above, &pooma;'s distributed execution model
- is defined in terms of one or more contexts, each of which may
- host one or more threads. A context is a distinct region of
- memory in some computer. The threads associated with the context
- can access data in that memory region and can run on the
- processors associated with that context. Threads running in
- different contexts cannot access memory in other contexts.</para>
-
- <para>A single context may include several physical processors,
- or just one. Conversely, different contexts do not have to be on
- separate computers—for example, a 32-node SMP computer could
- have up to 32 separate contexts. This release of &pooma; only
- supports a single context for each application, but can use
- multiple threads in the context on supported platforms. Support
- for multiple contexts will be added in an upcoming
- release.</para>
- </blockquote>
- </section>
-
- </chapter>
-
-
- <chapter id="sequential">
- <title>Writing Sequential Programs</title>
-
- <para>&pooma; can reorder computations to permit more efficient
- computation. When running a sequential program, reordering may
- permit omission of unneeded computations. For example, if only
- values from a particular field are printed, only computations
- involving the field and containers dependent on it need to occur.
- When running a distributed program, reordering may permit
- computation and communication among processors to overlap. &pooma;
- automatically tracks dependences between data-parallel expressions,
- ensuring correct ordering. It does not track statements accessing
- particular &array; and &field; values so the programmer must
- precede these statements with calls to
- <function>Pooma::blockAndEvaluate()</function>. Each call forces
- the executable to wait until all computation has completed. Thus,
- the desired values are known to be available. In practice, some
- calls to <function>Pooma::blockAndEvaluate</function> may not be
- necessary, but omitting them requires knowledge of &pooma;'s
- dependence computations, so the &author; recommends calling
- <function>Pooma::blockAndEvaluate</function> before each access to
- a particular value in an &array; or &field;. Omitting a necessary
- call may lead to a race condition. See <xref
- linkend="debugging_profiling-missing_blockandevaluate"></xref> for
- instructions how to diagnose and eliminate these race conditions.</para>
-
- <para>Section 3, "Domains and Views," of
- <filename>papers/iscope98.pdf</filename> describes five types of
- domains.</para>
-
- <para>UNFINISHED</para>
-
- <section id="sequential-benchmarks">
- <title>&benchmark; Programs</title>
-
- <para>Define a &benchmark; program vs. an example or an
- executable. Provide a short overview of how to run these
- programs. Provide an overview of how to write these programs.
- See <filename
- class="headerfile">src/Utilities/Benchmark.h</filename>.</para>
- </section>
-
-
- <section id="sequential-inform">
- <title>Using <type>Inform</type>s for Output</title>
-
- <para>UNFINISHED</para>
- </section>
-
-
- <section>
- <title>Miscellaneous</title>
-
- <para>Section 3, "Domains and Views," of
- <filename>papers/iscope98.pdf</filename> describes five types of
- domains.</para>
</section>
</chapter>
--- 801,806 ----
*************** HERE</para>
*** 3579,3588 ****
<para>To use multiple processors with &pooma; requires installing
the &cheetah; messaging library and an underlying messaging library
such as the Message Passing Interface (&mpi;) Communications
! Library or the &mm; Shared Memory Library. In this section, we
! first describe how to install &mm;. Read the section only if using
! &mm;, not &mpi;. Then we describe how to install &cheetah; and
! configure &pooma; to use it.</para>
<section id="installation-distributed_computing-mm">
<title>Obtaining and Installing the &mm; Shared Memory Library</title>
--- 2888,2897 ----
<para>To use multiple processors with &pooma; requires installing
the &cheetah; messaging library and an underlying messaging library
such as the Message Passing Interface (&mpi;) Communications
! Library or the &mm; Shared Memory Library. In the following
! section, we first describe how to install &mm;. Read it only if
! using &mm;, not &mpi;. Then we describe how to install &cheetah;
! and configure &pooma; to use it.</para>
<section id="installation-distributed_computing-mm">
<title>Obtaining and Installing the &mm; Shared Memory Library</title>
*************** HERE</para>
*** 3834,3839 ****
--- 3143,3154 ----
<title>Miscellaneous</title>
<orderedlist>
+ <listitem>
+ <para>Section 5, "Performance," of
+ <filename>papers/iscope98.pdf</filename> motivates and explains
+ stencils.</para>
+ </listitem>
+
<listitem>
<para>If there is time, present another example program, e.g., a
Jacobi solver.</para>
Index: figures/concepts.mp
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/figures/concepts.mp,v
retrieving revision 1.1
diff -c -p -r1.1 concepts.mp
*** figures/concepts.mp 2001/12/11 20:36:13 1.1
--- figures/concepts.mp 2001/12/13 04:02:07
*************** beginfig(101)
*** 144,150 ****
boxit.l6(btex \strut \type{Field}: etex);
boxit.l7(btex \strut $\mbox{index} \mapsto \mbox{value}$ etex);
boxit.l9(btex \strut \type{Field}: etex);
! boxit.l10(btex \strut $\mbox{indices} \mapsto \mbox{geometric value}$ etex);
fixsize(l1,l2,l3,l4,l6,l7,l9,l10);
ypart(l1.c - l2.c) = 0;
--- 144,150 ----
boxit.l6(btex \strut \type{Field}: etex);
boxit.l7(btex \strut $\mbox{index} \mapsto \mbox{value}$ etex);
boxit.l9(btex \strut \type{Field}: etex);
! boxit.l10(btex \strut $\mbox{indices} \mapsto \mbox{spatial value}$ etex);
fixsize(l1,l2,l3,l4,l6,l7,l9,l10);
ypart(l1.c - l2.c) = 0;
*************** beginfig(101)
*** 163,169 ****
% Create and layout the mesh boxes.
boxit.ia[2](btex indices etex);
boxit.ea[2](btex mesh etex);
! boxit.va[2](btex geometric value etex);
fixsize(ia[2],ea[2],va[2]);
ia[1].w - ia[2].w = 0.6(ia[0].w - ia[1].w);
ypart(va[2].w - ea[2].e) = ypart(ea[2].w - ia[2].e) = 0;
--- 163,169 ----
% Create and layout the mesh boxes.
boxit.ia[2](btex indices etex);
boxit.ea[2](btex mesh etex);
! boxit.va[2](btex spatial value etex);
fixsize(ia[2],ea[2],va[2]);
ia[1].w - ia[2].w = 0.6(ia[0].w - ia[1].w);
ypart(va[2].w - ea[2].e) = ypart(ea[2].w - ia[2].e) = 0;
More information about the pooma-dev
mailing list