From rguenth at tat.physik.uni-tuebingen.de  Tue Jun  1 09:51:41 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Tue, 1 Jun 2004 11:51:41 +0200 (CEST)
Subject: [PATCH] Drop in PETE tools
Message-ID: <Pine.LNX.4.53.0406011151010.2199@bellatrix.tat.physik.uni-tuebingen.de>

Hi!

I finally go around searching and fixing the right PETE version that was
used for generating the pooma pete header files.  I took the oportunity
to patch our manual fixing into the input files and compared the output
which results in

--- ../PoomaOperatorTags.h	Fri Jun 13 14:12:24 2003
+++ PoomaOperatorTags.h	Tue Jun  1 11:44:19 2004
@@ -13,6 +13,7 @@
 //
 ///////////////////////////////////////////////////////////////////////////////

+
 #include <cstdlib>
 #include <cmath>

--- ../../Array/PoomaArrayOperators.h	Fri Jan 24 10:28:46 2003
+++ PoomaArrayOperators.h	Tue Jun  1 11:44:19 2004
@@ -15,6 +15,9 @@
 ///////////////////////////////////////////////////////////////////////////////


+#include <cstdlib>
+#include <cmath>
+
 #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
 template<int D, class T, class EngineTag> class Tensor;

--- ../../DynamicArray/PoomaDynamicArrayOperators.h	Fri Jan 24 10:28:53 2003
+++ PoomaDynamicArrayOperators.h	Tue Jun  1 11:44:19 2004
@@ -15,6 +15,9 @@
 ///////////////////////////////////////////////////////////////////////////////


+#include <cstdlib>
+#include <cmath>
+
 #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
 template<int D, class T, class EngineTag> class Tensor;

--- ../../Field/PoomaFieldOperators.h	Fri Jan 24 10:28:57 2003
+++ PoomaFieldOperators.h	Tue Jun  1 11:44:20 2004
@@ -15,6 +15,9 @@
 ///////////////////////////////////////////////////////////////////////////////


+#include <cstdlib>
+#include <cmath>
+
 #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
 template<int D, class T, class EngineTag> class Tensor;


This would be a drop in of the attached tarball into src/PETE/Tools
and the following patch to src/Pooma/PETE/

Ok to apply?

Thanks,
Richard.


2004Jun01  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Pooma/PETE/PoomaOps.in: include <cstdlib> and <cmath>.
	src/Pooma/PETE/makefile: MakeOperators is in
	../../PETE/Tools/MakeOperators now.  diff target to compare
	current against new generated headers.

===== PoomaOps.in 1.1 vs edited =====
--- 1.1/r2/src/Pooma/PETE/PoomaOps.in	Mon May 13 17:47:42 2002
+++ edited/PoomaOps.in	Tue Jun  1 11:37:53 2004
@@ -1,6 +1,9 @@
 prefix
 -----
 TEXT = "
+#include <cstdlib>
+#include <cmath>
+
 #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
 template<int D, class T, class EngineTag> class Tensor;

===== makefile 1.1 vs edited =====
--- 1.1/r2/src/Pooma/PETE/makefile	Mon May 13 17:47:42 2002
+++ edited/makefile	Tue Jun  1 11:36:36 2004
@@ -25,15 +25,7 @@
 #  ----------------------------------------------------------------------
 # ACL:license

-#
-# include PETE make information
-# (support easy testing)
-#
-ifndef TEST
-MAKEOPERATORS = $(PETEDIR)/$(PETEARCHDIR)/bin/MakeOperators
-else
-MAKEOPERATORS = ./MakeOperators
-endif
+MAKEOPERATORS = ../../PETE/Tools/MakeOperators

 #
 # the files we will need to build
@@ -81,6 +73,17 @@
 	cp -f PoomaFieldOperators.h ../../Field
 	cp -f VectorFieldOperators.h ../../Field

+diff: $(ALLFILES)
+	-diff -u ../PoomaOperatorTags.h PoomaOperatorTags.h
+	-diff -u ../../Array/ArrayOperators.h ArrayOperators.h
+	-diff -u ../../Array/PoomaArrayOperators.h PoomaArrayOperators.h
+	-diff -u ../../Array/VectorArrayOperators.h VectorArrayOperators.h
+	-diff -u ../../DynamicArray/PoomaDynamicArrayOperators.h PoomaDynamicArrayOperators.h
+	-diff -u ../../DynamicArray/VectorDynamicArrayOperators.h VectorDynamicArrayOperators.h
+	-diff -u ../../DynamicArray/DynamicArrayOperators.h DynamicArrayOperators.h
+	-diff -u ../../Field/FieldOperators.h FieldOperators.h
+	-diff -u ../../Field/PoomaFieldOperators.h PoomaFieldOperators.h
+	-diff -u ../../Field/VectorFieldOperators.h VectorFieldOperators.h

 #
 # Common operations
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Tools.tar.gz
Type: application/octet-stream
Size: 19136 bytes
Desc: tools
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20040601/896a6407/attachment.obj>

From oldham at codesourcery.com  Tue Jun  1 14:51:25 2004
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Tue, 01 Jun 2004 07:51:25 -0700
Subject: [PATCH] Drop in PETE tools
In-Reply-To: <Pine.LNX.4.53.0406011151010.2199@bellatrix.tat.physik.uni-tuebingen.de>
References: <Pine.LNX.4.53.0406011151010.2199@bellatrix.tat.physik.uni-tuebingen.de>
Message-ID: <40BC97ED.9000305@codesourcery.com>

Yes, this change is acceptable.

Richard Guenther wrote:

