Patch: Tutorial Typographical Errors
Jeffrey Oldham
oldham at codesourcery.com
Mon Mar 26 23:51:44 UTC 2001
Mon Mar 26 15:50:55 2001 Jeffrey D. Oldham <oldham at codesourcery.com>
* background.html (struct AddOp): Match parameter name with
parameter use.
(struct MulOp): Likewise.
* tut-02.html: Add several missing spaces.
(RBJacobi): Change array's name to match previous line.
(Periodic Boundary Conditions): Fix line numbers for ApplyPeriodic.
* tut-04.html: Move sentence regarding component forwarding from
next paragraph to preceding paragraph concerning component
forwarding.
Remove an extra space and an extraneous comma. Add a missing
parenthesis. Fix array's name to match the other text.
Emphasize "ghost," which is implicitly defined.
Reword last sentence to de\"{e}mphasize Pooma developers' programming
expertise.
(accumulateWithLoop): Substitute "first0" and "last0" for "f0" and
"l0". "l0" looks like the number 10.
Remove some extraneous words.
* tut-06.html: "Recurring," not "recursing."
* tut-07.html: Remove extraneous word. Fix a comma. Fix
capitalization. Remove one of double word.
Add space between closing ">" in nested template.
Change expression font to typewriter.
s/>/</ in line 016 of n-D scalar advection.
* tut-08.html: (average): Change second "Expression1_t" to
"Expression2_t".
(Exported typedefs): Remove second, extraneous
"SurfaceNormalsArray_t".
Fix typo. Remove second of two contiguous periods. Remove second
of repeated world.
Suggested substitution s/right/correct/ to avoid confusion with
"left".
(FieldStencil example): Add ending ";". s/fv/vv/ to match
previous variable declaration.
Fix misspelled words. Add period at the end of a sentence.
Tested on Netscape 4.75 on Linux
Reviewed by Allan Stokes (Thanks!)
Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: background.html
===================================================================
RCS file: /home/pooma/Repository/r2/docs/background.html,v
retrieving revision 1.1
diff -c -p -r1.1 background.html
*** background.html 2001/03/19 16:11:13 1.1
--- background.html 2001/03/21 19:59:59
*************** arithmetic operations:
*** 761,767 ****
<blockquote><pre>
struct AddOp
{
! static inline double apply(const double & left, const double & y)
{
return x + y;
}
--- 761,767 ----
<blockquote><pre>
struct AddOp
{
! static inline double apply(const double & x, const double & y)
{
return x + y;
}
*************** struct AddOp
*** 769,775 ****
struct MulOp
{
! static inline double apply(const double & left, const double & y)
{
return x * y;
}
--- 769,775 ----
struct MulOp
{
! static inline double apply(const double & x, const double & y)
{
return x * y;
}
Index: tut-02.html
===================================================================
RCS file: /home/pooma/Repository/r2/docs/tut-02.html,v
retrieving revision 1.1
diff -c -p -r1.1 tut-02.html
*** tut-02.html 2001/03/19 16:11:13 1.1
--- tut-02.html 2001/03/21 19:59:59
*************** objects in some way.
*** 445,451 ****
<p>In POOMA, that way is to use a 2-dimensional
<tt>Interval</tt> or <tt>Range</tt> instead of a pair
of 1-dimensional <tt>Interval</tt>s or
! <tt>Range</tt>s. A 2-dimensional<tt>Interval</tt> is
just the cross-product of its 1-dimensional constituents: it specifies
a dense rectangular patch of an array. Similarly, a 2-dimensional
<tt>Range</tt> is a generalization of the red or black squares
--- 445,451 ----
<p>In POOMA, that way is to use a 2-dimensional
<tt>Interval</tt> or <tt>Range</tt> instead of a pair
of 1-dimensional <tt>Interval</tt>s or
! <tt>Range</tt>s. A 2-dimensional <tt>Interval</tt> is
just the cross-product of its 1-dimensional constituents: it specifies
a dense rectangular patch of an array. Similarly, a 2-dimensional
<tt>Range</tt> is a generalization of the red or black squares
*************** need not have the same spacing along dif
*** 455,461 ****
<p>An N-dimensional<tt>Interval</tt> is declared in the same
way as its 1-dimensional cousin. An N-dimensional
<tt>Interval</tt> is usually initialized by giving its
! constructor N 1-dimensional<tt>Interval</tt>s as arguments,
as shown in the following example:
<blockquote><pre>
--- 455,461 ----
<p>An N-dimensional<tt>Interval</tt> is declared in the same
way as its 1-dimensional cousin. An N-dimensional
<tt>Interval</tt> is usually initialized by giving its
! constructor N 1-dimensional <tt>Interval</tt>s as arguments,
as shown in the following example:
<blockquote><pre>
*************** using 2-dimensional subscripting:
*** 537,543 ****
32
33 // <em>The array we'll be solving for.</em>
34 Array<2> V(guarded);
! 35 x = 0.0;
36
37 // <em>The right hand side of the equation.</em>
38 Array<2> b(calc);
--- 537,543 ----
32
33 // <em>The array we'll be solving for.</em>
34 Array<2> V(guarded);
! 35 V = 0.0;
36
37 // <em>The right hand side of the equation.</em>
38 Array<2> b(calc);
*************** used to ensure zero boundary conditions.
*** 577,584 ****
condition could be represented equally well by assigning values to
these padding elements.
! <p>Using<tt>Interval</tt> objects that run from 1 to N-2 to
! specify the dimensions of the<tt>Interval</tt> object
<tt>calc</tt> defined on line 28 means that when the array
<tt>b</tt> is defined (line 38), its legal indices also run from
1 to N-2 along each axis. While POOMA uses 0..N-1 indexing by
--- 577,584 ----
condition could be represented equally well by assigning values to
these padding elements.
! <p>Using <tt>Interval</tt> objects that run from 1 to N-2 to
! specify the dimensions of the <tt>Interval</tt> object
<tt>calc</tt> defined on line 28 means that when the array
<tt>b</tt> is defined (line 38), its legal indices also run from
1 to N-2 along each axis. While POOMA uses 0..N-1 indexing by
*************** either axis are padding, and are to be o
*** 632,638 ****
iteration.
<p>The function that actually updates the periodic boundary conditions
! is called <tt>ApplyPeriodic()</tt>, and is shown on lines 20-28 below.
The key to understanding this code is that when a "naked" integer is
used to subscript a POOMA array, the result of that
subscripting operation is reduced by one dimension in relation to that
--- 632,638 ----
iteration.
<p>The function that actually updates the periodic boundary conditions
! is called <tt>ApplyPeriodic()</tt>, and is shown on lines 20-33 below.
The key to understanding this code is that when a "naked" integer is
used to subscript a POOMA array, the result of that
subscripting operation is reduced by one dimension in relation to that
*************** point yields an <tt>Array</tt> with just
*** 650,656 ****
zero-dimensional <tt>Array</tt> (at least not in this release of
POOMA), which is what the <tt>Loc<2></tt> would have returned.
The reduction in rank has to come from compile-time information, so
! <tt>Loc</tt> and integers reduce dimensionality, but<tt>Interval</tt>
and <tt>Range</tt> do not.
<blockquote><pre>
--- 650,656 ----
zero-dimensional <tt>Array</tt> (at least not in this release of
POOMA), which is what the <tt>Loc<2></tt> would have returned.
The reduction in rank has to come from compile-time information, so
! <tt>Loc</tt> and integers reduce dimensionality, but <tt>Interval</tt>
and <tt>Range</tt> do not.
<blockquote><pre>
*************** this, using the declarations:
*** 788,794 ****
<TR>
<TD>
! Taking a view using an<tt>Interval</tt>
<TD>
<center><tt>a(I)</tt></center>
<TD>
--- 788,794 ----
<TR>
<TD>
! Taking a view using an <tt>Interval</tt>
<TD>
<center><tt>a(I)</tt></center>
<TD>
*************** this, using the declarations:
*** 833,839 ****
<TR>
<TD WIDTH="32%">
! Taking a read-only view using an<tt>Interval</tt>
<TD WIDTH="18%">
<CENTER><tt>a.read(I)</tt></CENTER>
<TD WIDTH="50%">
--- 833,839 ----
<TR>
<TD WIDTH="32%">
! Taking a read-only view using an <tt>Interval</tt>
<TD WIDTH="18%">
<CENTER><tt>a.read(I)</tt></CENTER>
<TD WIDTH="50%">
Index: tut-04.html
===================================================================
RCS file: /home/pooma/Repository/r2/docs/tut-04.html,v
retrieving revision 1.1
diff -c -p -r1.1 tut-04.html
*** tut-04.html 2001/03/19 16:11:14 1.1
--- tut-04.html 2001/03/21 20:00:00
*************** supported. Please contact <a
*** 404,411 ****
href="mailto:pooma-devel at lanl.gov">pooma-devel at lanl.gov</a> for
information on using other, more complicated types.
! <p>The <tt>Array::comp()</tt> method used on line 16 does
! <a name="component-forwarding"><em>component forwarding</em></a>. The
expression <tt>rays.comp(2)</tt> returns an
<tt>Array<double></tt> that supports writing into the second
component of each vector element of rays. This is a data-parallel
--- 404,411 ----
href="mailto:pooma-devel at lanl.gov">pooma-devel at lanl.gov</a> for
information on using other, more complicated types.
! <p>The <tt>Array::comp()</tt> method used on line 16 does <a
! name="component-forwarding"><em>component forwarding</em></a>. The
expression <tt>rays.comp(2)</tt> returns an
<tt>Array<double></tt> that supports writing into the second
component of each vector element of rays. This is a data-parallel
*************** statement that works in a way analogous
*** 413,421 ****
except that the POOMA evaluator will calculate patches in
parallel. Thus, if a program had an array of tensors <tt>T</tt>, it
could change the element in the 0th row, 1st column with <tt>T.comp(0,
! 1)</tt>. Note that, unlike <tt>Array</tt>, both
! <tt>Vector</tt> and <tt>Tensor</tt> always index from
! zero.
<p>Line 24 shows that, as expected, the i<sup>th</sup> component
of a <tt>Vector</tt> <tt>V</tt> can be accessed for both
--- 413,422 ----
except that the POOMA evaluator will calculate patches in
parallel. Thus, if a program had an array of tensors <tt>T</tt>, it
could change the element in the 0th row, 1st column with <tt>T.comp(0,
! 1)</tt>. Note that, unlike <tt>Array</tt>, both <tt>Vector</tt> and
! <tt>Tensor</tt> always index from zero. Component forwarding is
! intimately related to the notion of component views, which are
! discussed <a href="#componentviews">below</a>.
<p>Line 24 shows that, as expected, the i<sup>th</sup> component
of a <tt>Vector</tt> <tt>V</tt> can be accessed for both
*************** reading and writing using the syntax <tt
*** 424,431 ****
the first subscript in the expression <tt>rays(i)(0)</tt> returns the
i<sup>th</sup> element of the <tt>Vector</tt> <tt>rays</tt>,
while the second subscript returns the zeroth component of that vector.
- Component forwarding is intimately related to the notion of component
- views, which are discussed <a href="#componentviews">below</a>.
<p>Line 28 shows that <tt>Vector</tt>s can be initialized
with <tt>Size</tt> element values. Similarly, instances of
--- 425,430 ----
*************** as are the following named functions on
*** 508,524 ****
(<em>i,j</em>) of the transpose is equal to element (<em>j,i</em>) of the
input tensor <tt>t</tt>.
! <p><dt> <tt>template<class OutputEngineTag, int D, class T, class EngineTag>
<br>Tensor<D,T,OutputEngineTag> &symmetrize(Tensor<D,T,E> &t)</tt>:
<dd>Returns a tensor of type
! <tt>Tensor<D,T,E></tt>, applying a n appropriate symmetrizing operation
to convert from the symmetry of the input <tt>EngineTag</tt> (for example,
<tt>Full</tt>) to the symmetry of the <tt>OutputEngineTag</tt> (for example,
! <tt>Antisymmetric</tt>. This is invoked using explicit template instantiation
for the desired <tt>OutputEngineTag</tt>. For example:
<pre>
! Tensor>2,double,Full> t(1.0, 2.0, 3.0, 4.0);
! Tensor>2,double,Antisymmetric> at = symmetrize<Antisymmetric>(t);
std::cout << " t = " << t << std::endl;
std::cout << "at = " << at << std::endl;
</blockquote></pre>
--- 507,523 ----
(<em>i,j</em>) of the transpose is equal to element (<em>j,i</em>) of the
input tensor <tt>t</tt>.
! <p><dt> <tt>template<class OutputEngineTag, int D, class T, class E>
<br>Tensor<D,T,OutputEngineTag> &symmetrize(Tensor<D,T,E> &t)</tt>:
<dd>Returns a tensor of type
! <tt>Tensor<D,T,E></tt>, applying an appropriate symmetrizing operation
to convert from the symmetry of the input <tt>EngineTag</tt> (for example,
<tt>Full</tt>) to the symmetry of the <tt>OutputEngineTag</tt> (for example,
! <tt>Antisymmetric</tt>). This is invoked using explicit template instantiation
for the desired <tt>OutputEngineTag</tt>. For example:
<pre>
! Tensor<2,double,Full> t(1.0, 2.0, 3.0, 4.0);
! Tensor<2,double,Antisymmetric> at = symmetrize<Antisymmetric>(t);
std::cout << " t = " << t << std::endl;
std::cout << "at = " << at << std::endl;
</blockquote></pre>
*************** via matrix-matrix product of the two arg
*** 547,553 ****
</dl>
These functions also operate on <tt>Array</tt>s of <tt>Tensor</tt>
! and <tt>Vector</tt> elements (and <tt>DynamicArray</tt>s, and <tt>Field</tt>s.)
<p> Lines 37-39 show construction of a diagonal tensor using the
<tt>Tensor</tt> class with <tt>Diagonal</tt> for the <tt>EngineTag</tt>
--- 546,552 ----
</dl>
These functions also operate on <tt>Array</tt>s of <tt>Tensor</tt>
! and <tt>Vector</tt> elements (and <tt>DynamicArray</tt>s and <tt>Field</tt>s).
<p> Lines 37-39 show construction of a diagonal tensor using the
<tt>Tensor</tt> class with <tt>Diagonal</tt> for the <tt>EngineTag</tt>
*************** like arrays of any other type.
*** 568,574 ****
<P>Accumulation operators such as <tt>operator*=()</tt> acting on
<tt>Tensor<D,T,EngineTag></tt> may result in a <tt>Tensor</tt> having
! different symmetry (different <tt>EngineTag</tt> than what you are accumulating into. For example,
<blockquote><pre>
Tensor<2,double,Antisymmetric> t1, t2;
// ... assign values
--- 567,573 ----
<P>Accumulation operators such as <tt>operator*=()</tt> acting on
<tt>Tensor<D,T,EngineTag></tt> may result in a <tt>Tensor</tt> having
! different symmetry (different <tt>EngineTag</tt> than what you are accumulating into). For example,
<blockquote><pre>
Tensor<2,double,Antisymmetric> t1, t2;
// ... assign values
*************** Array< 2, double, MultiPatch<Unifo
*** 611,617 ****
logical domain of the array being created. The 10×10
<tt>Loc</tt> is then used in the <tt>UniformGridLayout</tt>
declaration to specify that the total domain is to be managed using a
! total of 100 patches. When the <tt>Array</tt> <tt>a</tt> is
finally declared, <tt>Array</tt>'s third template parameter is
explicitly instantiated using <tt>MultiPatch</tt>, and
the layout object <tt>layout</tt> is used as a constructor parameter.
--- 610,616 ----
logical domain of the array being created. The 10×10
<tt>Loc</tt> is then used in the <tt>UniformGridLayout</tt>
declaration to specify that the total domain is to be managed using a
! total of 100 patches. When the <tt>Array</tt> <tt>A</tt> is
finally declared, <tt>Array</tt>'s third template parameter is
explicitly instantiated using <tt>MultiPatch</tt>, and
the layout object <tt>layout</tt> is used as a constructor parameter.
*************** patch. As the overhead for evaluating a
*** 752,758 ****
small sub-patch evaluations hurt efficiency.
<p>One mechanism for fixing this problem is to introduce
! <em>guard</em> (or ghost) layers. This done by having the individual
patches overlap slightly. Each patch still "owns" the same data as
before, but surrounds that data with a layer of guards. These guards
duplicate data that is owned by other patches, and can only be read
--- 751,757 ----
small sub-patch evaluations hurt efficiency.
<p>One mechanism for fixing this problem is to introduce
! <em>guard</em> (or <em>ghost</em>) layers. This done by having the individual
patches overlap slightly. Each patch still "owns" the same data as
before, but surrounds that data with a layer of guards. These guards
duplicate data that is owned by other patches, and can only be read
*************** glossed over, since the main intent of t
*** 815,829 ****
intermediate or advanced users of the library can tailor it to their
needs.
! <p>The most common array layout in POOMA is called a brick
! layout, and is signaled by the use of the class <tt>Brick</tt> as an
! engine specifier in template instantiation. Conceptually, a brick is
! a dense, rectangular patch of multi-dimensional space, such as the
! area [0..10]×[0..10]. Programs written by the typical user
! access the elements of bricks using nested loops, the indices of which
! sweep through the brick's extent along a particular axis. Programs
! written by POOMA's developers use more complicated access
! loops in order to take full advantage of cache behavior.
<p>The three functions <tt>accumulateWithLoop()</tt> defined below are
the guts of the general-purpose adding routine that we will build up
--- 814,828 ----
intermediate or advanced users of the library can tailor it to their
needs.
! <p>The most common array layout in POOMA is called a brick layout, and
! is signaled by the use of the class <tt>Brick</tt> as an engine
! specifier in template instantiation. Conceptually, a brick is a
! dense, rectangular patch of multi-dimensional space, such as the area
! [0..10]×[0..10]. Programs written by the typical user access
! the elements of bricks using nested loops, the indices of which sweep
! through the brick's extent along a particular axis. POOMA code uses
! more complicated access loops in order to take full advantage of cache
! behavior.
<p>The three functions <tt>accumulateWithLoop()</tt> defined below are
the guts of the general-purpose adding routine that we will build up
*************** inline T accumulateWithLoop(
*** 844,851 ****
const ConstArray<1,T,E>& x
){
T sum = 0;
! int f0 = x.first(0), l0 = x.last(0);
! for (int i0=f0; i0<=l0; ++i0)
sum += x(i0);
return sum;
}
--- 843,850 ----
const ConstArray<1,T,E>& x
){
T sum = 0;
! int first0 = x.first(0), last0 = x.last(0);
! for (int i0=first0; i0<=last0; ++i0)
sum += x(i0);
return sum;
}
*************** inline T accumulateWithLoop(
*** 855,864 ****
const ConstArray<2,T,E>& x
){
T sum = 0;
! int f0 = x.first(0), f1 = x.first(1);
! int l0 = x.last(0), l1 = x.last(1);
for (int i1=f1; i1<=l1; ++i1)
! for (int i0=f0; i0<=l0; ++i0)
sum += x(i0, i1);
return sum;
}
--- 854,863 ----
const ConstArray<2,T,E>& x
){
T sum = 0;
! int first0 = x.first(0), f1 = x.first(1);
! int last0 = x.last(0), l1 = x.last(1);
for (int i1=f1; i1<=l1; ++i1)
! for (int i0=first0; i0<=last0; ++i0)
sum += x(i0, i1);
return sum;
}
*************** inline T accumulateWithLoop(
*** 868,878 ****
const ConstArray<3,T,E>& x
){
T sum = 0;
! int f0 = x.first(0), f1 = x.first(1), f2 = x.first(2);
! int l0 = x.last(0), l1 = x.last(1), l2 = x.last(2);
for (int i2=f2; i2<=l2; ++i2)
for (int i1=f1; i1<=l1; ++i1)
! for (int i0=f0; i0<=l0; ++i0)
sum += x(i0, i1, i2);
return sum;
}
--- 867,877 ----
const ConstArray<3,T,E>& x
){
T sum = 0;
! int first0 = x.first(0), f1 = x.first(1), f2 = x.first(2);
! int last0 = x.last(0), l1 = x.last(1), l2 = x.last(2);
for (int i2=f2; i2<=l2; ++i2)
for (int i1=f1; i1<=l1; ++i1)
! for (int i0=first0; i0<=last0; ++i0)
sum += x(i0, i1, i2);
return sum;
}
*************** T accumulate(
*** 894,900 ****
}
</pre></blockquote>
! <p>This function just calls through to whichever version of
<tt>accumulateWithLoop()</tt> handles arrays of dimension <tt>D</tt>.
Since <tt>accumulateWithLoop()</tt> is an <tt>inline</tt> function,
this one extra function call will be eliminated by the compiler when
--- 893,899 ----
}
</pre></blockquote>
! <p>This function just calls whichever version of
<tt>accumulateWithLoop()</tt> handles arrays of dimension <tt>D</tt>.
Since <tt>accumulateWithLoop()</tt> is an <tt>inline</tt> function,
this one extra function call will be eliminated by the compiler when
Index: tut-06.html
===================================================================
RCS file: /home/pooma/Repository/r2/docs/tut-06.html,v
retrieving revision 1.1
diff -c -p -r1.1 tut-06.html
*** tut-06.html 2001/03/19 16:11:14 1.1
--- tut-06.html 2001/03/21 20:00:01
*************** in the <math.h> header file.)
*** 215,221 ****
<p>The second version of <tt>fft()</tt> does the real
number-crunching. If the computation has reached its final stage, odd
and even elements are combined directly (lines 106-111). If the
! computation is still recursing, the elements are shuffled, a
half-sized transform is applied on each subsection, and the results
are combined (lines 100-102). All of these operations use indirect
addressing to move data values around. Most of the rest of the
--- 215,221 ----
<p>The second version of <tt>fft()</tt> does the real
number-crunching. If the computation has reached its final stage, odd
and even elements are combined directly (lines 106-111). If the
! computation is still recurring, the elements are shuffled, a
half-sized transform is applied on each subsection, and the results
are combined (lines 100-102). All of these operations use indirect
addressing to move data values around. Most of the rest of the
Index: tut-07.html
===================================================================
RCS file: /home/pooma/Repository/r2/docs/tut-07.html,v
retrieving revision 1.1
diff -c -p -r1.1 tut-07.html
*** tut-07.html 2001/03/19 16:11:14 1.1
--- tut-07.html 2001/03/21 20:00:02
*************** class RectilinearCentering
*** 339,345 ****
</pre></blockquote>
<P>The <tt>RectilinearCenteringTag</tt> template parameter can be
! instantiated using a class whose centerings which are defined
componentwise. This means that each component of a multicomponent
field element type such as <tt>Vector</tt> or <tt>Tensor</tt> can have
its own independent centering position. The value of the Boolean
--- 339,345 ----
</pre></blockquote>
<P>The <tt>RectilinearCenteringTag</tt> template parameter can be
! instantiated using a class whose centerings are defined
componentwise. This means that each component of a multicomponent
field element type such as <tt>Vector</tt> or <tt>Tensor</tt> can have
its own independent centering position. The value of the Boolean
*************** mesh with complete set of centering poin
*** 426,432 ****
</table></center>
<P>As an example of componentwise centering, consider
! <tt>RectilinearCentering<2,VectorFaceRCTag<2>></tt>. The
<em>Y</em> components of a field element of <tt>Vector</tt> type are
centered on the faces perpendicular to the <em>Y</em> axis, while the
<em>X</em> components are centered on the faces perpendicular to
--- 426,432 ----
</table></center>
<P>As an example of componentwise centering, consider
! <tt>RectilinearCentering<2,VectorFaceRCTag<2> ></tt>. The
<em>Y</em> components of a field element of <tt>Vector</tt> type are
centered on the faces perpendicular to the <em>Y</em> axis, while the
<em>X</em> components are centered on the faces perpendicular to
*************** WIDTH="451"></a></tr>
*** 448,454 ****
<tr><td align="center" width="536"><em>Figure 4: Example of
componentwise centering, showing
! RectilinearCentering<2,VectorFace<2>></em>
</tr>
</table></center>
--- 448,454 ----
<tr><td align="center" width="536"><em>Figure 4: Example of
componentwise centering, showing
! RectilinearCentering<2,VectorFace<2>></em>
</tr>
</table></center>
*************** WIDTH="451"></a></tr>
*** 457,463 ****
<a name="centeringalloc"><h3>A Note on Allocation</h3></a>
<P>For componentwise rectilinear centerings such as
! <tt>RectilinearCentering<2,VectorFace<2> ></tt>, POOMA
currently allocates <tt>Field</tt> domains (and <tt>Array</tt> domains
in the associated <tt>DiscreteGeometry</tt>) with storage for
<tt>nVerts</tt> elements in each dimension, so storage for a
--- 457,463 ----
<a name="centeringalloc"><h3>A Note on Allocation</h3></a>
<P>For componentwise rectilinear centerings such as
! <tt>RectilinearCentering<2,VectorFaceRCTag<2> ></tt>, POOMA
currently allocates <tt>Field</tt> domains (and <tt>Array</tt> domains
in the associated <tt>DiscreteGeometry</tt>) with storage for
<tt>nVerts</tt> elements in each dimension, so storage for a
*************** following methods:
*** 593,599 ****
representation, such as a parameterized function object defining the
bounding surface of the domain, with a method to determine whether a
point in the space is inside or outside the set. The type of this
! object must be <tt>Domain_t</tt>,
<dt><tt>totalDomain()</tt>:
--- 593,599 ----
representation, such as a parameterized function object defining the
bounding surface of the domain, with a method to determine whether a
point in the space is inside or outside the set. The type of this
! object must be <tt>Domain_t</tt>.
<dt><tt>totalDomain()</tt>:
*************** following methods:
*** 604,610 ****
<a name="geomxmethod"></a><DT><tt>x()</tt>:
! <DD>returns an array of centering positions corresponding to the
total domain.
</DL>
--- 604,610 ----
<a name="geomxmethod"></a><DT><tt>x()</tt>:
! <DD>Returns an array of centering positions corresponding to the
total domain.
</DL>
*************** told to update themselves if necessary.
*** 765,771 ****
<tt>Field</tt>s that are based on its rectilinear mesh geometry
classes. The current release provides periodic, reflecting, constant,
and linear-extrapolation boundary condition types; future releases may
! may include others. More importantly, the required interface for the
boundary condition classes is meant to make it easy for users to
implement their own special boundary conditions. By following this
interface prescription, applications can attach their own boundary
--- 765,771 ----
<tt>Field</tt>s that are based on its rectilinear mesh geometry
classes. The current release provides periodic, reflecting, constant,
and linear-extrapolation boundary condition types; future releases may
! include others. More importantly, the required interface for the
boundary condition classes is meant to make it easy for users to
implement their own special boundary conditions. By following this
interface prescription, applications can attach their own boundary
*************** volumes by making use of the fact that t
*** 795,801 ****
beyond the number of vertices at the other side. The existence of
guard layers affects the information that <tt>Field</tt>s provide
about <a href="#fieldlocdef">the spatial position of their
! elements</a>. The expression f.x(0) is actually the position of one
corner of the total domain of the <tt>Field</tt> <tt>f</tt> only if
<tt>f</tt> has no guard layers, since the rule is that the physical
domain of a <tt>Field</tt> is always zero-based. This means that in
--- 795,801 ----
beyond the number of vertices at the other side. The existence of
guard layers affects the information that <tt>Field</tt>s provide
about <a href="#fieldlocdef">the spatial position of their
! elements</a>. The expression <tt>f.x(0)</tt> is actually the position of one
corner of the total domain of the <tt>Field</tt> <tt>f</tt> only if
<tt>f</tt> has no guard layers, since the rule is that the physical
domain of a <tt>Field</tt> is always zero-based. This means that in
*************** line 13 in the following source code:
*** 1165,1171 ****
013 const int Dim = 2;
014 const int nVerts = 129;
015 const int nCells = nVerts - 1;
! 016 Interval>Dim> vertexDomain;
017 int d;
018 for (d = 0; d < Dim; d++)
019 {
--- 1165,1171 ----
013 const int Dim = 2;
014 const int nVerts = 129;
015 const int nCells = nVerts - 1;
! 016 Interval<Dim> vertexDomain;
017 int d;
018 for (d = 0; d < Dim; d++)
019 {
Index: tut-08.html
===================================================================
RCS file: /home/pooma/Repository/r2/docs/tut-08.html,v
retrieving revision 1.1
diff -c -p -r1.1 tut-08.html
*** tut-08.html 2001/03/19 16:11:14 1.1
--- tut-08.html 2001/03/21 20:00:03
*************** average(const ConstField<Geometry, T,
*** 228,234 ****
TW, MeshTraits<typename Geometry::Mesh_t>::isLogicallyRectilinear> >
Functor_t;
typedef ConstField<Geometry, T, EngineTag> Expression1_t;
! typedef ConstField<Geometry, TW, EngineTagW> Expression1_t;
typedef View2<Functor_t, Expression1_t, Expression2_t> Ret_t;
return Ret_t::make(Functor_t(), f, weight);
}
--- 228,234 ----
TW, MeshTraits<typename Geometry::Mesh_t>::isLogicallyRectilinear> >
Functor_t;
typedef ConstField<Geometry, T, EngineTag> Expression1_t;
! typedef ConstField<Geometry, TW, EngineTagW> Expression2_t;
typedef View2<Functor_t, Expression1_t, Expression2_t> Ret_t;
return Ret_t::make(Functor_t(), f, weight);
}
*************** files.
*** 308,319 ****
</tr>
<tr>
- <td><tt>SurfaceNormalsArray_t</tt>
- <td>The type of <tt>ConstArray</tt> returned by
- <tt>cellSurfaceNormals()</tt>.
- </tr>
-
- <tr>
<td><tt>This_t</tt>
<td>The type of this class.
</tr>
--- 308,313 ----
*************** href="#dimension-def">dimensions</a></tt
*** 452,458 ****
logically-rectilinear mesh classes is the <tt>Dim</tt> template
parameter for their <tt>Array</tt> data members, such as the array of
vertex-vertex mesh spacings returned by <tt>vertexDeltas()</tt>. This
! value is also the number of integers require to index a single mesh
element. While the mesh class's dimension and its spatial
dimensionality are the same for logically-rectilinear meshes, an
unstructured mesh might well use one-dimensional <tt>Array</tt>s to
--- 446,452 ----
logically-rectilinear mesh classes is the <tt>Dim</tt> template
parameter for their <tt>Array</tt> data members, such as the array of
vertex-vertex mesh spacings returned by <tt>vertexDeltas()</tt>. This
! value is also the number of integers required to index a single mesh
element. While the mesh class's dimension and its spatial
dimensionality are the same for logically-rectilinear meshes, an
unstructured mesh might well use one-dimensional <tt>Array</tt>s to
*************** are lost. POOMA represents this notion b
*** 578,584 ****
geometry, there is no way to know what the geometry of the resulting
<tt>Field</tt> should be. (The library could make an arbitrary
choice, such as always using the geometry from the left operand, but
! this would be wrong as often as it was right). If the two
<tt>Field</tt>s have the same geometry type, it is still not possible
to know until run-time whether they really hold equivalent geometry
objects. Lacking a clear idea of how to construct the geometry, the
--- 572,578 ----
geometry, there is no way to know what the geometry of the resulting
<tt>Field</tt> should be. (The library could make an arbitrary
choice, such as always using the geometry from the left operand, but
! this would be wrong as often as it was correct). If the two
<tt>Field</tt>s have the same geometry type, it is still not possible
to know until run-time whether they really hold equivalent geometry
objects. Lacking a clear idea of how to construct the geometry, the
*************** example</a>:
*** 985,991 ****
<blockquote><pre>
// <em>Create the geometries, assuming RectilinearMesh object mesh:</em>
! typedef RectilinearMesh<Dim, Cartesian<Dim> > Mesh_t
DiscreteGeometry<Vert, Mesh_t> geomv(mesh, GuardLayers<Dim>(1));
DiscreteGeometry<Cell, Mesh_t> geomc(mesh, GuardLayers<Dim>(1));
--- 979,985 ----
<blockquote><pre>
// <em>Create the geometries, assuming RectilinearMesh object mesh:</em>
! typedef RectilinearMesh<Dim, Cartesian<Dim> > Mesh_t;
DiscreteGeometry<Vert, Mesh_t> geomv(mesh, GuardLayers<Dim>(1));
DiscreteGeometry<Cell, Mesh_t> geomc(mesh, GuardLayers<Dim>(1));
*************** typedef Div<Cell, DiscreteGeometry<
*** 998,1004 ****
FieldStencil<Div_t> divVV2SC();
// <em>Divergence, Vector/Vert-->Scalar/Cell</em>
! sc = divV2SC(fv);
</pre></blockquote>
<p> Programmers may also find it convenient to create wrappers by
--- 992,998 ----
FieldStencil<Div_t> divVV2SC();
// <em>Divergence, Vector/Vert-->Scalar/Cell</em>
! sc = divV2SC(vv);
</pre></blockquote>
<p> Programmers may also find it convenient to create wrappers by
*************** the scalar loop; and
*** 1044,1050 ****
<p>In addition, boundary conditions are not automatically evaluated
before a field is printed. Applications should therefore call
<tt>applyBoundaryConditions()</tt> before output statements to ensure
! that the boundary values displayed are up to date..
<a name="bdryprebuilt"><h3>Using Pre-Built Boundary Conditions</h3></a>
--- 1038,1044 ----
<p>In addition, boundary conditions are not automatically evaluated
before a field is printed. Applications should therefore call
<tt>applyBoundaryConditions()</tt> before output statements to ensure
! that the boundary values displayed are up to date.
<a name="bdryprebuilt"><h3>Using Pre-Built Boundary Conditions</h3></a>
*************** conditions are added in the functor's <t
*** 1214,1220 ****
which is called internally by the field.
<p>This release of POOMA predefines the functors listed below. Their
! effects can be inferred by comparing them with the the boundary
conditions given in the <a href="#builtinbc">previous table</a>.
<ul>
--- 1208,1214 ----
which is called internally by the field.
<p>This release of POOMA predefines the functors listed below. Their
! effects can be inferred by comparing them with the boundary
conditions given in the <a href="#builtinbc">previous table</a>.
<ul>
*************** with operators. The source code below, t
*** 1555,1564 ****
170 }
</pre></blockquote>
! <p>This is a simple Jacobi saolver for Laplace's equation using the <tt>PositionFaceBC</tt>
boundary condition discussed above. Lines 110-130 set up the mesh, the geometry, and the
<tt>Brick</tt>-engine-based <tt>Field</tt>. Notice that we do not add any boundary conditions
! to this field, but we do reserve one layer of external guard layers (line 125)
We then initialize the <tt>Field</tt> <tt>v</tt> and begin iterating. Since we need a
temporary field to store the result of the Laplacian stencil, we can efficiently perform
two applications of the stencil for each loop (lines 147 and 148). We know
--- 1549,1558 ----
170 }
</pre></blockquote>
! <p>This is a simple Jacobi solver for Laplace's equation using the <tt>PositionFaceBC</tt>
boundary condition discussed above. Lines 110-130 set up the mesh, the geometry, and the
<tt>Brick</tt>-engine-based <tt>Field</tt>. Notice that we do not add any boundary conditions
! to this field, but we do reserve one layer of external guard layers (line 125).
We then initialize the <tt>Field</tt> <tt>v</tt> and begin iterating. Since we need a
temporary field to store the result of the Laplacian stencil, we can efficiently perform
two applications of the stencil for each loop (lines 147 and 148). We know
*************** to monitor wall-clock time (lines 1
*** 1568,1574 ****
<p>The function <tt>applyLaplacian</tt> (lines 97-101) takes a <tt>Field</tt> to assign
to and a <tt>Field</tt> to stencil as arguments. This is where the boundary conditions are
! applied, follwed by the stencil. The <tt>Field</tt> stencil object <tt>Laplace</tt> is
straightforward, except for the static function <tt>applyBoundaryConditions</tt> that,
on the fly, creates boundary conditions for each face of the input field <tt>f</tt> and
applies them.</p>
--- 1562,1568 ----
<p>The function <tt>applyLaplacian</tt> (lines 97-101) takes a <tt>Field</tt> to assign
to and a <tt>Field</tt> to stencil as arguments. This is where the boundary conditions are
! applied, followed by the stencil. The <tt>Field</tt> stencil object <tt>Laplace</tt> is
straightforward, except for the static function <tt>applyBoundaryConditions</tt> that,
on the fly, creates boundary conditions for each face of the input field <tt>f</tt> and
applies them.</p>
More information about the pooma-dev
mailing list