>Hi!
>
>I finally go around searching and fixing the right PETE version that was
>used for generating the pooma pete header files.  I took the oportunity
>to patch our manual fixing into the input files and compared the output
>which results in
>
>--- ../PoomaOperatorTags.h	Fri Jun 13 14:12:24 2003
>+++ PoomaOperatorTags.h	Tue Jun  1 11:44:19 2004
>@@ -13,6 +13,7 @@
> //
> ///////////////////////////////////////////////////////////////////////////////
>
>+
> #include <cstdlib>
> #include <cmath>
>
>--- ../../Array/PoomaArrayOperators.h	Fri Jan 24 10:28:46 2003
>+++ PoomaArrayOperators.h	Tue Jun  1 11:44:19 2004
>@@ -15,6 +15,9 @@
> ///////////////////////////////////////////////////////////////////////////////
>
>
>+#include <cstdlib>
>+#include <cmath>
>+
> #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
> template<int D, class T, class EngineTag> class Tensor;
>
>--- ../../DynamicArray/PoomaDynamicArrayOperators.h	Fri Jan 24 10:28:53 2003
>+++ PoomaDynamicArrayOperators.h	Tue Jun  1 11:44:19 2004
>@@ -15,6 +15,9 @@
> ///////////////////////////////////////////////////////////////////////////////
>
>
>+#include <cstdlib>
>+#include <cmath>
>+
> #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
> template<int D, class T, class EngineTag> class Tensor;
>
>--- ../../Field/PoomaFieldOperators.h	Fri Jan 24 10:28:57 2003
>+++ PoomaFieldOperators.h	Tue Jun  1 11:44:20 2004
>@@ -15,6 +15,9 @@
> ///////////////////////////////////////////////////////////////////////////////
>
>
>+#include <cstdlib>
>+#include <cmath>
>+
> #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
> template<int D, class T, class EngineTag> class Tensor;
>
>
>This would be a drop in of the attached tarball into src/PETE/Tools
>and the following patch to src/Pooma/PETE/
>
>Ok to apply?
>
>Thanks,
>Richard.
>
>
>2004Jun01  Richard Guenther <richard.guenther at uni-tuebingen.de>
>
>	* src/Pooma/PETE/PoomaOps.in: include <cstdlib> and <cmath>.
>	src/Pooma/PETE/makefile: MakeOperators is in
>	../../PETE/Tools/MakeOperators now.  diff target to compare
>	current against new generated headers.
>
>===== PoomaOps.in 1.1 vs edited =====
>--- 1.1/r2/src/Pooma/PETE/PoomaOps.in	Mon May 13 17:47:42 2002
>+++ edited/PoomaOps.in	Tue Jun  1 11:37:53 2004
>@@ -1,6 +1,9 @@
> prefix
> -----
> TEXT = "
>+#include <cstdlib>
>+#include <cmath>
>+
> #if defined(POOMA_POOMA_POOMAOPERATORTAGS_H)
> template<int D, class T, class EngineTag> class Tensor;
>
>===== makefile 1.1 vs edited =====
>--- 1.1/r2/src/Pooma/PETE/makefile	Mon May 13 17:47:42 2002
>+++ edited/makefile	Tue Jun  1 11:36:36 2004
>@@ -25,15 +25,7 @@
> #  ----------------------------------------------------------------------
> # ACL:license
>
>-#
>-# include PETE make information
>-# (support easy testing)
>-#
>-ifndef TEST
>-MAKEOPERATORS = $(PETEDIR)/$(PETEARCHDIR)/bin/MakeOperators
>-else
>-MAKEOPERATORS = ./MakeOperators
>-endif
>+MAKEOPERATORS = ../../PETE/Tools/MakeOperators
>
> #
> # the files we will need to build
>@@ -81,6 +73,17 @@
> 	cp -f PoomaFieldOperators.h ../../Field
> 	cp -f VectorFieldOperators.h ../../Field
>
>+diff: $(ALLFILES)
>+	-diff -u ../PoomaOperatorTags.h PoomaOperatorTags.h
>+	-diff -u ../../Array/ArrayOperators.h ArrayOperators.h
>+	-diff -u ../../Array/PoomaArrayOperators.h PoomaArrayOperators.h
>+	-diff -u ../../Array/VectorArrayOperators.h VectorArrayOperators.h
>+	-diff -u ../../DynamicArray/PoomaDynamicArrayOperators.h PoomaDynamicArrayOperators.h
>+	-diff -u ../../DynamicArray/VectorDynamicArrayOperators.h VectorDynamicArrayOperators.h
>+	-diff -u ../../DynamicArray/DynamicArrayOperators.h DynamicArrayOperators.h
>+	-diff -u ../../Field/FieldOperators.h FieldOperators.h
>+	-diff -u ../../Field/PoomaFieldOperators.h PoomaFieldOperators.h
>+	-diff -u ../../Field/VectorFieldOperators.h VectorFieldOperators.h
>
> #
> # Common operations
>


-- 
Jeffrey D. Oldham
oldham at codesourcery.com




From oldham at codesourcery.com  Tue Jun  1 19:21:34 2004
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Tue, 01 Jun 2004 12:21:34 -0700
Subject: [PATCH] Shorten filenames during build/link
In-Reply-To: <40BB4C54.6020808@tat.physik.uni-tuebingen.de>
References: <40BB4C54.6020808@tat.physik.uni-tuebingen.de>
Message-ID: <40BCD73E.5050809@codesourcery.com>

Richard Guenther wrote:

> This patch shortens filenames by omitting full path to avoid overly 
> long command lines.  Compiled and tested building some examples, 
> benchmarks and tests.
>
> Ok?
>
> Richard.


Yes, this is fine as long as it does not break compiling on some 
operating system.  For example, does Windows support '.'?

> 2004May31  Richard Guenther <richard.guenther at uni-tuebingen.de>
>
>     * config/Shared/include1.mk: set THISDIR to .
>     config/Shared/tail.mk: don't change into PROJECT_ROOT
>     for PRE_CMDLINE.
>
>------------------------------------------------------------------------
>
>===== config/Shared/include1.mk 1.1 vs edited =====
>--- 1.1/r2/config/Shared/include1.mk	2002-05-13 17:47:19 +02:00
>+++ edited/config/Shared/include1.mk	2004-05-31 17:06:53 +02:00
>@@ -32,8 +32,7 @@
> ########################################################################
> 
> ifndef NEXTDIR
>-#	THISDIR :=$(subst /tmp_mnt,,$(shell pwd))
>-	THISDIR :=$(shell pwd)
>+	THISDIR := .
> 	DIR_LIST :=$(THISDIR)
> else
> 	DIR_LIST :=$(THISDIR)/$(NEXTDIR) $(DIR_LIST)
>===== config/Shared/tail.mk 1.2 vs edited =====
>--- 1.2/r2/config/Shared/tail.mk	2003-06-23 14:50:42 +02:00
>+++ edited/config/Shared/tail.mk	2004-05-31 16:08:26 +02:00
>@@ -57,7 +57,7 @@
> INFO_FILE            = $@_$(PASS).info
> 
> # This is prepended to compile, link, archive, preprocess, etc rules.
>-PRE_CMDLINE          = cd $(PROJECT_ROOT); TMPDIR=$(TMPDIR)/$(SUITE); $(TIME)
>+PRE_CMDLINE          = TMPDIR=$(TMPDIR)/$(SUITE); $(TIME)
> 
> # This is prepended to compile, link, archive, preprocess, etc rules.
> PDB_PRE_CMDLINE      = cd $(@D); TMPDIR=$(TMPDIR)/$(SUITE); $(TIME)
>  
>


-- 
Jeffrey D. Oldham
oldham at codesourcery.com




From oldham at codesourcery.com  Tue Jun  1 19:23:19 2004
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Tue, 01 Jun 2004 12:23:19 -0700
Subject: [PATCH] Minor cleanups
In-Reply-To: <40BB4D30.3020109@tat.physik.uni-tuebingen.de>
References: <40BB4D30.3020109@tat.physik.uni-tuebingen.de>
Message-ID: <40BCD7A7.3010103@codesourcery.com>

Richard Guenther wrote:

> Hi!
>
> This patch changes the comp(int) methods of Array/Field to not pass by 
> const reference, it also removes an unused specialization of 
> ComponentView.
>
> Compiled and tested on ia32-linux, ok?


Yes, please commit this improvement.

> Richard.
>
> 2004May31  Richard Guenther <richard.guenther at uni-tuebingen.de>
>
>     * src/Array/Array.h: remove ComponentView<int, > specialization,
>     do not pass i1 by const reference for comp() method.
>     src/Field/Field.h: do not pass i1 by const reference for 
> comp()        method.
>
>------------------------------------------------------------------------
>
>===== src/Array/Array.h 1.12 vs edited =====
>--- 1.12/r2/src/Array/Array.h	2004-05-31 15:47:13 +02:00
>+++ edited/src/Array/Array.h	2004-05-31 16:16:31 +02:00
>@@ -1288,12 +1288,6 @@
>  * Changes to ComponentView should also be made to AltComponentView.
>  */
> 
>-template<int Dim, class T, class EngineTag>
>-struct ComponentView<int, Array<Dim, T, EngineTag> >
>-{
>-  typedef int Type_t;
>-};
>-
> template<class Components, int Dim, class T, class EngineTag>
> struct ComponentView<Components, Array<Dim, T, EngineTag> >
> {
>@@ -1978,7 +1972,7 @@
>   /// that returns a reference or proxy to the component.
>   //@{
>   inline typename AltComponentView<Loc<1>, This_t>::Type_t
>-  comp(const int &i1) const
>+  comp(int i1) const
>     {
>       return ComponentView<Loc<1>, This_t>::make(*this, Loc<1>(i1));
>     }
>===== src/Field/Field.h 1.19 vs edited =====
>--- 1.19/r2/src/Field/Field.h	2004-05-31 15:47:13 +02:00
>+++ edited/src/Field/Field.h	2004-05-31 16:14:56 +02:00
>@@ -1414,7 +1414,7 @@
>   //@{
> 
>   inline typename ComponentView<Loc<1>, This_t>::Type_t
>-  comp(const int &i1) const
>+  comp(int i1) const
>   {
>     return ComponentView<Loc<1>, This_t>::make(*this, Loc<1>(i1));
>   }
>  
>


-- 
Jeffrey D. Oldham
oldham at codesourcery.com




From rguenth at tat.physik.uni-tuebingen.de  Tue Jun  1 19:43:29 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Tue, 01 Jun 2004 21:43:29 +0200
Subject: [pooma-dev] Re: [PATCH] Shorten filenames during build/link
In-Reply-To: <40BCD73E.5050809@codesourcery.com>
References: <40BB4C54.6020808@tat.physik.uni-tuebingen.de> <40BCD73E.5050809@codesourcery.com>
Message-ID: <40BCDC61.3080400@tat.physik.uni-tuebingen.de>

Jeffrey D. Oldham wrote:
> Richard Guenther wrote:
> 
>> This patch shortens filenames by omitting full path to avoid overly 
>> long command lines.  Compiled and tested building some examples, 
>> benchmarks and tests.
>>
>> Ok?
>>
>> Richard.
> 
> 
> 
> Yes, this is fine as long as it does not break compiling on some 
> operating system.  For example, does Windows support '.'?

I don't know.  I don't care either, and I never did (f.i. I don't know 
of the impact of the configure changes).  Do we care about Windows?  Can 
Windows use the make infrastructure at all?  Or does it need the CW 
project stuff?

I'll hold on this until someone can either report that Windows compiling 
is broken anyway, or can confirm the change is safe.

Richard.



From oldham at codesourcery.com  Tue Jun  1 19:51:13 2004
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Tue, 01 Jun 2004 12:51:13 -0700
Subject: [pooma-dev] Re: [PATCH] Shorten filenames during build/link
In-Reply-To: <40BCDC61.3080400@tat.physik.uni-tuebingen.de>
References: <40BB4C54.6020808@tat.physik.uni-tuebingen.de> <40BCD73E.5050809@codesourcery.com> <40BCDC61.3080400@tat.physik.uni-tuebingen.de>
Message-ID: <40BCDE31.8070704@codesourcery.com>

Richard Guenther wrote:

> Jeffrey D. Oldham wrote:
>
>> Richard Guenther wrote:
>>
>>> This patch shortens filenames by omitting full path to avoid overly 
>>> long command lines.  Compiled and tested building some examples, 
>>> benchmarks and tests.
>>>
>>> Ok?
>>>
>>> Richard.
>>
>>
>>
>>
>> Yes, this is fine as long as it does not break compiling on some 
>> operating system.  For example, does Windows support '.'?
>
>
> I don't know.  I don't care either, and I never did (f.i. I don't know 
> of the impact of the configure changes).  Do we care about Windows?  
> Can Windows use the make infrastructure at all?  Or does it need the 
> CW project stuff?
>
> I'll hold on this until someone can either report that Windows 
> compiling is broken anyway, or can confirm the change is safe.
>
> Richard.
>
Do as you wish, but I would recommend committing it.  I think it's 
unlikely that an operating system does not have . but does have a 
hierarchy, but I thought it was worth asking.

I do not know if POOMA compiles under Windows.

-- 
Jeffrey D. Oldham
oldham at codesourcery.com




From wdn at lanl.gov  Tue Jun  1 20:05:55 2004
From: wdn at lanl.gov (Dave Nystrom)
Date: Tue, 1 Jun 2004 14:05:55 -0600
Subject: [pooma-dev] Re: [PATCH] Shorten filenames during build/link
In-Reply-To: <40BCDE31.8070704@codesourcery.com>
References: <40BB4C54.6020808@tat.physik.uni-tuebingen.de>
	<40BCD73E.5050809@codesourcery.com>
	<40BCDC61.3080400@tat.physik.uni-tuebingen.de>
	<40BCDE31.8070704@codesourcery.com>
Message-ID: <16572.57763.170475.441078@bedell.lanl.gov>

Perhaps John Hall should comment on this.  I know that he and his
collaborators are developing with Windows using Pooma 2.  I believe it is
possible to install gmake and other tools/utilities under Windows to make it
emulate a Unix environment.  However, most people who work in a Windows
environment probably want to take advantage of an IDE.

Anyway, I am copying John on this response.

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-2			phone: 505-667-7913	fax: 505-665-2227

Jeffrey D. Oldham writes:
 > Richard Guenther wrote:
 > 
 > > Jeffrey D. Oldham wrote:
 > >
 > >> Richard Guenther wrote:
 > >>
 > >>> This patch shortens filenames by omitting full path to avoid overly 
 > >>> long command lines.  Compiled and tested building some examples, 
 > >>> benchmarks and tests.
 > >>>
 > >>> Ok?
 > >>>
 > >>> Richard.
 > >>
 > >>
 > >>
 > >>
 > >> Yes, this is fine as long as it does not break compiling on some 
 > >> operating system.  For example, does Windows support '.'?
 > >
 > >
 > > I don't know.  I don't care either, and I never did (f.i. I don't know 
 > > of the impact of the configure changes).  Do we care about Windows?  
 > > Can Windows use the make infrastructure at all?  Or does it need the 
 > > CW project stuff?
 > >
 > > I'll hold on this until someone can either report that Windows 
 > > compiling is broken anyway, or can confirm the change is safe.
 > >
 > > Richard.
 > >
 > Do as you wish, but I would recommend committing it.  I think it's 
 > unlikely that an operating system does not have . but does have a 
 > hierarchy, but I thought it was worth asking.
 > 
 > I do not know if POOMA compiles under Windows.
 > 
 > -- 
 > Jeffrey D. Oldham
 > oldham at codesourcery.com
 > 
 > 


From rguenth at tat.physik.uni-tuebingen.de  Wed Jun  2 10:10:52 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Wed, 2 Jun 2004 12:10:52 +0200 (CEST)
Subject: Problems with domain iterators
Message-ID: <Pine.LNX.4.53.0406021057050.2199@bellatrix.tat.physik.uni-tuebingen.de>

All domain iterators contain

  inline const Value_t &operator*() const

which return references to possibly temporary objects.  This is nasty and
not what iterators are supposed to do.  We get miscompiled code dependend
on compiler versions and stack layout.  Ugh.  It's easy to avoid the above
(just return a copy), but what to do with

  // Member selection operator. Allows calling const Loc
  // member functions. Not too useful, but it is part of
  // the required input iterator interface.

  inline const Value_t *operator->() const

not the comment - what is "the required input iterator interface"?  Where
is it defined?  If it is the STL input iterator definition, I cannot find
any sign of required operator->() there.  Referencing the definition, an
input iterator _may_ be mutable, and looking into the Trivial Iterator
definition, it also _may_ be dereferencable, but must not be.

So I guess we should drop operator->() from the domain iterators and
return copies for operator*() const.

Other ideas?

Below is a proposed patch.  Compiled and tested Domain and Layout with
one regression, Layout/sparsetilelayout_test fails with

### POOMA Assertion Failure ###
### Bad location requested in SparseTileLayout
### File /home/rguenth/src/pooma-bk/r2/src/Layout/SparseTileLayout.cpp;
Line 547.

So I guess I opened a can of worms!?

Richard.

Index: DomainBlockIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainBlockIterator.h,v
retrieving revision 1.10
diff -u -u -r1.10 DomainBlockIterator.h
--- DomainBlockIterator.h	10 Oct 2003 19:26:43 -0000	1.10
+++ DomainBlockIterator.h	2 Jun 2004 10:10:39 -0000
@@ -133,7 +133,7 @@

   // Dereference operator. Returns const ref to internal block.

-  inline const Block_t &operator*() const
+  inline Block_t operator*() const
     {
       PAssert(!done());
       return block_m;
@@ -146,7 +146,7 @@
   inline const Block_t *operator->() const
     {
       PAssert(!done());
-      return block_m;
+      return &block_m;
     }

   // Return the upper-left corner of the current block; this is just a
Index: DomainIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainIterator.h,v
retrieving revision 1.11
diff -u -u -r1.11 DomainIterator.h
--- DomainIterator.h	10 Oct 2003 19:26:43 -0000	1.11
+++ DomainIterator.h	2 Jun 2004 10:10:39 -0000
@@ -127,7 +127,7 @@

   // Dereference operator. Returns const ref to internal Loc.

-  inline const Value_t &operator*() const
+  inline Value_t operator*() const
     {
       PAssert(!done());
       return loc_m;
Index: IndirectionListIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/IndirectionListIterator.h,v
retrieving revision 1.6
diff -u -u -r1.6 IndirectionListIterator.h
--- IndirectionListIterator.h	12 Oct 2003 11:14:38 -0000	1.6
+++ IndirectionListIterator.h	2 Jun 2004 10:10:39 -0000
@@ -110,7 +110,7 @@

   // Dereference operator. Returns const ref to T.

-  inline const Value_t & operator*() const { PAssert(!done()); return val_m; }
+  inline Value_t operator*() const { PAssert(!done()); return val_m; }

   // Member selection operator.

Index: IntervalIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/IntervalIterator.h,v
retrieving revision 1.7
diff -u -u -r1.7 IntervalIterator.h
--- IntervalIterator.h	12 Oct 2003 11:14:38 -0000	1.7
+++ IntervalIterator.h	2 Jun 2004 10:10:39 -0000
@@ -107,7 +107,7 @@

   // Dereference operator. Returns const ref to internal Loc.

-  inline const Value_t &operator*() const { PAssert(!done()); return val_m; }
+  inline Value_t operator*() const { PAssert(!done()); return val_m; }

   // Member selection operator. Not really useful (ints have no
   // members to invoke), but part of the required interface.
Index: RangeIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/RangeIterator.h,v
retrieving revision 1.7
diff -u -u -r1.7 RangeIterator.h
--- RangeIterator.h	12 Oct 2003 11:14:38 -0000	1.7
+++ RangeIterator.h	2 Jun 2004 10:10:39 -0000
@@ -109,7 +109,7 @@

   // Dereference operator. Returns const ref to internal Loc.

-  inline const Value_t &operator*() const { PAssert(!done()); return val_m; }
+  inline Value_t operator*() const { PAssert(!done()); return val_m; }

   // Member selection operator. Not really useful (ints have no
   // members to invoke), but part of the required interface.


From rguenth at tat.physik.uni-tuebingen.de  Wed Jun  2 21:19:41 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Wed, 02 Jun 2004 23:19:41 +0200
Subject: [pooma-dev] Problems with domain iterators
In-Reply-To: <Pine.LNX.4.53.0406021057050.2199@bellatrix.tat.physik.uni-tuebingen.de>
References: <Pine.LNX.4.53.0406021057050.2199@bellatrix.tat.physik.uni-tuebingen.de>
Message-ID: <40BE446D.4080909@tat.physik.uni-tuebingen.de>

Richard Guenther wrote:
> All domain iterators contain
> 
>   inline const Value_t &operator*() const
> 
> which return references to possibly temporary objects.  This is nasty and
> not what iterators are supposed to do.  We get miscompiled code dependend
> on compiler versions and stack layout.  Ugh.  It's easy to avoid the above
> (just return a copy), but what to do with
> 
>   // Member selection operator. Allows calling const Loc
>   // member functions. Not too useful, but it is part of
>   // the required input iterator interface.
> 
>   inline const Value_t *operator->() const
> 
> not the comment - what is "the required input iterator interface"?  Where
> is it defined?  If it is the STL input iterator definition, I cannot find
> any sign of required operator->() there.  Referencing the definition, an
> input iterator _may_ be mutable, and looking into the Trivial Iterator
> definition, it also _may_ be dereferencable, but must not be.
> 
> So I guess we should drop operator->() from the domain iterators and
> return copies for operator*() const.
> 
> Other ideas?

Ok, the problem seems rather that POOMA domain iterators are not like 
STL iterators at all.  So we shouln't try to mix them like we do in
Utilities/algorithms:delete_backfill where we use std::reverse_iterator
on IntervalIterator.  This ends up returning references to temporary 
objects because of the way STL iterators are ment to be constructed.  In 
contrast to the POOMA domain iterators dereferencing them leads to 
storage separate from the iterator and with possibly different (longer) 
lifetime.  This is not the way it works with the POOMA iterators.

So we need to rip out the use of STL iterators (and possibly algorithms)
or try to very clever rework our iterators (I don't have constructive 
ideas here).

For reference, this mess turned up because of gcc PR 
rtl-optimization/14863 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14863).

So, how was this thought to work?

Richard.


From jxyh at lanl.gov  Thu Jun  3 15:00:34 2004
From: jxyh at lanl.gov (John H. Hall)
Date: Thu, 3 Jun 2004 11:00:34 -0400
Subject: [pooma-dev] Cheetah / PETE license
In-Reply-To: <40BB48CC.9050101@tat.physik.uni-tuebingen.de>
References: <40BB48CC.9050101@tat.physik.uni-tuebingen.de>
Message-ID: <C3D34F05-B56E-11D8-BB4F-000A958E5012@lanl.gov>

Nope. Sorry. I haven't been in Los Alamos for a while. I am now in 
Alexandria VA until August. So getting things done back at the lab is 
very difficult. I will try to look into it again, but, I need a 
champion who is physically located there. You can't remove the 
dependency on PETE easily, so we might as well just go ahead and get 
the licenses straightened out.

You will have to ask others how important Cheetah is. I haven't had to 
go down to that level of detail yet. Remember, those of us using 
supercomputers have to have the ability to work on a single box and 
across multiple boxes, which might require different protocols (e.g. 
threads within a box, MPI across boxes?). I seem to remember that being 
what Cheetah was all about.
John Hall

On May 31, 2004, at 11:01 AM, Richard Guenther wrote:

> Hi!
>
> Is there any progress regarding the missing Cheetah / PETE licenses? 
> Would there be objections against removing Cheetah support from POOMA?
>
> Thanks,
> Richard.



From jxyh at lanl.gov  Thu Jun  3 15:15:54 2004
From: jxyh at lanl.gov (John H. Hall)
Date: Thu, 3 Jun 2004 11:15:54 -0400
Subject: [pooma-dev] Re: [PATCH] Shorten filenames during build/link
In-Reply-To: <40BCDC61.3080400@tat.physik.uni-tuebingen.de>
References: <40BB4C54.6020808@tat.physik.uni-tuebingen.de> <40BCD73E.5050809@codesourcery.com> <40BCDC61.3080400@tat.physik.uni-tuebingen.de>
Message-ID: <E87AAF54-B570-11D8-BB4F-000A958E5012@lanl.gov>

Richard:
AFAIK, the only way to use a gmake makefile with Windows is to either 
use MinGW/MSys or Cygwin. Since these emulate a unix environment, the 
changes should work fine. I don't believe our make stuff will work with 
a make other than gmake. So go ahead and commit it as far as I am 
concerned. I use CodeWarrior on both Macs and PCs so there are no 
makefiles. MinGW/MSys is switching over to GCC v3.4 right now and they 
have had some performance issues on just simple C++. So I will be 
sticking with CodeWarrior until these details get worked out. At that 
point I will probably try to compare v3.4 on WIndows with the 
CodeWarrior executable.
John Hall


On Jun 1, 2004, at 3:43 PM, Richard Guenther wrote:

> Jeffrey D. Oldham wrote:
>> Richard Guenther wrote:
>>> This patch shortens filenames by omitting full path to avoid overly 
>>> long command lines.  Compiled and tested building some examples, 
>>> benchmarks and tests.
>>>
>>> Ok?
>>>
>>> Richard.
>> Yes, this is fine as long as it does not break compiling on some 
>> operating system.  For example, does Windows support '.'?
>
> I don't know.  I don't care either, and I never did (f.i. I don't know 
> of the impact of the configure changes).  Do we care about Windows?  
> Can Windows use the make infrastructure at all?  Or does it need the 
> CW project stuff?
>
> I'll hold on this until someone can either report that Windows 
> compiling is broken anyway, or can confirm the change is safe.
>
> Richard.



From rguenth at tat.physik.uni-tuebingen.de  Tue Jun 15 13:23:10 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Tue, 15 Jun 2004 15:23:10 +0200 (CEST)
Subject: Relations
Message-ID: <Pine.LNX.4.53.0406151509070.2199@bellatrix.tat.physik.uni-tuebingen.de>

I'm a little bit confused about the ideas behind RelationListItem:

  virtual void notifyPreRead()
    {
      if (Pooma::isRelationGroupActive(groups_m) && dirty_m)
        {
          apply();
          clearDirty();
        }
    }

  virtual void notifyPostWrite()
    {
      setDirty();
    }

  virtual void setDirty()
    {
      dirty_m = true;
    }

  virtual void clearDirty()
    {
      dirty_m = false;
    }

why are _all_ these virtual?  The only ever overloaded is setDirty (from
InfluenceRelation).  Why do we have notifyPreRead()/notifyPostWrite() at
all?  We use setDirty() in Field.h and applyRelations (which uses
notifyPreRead - ok).

I guess my idea would be to make setDirty/clearDirty non-virtual and
explicitly use notifyPreRead()/notifyPostWrite() where previously
setDirty/applyRelations was used.

The reason I'm looking at all this is because writing to a Field which
is the target of an Influence relation gets this relation dirtied and
re-applied before reading (Ok, maybe it's not nice what I'm doing, but
at the first look, it's quite confusing).  So for me it would work
to override notifyPostWrite() in Relation1-n to do nothing.

So would be a patch like the one below ok?  There would be the opportunity
to remove Field::setDirty() and Field::clearDirty().  I would leave
Field::applyRelations() alone, but maybe do not call notifyPreRead() from
it but some sort of run() directly.

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/


===== Field.h 1.15 vs edited =====
--- 1.15/r2/src/Field/Field.h	Thu May 27 10:56:35 2004
+++ edited/Field.h	Tue Jun 15 14:56:08 2004
@@ -1606,6 +1606,22 @@
     }
   }

+  /// notify relations of upcoming read
+  void notifyPreRead() const
+  {
+    for (int m = 0; m < numMaterials(); ++m)
+      for (int c = 0; c < centering().size(); ++c)
+        fieldEngine_m.data(m, c).relations().notifyPreRead();
+  }
+
+  /// notify relations of past write
+  void notifyPostWrite() const
+  {
+    for (int m = 0; m < numMaterials(); ++m)
+      for (int c = 0; c < centering().size(); ++c)
+        fieldEngine_m.data(m, c).relations().notifyPostWrite();
+  }
+
   /// dirty field, dirtying all relations
   void setDirty() const
   {
@@ -1630,6 +1646,20 @@
     }
   }

+  /// checks, if any of the fields relations is dirty
+  bool isDirty() const
+  {
+    for (int m = 0; m < numMaterials(); ++m)
+    {
+      for (int c = 0; c < centering().size(); ++ c)
+      {
+        if (fieldEngine_m.data(m, c).relations().dirty())
+	  return true;
+      }
+    }
+    return false;
+  }
+
   //@}

 private:
@@ -1853,7 +1883,7 @@
 // that it is going to be read and, therefore, needs to update itself.
 //
 // The second handles fields other than those with expression-engines by simply
-// calling applyRelations(). The third passes the tag to the leaves.
+// calling notifyPreRead(). The third passes the tag to the leaves.
 //
 // Fields with engines that store internal fields AND don't copy those
 // fields' relations to its list must provide a specialization to get the
@@ -1874,7 +1904,7 @@
   inline static
   Type_t apply(const Subject_t &f, const PerformUpdateTag &)
     {
-      f.applyRelations();
+      f.notifyPreRead();
       return 0;
     }
 };
@@ -2014,7 +2044,7 @@
           const Field<Mesh, T, EngineTag> &l = lhs.subField(m, c);

           if (AssignOpReadWriteTraits<Op>::readLHS)
-            l.applyRelations();
+            l.notifyPreRead();

           // Evaluate.

@@ -2023,7 +2053,7 @@
           // Having done the evaluation, we need to notify the LHS
           // that we've just written.

-          l.setDirty();
+          l.notifyPostWrite();
         }
     }

@@ -2053,7 +2083,7 @@
           forEach(r, PerformUpdateTag(), NullCombine());

           if (AssignOpReadWriteTraits<Op>::readLHS)
-            l.applyRelations();
+            l.notifyPreRead();

           // Evaluate.

@@ -2062,7 +2092,7 @@
           // Having done the evaluation, we need to notify the LHS
           // that we've just written.

-          l.setDirty();
+          l.notifyPostWrite();
         }
     }

@@ -2086,7 +2116,7 @@
           const Field<Mesh, T, EngineTag> &l = lhs.subField(m, c);

           if (AssignOpReadWriteTraits<Op>::readLHS)
-            l.applyRelations();
+            l.notifyPreRead();

           // Make an array out of the scalar.

@@ -2101,7 +2131,7 @@
           // Having done the evaluation, we need to notify the LHS
           // that we've just written.

-          l.setDirty();
+          l.notifyPostWrite();
         }
     }

===== Relations/RelationList.h 1.3 vs edited =====
--- 1.3/r2/src/Field/Relations/RelationList.h	Wed Dec  3 12:30:42 2003
+++ edited/Relations/RelationList.h	Tue Jun 15 15:03:23 2004
@@ -242,7 +242,10 @@


   //---------------------------------------------------------------------------
-  // Set/clear the dirty flags for all of the relations.
+  //@name dirty flag handling, deprecated
+  //@{
+
+  /// Set the dirty flags for all relations.

   void setDirty() const
     {
@@ -250,12 +253,25 @@
         list_m->elem(i)->setDirty();
     }

+  /// Set the dirty flags for all relations.
+
   void clearDirty() const
     {
       for (int i = 0; i < list_m->size(); ++i)
         list_m->elem(i)->clearDirty();
     }

+  /// Query if any of the relations is dirty.
+
+  bool dirty() const
+    {
+      for (int i = 0; i < list_m->size(); ++i)
+        if (list_m->elem(i)->dirty())
+	  return true;
+      return false;
+    }
+
+  //@}

   //---------------------------------------------------------------------------
   // Give access to a specific relation.
===== Evaluator/MultiArgEvaluator.h 1.19 vs edited =====
--- 1.19/r2/src/Evaluator/MultiArgEvaluator.h	Thu May 27 10:56:35 2004
+++ edited/Evaluator/MultiArgEvaluator.h	Tue Jun 15 14:50:38 2004
@@ -104,7 +104,7 @@
   template<class A>
   inline void dirtyRelations(const A &a, const WrappedInt<true>&) const
   {
-    a.setDirty();
+    a.notifyPostWrite();
   }

   template<class A>


From rguenth at tat.physik.uni-tuebingen.de  Fri Jun 18 11:42:56 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Fri, 18 Jun 2004 13:42:56 +0200 (CEST)
Subject: A way to handle CSE in Expression Templates
Message-ID: <Pine.LNX.4.53.0406181328440.2199@bellatrix.tat.physik.uni-tuebingen.de>

Hi!

I just got bored writing subexpressions multiple times in expressions and
then to watch the compiler not being able to find out it can do CSE.
Here's a quick-and-dirty solution which has the only disadvantage to
require a tag class per CSE and produces a global storage per CSE (which
actually gets written/read to at least once, dependent on the capabilities
of your optimizing compiler).

With the code snippets below you can now write stuff like:

struct DivV {};

  ...
  ScalarCode<GradV<Dim> >()(gradv, v);
  a_pg(I) = where(save<DivV>(dot(gradv, Vector<Dim>(1))) < 0.0,
		  c * rh * pow2(spacings(rh).comp(0)) * ref<DivV, double>()),
		  0.0);

to compute f.i. an artificial pressure like above.  See that we create a
CSE that contains dot(gradv, Vector<Dim>(1)) - i.e. actually the
divergence of v, and re-use the computed value in the first arm of the
where expression using ref<DivV, double>().  The requirement of specifying
the type of the CSE expression result looks annoying, but I didn't find a
way to avoid this.

Basically the above is equal to the following 1d C code:

  double divv;
  for (int i=0; i<n; ++i) {
    divv = dot(gradv(i), Vector<Dim>(1));
    if (divv < 0.0)
      a_pg(i) = c * rh(i) * pow2(spacings(rh).comp(0)(i)) * divv;
    else
      a_pg(i) = 0.0;
  }

Not only is the compiler much more happy with the above, compile-time also
benefits.  Caveats are that ref<> objects may not occour with scalars -
i.e. just writing 2*ref<>() does not work.  You can work around this by
creating IndexFunction Arrays for ref<>(), but that seemed ugly, too,
as you need to specify domains et al.

Hope someone may find this useful, like I did.

Richard.


template <class Tag, class T>
struct FnSave
{
  inline T
  operator()(const T &a) const
  {
    val = a;
    return a;
  }
  static T val;
};
template <class Tag, class T>
T FnSave<Tag, T>::val;

template<class Tag, int D1,class T1,class E1>
inline typename MakeReturn<UnaryNode<FnSave<Tag, T1>,
  typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t> >::Expression_t
save(const Array<D1,T1,E1> & l)
{
  typedef UnaryNode<FnSave<Tag, T1>,
    typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t> Tree_t;
  return MakeReturn<Tree_t>::make(Tree_t(
    CreateLeaf<Array<D1,T1,E1> >::make(l)));
}

template<class Tag, class M1,class T1,class E1>
inline typename MakeReturn<UnaryNode<FnSave<Tag, T1>,
  typename CreateLeaf<Field<M1,T1,E1> >::Leaf_t> >::Expression_t
save(const Field<M1,T1,E1> & l)
{
  typedef UnaryNode<FnSave<Tag, T1>,
    typename CreateLeaf<Field<M1,T1,E1> >::Leaf_t> Tree_t;
  return MakeReturn<Tree_t>::make(Tree_t(
    CreateLeaf<Field<M1,T1,E1> >::make(l)));
}

template <class Tag, class T>
struct SaveRef
{
  SaveRef() {}
  inline
  operator T() const
  {
    return FnSave<Tag, T>::val;
  }
};

template<class Tag, class T>
inline Expression<Scalar<SaveRef<Tag, T> > >
ref()
{
  return Expression<Scalar<SaveRef<Tag, T> > >(SaveRef<Tag, T>());
}


From rkrylov at mail.ru  Thu Jun 24 13:00:49 2004
From: rkrylov at mail.ru (Roman Krylov)
Date: Thu, 24 Jun 2004 17:00:49 +0400
Subject: Geometries
Message-ID: <40DAD081.1020807@mail.ru>

Hi.
I've downloaded src tree from cvs and found that
<pooma_root>/src/Geometry is empty.
I think it should contain DiscreteGeometry.h and something else.
Anyone knows where can I get it?
Thanks.
    Roman.


From rguenth at tat.physik.uni-tuebingen.de  Thu Jun 24 13:04:41 2004
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 24 Jun 2004 15:04:41 +0200 (CEST)
Subject: [pooma-dev] Geometries
In-Reply-To: <40DAD081.1020807@mail.ru>
References: <40DAD081.1020807@mail.ru>
Message-ID: <Pine.LNX.4.53.0406241502070.2199@bellatrix.tat.physik.uni-tuebingen.de>

On Thu, 24 Jun 2004, Roman Krylov wrote:

> Hi.
> I've downloaded src tree from cvs and found that
> <pooma_root>/src/Geometry is empty.
> I think it should contain DiscreteGeometry.h and something else.
> Anyone knows where can I get it?

Geometry/ is no longer with the new Field representation.  For equivalent
stuff look into Field/Mesh/.  Note that Particle-Field interaction does
not work in CVS due to lack of conversion to Field r2 in these area.  Same
happened (not) for some of the Field examples/benchmarks.

If you update with 'cvs update -P' you get empty directories automatically
removed by CVS, so they don't distress you ;)

Hope this helps,
Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/


From rkrylov at mail.ru  Tue Jun 29 14:35:42 2004
From: rkrylov at mail.ru (Roman Krylov)
Date: Tue, 29 Jun 2004 18:35:42 +0400
Subject: ?
Message-ID: <40E17E3E.5000408@mail.ru>

Hi!
I had some questions when I read pooma tutorials. Now as this mailing 
list do exist I'll ask one of them.

http://www.zib.de/benger/pooma/tut-01.html#laplace

> Laplace's equation in two dimensions is:
> /d^2 V/dx^2 + d^2 V/dy^2 = 0 /
>
> where /V/ is, for example, the electric potential in a flat metal sheet.

    How a flat metal(perfect conductor as I suppose) sheet could have a 
_potential distribution_? It has only the charge distribution,
but the electric potential is constant on the conducting surface in 
(quasi)static case.

Cheers,
    Roman.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20040629/38b7f118/attachment.html>

From oldham at codesourcery.com  Tue Jun 29 15:02:49 2004
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Tue, 29 Jun 2004 08:02:49 -0700
Subject: [pooma-dev] ?
In-Reply-To: <40E17E3E.5000408@mail.ru>
References: <40E17E3E.5000408@mail.ru>
Message-ID: <40E18499.9040608@codesourcery.com>

Roman Krylov wrote:

> Hi!
> I had some questions when I read pooma tutorials. Now as this mailing 
> list do exist I'll ask one of them.
>
> http://www.zib.de/benger/pooma/tut-01.html#laplace
>
>> Laplace's equation in two dimensions is:
>> /d^2 V/dx^2 + d^2 V/dy^2 = 0 /
>>
>> where /V/ is, for example, the electric potential in a flat metal sheet.
>
>     How a flat metal(perfect conductor as I suppose) sheet could have 
> a _potential distribution_? It has only the charge distribution,
> but the electric potential is constant on the conducting surface in 
> (quasi)static case.
>
> Cheers,
>     Roman.

Would this text be more acceptable:
"... where V is, for example, the electric potential of a charge-free 
flat metal sheet"?

-- 
Jeffrey D. Oldham
oldham at codesourcery.com




From rkrylov at mail.ru  Tue Jun 29 15:28:04 2004
From: rkrylov at mail.ru (Roman Krylov)
Date: Tue, 29 Jun 2004 19:28:04 +0400
Subject: [pooma-dev] ?
In-Reply-To: <40E18499.9040608@codesourcery.com>
References: <40E17E3E.5000408@mail.ru> <40E18499.9040608@codesourcery.com>
Message-ID: <40E18A84.9090602@mail.ru>

I'm sorry, I merely copied/pasted it from  
http://www.zib.de/benger/pooma/tut-01.html#laplace
So,... is it proposal to change that  tutorial?
But the question persists:
     how a metal sheet could have non-constant(spatially) electric 
potential distribution whereas it should be constant V=const ?
Cheers
    Roman.

>
> Would this text be more acceptable:
> "... where V is, for example, the electric potential of a charge-free 
> flat metal sheet"?
>



From oldham at codesourcery.com  Tue Jun 29 15:48:13 2004
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Tue, 29 Jun 2004 08:48:13 -0700
Subject: [pooma-dev] ?
In-Reply-To: <40E18A84.9090602@mail.ru>
References: <40E17E3E.5000408@mail.ru> <40E18499.9040608@codesourcery.com> <40E18A84.9090602@mail.ru>
Message-ID: <40E18F3D.3090604@codesourcery.com>

Roman Krylov wrote:

> I'm sorry, I merely copied/pasted it from  
> http://www.zib.de/benger/pooma/tut-01.html#laplace
> So,... is it proposal to change that  tutorial?
> But the question persists:
>     how a metal sheet could have non-constant(spatially) electric 
> potential distribution whereas it should be constant V=const ?
> Cheers
>    Roman.

First, I apologize for my slowness in understanding the physics issues.  
I have more of a computer science than a physics background.

The purpose of tutorial 1 is to introduce using POOMA to solve Laplace's 
Equation.  The particular application of Laplace's Equation is not 
important for this tutorial.  It is just added to motivate the 
tutorial.  All the equations, iterative solutions, and programs stand 
independent of the motivation.

The tutorial begins with Laplace's Equation for a charge-free region of 
space.  (Compare with 
http://hyperphysics.phy-astr.gsu.edu/hbase/electric/laplace.html .)   By 
the end of the first section, the tutorial introduces a charge 
distribution \Beta, modifying the iterative equation.  Then the tutorial 
demonstrates how to use POOMA to write a program simulating the 
iterative equation.

With a non-zero charge distribution /Beta, the resulting V should not be 
constant.  With a zero charge distribution, V should be constant.  
Running the POOMA program should reveal this regardless of whether one 
could prove this mathematically without the use of a program.

Does this answer your query?

>>
>> Would this text be more acceptable:
>> "... where V is, for example, the electric potential of a charge-free 
>> flat metal sheet"?
>
-- 
Jeffrey D. Oldham
oldham at codesourcery.com