From mark at codesourcery.com  Mon Apr  2 16:46:51 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Mon, 02 Apr 2001 09:46:51 -0700
Subject: [pooma-dev] goofy Domain constructors
In-Reply-To: <3AC53EDF.B0D3979C@cacr.caltech.edu>
References: <3AC53EDF.B0D3979C@cacr.caltech.edu>
Message-ID: <20010402094651A.mitchell@codesourcery.com>


    Julian> members from a templated base class.  These members are
    Julian> not visible under the C++ lookup rules, so you have to
    Julian> qualify these with the "this" pointer (or with the base
    Julian> class name for static members).

I don't understand this.  The funny lookup rules only apply to types;
data members should work fine.  For example, this is legal:

  template <typename T>
  struct A { int i; };

  template <typename T>
  struct B : public A<T> { 
    void f() { i = 3; }
  };

However, your changes still aren't a bad idea; the standard says that
if there was a global `i', the code in B would use that *rather* than
the base class version.

A meta-point here as well: it's good to make the code cleaner, but
working with HP's compiler is not *in and of itself* a project goal.
If we get better code that way, or if you get other work done, that's
good; otherwise, it's probably not worth it. 

It's horrible to be pretending to be management; you have to actually
say things like that.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From scotth at proximation.com  Mon Apr  2 17:07:02 2001
From: scotth at proximation.com (Scott Haney)
Date: Mon, 2 Apr 2001 11:07:02 -0600
Subject: [pooma-dev] goofy Domain constructors
In-Reply-To: <20010402094651A.mitchell@codesourcery.com>
Message-ID: <mailman.8.1331172040.20475.pooma-dev@codesourcery.com>


On Monday, April 2, 2001, at 10:46 AM, Mark Mitchell wrote:

>     Julian> members from a templated base class.  These members are
>     Julian> not visible under the C++ lookup rules, so you have to
>     Julian> qualify these with the "this" pointer (or with the base
>     Julian> class name for static members).
>
> I don't understand this.  The funny lookup rules only apply to types;
> data members should work fine.  For example, this is legal:
>
>   template <typename T>
>   struct A { int i; };
>
>   template <typename T>
>   struct B : public A<T> {
>     void f() { i = 3; }
>   };
>
> However, your changes still aren't a bad idea; the standard says that
> if there was a global `i', the code in B would use that *rather* than
> the base class version.

I think these changes are a bad idea.

First, as Mark points out, data members should be visible. Moreover, we 
add the suffix _m to data members (e.g., foo_m) so there should never be 
a name collision with a global. I don't not want to see a bunch of 
this->that show up because of an HP compiler bug.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1100 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010402/ae690da9/attachment.bin>

From mark at codesourcery.com  Mon Apr  2 17:18:17 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Mon, 02 Apr 2001 10:18:17 -0700
Subject: [pooma-dev] goofy Domain constructors
In-Reply-To: <200104021713.KAA10428@gandalf.codesourcery.com>
References: <20010402094651A.mitchell@codesourcery.com>
	<200104021713.KAA10428@gandalf.codesourcery.com>
Message-ID: <20010402101817K.mitchell@codesourcery.com>

>>>>> "Scott" == Scott Haney <scotth at proximation.com> writes:

    >> However, your changes still aren't a bad idea; the standard
    >> says that if there was a global `i', the code in B would use
    >> that *rather* than the base class version.

    Scott> I think these changes are a bad idea.

    Scott> First, as Mark points out, data members should be
    Scott> visible. Moreover, we add the suffix _m to data members

Given this naming convention, I agree with Scott.

    Scott> with a global. I don't not want to see a bunch of
    this-> that show up because of an HP compiler bug.

Right.  

Note that I'd feel differently if Blanca used aCC -- but as far as I
know they don't.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From drnuke at lanl.gov  Mon Apr  2 21:59:15 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Mon, 2 Apr 2001 15:59:15 -0600
Subject: vector access in particles
Message-ID: <NDBBIAJIJKLEAIAEGGACIEOJCFAA.drnuke@lanl.gov>

how does one access the x-axis dimension in a particle attribute direction?

1.  Neutrons.Direction( 0 )( ipart )

 -or-

2.  Neutrons.Direction( ipart ) ( 0 );

where ipart is the particle of interest and 0 denotes the x-axis member

-steve



From cummings at linkline.com  Mon Apr  2 22:55:18 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 2 Apr 2001 15:55:18 -0700
Subject: [pooma-dev] goofy Domain constructors
In-Reply-To: <20010402101817K.mitchell@codesourcery.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGMEGOCBAA.cummings@linkline.com>

OK, guys.  Thanks for the comments.  I agree
that adding "this->" all over the place is a 
nuisance and is unwarranted in this case.  As
Scott points out, our coding style eliminates 
concerns of name collisions.  I can strip this
change out of my changes to the Domain sources.
Beyond this, is the change from enums to static
typed data OK?

The HP compiler only marks these things as 
"future" errors, so they do not inhibit the
compilation.  The messages refer to a specific 
section of the ANSI standard, so I will have a 
look at that.  If HP is indeed wrong in their
interpretation of the standard, I should let 
them know.  Meanwhile, I think there is a flag
to turn off their Koenig name lookup, so that
the flood of "future" errors will go away.

BTW, the HP compiler did point out some minor 
bugs that I fixed yesterday.  And I think the 
elimination of enums and the associated casting
of types cleans things up a bit.  So it hasn't 
been a completely worthless exercise attempting 
to run Pooma II through their compiler.  I hope
aCC will eventually be able to handle Pooma, so
we can use it on our parallel machines here.

-- Julian C.


-----Original Message-----
From: Mark Mitchell [mailto:mitchell at codesourcery.com]On Behalf Of Mark
Mitchell
Sent: Monday, April 02, 2001 10:18 AM
To: scotth at proximation.com
Cc: cummings at cacr.caltech.edu; pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] goofy Domain constructors


>>>>> "Scott" == Scott Haney <scotth at proximation.com> writes:

    >> However, your changes still aren't a bad idea; the standard
    >> says that if there was a global `i', the code in B would use
    >> that *rather* than the base class version.

    Scott> I think these changes are a bad idea.

    Scott> First, as Mark points out, data members should be
    Scott> visible. Moreover, we add the suffix _m to data members

Given this naming convention, I agree with Scott.

    Scott> with a global. I don't not want to see a bunch of
    this-> that show up because of an HP compiler bug.

Right.  

Note that I'd feel differently if Blanca used aCC -- but as far as I
know they don't.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com



From cummings at linkline.com  Mon Apr  2 23:15:31 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 2 Apr 2001 16:15:31 -0700
Subject: [pooma-dev] vector access in particles
In-Reply-To: <NDBBIAJIJKLEAIAEGGACIEOJCFAA.drnuke@lanl.gov>
Message-ID: <NEBBLCJDELMDOJLGLNJGGEGPCBAA.cummings@linkline.com>

Use Method 2 below.  There is a way to
access the x component of a Vector
attribute for all particles, using the 
comp() method of Arrays:

Neutrons.Direction.comp(0)

The result of this component access is
an Array of scalar data, and you can index
elements of that Array just like any other.
So you could do something like

Neutrons.Direction.comp(0)(ipart)

to get element ipart.  However, you
probably want to save the result of 
the component access as a temporary 
Array component view, since there is
a cost associated with creating these.
There is a fairly gnarly syntax used
to get the type of this temporary Array
component view:

ComponentView<Loc<1>,Array_t>::Type_t

where Array_t is the type of the original
DynamicArray that you are viewing a
component of.  The Loc<1> is used to store
the single component index used to reference
a component of a Vector attribute.

My advice is, don't go through the work of
creating a component view unless you need to
pass the component as an Array to some function.
Just access single elements of the Vector 
attribute, then access the component you want:

Neutrons.Direction(ipart)(0)


-- Julian C.


-----Original Message-----
From: Steve Nolen [mailto:drnuke at lanl.gov]
Sent: Monday, April 02, 2001 2:59 PM
To: Pooma
Subject: [pooma-dev] vector access in particles


how does one access the x-axis dimension in a particle attribute direction?

1.  Neutrons.Direction( 0 )( ipart )

 -or-

2.  Neutrons.Direction( ipart ) ( 0 );

where ipart is the particle of interest and 0 denotes the x-axis member

-steve




From drnuke at lanl.gov  Tue Apr  3 16:40:56 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Tue, 3 Apr 2001 10:40:56 -0600
Subject: an attempt at your particle BC
In-Reply-To: <NEBBLCJDELMDOJLGLNJGEEHBCBAA.cummings@cacr.caltech.edu>
Message-ID: <NDBBIAJIJKLEAIAEGGACCEOLCFAA.drnuke@lanl.gov>

it would be nice if one of the destroy or sync functions accepted a list or
vector of integers denoting which particles to destroy.  the conversion to
an IndirectionList (or even a DynamicArray for this matter) is just a little
too much pooma for the casual user.

> -----Original Message-----
> From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
> Sent: Monday, April 02, 2001 6:26 PM
> To: Steve Nolen
> Subject: RE: an attempt at your particle BC
>
<snip>
>
> To assign a particle to the destroy list, use the
> deferredDestroy() method.  The first argument is a
> Domain describing the particle(s) to be added to
> the list, and the second is a local patch id number
> (if this is a local particle destroy).  For a single
> particle, the Domain will be an int or a Loc<1>
> containing the local index number of the particle,
> and the patchID says which local patch has this
> particle.  Particles on the destroy list are not
> destroyed until you call performDestroy() (or it gets
> called by the sync() method).
>
> If you are going to do this repeatedly, you might want
> to create your own temporary destroy list.  Create a
> DynamicArray of ints to store the indices of local
> particles to be destroyed on a particular local patch.
> Call the create() method to add a new element for each
> particle to be destroyed.  Then assign the local index
> number of the particle to that element in your destroy
> list.  Once your destroy list is complete, you must
> convert it into an IndirectionList<int>.  The destroy
> functions only accept domain types as descriptors of
> the set of particles to be destroyed, so you must use
> the IndirectionList here.  IndirectionList has a
> constructor which takes a 1D Array as its argument.
> Now you can call either deferredDestroy (to destroy
> later on) or destroy (to do it now) and pass it the
> IndirectionList and the local patchID.
>
> DynamicArray<int> kill;
> kill.create(1);
> kill(0) = i;  // add particle i to list
> IndirectionList<int> klist(kill);
> Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
>
>



From JimC at proximation.com  Tue Apr  3 16:54:19 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 3 Apr 2001 09:54:19 -0700 
Subject: [pooma-dev] RE: an attempt at your particle BC
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BB6@proxim-sf001.santafe.proximation.com>

Actually, I think destroy will take quite a variety of domain
representations. For example, it will take a pair of iterators into a list:

(from Engine/tests/dynamic_test2.cpp)

    int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19};
    
    C.destroy(kill_array, kill_array+8, BackFill());
    
It will also take our regular domain objects. IndirectionList is used
internally (for its shallow copy semantics, I think), but I do not recommend
that users use it - it really wasn't designed to be an all-purpose
user-friendly class. (It is easy to get bitten by its shallow copy
semantics, IMHO). I guess I'd tend to use a std::vector for these things,
but I'd have to see the real application to understand if that is correct.

Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

 -----Original Message-----
From: 	Steve Nolen [mailto:drnuke at lanl.gov] 
Sent:	Tuesday, April 03, 2001 10:41 AM
To:	cummings at cacr.caltech.edu
Cc:	Pooma
Subject:	[pooma-dev] RE: an attempt at your particle BC

it would be nice if one of the destroy or sync functions accepted a list or
vector of integers denoting which particles to destroy.  the conversion to
an IndirectionList (or even a DynamicArray for this matter) is just a little
too much pooma for the casual user.

> -----Original Message-----
> From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
> Sent: Monday, April 02, 2001 6:26 PM
> To: Steve Nolen
> Subject: RE: an attempt at your particle BC
>
<snip>
>
> To assign a particle to the destroy list, use the
> deferredDestroy() method.  The first argument is a
> Domain describing the particle(s) to be added to
> the list, and the second is a local patch id number
> (if this is a local particle destroy).  For a single
> particle, the Domain will be an int or a Loc<1>
> containing the local index number of the particle,
> and the patchID says which local patch has this
> particle.  Particles on the destroy list are not
> destroyed until you call performDestroy() (or it gets
> called by the sync() method).
>
> If you are going to do this repeatedly, you might want
> to create your own temporary destroy list.  Create a
> DynamicArray of ints to store the indices of local
> particles to be destroyed on a particular local patch.
> Call the create() method to add a new element for each
> particle to be destroyed.  Then assign the local index
> number of the particle to that element in your destroy
> list.  Once your destroy list is complete, you must
> convert it into an IndirectionList<int>.  The destroy
> functions only accept domain types as descriptors of
> the set of particles to be destroyed, so you must use
> the IndirectionList here.  IndirectionList has a
> constructor which takes a 1D Array as its argument.
> Now you can call either deferredDestroy (to destroy
> later on) or destroy (to do it now) and pass it the
> IndirectionList and the local patchID.
>
> DynamicArray<int> kill;
> kill.create(1);
> kill(0) = i;  // add particle i to list
> IndirectionList<int> klist(kill);
> Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010403/dfdb7b76/attachment.html>

From drnuke at lanl.gov  Tue Apr  3 17:04:36 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Tue, 3 Apr 2001 11:04:36 -0600
Subject: [pooma-dev] RE: an attempt at your particle BC
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BB6@proxim-sf001.santafe.proximation.com>
Message-ID: <NDBBIAJIJKLEAIAEGGACKEOLCFAA.drnuke@lanl.gov>

RE: [pooma-dev] RE: an attempt at your particle BCi tried sending a
vector<int> object but it (le compiler) complained about not having
"domain[0].size()".
  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Tuesday, April 03, 2001 10:54 AM
  To: 'Steve Nolen'; 'cummings at cacr.caltech.edu'
  Cc: 'Pooma'
  Subject: RE: [pooma-dev] RE: an attempt at your particle BC


  Actually, I think destroy will take quite a variety of domain
representations. For example, it will take a pair of iterators into a list:

  (from Engine/tests/dynamic_test2.cpp)

      int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19};

      C.destroy(kill_array, kill_array+8, BackFill());

  It will also take our regular domain objects. IndirectionList is used
internally (for its shallow copy semantics, I think), but I do not recommend
that users use it - it really wasn't designed to be an all-purpose
user-friendly class. (It is easy to get bitten by its shallow copy
semantics, IMHO). I guess I'd tend to use a std::vector for these things,
but I'd have to see the real application to understand if that is correct.

  Jim

  ---------------------------------------------------
  James A. Crotinger
  Software Research Scientist
  Proximation, LLC

   -----Original Message-----
  From:   Steve Nolen [mailto:drnuke at lanl.gov]
  Sent:   Tuesday, April 03, 2001 10:41 AM
  To:     cummings at cacr.caltech.edu
  Cc:     Pooma
  Subject:        [pooma-dev] RE: an attempt at your particle BC

  it would be nice if one of the destroy or sync functions accepted a list
or
  vector of integers denoting which particles to destroy.  the conversion to
  an IndirectionList (or even a DynamicArray for this matter) is just a
little
  too much pooma for the casual user.

  > -----Original Message-----
  > From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
  > Sent: Monday, April 02, 2001 6:26 PM
  > To: Steve Nolen
  > Subject: RE: an attempt at your particle BC
  >
  <snip>
  >
  > To assign a particle to the destroy list, use the
  > deferredDestroy() method.  The first argument is a
  > Domain describing the particle(s) to be added to
  > the list, and the second is a local patch id number
  > (if this is a local particle destroy).  For a single
  > particle, the Domain will be an int or a Loc<1>
  > containing the local index number of the particle,
  > and the patchID says which local patch has this
  > particle.  Particles on the destroy list are not
  > destroyed until you call performDestroy() (or it gets
  > called by the sync() method).
  >
  > If you are going to do this repeatedly, you might want
  > to create your own temporary destroy list.  Create a
  > DynamicArray of ints to store the indices of local
  > particles to be destroyed on a particular local patch.
  > Call the create() method to add a new element for each
  > particle to be destroyed.  Then assign the local index
  > number of the particle to that element in your destroy
  > list.  Once your destroy list is complete, you must
  > convert it into an IndirectionList<int>.  The destroy
  > functions only accept domain types as descriptors of
  > the set of particles to be destroyed, so you must use
  > the IndirectionList here.  IndirectionList has a
  > constructor which takes a 1D Array as its argument.
  > Now you can call either deferredDestroy (to destroy
  > later on) or destroy (to do it now) and pass it the
  > IndirectionList and the local patchID.
  >
  > DynamicArray<int> kill;
  > kill.create(1);
  > kill(0) = i;  // add particle i to list
  > IndirectionList<int> klist(kill);
  > Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
  >
  >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010403/403a9583/attachment.html>

From JimC at proximation.com  Tue Apr  3 17:13:02 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 3 Apr 2001 10:13:02 -0700 
Subject: [pooma-dev] RE: an attempt at your particle BC
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BB7@proxim-sf001.santafe.proximation.com>

Don't send vector<int> - it will think you're sending a "domain", which has
a size() method.
Instead, send a.begin() and a.end() where a is your vector<int>.
 
            Jim
 
 
---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC
 
-----Original Message-----
From: Steve Nolen [mailto:drnuke at lanl.gov]
Sent: Tuesday, April 03, 2001 11:05 AM
To: James Crotinger; cummings at cacr.caltech.edu
Cc: 'Pooma'
Subject: RE: [pooma-dev] RE: an attempt at your particle BC
 
i tried sending a vector<int> object but it (le compiler) complained about
not having "domain[0].size()".
-----Original Message-----
From: James Crotinger [mailto:JimC at proximation.com]
Sent: Tuesday, April 03, 2001 10:54 AM
To: 'Steve Nolen'; 'cummings at cacr.caltech.edu'
Cc: 'Pooma'
Subject: RE: [pooma-dev] RE: an attempt at your particle BC
Actually, I think destroy will take quite a variety of domain
representations. For example, it will take a pair of iterators into a list:
(from Engine/tests/dynamic_test2.cpp) 
    int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19}; 
    
    C.destroy(kill_array, kill_array+8, BackFill()); 
    
It will also take our regular domain objects. IndirectionList is used
internally (for its shallow copy semantics, I think), but I do not recommend
that users use it - it really wasn't designed to be an all-purpose
user-friendly class. (It is easy to get bitten by its shallow copy
semantics, IMHO). I guess I'd tend to use a std::vector for these things,
but I'd have to see the real application to understand if that is correct.
Jim 
--------------------------------------------------- 
James A. Crotinger 
Software Research Scientist 
Proximation, LLC 
 -----Original Message----- 
From:   Steve Nolen [ mailto:drnuke at lanl.gov <mailto:drnuke at lanl.gov> ] 
Sent:   Tuesday, April 03, 2001 10:41 AM 
To:     cummings at cacr.caltech.edu 
Cc:     Pooma 
Subject:        [pooma-dev] RE: an attempt at your particle BC 
it would be nice if one of the destroy or sync functions accepted a list or 
vector of integers denoting which particles to destroy.  the conversion to 
an IndirectionList (or even a DynamicArray for this matter) is just a little

too much pooma for the casual user. 
> -----Original Message----- 
> From: Julian C. Cummings [ mailto:cummings at cacr.caltech.edu
<mailto:cummings at cacr.caltech.edu> ] 
> Sent: Monday, April 02, 2001 6:26 PM 
> To: Steve Nolen 
> Subject: RE: an attempt at your particle BC 
> 
<snip> 
> 
> To assign a particle to the destroy list, use the 
> deferredDestroy() method.  The first argument is a 
> Domain describing the particle(s) to be added to 
> the list, and the second is a local patch id number 
> (if this is a local particle destroy).  For a single 
> particle, the Domain will be an int or a Loc<1> 
> containing the local index number of the particle, 
> and the patchID says which local patch has this 
> particle.  Particles on the destroy list are not 
> destroyed until you call performDestroy() (or it gets 
> called by the sync() method). 
> 
> If you are going to do this repeatedly, you might want 
> to create your own temporary destroy list.  Create a 
> DynamicArray of ints to store the indices of local 
> particles to be destroyed on a particular local patch. 
> Call the create() method to add a new element for each 
> particle to be destroyed.  Then assign the local index 
> number of the particle to that element in your destroy 
> list.  Once your destroy list is complete, you must 
> convert it into an IndirectionList<int>.  The destroy 
> functions only accept domain types as descriptors of 
> the set of particles to be destroyed, so you must use 
> the IndirectionList here.  IndirectionList has a 
> constructor which takes a 1D Array as its argument. 
> Now you can call either deferredDestroy (to destroy 
> later on) or destroy (to do it now) and pass it the 
> IndirectionList and the local patchID. 
> 
> DynamicArray<int> kill; 
> kill.create(1); 
> kill(0) = i;  // add particle i to list 
> IndirectionList<int> klist(kill); 
> Neutrons.destroy(klist,patch);  // destroy particles in klist on patch 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010403/1de65ae8/attachment.html>

From cummings at cacr.caltech.edu  Tue Apr  3 17:26:42 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Tue, 03 Apr 2001 10:26:42 -0700
Subject: [pooma-dev] RE: an attempt at your particle BC
References: <F871BB04B0EA224A821A5274C31DF3152BB7@proxim-sf001.santafe.proximation.com>
Message-ID: <3ACA07D2.E13DFCC1@cacr.caltech.edu>

Gentlemen:

There's a problem here.  The interface that Jim cited,
describing a destroy list with a pair of iterators into
some list of indices, exists for DynamicEngine, but
*not* for DynamicArray (or Particles).  We need to
add this before Steve would be able to use this method.

I can take a crack at this late in the day today, unless
someone else has time to deal with it sooner.

-- Julian C.


James Crotinger wrote:

> Don't send vector<int> - it will think you're sending a "domain", which has a
> size() method.
> Instead, send a.begin() and a.end() where a is your vector<int>.
>
> Jim
>
> ---------------------------------------------------
>
> James A. Crotinger
>
> Software Research Scientist
>
> Proximation, LLC
>
> -----Original Message-----
> From: Steve Nolen [mailto:drnuke at lanl.gov]
> Sent: Tuesday, April 03, 2001 11:05 AM
> To: James Crotinger; cummings at cacr.caltech.edu
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> i tried sending a vector<int> object but it (le compiler) complained about not
> having "domain[0].size()".
> -----Original Message-----
>
>
> From: James Crotinger [mailto:JimC at proximation.com]
> Sent: Tuesday, April 03, 2001 10:54 AM
> To: 'Steve Nolen'; 'cummings at cacr.caltech.edu'
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> Actually, I think destroy will take quite a variety of domain representations.
> For example, it will take a pair of iterators into a list:
>
> (from Engine/tests/dynamic_test2.cpp)
>
>     int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19};
>
>     C.destroy(kill_array, kill_array+8, BackFill());
>
> It will also take our regular domain objects. IndirectionList is used
> internally (for its shallow copy semantics, I think), but I do not recommend
> that users use it - it really wasn't designed to be an all-purpose
> user-friendly class. (It is easy to get bitten by its shallow copy semantics,
> IMHO). I guess I'd tend to use a std::vector for these things, but I'd have to
> see the real application to understand if that is correct.
>
> Jim
>
> ---------------------------------------------------
> James A. Crotinger
> Software Research Scientist
> Proximation, LLC
>
> -----Original Message-----
> From:   Steve Nolen [mailto:drnuke at lanl.gov]
> Sent:   Tuesday, April 03, 2001 10:41 AM
> To:     cummings at cacr.caltech.edu
> Cc:     Pooma
> Subject:        [pooma-dev] RE: an attempt at your particle BC
>
> it would be nice if one of the destroy or sync functions accepted a list or
> vector of integers denoting which particles to destroy.  the conversion to
> an IndirectionList (or even a DynamicArray for this matter) is just a little
> too much pooma for the casual user.
>
> > -----Original Message-----
> > From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
> > Sent: Monday, April 02, 2001 6:26 PM
> > To: Steve Nolen
> > Subject: RE: an attempt at your particle BC
> >
> <snip>
> >
> > To assign a particle to the destroy list, use the
> > deferredDestroy() method.  The first argument is a
> > Domain describing the particle(s) to be added to
> > the list, and the second is a local patch id number
> > (if this is a local particle destroy).  For a single
> > particle, the Domain will be an int or a Loc<1>
> > containing the local index number of the particle,
> > and the patchID says which local patch has this
> > particle.  Particles on the destroy list are not
> > destroyed until you call performDestroy() (or it gets
> > called by the sync() method).
> >
> > If you are going to do this repeatedly, you might want
> > to create your own temporary destroy list.  Create a
> > DynamicArray of ints to store the indices of local
> > particles to be destroyed on a particular local patch.
> > Call the create() method to add a new element for each
> > particle to be destroyed.  Then assign the local index
> > number of the particle to that element in your destroy
> > list.  Once your destroy list is complete, you must
> > convert it into an IndirectionList<int>.  The destroy
> > functions only accept domain types as descriptors of
> > the set of particles to be destroyed, so you must use
> > the IndirectionList here.  IndirectionList has a
> > constructor which takes a 1D Array as its argument.
> > Now you can call either deferredDestroy (to destroy
> > later on) or destroy (to do it now) and pass it the
> > IndirectionList and the local patchID.
> >
> > DynamicArray<int> kill;
> > kill.create(1);
> > kill(0) = i;  // add particle i to list
> > IndirectionList<int> klist(kill);
> > Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
> >
> >
>
--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From JimC at proximation.com  Tue Apr  3 17:30:20 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 3 Apr 2001 10:30:20 -0700 
Subject: [pooma-dev] RE: an attempt at your particle BC
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BB8@proxim-sf001.santafe.proximation.com>

Oops - sorry about that Steve. Julian's right. Don't know how that feature
slipped through the cracks. I put it in DynamicEngine to make these sorts of
things easier and it never made it to DynamicArray. I'm in the middle of
debugging a socket problem. If I can get that sorted out soon, I'll take a
crack at this.

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

 -----Original Message-----
From: 	Julian Cummings [mailto:cummings at cacr.caltech.edu] 
Sent:	Tuesday, April 03, 2001 11:27 AM
To:	James Crotinger
Cc:	'Steve Nolen'; 'Pooma'
Subject:	Re: [pooma-dev] RE: an attempt at your particle BC

Gentlemen:

There's a problem here.  The interface that Jim cited,
describing a destroy list with a pair of iterators into
some list of indices, exists for DynamicEngine, but
*not* for DynamicArray (or Particles).  We need to
add this before Steve would be able to use this method.

I can take a crack at this late in the day today, unless
someone else has time to deal with it sooner.

-- Julian C.


James Crotinger wrote:

> Don't send vector<int> - it will think you're sending a "domain", which
has a
> size() method.
> Instead, send a.begin() and a.end() where a is your vector<int>.
>
> Jim
>
> ---------------------------------------------------
>
> James A. Crotinger
>
> Software Research Scientist
>
> Proximation, LLC
>
> -----Original Message-----
> From: Steve Nolen [mailto:drnuke at lanl.gov]
> Sent: Tuesday, April 03, 2001 11:05 AM
> To: James Crotinger; cummings at cacr.caltech.edu
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> i tried sending a vector<int> object but it (le compiler) complained about
not
> having "domain[0].size()".
> -----Original Message-----
>
>
> From: James Crotinger [mailto:JimC at proximation.com]
> Sent: Tuesday, April 03, 2001 10:54 AM
> To: 'Steve Nolen'; 'cummings at cacr.caltech.edu'
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> Actually, I think destroy will take quite a variety of domain
representations.
> For example, it will take a pair of iterators into a list:
>
> (from Engine/tests/dynamic_test2.cpp)
>
>     int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19};
>
>     C.destroy(kill_array, kill_array+8, BackFill());
>
> It will also take our regular domain objects. IndirectionList is used
> internally (for its shallow copy semantics, I think), but I do not
recommend
> that users use it - it really wasn't designed to be an all-purpose
> user-friendly class. (It is easy to get bitten by its shallow copy
semantics,
> IMHO). I guess I'd tend to use a std::vector for these things, but I'd
have to
> see the real application to understand if that is correct.
>
> Jim
>
> ---------------------------------------------------
> James A. Crotinger
> Software Research Scientist
> Proximation, LLC
>
> -----Original Message-----
> From:   Steve Nolen [mailto:drnuke at lanl.gov]
> Sent:   Tuesday, April 03, 2001 10:41 AM
> To:     cummings at cacr.caltech.edu
> Cc:     Pooma
> Subject:        [pooma-dev] RE: an attempt at your particle BC
>
> it would be nice if one of the destroy or sync functions accepted a list
or
> vector of integers denoting which particles to destroy.  the conversion to
> an IndirectionList (or even a DynamicArray for this matter) is just a
little
> too much pooma for the casual user.
>
> > -----Original Message-----
> > From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
> > Sent: Monday, April 02, 2001 6:26 PM
> > To: Steve Nolen
> > Subject: RE: an attempt at your particle BC
> >
> <snip>
> >
> > To assign a particle to the destroy list, use the
> > deferredDestroy() method.  The first argument is a
> > Domain describing the particle(s) to be added to
> > the list, and the second is a local patch id number
> > (if this is a local particle destroy).  For a single
> > particle, the Domain will be an int or a Loc<1>
> > containing the local index number of the particle,
> > and the patchID says which local patch has this
> > particle.  Particles on the destroy list are not
> > destroyed until you call performDestroy() (or it gets
> > called by the sync() method).
> >
> > If you are going to do this repeatedly, you might want
> > to create your own temporary destroy list.  Create a
> > DynamicArray of ints to store the indices of local
> > particles to be destroyed on a particular local patch.
> > Call the create() method to add a new element for each
> > particle to be destroyed.  Then assign the local index
> > number of the particle to that element in your destroy
> > list.  Once your destroy list is complete, you must
> > convert it into an IndirectionList<int>.  The destroy
> > functions only accept domain types as descriptors of
> > the set of particles to be destroyed, so you must use
> > the IndirectionList here.  IndirectionList has a
> > constructor which takes a 1D Array as its argument.
> > Now you can call either deferredDestroy (to destroy
> > later on) or destroy (to do it now) and pass it the
> > IndirectionList and the local patchID.
> >
> > DynamicArray<int> kill;
> > kill.create(1);
> > kill(0) = i;  // add particle i to list
> > IndirectionList<int> klist(kill);
> > Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
> >
> >
>
--
Dr. Julian C. Cummings                       E-mail:
cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010403/db16e02f/attachment.html>

From mark at codesourcery.com  Tue Apr  3 19:06:10 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Tue, 03 Apr 2001 12:06:10 -0700
Subject: POOMA Changes from LANL
Message-ID: <20010403120610Z.mitchell@codesourcery.com>


John Hall made a few changes to POOMA after we moved the repository.

I've attached the diffs.  

Scott, would you please review and commit the changes?  Or if you are
too busy, ask Jim to do so?

This is an important task because we want Blanca to start using our
CVS repository, and apparently they need these changes.

John, in future, please send changes to
pooma-dev at pooma.codesourcery.com, and we'll get them processed.

Thanks to all,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index: src/Engine/DataObject.h
===================================================================
RCS file: /usr/local/pooma/repository/r2/src/Engine/DataObject.h,v
retrieving revision 1.29
retrieving revision 1.30
diff -c -p -r1.29 -r1.30
*** DataObject.h	2000/03/07 13:16:50	1.29
--- DataObject.h	2001/03/19 22:22:31	1.30
*************** struct Combine2<int, int, Op, AffinityCo
*** 209,215 ****
  {
    typedef int Type_t;
    inline static
!   Type_t combine(int a,int b,Op ,AffinityCombine )
    {
      return a;
    }
--- 209,215 ----
  {
    typedef int Type_t;
    inline static
!   Type_t combine(int a,int b,AffinityCombine )
    {
      return a;
    }
*************** public:
*** 248,254 ****
  
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
! // $RCSfile: DataObject.h,v $   $Author: swhaney $
! // $Revision: 1.29 $   $Date: 2000/03/07 13:16:50 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
--- 248,254 ----
  
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
! // $RCSfile: DataObject.h,v $   $Author: jxyh $
! // $Revision: 1.30 $   $Date: 2001/03/19 22:22:31 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
Index: src/Evaluator/MultiArgEvaluator.h
===================================================================
RCS file: /usr/local/pooma/repository/r2/src/Evaluator/MultiArgEvaluator.h,v
retrieving revision 1.5
retrieving revision 1.7
diff -c -p -r1.5 -r1.7
*** MultiArgEvaluator.h	2001/03/04 06:46:48	1.5
--- MultiArgEvaluator.h	2001/03/14 05:36:16	1.7
*************** public:
*** 136,142 ****
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   const Function &function,
  	   const Interval<Dim> &domain,
  	   const Kernel &kernel)
    {
--- 136,142 ----
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   Function &function,
  	   const Interval<Dim> &domain,
  	   const Kernel &kernel)
    {
*************** public:
*** 158,164 ****
    template<class A1, class Function, int Dim, class Kernel>
    static void
    createIterate(const A1& a1,
! 		const Function& function,
  		const Interval<Dim> &domain,
  		ScalarCodeInfo &info,
  		const Kernel &)
--- 158,164 ----
    template<class A1, class Function, int Dim, class Kernel>
    static void
    createIterate(const A1& a1,
! 		Function& function,
  		const Interval<Dim> &domain,
  		ScalarCodeInfo &info,
  		const Kernel &)
*************** public:
*** 196,202 ****
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg& multiArg,
! 	   const Function& function,
  	   Interval<Dim> domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
--- 196,202 ----
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg& multiArg,
! 	   Function& function,
  	   Interval<Dim> domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
*************** public:
*** 237,243 ****
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   const Function &function,
  	   const Interval<Dim> &domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
--- 237,243 ----
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   Function &function,
  	   const Interval<Dim> &domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
*************** struct MultiArgEvaluator<RemoteSinglePat
*** 288,294 ****
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   const Function &function,
  	   const Interval<Dim> &domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
--- 288,294 ----
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   Function &function,
  	   const Interval<Dim> &domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
*************** struct MultiArgEvaluator<RemoteMultiPatc
*** 338,344 ****
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   const Function &function,
  	   const Interval<Dim> &domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
--- 338,344 ----
    template<class MultiArg, class Function, int Dim, class Kernel>
    static void
    evaluate(const MultiArg &multiArg,
! 	   Function &function,
  	   const Interval<Dim> &domain,
  	   ScalarCodeInfo &info,
  	   const Kernel &kernel)
*************** struct MultiArgEvaluatorTag<MultiArg3<A1
*** 385,390 ****
--- 385,435 ----
    Evaluator_t;
  };
  
+ template<class A1, class A2, class A3, class A4>
+ struct MultiArgEvaluatorTag<MultiArg4<A1, A2, A3, A4> >
+ {
+   typedef typename EvaluatorTag1<A1>::Evaluator_t Eval1_t;
+   typedef typename EvaluatorTag1<A2>::Evaluator_t Eval2_t;
+   typedef typename EvaluatorTag1<A3>::Evaluator_t Eval3_t;
+   typedef typename EvaluatorTag1<A4>::Evaluator_t Eval4_t;
+   typedef typename EvaluatorCombine<Eval1_t, Eval2_t>::Evaluator_t Eval12_t;
+   typedef typename EvaluatorCombine<Eval3_t, Eval12_t>::Evaluator_t  Eval123_t;
+   typedef typename EvaluatorCombine<Eval4_t, Eval123_t>::Evaluator_t
+   Evaluator_t;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5>
+ struct MultiArgEvaluatorTag<MultiArg5<A1, A2, A3, A4, A5> >
+ {
+   typedef typename EvaluatorTag1<A1>::Evaluator_t Eval1_t;
+   typedef typename EvaluatorTag1<A2>::Evaluator_t Eval2_t;
+   typedef typename EvaluatorTag1<A3>::Evaluator_t Eval3_t;
+   typedef typename EvaluatorTag1<A4>::Evaluator_t Eval4_t;
+   typedef typename EvaluatorTag1<A5>::Evaluator_t Eval5_t;
+   typedef typename EvaluatorCombine<Eval1_t, Eval2_t>::Evaluator_t Eval12_t;
+   typedef typename EvaluatorCombine<Eval3_t, Eval12_t>::Evaluator_t  Eval123_t;
+   typedef typename EvaluatorCombine<Eval4_t, Eval123_t>::Evaluator_t  Eval1234_t;
+   typedef typename EvaluatorCombine<Eval5_t, Eval1234_t>::Evaluator_t
+   Evaluator_t;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6>
+ struct MultiArgEvaluatorTag<MultiArg6<A1, A2, A3, A4, A5, A6> >
+ {
+   typedef typename EvaluatorTag1<A1>::Evaluator_t Eval1_t;
+   typedef typename EvaluatorTag1<A2>::Evaluator_t Eval2_t;
+   typedef typename EvaluatorTag1<A3>::Evaluator_t Eval3_t;
+   typedef typename EvaluatorTag1<A4>::Evaluator_t Eval4_t;
+   typedef typename EvaluatorTag1<A5>::Evaluator_t Eval5_t;
+   typedef typename EvaluatorTag1<A6>::Evaluator_t Eval6_t;
+   typedef typename EvaluatorCombine<Eval1_t, Eval2_t>::Evaluator_t Eval12_t;
+   typedef typename EvaluatorCombine<Eval3_t, Eval12_t>::Evaluator_t  Eval123_t;
+   typedef typename EvaluatorCombine<Eval4_t, Eval123_t>::Evaluator_t  Eval1234_t;
+   typedef typename EvaluatorCombine<Eval5_t, Eval1234_t>::Evaluator_t  Eval12345_t;
+   typedef typename EvaluatorCombine<Eval6_t, Eval12345_t>::Evaluator_t
+   Evaluator_t;
+ };
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7>
  struct MultiArgEvaluatorTag<MultiArg7<A1, A2, A3, A4, A5, A6, A7> >
  {
*************** struct MultiArgEvaluatorTag<MultiArg7<A1
*** 411,416 ****
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: MultiArgEvaluator.h,v $   $Author: jxyh $
! // $Revision: 1.5 $   $Date: 2001/03/04 06:46:48 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
--- 456,461 ----
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: MultiArgEvaluator.h,v $   $Author: jxyh $
! // $Revision: 1.7 $   $Date: 2001/03/14 05:36:16 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
Index: src/Evaluator/ScalarCode.h
===================================================================
RCS file: /usr/local/pooma/repository/r2/src/Evaluator/ScalarCode.h,v
retrieving revision 1.5
retrieving revision 1.7
diff -c -p -r1.5 -r1.7
*** ScalarCode.h	2001/03/04 22:19:15	1.5
--- ScalarCode.h	2001/03/14 05:36:16	1.7
*************** struct ApplyMultiArgLoc<MultiArg1<A1>, F
*** 102,108 ****
  template<class A1, class A2, class Function>
  struct ApplyMultiArgLoc<MultiArg2<A1, A2>, Function>
  {
!   ApplyMultiArgLoc(const MultiArg2<A1, A2> &multiArg,const Function &function)
      : multiArg_m(multiArg), function_m(function)
    {
    }
--- 102,108 ----
  template<class A1, class A2, class Function>
  struct ApplyMultiArgLoc<MultiArg2<A1, A2>, Function>
  {
!   ApplyMultiArgLoc(const MultiArg2<A1, A2> &multiArg,Function &function)
      : multiArg_m(multiArg), function_m(function)
    {
    }
*************** struct ApplyMultiArgLoc<MultiArg2<A1, A2
*** 128,141 ****
    }
  
    const MultiArg2<A1, A2> &multiArg_m;
!   const Function &function_m;
  };
  
  template<class A1, class A2, class A3, class Function>
  struct ApplyMultiArgLoc<MultiArg3<A1, A2, A3>, Function>
  {
    ApplyMultiArgLoc(const MultiArg3<A1, A2, A3> &multiArg,
! 		   const Function &function)
      : multiArg_m(multiArg), function_m(function)
    {
    }
--- 128,141 ----
    }
  
    const MultiArg2<A1, A2> &multiArg_m;
!   Function &function_m;
  };
  
  template<class A1, class A2, class A3, class Function>
  struct ApplyMultiArgLoc<MultiArg3<A1, A2, A3>, Function>
  {
    ApplyMultiArgLoc(const MultiArg3<A1, A2, A3> &multiArg,
! 		   Function &function)
      : multiArg_m(multiArg), function_m(function)
    {
    }
*************** struct ApplyMultiArgLoc<MultiArg3<A1, A2
*** 165,178 ****
    }
  
    const MultiArg3<A1, A2, A3> &multiArg_m;
!   const Function &function_m;
  };
  
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class Function>
  struct ApplyMultiArgLoc<MultiArg7<A1, A2, A3, A4, A5, A6, A7>, Function>
  {
    ApplyMultiArgLoc(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg,
! 		   const Function &function)
      : multiArg_m(multiArg), function_m(function)
    {
    }
--- 165,293 ----
    }
  
    const MultiArg3<A1, A2, A3> &multiArg_m;
!   Function &function_m;
  };
  
+ template<class A1, class A2, class A3, class A4, class Function>
+ struct ApplyMultiArgLoc<MultiArg4<A1, A2, A3, A4>, Function>
+ {
+   ApplyMultiArgLoc(const MultiArg4<A1, A2, A3, A4> &multiArg,
+ 		   Function &function)
+     : multiArg_m(multiArg), function_m(function)
+   {
+   }
+ 
+   void operator()(int i0)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, Loc<1>(i0));
+   }
+ 
+   void operator()(int i0, int i1)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, Loc<2>(i0, i1));
+   }
+ 
+   void operator()(int i0, int i1, int i2)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, Loc<3>(i0, i1, i2));
+   }
+ 
+   void operator()(int i0, int i1, int i2, int i3)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, Loc<4>(i0, i1, i2, i3));
+   }
+ 
+   const MultiArg4<A1, A2, A3, A4> &multiArg_m;
+   Function &function_m;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class Function>
+ struct ApplyMultiArgLoc<MultiArg5<A1, A2, A3, A4, A5>, Function>
+ {
+   ApplyMultiArgLoc(const MultiArg5<A1, A2, A3, A4, A5> &multiArg,
+ 		   Function &function)
+     : multiArg_m(multiArg), function_m(function)
+   {
+   }
+ 
+   void operator()(int i0)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<1>(i0));
+   }
+ 
+   void operator()(int i0, int i1)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<2>(i0, i1));
+   }
+ 
+   void operator()(int i0, int i1, int i2)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<3>(i0, i1, i2));
+   }
+ 
+   void operator()(int i0, int i1, int i2, int i3)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<4>(i0, i1, i2, i3));
+   }
+ 
+   const MultiArg5<A1, A2, A3, A4, A5> &multiArg_m;
+   Function &function_m;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6, class Function>
+ struct ApplyMultiArgLoc<MultiArg6<A1, A2, A3, A4, A5, A6>, Function>
+ {
+   ApplyMultiArgLoc(const MultiArg6<A1, A2, A3, A4, A5, A6> &multiArg,
+ 		   Function &function)
+     : multiArg_m(multiArg), function_m(function)
+   {
+   }
+ 
+   void operator()(int i0)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
+                Loc<1>(i0));
+   }
+ 
+   void operator()(int i0, int i1)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
+                Loc<2>(i0, i1));
+   }
+ 
+   void operator()(int i0, int i1, int i2)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
+                Loc<3>(i0, i1, i2));
+   }
+ 
+   void operator()(int i0, int i1, int i2, int i3)
+   {
+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
+                Loc<4>(i0, i1, i2, i3));
+   }
+ 
+   const MultiArg6<A1, A2, A3, A4, A5, A6> &multiArg_m;
+   Function &function_m;
+ };
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class Function>
  struct ApplyMultiArgLoc<MultiArg7<A1, A2, A3, A4, A5, A6, A7>, Function>
  {
    ApplyMultiArgLoc(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg,
! 		   Function &function)
      : multiArg_m(multiArg), function_m(function)
    {
    }
*************** struct ApplyMultiArgLoc<MultiArg7<A1, A2
*** 206,212 ****
    }
  
    const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg_m;
!   const Function &function_m;
  };
  
  template<class Function, int Dim>
--- 321,327 ----
    }
  
    const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg_m;
!   Function &function_m;
  };
  
  template<class Function, int Dim>
*************** struct EvaluateLocLoop
*** 216,222 ****
    {
    }
  
!   EvaluateLocLoop(const Function &function, const Interval<Dim> &domain)
      : function_m(function), domain_m(domain)
    {
    }
--- 331,337 ----
    {
    }
  
!   EvaluateLocLoop(Function &function, const Interval<Dim> &domain)
      : function_m(function), domain_m(domain)
    {
    }
*************** struct ScalarCode
*** 239,245 ****
    {
    }
  
!   ScalarCode(const Function &function)
      : function_m(function)
    {
    }
--- 354,360 ----
    {
    }
  
!   ScalarCode(Function &function)
      : function_m(function)
    {
    }
*************** struct ScalarCode
*** 283,288 ****
--- 398,442 ----
  	       kernel);
    }
  
+   template<class F1, class F2, class F3, class F4>
+   void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const F4 &f4)
+   {
+     enum { dimensions = F1::dimensions };
+     MultiArg4<F1, F2, F3, F4> multiArg(f1, f2, f3, f4);
+     EvaluateLocLoop<Function, dimensions> kernel(function_m,f1.physicalDomain());
+ 
+     MultiArgEvaluator<MainEvaluatorTag>().
+       evaluate<MultiArg4<F1, F2, F3, F4> >(multiArg, function_m,
+ 	       f1.physicalDomain(),
+ 	       kernel);
+   }
+ 
+   template<class F1, class F2, class F3, class F4, class F5>
+   void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const F4 &f4, const F5 &f5)
+   {
+     enum { dimensions = F1::dimensions };
+     MultiArg5<F1, F2, F3, F4, F5> multiArg(f1, f2, f3, f4, f5);
+     EvaluateLocLoop<Function, dimensions> kernel(function_m,f1.physicalDomain());
+ 
+     MultiArgEvaluator<MainEvaluatorTag>().
+       evaluate<MultiArg5<F1, F2, F3, F4, F5> >(multiArg, function_m,
+ 	       f1.physicalDomain(),
+ 	       kernel);
+   }
+ 
+   template<class F1, class F2, class F3, class F4, class F5, class F6>
+   void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const F4 &f4, const F5 &f5, const F6 &f6)
+   {
+     enum { dimensions = F1::dimensions };
+     MultiArg6<F1, F2, F3, F4, F5, F6> multiArg(f1, f2, f3, f4, f5, f6);
+     EvaluateLocLoop<Function, dimensions> kernel(function_m,f1.physicalDomain());
+ 
+     MultiArgEvaluator<MainEvaluatorTag>().
+       evaluate<MultiArg6<F1, F2, F3, F4, F5, F6> >(multiArg, function_m,
+ 	       f1.physicalDomain(),
+ 	       kernel);
+   }
+ 
    template<class F1, class F2, class F3, class F4, class F5, class F6, class F7>
    void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const F4 &f4, const F5 &f5, const F6 &f6, const F7 &f7)
    {
*************** struct ScalarCode
*** 308,313 ****
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: ScalarCode.h,v $   $Author: jxyh $
! // $Revision: 1.5 $   $Date: 2001/03/04 22:19:15 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
--- 462,467 ----
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: ScalarCode.h,v $   $Author: jxyh $
! // $Revision: 1.7 $   $Date: 2001/03/14 05:36:16 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
Index: src/Evaluator/ScalarCodeInfo.h
===================================================================
RCS file: /usr/local/pooma/repository/r2/src/Evaluator/ScalarCodeInfo.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -p -r1.2 -r1.3
*** ScalarCodeInfo.h	2001/03/04 06:46:48	1.2
--- ScalarCodeInfo.h	2001/03/13 06:32:22	1.3
*************** public:
*** 176,183 ****
        ret[d] =
  	Interval<1>(
  //		    lower_m[d],
!             domain[d].first(),
! 		    domain[d].last() - domain[d].first() // + lower_m[d]
  		    );
      }
      return ret;
--- 176,183 ----
        ret[d] =
  	Interval<1>(
  //		    lower_m[d],
!             domain[d].first() + lower_m[d],
! 		    domain[d].last() - domain[d].first() + lower_m[d]
  		    );
      }
      return ret;
*************** private:
*** 209,214 ****
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: ScalarCodeInfo.h,v $   $Author: jxyh $
! // $Revision: 1.2 $   $Date: 2001/03/04 06:46:48 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
--- 209,214 ----
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: ScalarCodeInfo.h,v $   $Author: jxyh $
! // $Revision: 1.3 $   $Date: 2001/03/13 06:32:22 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
Index: src/Functions/MultiArg.h
===================================================================
RCS file: /usr/local/pooma/repository/r2/src/Functions/MultiArg.h,v
retrieving revision 1.4
retrieving revision 1.5
diff -c -p -r1.4 -r1.5
*** MultiArg.h	2001/03/04 06:47:18	1.4
--- MultiArg.h	2001/03/11 00:34:29	1.5
***************
*** 81,86 ****
--- 81,89 ----
  template<class A1> struct MultiArg1;
  template<class A1, class A2> struct MultiArg2;
  template<class A1, class A2, class A3> struct MultiArg3;
+ template<class A1, class A2, class A3, class A4> struct MultiArg4;
+ template<class A1, class A2, class A3, class A4, class A5> struct MultiArg5;
+ template<class A1, class A2, class A3, class A4, class A5, class A6> struct MultiArg6;
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7> struct MultiArg7;
  
  // These MultiArgView structs are workarounds for Compaq's
*************** struct MultiArgView3
*** 111,116 ****
--- 114,152 ----
    typedef MultiArg3<A1_t, A2_t, A3_t> Type_t;
  };
  
+ template<class A1, class A2, class A3, class A4, class Dom>
+ struct MultiArgView4
+ {
+   typedef typename View1<A1, Dom>::Type_t A1_t;
+   typedef typename View1<A2, Dom>::Type_t A2_t;
+   typedef typename View1<A3, Dom>::Type_t A3_t;
+   typedef typename View1<A4, Dom>::Type_t A4_t;
+   typedef MultiArg4<A1_t, A2_t, A3_t, A4_t> Type_t;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class Dom>
+ struct MultiArgView5
+ {
+   typedef typename View1<A1, Dom>::Type_t A1_t;
+   typedef typename View1<A2, Dom>::Type_t A2_t;
+   typedef typename View1<A3, Dom>::Type_t A3_t;
+   typedef typename View1<A4, Dom>::Type_t A4_t;
+   typedef typename View1<A5, Dom>::Type_t A5_t;
+   typedef MultiArg5<A1_t, A2_t, A3_t, A4_t, A5_t> Type_t;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6, class Dom>
+ struct MultiArgView6
+ {
+   typedef typename View1<A1, Dom>::Type_t A1_t;
+   typedef typename View1<A2, Dom>::Type_t A2_t;
+   typedef typename View1<A3, Dom>::Type_t A3_t;
+   typedef typename View1<A4, Dom>::Type_t A4_t;
+   typedef typename View1<A5, Dom>::Type_t A5_t;
+   typedef typename View1<A6, Dom>::Type_t A6_t;
+   typedef MultiArg6<A1_t, A2_t, A3_t, A4_t, A5_t, A6_t> Type_t;
+ };
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class Dom>
  struct MultiArgView7
  {
*************** struct View1<MultiArg3<A1, A2, A3>, Dom>
*** 142,147 ****
--- 178,201 ----
    typedef typename MultiArgView3<A1, A2, A3, Dom>::Type_t Type_t;
  };
  
+ template<class A1, class A2, class A3, class A4, class Dom>
+ struct View1<MultiArg4<A1, A2, A3, A4>, Dom>
+ {
+   typedef typename MultiArgView4<A1, A2, A3, A4, Dom>::Type_t Type_t;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class Dom>
+ struct View1<MultiArg5<A1, A2, A3, A4, A5>, Dom>
+ {
+   typedef typename MultiArgView5<A1, A2, A3, A4, A5, Dom>::Type_t Type_t;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6, class Dom>
+ struct View1<MultiArg6<A1, A2, A3, A4, A5, A6>, Dom>
+ {
+   typedef typename MultiArgView6<A1, A2, A3, A4, A5, A6, Dom>::Type_t Type_t;
+ };
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class Dom>
  struct View1<MultiArg7<A1, A2, A3, A4, A5, A6, A7>, Dom>
  {
*************** struct MultiArg3
*** 214,219 ****
--- 268,348 ----
    A3 a3_m;
  };
  
+ template<class A1, class A2, class A3, class A4>
+ struct MultiArg4
+ {
+   enum { size = 4 };
+ 
+   MultiArg4(const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4)
+     : a1_m(a1), a2_m(a2), a3_m(a3), a4_m(a4)
+   {
+   }
+ 
+   template<class Dom>
+   typename View1<MultiArg4<A1, A2, A3, A4>, Dom>::Type_t
+   operator()(Dom &dom) const
+   {
+     typedef typename View1<MultiArg4<A1, A2, A3, A4>, Dom>::Type_t Ret_t;
+     return Ret_t(a1_m(dom), a2_m(dom), a3_m(dom), a4_m(dom));
+   }
+ 
+   A1 a1_m;
+   A2 a2_m;
+   A3 a3_m;
+   A4 a4_m;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5>
+ struct MultiArg5
+ {
+   enum { size = 5 };
+ 
+   MultiArg5(const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4, const A5 &a5)
+     : a1_m(a1), a2_m(a2), a3_m(a3), a4_m(a4), a5_m(a5)
+   {
+   }
+ 
+   template<class Dom>
+   typename View1<MultiArg5<A1, A2, A3, A4, A5>, Dom>::Type_t
+   operator()(Dom &dom) const
+   {
+     typedef typename View1<MultiArg5<A1, A2, A3, A4, A5>, Dom>::Type_t Ret_t;
+     return Ret_t(a1_m(dom), a2_m(dom), a3_m(dom), a4_m(dom), a5_m(dom));
+   }
+ 
+   A1 a1_m;
+   A2 a2_m;
+   A3 a3_m;
+   A4 a4_m;
+   A5 a5_m;
+ };
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6>
+ struct MultiArg6
+ {
+   enum { size = 6 };
+ 
+   MultiArg6(const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4, const A5 &a5, const A6 &a6)
+     : a1_m(a1), a2_m(a2), a3_m(a3), a4_m(a4), a5_m(a5), a6_m(a6)
+   {
+   }
+ 
+   template<class Dom>
+   typename View1<MultiArg6<A1, A2, A3, A4, A5, A6>, Dom>::Type_t
+   operator()(Dom &dom) const
+   {
+     typedef typename View1<MultiArg6<A1, A2, A3, A4, A5, A6>, Dom>::Type_t Ret_t;
+     return Ret_t(a1_m(dom), a2_m(dom), a3_m(dom), a4_m(dom), a5_m(dom), a6_m(dom));
+   }
+ 
+   A1 a1_m;
+   A2 a2_m;
+   A3 a3_m;
+   A4 a4_m;
+   A5 a5_m;
+   A6 a6_m;
+ };
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7>
  struct MultiArg7
  {
*************** void applyMultiArg(const MultiArg3<A1, A
*** 283,288 ****
--- 412,459 ----
    f(node.a1_m, node.a2_m, node.a3_m, i1, i2);
  }
  
+ template<class A1, class A2, class A3, class A4, class Function>
+ void applyMultiArg(const MultiArg4<A1, A2, A3, A4> &node,
+ 	       const Function &f, int i1)
+ {
+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, i1);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class Function>
+ void applyMultiArg(const MultiArg4<A1, A2, A3, A4> &node,
+ 	       const Function &f, int i1, int i2)
+ {
+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, i1, i2);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class Function>
+ void applyMultiArg(const MultiArg5<A1, A2, A3, A4, A5> &node,
+ 	       const Function &f, int i1)
+ {
+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, i1);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class Function>
+ void applyMultiArg(const MultiArg5<A1, A2, A3, A4, A5> &node,
+ 	       const Function &f, int i1, int i2)
+ {
+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, i1, i2);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6, class Function>
+ void applyMultiArg(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
+ 	       const Function &f, int i1)
+ {
+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, node.a6_m, i1);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6, class Function>
+ void applyMultiArg(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
+ 	       const Function &f, int i1, int i2)
+ {
+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, node.a6_m, i1, i2);
+ }
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class Function>
  void applyMultiArg(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &node,
  	       const Function &f, int i1)
*************** void applyMultiArg(const MultiArg3<A1, A
*** 324,329 ****
--- 495,536 ----
    f(node.a3_m, condition[2]);
  }
  
+ template<class A1, class A2, class A3, class A4, class Function>
+ void applyMultiArg(const MultiArg4<A1, A2, A3, A4> &node,
+ 	       const Function &f,
+ 	       const std::vector<bool> &condition)
+ {
+   f(node.a1_m, condition[0]);
+   f(node.a2_m, condition[1]);
+   f(node.a3_m, condition[2]);
+   f(node.a4_m, condition[3]);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class Function>
+ void applyMultiArg(const MultiArg5<A1, A2, A3, A4, A5> &node,
+ 	       const Function &f,
+ 	       const std::vector<bool> &condition)
+ {
+   f(node.a1_m, condition[0]);
+   f(node.a2_m, condition[1]);
+   f(node.a3_m, condition[2]);
+   f(node.a4_m, condition[3]);
+   f(node.a5_m, condition[4]);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6, class Function>
+ void applyMultiArg(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
+ 	       const Function &f,
+ 	       const std::vector<bool> &condition)
+ {
+   f(node.a1_m, condition[0]);
+   f(node.a2_m, condition[1]);
+   f(node.a3_m, condition[2]);
+   f(node.a4_m, condition[3]);
+   f(node.a5_m, condition[4]);
+   f(node.a6_m, condition[5]);
+ }
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class Function>
  void applyMultiArg(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &node,
  	       const Function &f,
*************** void applyMultiArgIf(const MultiArg3<A1,
*** 374,379 ****
--- 581,649 ----
      f(node.a3_m);
  }
  
+ template<class A1, class A2, class A3, class A4, class Function>
+ void applyMultiArgIf(const MultiArg4<A1, A2, A3, A4> &node,
+ 		 const Function &f,
+ 		 const std::vector<bool> &condition)
+ {
+   if (condition[0])
+     f(node.a1_m);
+ 
+   if (condition[1])
+     f(node.a2_m);
+ 
+   if (condition[2])
+     f(node.a3_m);
+ 
+   if (condition[3])
+     f(node.a4_m);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class Function>
+ void applyMultiArgIf(const MultiArg5<A1, A2, A3, A4, A5> &node,
+ 		 const Function &f,
+ 		 const std::vector<bool> &condition)
+ {
+   if (condition[0])
+     f(node.a1_m);
+ 
+   if (condition[1])
+     f(node.a2_m);
+ 
+   if (condition[2])
+     f(node.a3_m);
+ 
+   if (condition[3])
+     f(node.a4_m);
+ 
+   if (condition[4])
+     f(node.a5_m);
+ }
+ 
+ template<class A1, class A2, class A3, class A4, class A5, class A6, class Function>
+ void applyMultiArgIf(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
+ 		 const Function &f,
+ 		 const std::vector<bool> &condition)
+ {
+   if (condition[0])
+     f(node.a1_m);
+ 
+   if (condition[1])
+     f(node.a2_m);
+ 
+   if (condition[2])
+     f(node.a3_m);
+ 
+   if (condition[3])
+     f(node.a4_m);
+ 
+   if (condition[4])
+     f(node.a5_m);
+ 
+   if (condition[5])
+     f(node.a6_m);
+ }
+ 
  template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class Function>
  void applyMultiArgIf(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &node,
  		 const Function &f,
*************** void applyMultiArgIf(const MultiArg7<A1,
*** 406,411 ****
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: MultiArg.h,v $   $Author: jxyh $
! // $Revision: 1.4 $   $Date: 2001/03/04 06:47:18 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
--- 676,681 ----
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
  // $RCSfile: MultiArg.h,v $   $Author: jxyh $
! // $Revision: 1.5 $   $Date: 2001/03/11 00:34:29 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
Index: src/Pooma/PETE/AssertEquals.h
===================================================================
RCS file: /usr/local/pooma/repository/r2/src/Pooma/PETE/AssertEquals.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -c -p -r1.2 -r1.3
*** AssertEquals.h	2000/03/07 13:18:06	1.2
--- AssertEquals.h	2001/03/19 22:23:48	1.3
*************** struct Combine2<int, int, Op, AssertEqua
*** 79,86 ****
  {
    typedef int Type_t;
    inline static
!   Type_t combine(const int &a, const int &b,
! 		 const Op &, const AssertEquals &ae)
    {
      int ret = a;
      if ((a != ae.ignore_m) && (b != ae.ignore_m))
--- 79,85 ----
  {
    typedef int Type_t;
    inline static
!   Type_t combine(const int &a, const int &b, const AssertEquals &ae)
    {
      int ret = a;
      if ((a != ae.ignore_m) && (b != ae.ignore_m))
*************** struct Combine2<int, int, Op, AssertEqua
*** 101,107 ****
  
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
! // $RCSfile: AssertEquals.h,v $   $Author: swhaney $
! // $Revision: 1.2 $   $Date: 2000/03/07 13:18:06 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo
--- 100,106 ----
  
  // ACL:rcsinfo
  // ----------------------------------------------------------------------
! // $RCSfile: AssertEquals.h,v $   $Author: jxyh $
! // $Revision: 1.3 $   $Date: 2001/03/19 22:23:48 $
  // ----------------------------------------------------------------------
  // ACL:rcsinfo


From drnuke at lanl.gov  Tue Apr  3 19:06:31 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Tue, 3 Apr 2001 13:06:31 -0600
Subject: [pooma-dev] RE: an attempt at your particle BC
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BB8@proxim-sf001.santafe.proximation.com>
Message-ID: <NDBBIAJIJKLEAIAEGGACIEOMCFAA.drnuke@lanl.gov>

RE: [pooma-dev] RE: an attempt at your particle BCalright.  let me know when
you or julian have added this, and i'll try it out.

i didn't see a function signature amenable to the vector<int> call in the
particle stuff, but i was hoping providence would play a role when it got
reinterpreted as a domain. :)

-steve
  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Tuesday, April 03, 2001 11:30 AM
  To: 'Julian Cummings'; James Crotinger
  Cc: 'Steve Nolen'; 'Pooma'
  Subject: RE: [pooma-dev] RE: an attempt at your particle BC


  Oops - sorry about that Steve. Julian's right. Don't know how that feature
slipped through the cracks. I put it in DynamicEngine to make these sorts of
things easier and it never made it to DynamicArray. I'm in the middle of
debugging a socket problem. If I can get that sorted out soon, I'll take a
crack at this.

          Jim

  ---------------------------------------------------
  James A. Crotinger
  Software Research Scientist
  Proximation, LLC

   -----Original Message-----
  From:   Julian Cummings [mailto:cummings at cacr.caltech.edu]
  Sent:   Tuesday, April 03, 2001 11:27 AM
  To:     James Crotinger
  Cc:     'Steve Nolen'; 'Pooma'
  Subject:        Re: [pooma-dev] RE: an attempt at your particle BC

  Gentlemen:

  There's a problem here.  The interface that Jim cited,
  describing a destroy list with a pair of iterators into
  some list of indices, exists for DynamicEngine, but
  *not* for DynamicArray (or Particles).  We need to
  add this before Steve would be able to use this method.

  I can take a crack at this late in the day today, unless
  someone else has time to deal with it sooner.

  -- Julian C.



  James Crotinger wrote:

  > Don't send vector<int> - it will think you're sending a "domain", which
has a
  > size() method.
  > Instead, send a.begin() and a.end() where a is your vector<int>.
  >
  > Jim
  >
  > ---------------------------------------------------
  >
  > James A. Crotinger
  >
  > Software Research Scientist
  >
  > Proximation, LLC
  >
  > -----Original Message-----
  > From: Steve Nolen [mailto:drnuke at lanl.gov]
  > Sent: Tuesday, April 03, 2001 11:05 AM
  > To: James Crotinger; cummings at cacr.caltech.edu
  > Cc: 'Pooma'
  > Subject: RE: [pooma-dev] RE: an attempt at your particle BC
  >
  > i tried sending a vector<int> object but it (le compiler) complained
about not
  > having "domain[0].size()".
  > -----Original Message-----
  >
  >
  > From: James Crotinger [mailto:JimC at proximation.com]
  > Sent: Tuesday, April 03, 2001 10:54 AM
  > To: 'Steve Nolen'; 'cummings at cacr.caltech.edu'
  > Cc: 'Pooma'
  > Subject: RE: [pooma-dev] RE: an attempt at your particle BC
  >
  > Actually, I think destroy will take quite a variety of domain
representations.
  > For example, it will take a pair of iterators into a list:
  >
  > (from Engine/tests/dynamic_test2.cpp)
  >
  >     int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19};
  >
  >     C.destroy(kill_array, kill_array+8, BackFill());
  >
  > It will also take our regular domain objects. IndirectionList is used
  > internally (for its shallow copy semantics, I think), but I do not
recommend
  > that users use it - it really wasn't designed to be an all-purpose
  > user-friendly class. (It is easy to get bitten by its shallow copy
semantics,
  > IMHO). I guess I'd tend to use a std::vector for these things, but I'd
have to
  > see the real application to understand if that is correct.
  >
  > Jim
  >
  > ---------------------------------------------------
  > James A. Crotinger
  > Software Research Scientist
  > Proximation, LLC
  >
  > -----Original Message-----
  > From:   Steve Nolen [mailto:drnuke at lanl.gov]
  > Sent:   Tuesday, April 03, 2001 10:41 AM
  > To:     cummings at cacr.caltech.edu
  > Cc:     Pooma
  > Subject:        [pooma-dev] RE: an attempt at your particle BC
  >
  > it would be nice if one of the destroy or sync functions accepted a list
or
  > vector of integers denoting which particles to destroy.  the conversion
to
  > an IndirectionList (or even a DynamicArray for this matter) is just a
little
  > too much pooma for the casual user.
  >
  > > -----Original Message-----
  > > From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
  > > Sent: Monday, April 02, 2001 6:26 PM
  > > To: Steve Nolen
  > > Subject: RE: an attempt at your particle BC
  > >
  > <snip>
  > >
  > > To assign a particle to the destroy list, use the
  > > deferredDestroy() method.  The first argument is a
  > > Domain describing the particle(s) to be added to
  > > the list, and the second is a local patch id number
  > > (if this is a local particle destroy).  For a single
  > > particle, the Domain will be an int or a Loc<1>
  > > containing the local index number of the particle,
  > > and the patchID says which local patch has this
  > > particle.  Particles on the destroy list are not
  > > destroyed until you call performDestroy() (or it gets
  > > called by the sync() method).
  > >
  > > If you are going to do this repeatedly, you might want
  > > to create your own temporary destroy list.  Create a
  > > DynamicArray of ints to store the indices of local
  > > particles to be destroyed on a particular local patch.
  > > Call the create() method to add a new element for each
  > > particle to be destroyed.  Then assign the local index
  > > number of the particle to that element in your destroy
  > > list.  Once your destroy list is complete, you must
  > > convert it into an IndirectionList<int>.  The destroy
  > > functions only accept domain types as descriptors of
  > > the set of particles to be destroyed, so you must use
  > > the IndirectionList here.  IndirectionList has a
  > > constructor which takes a 1D Array as its argument.
  > > Now you can call either deferredDestroy (to destroy
  > > later on) or destroy (to do it now) and pass it the
  > > IndirectionList and the local patchID.
  > >
  > > DynamicArray<int> kill;
  > > kill.create(1);
  > > kill(0) = i;  // add particle i to list
  > > IndirectionList<int> klist(kill);
  > > Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
  > >
  > >
  >
  --
  Dr. Julian C. Cummings                       E-mail:
cummings at cacr.caltech.edu
  California Institute of Technology           Phone:  626-395-2543
  1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
  Pasadena, CA 91125



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010403/fff3cba9/attachment.html>

From JimC at proximation.com  Tue Apr  3 20:29:00 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 3 Apr 2001 13:29:00 -0700 
Subject: [pooma-dev] RE: an attempt at your particle BC
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BB9@proxim-sf001.santafe.proximation.com>

I had blocked from my memory the Byzantine path that is taken when
destroying elements of a multi-patch dynamic array. I'm looking at this
right now, but it's not going to be 10 minutes work. (It involves changes in
DynamicArray, MultiPatchEngine, DynamicLayout, and the observer events -
ack! I see why this never made it in. 8-)

Julian, if you're chomping at the bit to do this bit of work, let me know
ASAP. I have to leave soon so I certainly won't have time to finish this
today.

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

 -----Original Message-----
From: 	cummings at cacr.caltech.edu [mailto:cummings at cacr.caltech.edu] 
Sent:	Tuesday, April 03, 2001 11:27 AM
To:	James Crotinger
Cc:	'Steve Nolen'; 'Pooma'
Subject:	Re: [pooma-dev] RE: an attempt at your particle BC

Gentlemen:

There's a problem here.  The interface that Jim cited,
describing a destroy list with a pair of iterators into
some list of indices, exists for DynamicEngine, but
*not* for DynamicArray (or Particles).  We need to
add this before Steve would be able to use this method.

I can take a crack at this late in the day today, unless
someone else has time to deal with it sooner.

-- Julian C.


James Crotinger wrote:

> Don't send vector<int> - it will think you're sending a "domain", which
has a
> size() method.
> Instead, send a.begin() and a.end() where a is your vector<int>.
>
> Jim
>
> ---------------------------------------------------
>
> James A. Crotinger
>
> Software Research Scientist
>
> Proximation, LLC
>
> -----Original Message-----
> From: Steve Nolen [mailto:drnuke at lanl.gov]
> Sent: Tuesday, April 03, 2001 11:05 AM
> To: James Crotinger; cummings at cacr.caltech.edu
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> i tried sending a vector<int> object but it (le compiler) complained about
not
> having "domain[0].size()".
> -----Original Message-----
>
>
> From: James Crotinger [mailto:JimC at proximation.com]
> Sent: Tuesday, April 03, 2001 10:54 AM
> To: 'Steve Nolen'; 'cummings at cacr.caltech.edu'
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> Actually, I think destroy will take quite a variety of domain
representations.
> For example, it will take a pair of iterators into a list:
>
> (from Engine/tests/dynamic_test2.cpp)
>
>     int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19};
>
>     C.destroy(kill_array, kill_array+8, BackFill());
>
> It will also take our regular domain objects. IndirectionList is used
> internally (for its shallow copy semantics, I think), but I do not
recommend
> that users use it - it really wasn't designed to be an all-purpose
> user-friendly class. (It is easy to get bitten by its shallow copy
semantics,
> IMHO). I guess I'd tend to use a std::vector for these things, but I'd
have to
> see the real application to understand if that is correct.
>
> Jim
>
> ---------------------------------------------------
> James A. Crotinger
> Software Research Scientist
> Proximation, LLC
>
> -----Original Message-----
> From:   Steve Nolen [mailto:drnuke at lanl.gov]
> Sent:   Tuesday, April 03, 2001 10:41 AM
> To:     cummings at cacr.caltech.edu
> Cc:     Pooma
> Subject:        [pooma-dev] RE: an attempt at your particle BC
>
> it would be nice if one of the destroy or sync functions accepted a list
or
> vector of integers denoting which particles to destroy.  the conversion to
> an IndirectionList (or even a DynamicArray for this matter) is just a
little
> too much pooma for the casual user.
>
> > -----Original Message-----
> > From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
> > Sent: Monday, April 02, 2001 6:26 PM
> > To: Steve Nolen
> > Subject: RE: an attempt at your particle BC
> >
> <snip>
> >
> > To assign a particle to the destroy list, use the
> > deferredDestroy() method.  The first argument is a
> > Domain describing the particle(s) to be added to
> > the list, and the second is a local patch id number
> > (if this is a local particle destroy).  For a single
> > particle, the Domain will be an int or a Loc<1>
> > containing the local index number of the particle,
> > and the patchID says which local patch has this
> > particle.  Particles on the destroy list are not
> > destroyed until you call performDestroy() (or it gets
> > called by the sync() method).
> >
> > If you are going to do this repeatedly, you might want
> > to create your own temporary destroy list.  Create a
> > DynamicArray of ints to store the indices of local
> > particles to be destroyed on a particular local patch.
> > Call the create() method to add a new element for each
> > particle to be destroyed.  Then assign the local index
> > number of the particle to that element in your destroy
> > list.  Once your destroy list is complete, you must
> > convert it into an IndirectionList<int>.  The destroy
> > functions only accept domain types as descriptors of
> > the set of particles to be destroyed, so you must use
> > the IndirectionList here.  IndirectionList has a
> > constructor which takes a 1D Array as its argument.
> > Now you can call either deferredDestroy (to destroy
> > later on) or destroy (to do it now) and pass it the
> > IndirectionList and the local patchID.
> >
> > DynamicArray<int> kill;
> > kill.create(1);
> > kill(0) = i;  // add particle i to list
> > IndirectionList<int> klist(kill);
> > Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
> >
> >
>
--
Dr. Julian C. Cummings                       E-mail:
cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010403/6123e9ac/attachment.html>

From JimC at proximation.com  Tue Apr  3 20:42:30 2001
From: JimC at proximation.com (James Crotinger)
Date: Tue, 3 Apr 2001 13:42:30 -0700 
Subject: [pooma-dev] RE: an attempt at your particle BC
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BBA@proxim-sf001.santafe.proximation.com>

How important is it to avoid making a copy of the "kill list"? 
If we can ascertain (through specializations) that the iterators are
equivalent to pointers into contiguous memory, we can probably construct an
IndirectionList on the fly without copying the data (first construct a
BrickEngine using the address of the first element and the length, then
construct an Array, and then an IndirectionList). If these iterators were
from something like an std::list, though, then this would not be possible.
If this is the case, the easy way to write the code would be to copy the
data, but that is almost certainly undesirable. The other way is to
specialize the entire flow for a pair of iterators (in which case, doing
something special for pointer-like ones probably buys you nothing). The
problem with this is that DynamicEventType and DestroyEvent are templated on
a domain. Possibly the easiest way to fix these would be to specialize them
for std::pair<Iter,Iter>. 

At any rate, I'm not going to get this done today.

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

 -----Original Message-----
From: 	cummings at cacr.caltech.edu [mailto:cummings at cacr.caltech.edu] 
Sent:	Tuesday, April 03, 2001 11:27 AM
To:	James Crotinger
Cc:	'Steve Nolen'; 'Pooma'
Subject:	Re: [pooma-dev] RE: an attempt at your particle BC

Gentlemen:

There's a problem here.  The interface that Jim cited,
describing a destroy list with a pair of iterators into
some list of indices, exists for DynamicEngine, but
*not* for DynamicArray (or Particles).  We need to
add this before Steve would be able to use this method.

I can take a crack at this late in the day today, unless
someone else has time to deal with it sooner.

-- Julian C.


James Crotinger wrote:

> Don't send vector<int> - it will think you're sending a "domain", which
has a
> size() method.
> Instead, send a.begin() and a.end() where a is your vector<int>.
>
> Jim
>
> ---------------------------------------------------
>
> James A. Crotinger
>
> Software Research Scientist
>
> Proximation, LLC
>
> -----Original Message-----
> From: Steve Nolen [mailto:drnuke at lanl.gov]
> Sent: Tuesday, April 03, 2001 11:05 AM
> To: James Crotinger; cummings at cacr.caltech.edu
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> i tried sending a vector<int> object but it (le compiler) complained about
not
> having "domain[0].size()".
> -----Original Message-----
>
>
> From: James Crotinger [mailto:JimC at proximation.com]
> Sent: Tuesday, April 03, 2001 10:54 AM
> To: 'Steve Nolen'; 'cummings at cacr.caltech.edu'
> Cc: 'Pooma'
> Subject: RE: [pooma-dev] RE: an attempt at your particle BC
>
> Actually, I think destroy will take quite a variety of domain
representations.
> For example, it will take a pair of iterators into a list:
>
> (from Engine/tests/dynamic_test2.cpp)
>
>     int kill_array[8] = {0, 1, 5, 6, 7, 14, 18, 19};
>
>     C.destroy(kill_array, kill_array+8, BackFill());
>
> It will also take our regular domain objects. IndirectionList is used
> internally (for its shallow copy semantics, I think), but I do not
recommend
> that users use it - it really wasn't designed to be an all-purpose
> user-friendly class. (It is easy to get bitten by its shallow copy
semantics,
> IMHO). I guess I'd tend to use a std::vector for these things, but I'd
have to
> see the real application to understand if that is correct.
>
> Jim
>
> ---------------------------------------------------
> James A. Crotinger
> Software Research Scientist
> Proximation, LLC
>
> -----Original Message-----
> From:   Steve Nolen [mailto:drnuke at lanl.gov]
> Sent:   Tuesday, April 03, 2001 10:41 AM
> To:     cummings at cacr.caltech.edu
> Cc:     Pooma
> Subject:        [pooma-dev] RE: an attempt at your particle BC
>
> it would be nice if one of the destroy or sync functions accepted a list
or
> vector of integers denoting which particles to destroy.  the conversion to
> an IndirectionList (or even a DynamicArray for this matter) is just a
little
> too much pooma for the casual user.
>
> > -----Original Message-----
> > From: Julian C. Cummings [mailto:cummings at cacr.caltech.edu]
> > Sent: Monday, April 02, 2001 6:26 PM
> > To: Steve Nolen
> > Subject: RE: an attempt at your particle BC
> >
> <snip>
> >
> > To assign a particle to the destroy list, use the
> > deferredDestroy() method.  The first argument is a
> > Domain describing the particle(s) to be added to
> > the list, and the second is a local patch id number
> > (if this is a local particle destroy).  For a single
> > particle, the Domain will be an int or a Loc<1>
> > containing the local index number of the particle,
> > and the patchID says which local patch has this
> > particle.  Particles on the destroy list are not
> > destroyed until you call performDestroy() (or it gets
> > called by the sync() method).
> >
> > If you are going to do this repeatedly, you might want
> > to create your own temporary destroy list.  Create a
> > DynamicArray of ints to store the indices of local
> > particles to be destroyed on a particular local patch.
> > Call the create() method to add a new element for each
> > particle to be destroyed.  Then assign the local index
> > number of the particle to that element in your destroy
> > list.  Once your destroy list is complete, you must
> > convert it into an IndirectionList<int>.  The destroy
> > functions only accept domain types as descriptors of
> > the set of particles to be destroyed, so you must use
> > the IndirectionList here.  IndirectionList has a
> > constructor which takes a 1D Array as its argument.
> > Now you can call either deferredDestroy (to destroy
> > later on) or destroy (to do it now) and pass it the
> > IndirectionList and the local patchID.
> >
> > DynamicArray<int> kill;
> > kill.create(1);
> > kill(0) = i;  // add particle i to list
> > IndirectionList<int> klist(kill);
> > Neutrons.destroy(klist,patch);  // destroy particles in klist on patch
> >
> >
>
--
Dr. Julian C. Cummings                       E-mail:
cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010403/201503ab/attachment.html>

From drnuke at lanl.gov  Tue Apr  3 22:30:22 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Tue, 3 Apr 2001 16:30:22 -0600
Subject: particle suggestion
Message-ID: <NDBBIAJIJKLEAIAEGGACAEOOCFAA.drnuke@lanl.gov>

would it be possible to add a particle by simply calling a push_back type
function.  this would avoid the user having to keep track of where the end
of a growing list of particles is.  a supported call for first() or last()
would also be nice, and would also solve the previous problem (maybe not if
the last() is only valid after a call to sync()?)

-steve



From sasmith at proximation.com  Tue Apr  3 22:00:52 2001
From: sasmith at proximation.com (Stephen A. Smith)
Date: Tue, 03 Apr 2001 16:00:52 -0600
Subject: Patch: src/Engine/DataObject.h
Message-ID: <3ACA4814.E5181E23@proximation.com>

One of the changes from the old repository.

* Engine/DataObject.h  fix a combiner to follow the new syntax

Tested with Smarts, Linux, egcs-2.95.2

    Stephen
-------------- next part --------------
Index: DataObject.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/DataObject.h,v
retrieving revision 1.29
diff -r1.29 DataObject.h
212c212
<   Type_t combine(int a,int b,Op ,AffinityCombine )
---
>   Type_t combine(int a, int b, AffinityCombine)

From oldham at codesourcery.com  Tue Apr  3 23:01:26 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 3 Apr 2001 16:01:26 -0700
Subject: RFA: src: Spelling and Initializer Reordering Patch
Message-ID: <20010403160126.A14457@codesourcery.com>

OK to commit this proposed patch to Pooma's r2/src/?

2001-04-03  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Domain/DomainIterator.h (DomainIterator::DomainIterator):
	Reorder initializers to reflect class declaration order.
	* Domain/Loc.h: Fix spelling in comment.
	* Engine/ConstantFunctionEngine.h (Engine::Engine):
	Reorder initializers to reflect class declaration order.
	* Engine/IndexFunctionEngine.h (Engine::Engine): Likewise.
	* Evaluator/WhereProxy.h: Fix spelling in comment.
	* Layout/Node.h (Node::Node): Reorder initializers to reflect
	class declaration order.
	* NewField/FieldCreateLeaf.h: Fix spelling in comment.
	* NewField/FieldInitializers.h: Likewise.
	* NewField/FieldReductions.h: Likewise.
	* NewField/DiffOps/Div.UR.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comments.
	* NewField/DiffOps/Div.h: Fix spelling in comment.
	* NewField/DiffOps/FieldStencil.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comment.
	* NewField/Updater/PeriodicFaceBC.h: Fix typo in comment.
	* NewField/Updater/PosReflectFaceBC.h: Likewise.
	* NewField/tests/VectorTest.cpp (main): Fix test's name in the
	source code.
	* Pooma/Pooma.cmpl.cpp (initialize): Fix spelling in comment.
	* Utilities/RefCountedBlockPtr.h
	(RefBlockController::RefBlockController): Reorder initializers to
	reflect class declaration order.
	(RefCountedBlockPtr::RefCountedBlockPtr): Likewise.

Tested on	sequential Linux using gcc 3.1
Reviewed by	???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
2001-04-03  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Domain/DomainIterator.h (DomainIterator::DomainIterator):
	Reorder initializers to reflect class declaration order.
	* Domain/Loc.h: Fix spelling in comment.
	* Engine/ConstantFunctionEngine.h (Engine::Engine):
	Reorder initializers to reflect class declaration order.
	* Engine/IndexFunctionEngine.h (Engine::Engine): Likewise.
	* Evaluator/WhereProxy.h: Fix spelling in comment.
	* Layout/Node.h (Node::Node): Reorder initializers to reflect
	class declaration order.
	* NewField/FieldCreateLeaf.h: Fix spelling in comment.
	* NewField/FieldInitializers.h: Likewise.
	* NewField/FieldReductions.h: Likewise.
	* NewField/DiffOps/Div.UR.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comments.
	* NewField/DiffOps/Div.h: Fix spelling in comment.
	* NewField/DiffOps/FieldStencil.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comment.
	* NewField/Updater/PeriodicFaceBC.h: Fix typo in comment.
	* NewField/Updater/PosReflectFaceBC.h: Likewise.
	* NewField/tests/VectorTest.cpp (main): Fix test's name in the
	source code.
	* Pooma/Pooma.cmpl.cpp (initialize): Fix spelling in comment.
	* Utilities/RefCountedBlockPtr.h
	(RefBlockController::RefBlockController): Reorder initializers to
	reflect class declaration order.
	(RefCountedBlockPtr::RefCountedBlockPtr): Likewise.

From mark at codesourcery.com  Wed Apr  4 01:04:05 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Tue, 03 Apr 2001 18:04:05 -0700
Subject: Timesheet guidelines
Message-ID: <20010403180405D.mitchell@codesourcery.com>


Gentlemen --

  Thanks for submitting your timesheets.

  I noticed that some of you (Smith, Stokes, de Long, you are the most
common guilty parties) sometimes don't put descriptions with your
timesheet entries.  That's a problem since the invoices we send to the
customer are generated automatically from this database, and customers
tend not to like to pay for "6 hrs [no description]". :-)

  For consistency, let's all try to use this format, 

    Did this.  Fixed that.  Examined the other thing.

Capital letters at the beginning of sentences, and verb-object
constructions.  

  I should have made this clear earlier.  Sorry.  Next time around,
I'll be more scrupulous reviewing timesheets, reject submissions
without descriptions.

  Thanks!

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From jxyh at lanl.gov  Wed Apr  4 02:10:26 2001
From: jxyh at lanl.gov (John Hall)
Date: Tue, 3 Apr 2001 20:10:26 -0600
Subject: POOMA Changes from LANL
In-Reply-To: <20010403120610Z.mitchell@codesourcery.com>
References: <20010403120610Z.mitchell@codesourcery.com>
Message-ID: <p04320401b6f031ac5527@[128.165.16.39]>

Mark:
I have already discussed the changes with Stephen Smith. They boil 
down to one missed change in removing the Op parameter from PETE and 
changing const Function& to Function& for the scalar code (global 
replace of every occurrence in MultiArgEvaluator.h and ScalarCode.h). 
Stephen already has examined and approved the changes, unfortunately 
he asked me to check them in and I haven't had time to get set up for 
that yet (I need a password, etc.) So, overall there wasn't a lot to 
the changes. The reason your listing is so long is that Stephen and I 
both extended the scalar code to handle up to seven arguments. We'll 
just stick with Stephen's version which is compiling our code fine 
once the const Function change is made.
John

>John Hall made a few changes to POOMA after we moved the repository.
>
>I've attached the diffs. 
>
>Scott, would you please review and commit the changes?  Or if you are
>too busy, ask Jim to do so?
>
>This is an important task because we want Blanca to start using our
>CVS repository, and apparently they need these changes.
>
>John, in future, please send changes to
>pooma-dev at pooma.codesourcery.com, and we'll get them processed.
>
>Thanks to all,
>
>--
>Mark Mitchell                   mark at codesourcery.com
>CodeSourcery, LLC               http://www.codesourcery.com
>
>Index: src/Engine/DataObject.h
>===================================================================
>RCS file: /usr/local/pooma/repository/r2/src/Engine/DataObject.h,v
>retrieving revision 1.29
>retrieving revision 1.30
>diff -c -p -r1.29 -r1.30
>*** DataObject.h	2000/03/07 13:16:50	1.29
>--- DataObject.h	2001/03/19 22:22:31	1.30
>*************** struct Combine2<int, int, Op, AffinityCo
>*** 209,215 ****
>   {
>     typedef int Type_t;
>     inline static
>!   Type_t combine(int a,int b,Op ,AffinityCombine )
>     {
>       return a;
>     }
>--- 209,215 ----
>   {
>     typedef int Type_t;
>     inline static
>!   Type_t combine(int a,int b,AffinityCombine )
>     {
>       return a;
>     }
>*************** public:
>*** 248,254 ****
>
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>! // $RCSfile: DataObject.h,v $   $Author: swhaney $
>! // $Revision: 1.29 $   $Date: 2000/03/07 13:16:50 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>--- 248,254 ----
>
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>! // $RCSfile: DataObject.h,v $   $Author: jxyh $
>! // $Revision: 1.30 $   $Date: 2001/03/19 22:22:31 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>Index: src/Evaluator/MultiArgEvaluator.h
>===================================================================
>RCS file: /usr/local/pooma/repository/r2/src/Evaluator/MultiArgEvaluator.h,v
>retrieving revision 1.5
>retrieving revision 1.7
>diff -c -p -r1.5 -r1.7
>*** MultiArgEvaluator.h	2001/03/04 06:46:48	1.5
>--- MultiArgEvaluator.h	2001/03/14 05:36:16	1.7
>*************** public:
>*** 136,142 ****
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   const Function &function,
>  	   const Interval<Dim> &domain,
>  	   const Kernel &kernel)
>     {
>--- 136,142 ----
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   Function &function,
>  	   const Interval<Dim> &domain,
>  	   const Kernel &kernel)
>     {
>*************** public:
>*** 158,164 ****
>     template<class A1, class Function, int Dim, class Kernel>
>     static void
>     createIterate(const A1& a1,
>!		const Function& function,
>  		const Interval<Dim> &domain,
>  		ScalarCodeInfo &info,
>  		const Kernel &)
>--- 158,164 ----
>     template<class A1, class Function, int Dim, class Kernel>
>     static void
>     createIterate(const A1& a1,
>!		Function& function,
>  		const Interval<Dim> &domain,
>  		ScalarCodeInfo &info,
>  		const Kernel &)
>*************** public:
>*** 196,202 ****
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg& multiArg,
>!	   const Function& function,
>  	   Interval<Dim> domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>--- 196,202 ----
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg& multiArg,
>!	   Function& function,
>  	   Interval<Dim> domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>*************** public:
>*** 237,243 ****
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   const Function &function,
>  	   const Interval<Dim> &domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>--- 237,243 ----
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   Function &function,
>  	   const Interval<Dim> &domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>*************** struct MultiArgEvaluator<RemoteSinglePat
>*** 288,294 ****
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   const Function &function,
>  	   const Interval<Dim> &domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>--- 288,294 ----
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   Function &function,
>  	   const Interval<Dim> &domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>*************** struct MultiArgEvaluator<RemoteMultiPatc
>*** 338,344 ****
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   const Function &function,
>  	   const Interval<Dim> &domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>--- 338,344 ----
>     template<class MultiArg, class Function, int Dim, class Kernel>
>     static void
>     evaluate(const MultiArg &multiArg,
>!	   Function &function,
>  	   const Interval<Dim> &domain,
>  	   ScalarCodeInfo &info,
>  	   const Kernel &kernel)
>*************** struct MultiArgEvaluatorTag<MultiArg3<A1
>*** 385,390 ****
>--- 385,435 ----
>     Evaluator_t;
>   };
>
>+ template<class A1, class A2, class A3, class A4>
>+ struct MultiArgEvaluatorTag<MultiArg4<A1, A2, A3, A4> >
>+ {
>+   typedef typename EvaluatorTag1<A1>::Evaluator_t Eval1_t;
>+   typedef typename EvaluatorTag1<A2>::Evaluator_t Eval2_t;
>+   typedef typename EvaluatorTag1<A3>::Evaluator_t Eval3_t;
>+   typedef typename EvaluatorTag1<A4>::Evaluator_t Eval4_t;
>+   typedef typename EvaluatorCombine<Eval1_t, Eval2_t>::Evaluator_t Eval12_t;
>+   typedef typename EvaluatorCombine<Eval3_t, 
>Eval12_t>::Evaluator_t  Eval123_t;
>+   typedef typename EvaluatorCombine<Eval4_t, Eval123_t>::Evaluator_t
>+   Evaluator_t;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5>
>+ struct MultiArgEvaluatorTag<MultiArg5<A1, A2, A3, A4, A5> >
>+ {
>+   typedef typename EvaluatorTag1<A1>::Evaluator_t Eval1_t;
>+   typedef typename EvaluatorTag1<A2>::Evaluator_t Eval2_t;
>+   typedef typename EvaluatorTag1<A3>::Evaluator_t Eval3_t;
>+   typedef typename EvaluatorTag1<A4>::Evaluator_t Eval4_t;
>+   typedef typename EvaluatorTag1<A5>::Evaluator_t Eval5_t;
>+   typedef typename EvaluatorCombine<Eval1_t, Eval2_t>::Evaluator_t Eval12_t;
>+   typedef typename EvaluatorCombine<Eval3_t, 
>Eval12_t>::Evaluator_t  Eval123_t;
>+   typedef typename EvaluatorCombine<Eval4_t, 
>Eval123_t>::Evaluator_t  Eval1234_t;
>+   typedef typename EvaluatorCombine<Eval5_t, Eval1234_t>::Evaluator_t
>+   Evaluator_t;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class A6>
>+ struct MultiArgEvaluatorTag<MultiArg6<A1, A2, A3, A4, A5, A6> >
>+ {
>+   typedef typename EvaluatorTag1<A1>::Evaluator_t Eval1_t;
>+   typedef typename EvaluatorTag1<A2>::Evaluator_t Eval2_t;
>+   typedef typename EvaluatorTag1<A3>::Evaluator_t Eval3_t;
>+   typedef typename EvaluatorTag1<A4>::Evaluator_t Eval4_t;
>+   typedef typename EvaluatorTag1<A5>::Evaluator_t Eval5_t;
>+   typedef typename EvaluatorTag1<A6>::Evaluator_t Eval6_t;
>+   typedef typename EvaluatorCombine<Eval1_t, Eval2_t>::Evaluator_t Eval12_t;
>+   typedef typename EvaluatorCombine<Eval3_t, 
>Eval12_t>::Evaluator_t  Eval123_t;
>+   typedef typename EvaluatorCombine<Eval4_t, 
>Eval123_t>::Evaluator_t  Eval1234_t;
>+   typedef typename EvaluatorCombine<Eval5_t, 
>Eval1234_t>::Evaluator_t  Eval12345_t;
>+   typedef typename EvaluatorCombine<Eval6_t, Eval12345_t>::Evaluator_t
>+   Evaluator_t;
>+ };
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7>
>   struct MultiArgEvaluatorTag<MultiArg7<A1, A2, A3, A4, A5, A6, A7> >
>   {
>*************** struct MultiArgEvaluatorTag<MultiArg7<A1
>*** 411,416 ****
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: MultiArgEvaluator.h,v $   $Author: jxyh $
>! // $Revision: 1.5 $   $Date: 2001/03/04 06:46:48 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>--- 456,461 ----
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: MultiArgEvaluator.h,v $   $Author: jxyh $
>! // $Revision: 1.7 $   $Date: 2001/03/14 05:36:16 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>Index: src/Evaluator/ScalarCode.h
>===================================================================
>RCS file: /usr/local/pooma/repository/r2/src/Evaluator/ScalarCode.h,v
>retrieving revision 1.5
>retrieving revision 1.7
>diff -c -p -r1.5 -r1.7
>*** ScalarCode.h	2001/03/04 22:19:15	1.5
>--- ScalarCode.h	2001/03/14 05:36:16	1.7
>*************** struct ApplyMultiArgLoc<MultiArg1<A1>, F
>*** 102,108 ****
>   template<class A1, class A2, class Function>
>   struct ApplyMultiArgLoc<MultiArg2<A1, A2>, Function>
>   {
>!   ApplyMultiArgLoc(const MultiArg2<A1, A2> &multiArg,const 
>Function &function)
>       : multiArg_m(multiArg), function_m(function)
>     {
>     }
>--- 102,108 ----
>   template<class A1, class A2, class Function>
>   struct ApplyMultiArgLoc<MultiArg2<A1, A2>, Function>
>   {
>!   ApplyMultiArgLoc(const MultiArg2<A1, A2> &multiArg,Function &function)
>       : multiArg_m(multiArg), function_m(function)
>     {
>     }
>*************** struct ApplyMultiArgLoc<MultiArg2<A1, A2
>*** 128,141 ****
>     }
>
>     const MultiArg2<A1, A2> &multiArg_m;
>!   const Function &function_m;
>   };
>
>   template<class A1, class A2, class A3, class Function>
>   struct ApplyMultiArgLoc<MultiArg3<A1, A2, A3>, Function>
>   {
>     ApplyMultiArgLoc(const MultiArg3<A1, A2, A3> &multiArg,
>!		   const Function &function)
>       : multiArg_m(multiArg), function_m(function)
>     {
>     }
>--- 128,141 ----
>     }
>
>     const MultiArg2<A1, A2> &multiArg_m;
>!   Function &function_m;
>   };
>
>   template<class A1, class A2, class A3, class Function>
>   struct ApplyMultiArgLoc<MultiArg3<A1, A2, A3>, Function>
>   {
>     ApplyMultiArgLoc(const MultiArg3<A1, A2, A3> &multiArg,
>!		   Function &function)
>       : multiArg_m(multiArg), function_m(function)
>     {
>     }
>*************** struct ApplyMultiArgLoc<MultiArg3<A1, A2
>*** 165,178 ****
>     }
>
>     const MultiArg3<A1, A2, A3> &multiArg_m;
>!   const Function &function_m;
>   };
>
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7, class Function>
>   struct ApplyMultiArgLoc<MultiArg7<A1, A2, A3, A4, A5, A6, A7>, Function>
>   {
>     ApplyMultiArgLoc(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg,
>!		   const Function &function)
>       : multiArg_m(multiArg), function_m(function)
>     {
>     }
>--- 165,293 ----
>     }
>
>     const MultiArg3<A1, A2, A3> &multiArg_m;
>!   Function &function_m;
>   };
>
>+ template<class A1, class A2, class A3, class A4, class Function>
>+ struct ApplyMultiArgLoc<MultiArg4<A1, A2, A3, A4>, Function>
>+ {
>+   ApplyMultiArgLoc(const MultiArg4<A1, A2, A3, A4> &multiArg,
>+		   Function &function)
>+     : multiArg_m(multiArg), function_m(function)
>+   {
>+   }
>+
>+   void operator()(int i0)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, Loc<1>(i0));
>+   }
>+
>+   void operator()(int i0, int i1)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, Loc<2>(i0, i1));
>+   }
>+
>+   void operator()(int i0, int i1, int i2)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, Loc<3>(i0, i1, i2));
>+   }
>+
>+   void operator()(int i0, int i1, int i2, int i3)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, Loc<4>(i0, i1, i2, i3));
>+   }
>+
>+   const MultiArg4<A1, A2, A3, A4> &multiArg_m;
>+   Function &function_m;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class Function>
>+ struct ApplyMultiArgLoc<MultiArg5<A1, A2, A3, A4, A5>, Function>
>+ {
>+   ApplyMultiArgLoc(const MultiArg5<A1, A2, A3, A4, A5> &multiArg,
>+		   Function &function)
>+     : multiArg_m(multiArg), function_m(function)
>+   {
>+   }
>+
>+   void operator()(int i0)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<1>(i0));
>+   }
>+
>+   void operator()(int i0, int i1)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<2>(i0, i1));
>+   }
>+
>+   void operator()(int i0, int i1, int i2)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<3>(i0, i1, i2));
>+   }
>+
>+   void operator()(int i0, int i1, int i2, int i3)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, Loc<4>(i0, i1, i2, i3));
>+   }
>+
>+   const MultiArg5<A1, A2, A3, A4, A5> &multiArg_m;
>+   Function &function_m;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class Function>
>+ struct ApplyMultiArgLoc<MultiArg6<A1, A2, A3, A4, A5, A6>, Function>
>+ {
>+   ApplyMultiArgLoc(const MultiArg6<A1, A2, A3, A4, A5, A6> &multiArg,
>+		   Function &function)
>+     : multiArg_m(multiArg), function_m(function)
>+   {
>+   }
>+
>+   void operator()(int i0)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
>+                Loc<1>(i0));
>+   }
>+
>+   void operator()(int i0, int i1)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
>+                Loc<2>(i0, i1));
>+   }
>+
>+   void operator()(int i0, int i1, int i2)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
>+                Loc<3>(i0, i1, i2));
>+   }
>+
>+   void operator()(int i0, int i1, int i2, int i3)
>+   {
>+     function_m(multiArg_m.a1_m, multiArg_m.a2_m, multiArg_m.a3_m,
>+                multiArg_m.a4_m, multiArg_m.a5_m, multiArg_m.a6_m,
>+                Loc<4>(i0, i1, i2, i3));
>+   }
>+
>+   const MultiArg6<A1, A2, A3, A4, A5, A6> &multiArg_m;
>+   Function &function_m;
>+ };
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7, class Function>
>   struct ApplyMultiArgLoc<MultiArg7<A1, A2, A3, A4, A5, A6, A7>, Function>
>   {
>     ApplyMultiArgLoc(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg,
>!		   Function &function)
>       : multiArg_m(multiArg), function_m(function)
>     {
>     }
>*************** struct ApplyMultiArgLoc<MultiArg7<A1, A2
>*** 206,212 ****
>     }
>
>     const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg_m;
>!   const Function &function_m;
>   };
>
>   template<class Function, int Dim>
>--- 321,327 ----
>     }
>
>     const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiArg_m;
>!   Function &function_m;
>   };
>
>   template<class Function, int Dim>
>*************** struct EvaluateLocLoop
>*** 216,222 ****
>     {
>     }
>
>!   EvaluateLocLoop(const Function &function, const Interval<Dim> &domain)
>       : function_m(function), domain_m(domain)
>     {
>     }
>--- 331,337 ----
>     {
>     }
>
>!   EvaluateLocLoop(Function &function, const Interval<Dim> &domain)
>       : function_m(function), domain_m(domain)
>     {
>     }
>*************** struct ScalarCode
>*** 239,245 ****
>     {
>     }
>
>!   ScalarCode(const Function &function)
>       : function_m(function)
>     {
>     }
>--- 354,360 ----
>     {
>     }
>
>!   ScalarCode(Function &function)
>       : function_m(function)
>     {
>     }
>*************** struct ScalarCode
>*** 283,288 ****
>--- 398,442 ----
>  	       kernel);
>     }
>
>+   template<class F1, class F2, class F3, class F4>
>+   void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const F4 &f4)
>+   {
>+     enum { dimensions = F1::dimensions };
>+     MultiArg4<F1, F2, F3, F4> multiArg(f1, f2, f3, f4);
>+     EvaluateLocLoop<Function, dimensions> 
>kernel(function_m,f1.physicalDomain());
>+
>+     MultiArgEvaluator<MainEvaluatorTag>().
>+       evaluate<MultiArg4<F1, F2, F3, F4> >(multiArg, function_m,
>+	       f1.physicalDomain(),
>+	       kernel);
>+   }
>+
>+   template<class F1, class F2, class F3, class F4, class F5>
>+   void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const 
>F4 &f4, const F5 &f5)
>+   {
>+     enum { dimensions = F1::dimensions };
>+     MultiArg5<F1, F2, F3, F4, F5> multiArg(f1, f2, f3, f4, f5);
>+     EvaluateLocLoop<Function, dimensions> 
>kernel(function_m,f1.physicalDomain());
>+
>+     MultiArgEvaluator<MainEvaluatorTag>().
>+       evaluate<MultiArg5<F1, F2, F3, F4, F5> >(multiArg, function_m,
>+	       f1.physicalDomain(),
>+	       kernel);
>+   }
>+
>+   template<class F1, class F2, class F3, class F4, class F5, class F6>
>+   void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const 
>F4 &f4, const F5 &f5, const F6 &f6)
>+   {
>+     enum { dimensions = F1::dimensions };
>+     MultiArg6<F1, F2, F3, F4, F5, F6> multiArg(f1, f2, f3, f4, f5, f6);
>+     EvaluateLocLoop<Function, dimensions> 
>kernel(function_m,f1.physicalDomain());
>+
>+     MultiArgEvaluator<MainEvaluatorTag>().
>+       evaluate<MultiArg6<F1, F2, F3, F4, F5, F6> >(multiArg, function_m,
>+	       f1.physicalDomain(),
>+	       kernel);
>+   }
>+
>     template<class F1, class F2, class F3, class F4, class F5, class 
>F6, class F7>
>     void operator()(const F1 &f1, const F2 &f2, const F3 &f3, const 
>F4 &f4, const F5 &f5, const F6 &f6, const F7 &f7)
>     {
>*************** struct ScalarCode
>*** 308,313 ****
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: ScalarCode.h,v $   $Author: jxyh $
>! // $Revision: 1.5 $   $Date: 2001/03/04 22:19:15 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>--- 462,467 ----
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: ScalarCode.h,v $   $Author: jxyh $
>! // $Revision: 1.7 $   $Date: 2001/03/14 05:36:16 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>Index: src/Evaluator/ScalarCodeInfo.h
>===================================================================
>RCS file: /usr/local/pooma/repository/r2/src/Evaluator/ScalarCodeInfo.h,v
>retrieving revision 1.2
>retrieving revision 1.3
>diff -c -p -r1.2 -r1.3
>*** ScalarCodeInfo.h	2001/03/04 06:46:48	1.2
>--- ScalarCodeInfo.h	2001/03/13 06:32:22	1.3
>*************** public:
>*** 176,183 ****
>         ret[d] =
>  	Interval<1>(
>   //		    lower_m[d],
>!             domain[d].first(),
>!		    domain[d].last() - domain[d].first() // + lower_m[d]
>  		    );
>       }
>       return ret;
>--- 176,183 ----
>         ret[d] =
>  	Interval<1>(
>   //		    lower_m[d],
>!             domain[d].first() + lower_m[d],
>!		    domain[d].last() - domain[d].first() + lower_m[d]
>  		    );
>       }
>       return ret;
>*************** private:
>*** 209,214 ****
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: ScalarCodeInfo.h,v $   $Author: jxyh $
>! // $Revision: 1.2 $   $Date: 2001/03/04 06:46:48 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>--- 209,214 ----
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: ScalarCodeInfo.h,v $   $Author: jxyh $
>! // $Revision: 1.3 $   $Date: 2001/03/13 06:32:22 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>Index: src/Functions/MultiArg.h
>===================================================================
>RCS file: /usr/local/pooma/repository/r2/src/Functions/MultiArg.h,v
>retrieving revision 1.4
>retrieving revision 1.5
>diff -c -p -r1.4 -r1.5
>*** MultiArg.h	2001/03/04 06:47:18	1.4
>--- MultiArg.h	2001/03/11 00:34:29	1.5
>***************
>*** 81,86 ****
>--- 81,89 ----
>   template<class A1> struct MultiArg1;
>   template<class A1, class A2> struct MultiArg2;
>   template<class A1, class A2, class A3> struct MultiArg3;
>+ template<class A1, class A2, class A3, class A4> struct MultiArg4;
>+ template<class A1, class A2, class A3, class A4, class A5> struct MultiArg5;
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6> struct MultiArg6;
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7> struct MultiArg7;
>
>   // These MultiArgView structs are workarounds for Compaq's
>*************** struct MultiArgView3
>*** 111,116 ****
>--- 114,152 ----
>     typedef MultiArg3<A1_t, A2_t, A3_t> Type_t;
>   };
>
>+ template<class A1, class A2, class A3, class A4, class Dom>
>+ struct MultiArgView4
>+ {
>+   typedef typename View1<A1, Dom>::Type_t A1_t;
>+   typedef typename View1<A2, Dom>::Type_t A2_t;
>+   typedef typename View1<A3, Dom>::Type_t A3_t;
>+   typedef typename View1<A4, Dom>::Type_t A4_t;
>+   typedef MultiArg4<A1_t, A2_t, A3_t, A4_t> Type_t;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class Dom>
>+ struct MultiArgView5
>+ {
>+   typedef typename View1<A1, Dom>::Type_t A1_t;
>+   typedef typename View1<A2, Dom>::Type_t A2_t;
>+   typedef typename View1<A3, Dom>::Type_t A3_t;
>+   typedef typename View1<A4, Dom>::Type_t A4_t;
>+   typedef typename View1<A5, Dom>::Type_t A5_t;
>+   typedef MultiArg5<A1_t, A2_t, A3_t, A4_t, A5_t> Type_t;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class Dom>
>+ struct MultiArgView6
>+ {
>+   typedef typename View1<A1, Dom>::Type_t A1_t;
>+   typedef typename View1<A2, Dom>::Type_t A2_t;
>+   typedef typename View1<A3, Dom>::Type_t A3_t;
>+   typedef typename View1<A4, Dom>::Type_t A4_t;
>+   typedef typename View1<A5, Dom>::Type_t A5_t;
>+   typedef typename View1<A6, Dom>::Type_t A6_t;
>+   typedef MultiArg6<A1_t, A2_t, A3_t, A4_t, A5_t, A6_t> Type_t;
>+ };
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7, class Dom>
>   struct MultiArgView7
>   {
>*************** struct View1<MultiArg3<A1, A2, A3>, Dom>
>*** 142,147 ****
>--- 178,201 ----
>     typedef typename MultiArgView3<A1, A2, A3, Dom>::Type_t Type_t;
>   };
>
>+ template<class A1, class A2, class A3, class A4, class Dom>
>+ struct View1<MultiArg4<A1, A2, A3, A4>, Dom>
>+ {
>+   typedef typename MultiArgView4<A1, A2, A3, A4, Dom>::Type_t Type_t;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class Dom>
>+ struct View1<MultiArg5<A1, A2, A3, A4, A5>, Dom>
>+ {
>+   typedef typename MultiArgView5<A1, A2, A3, A4, A5, Dom>::Type_t Type_t;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class Dom>
>+ struct View1<MultiArg6<A1, A2, A3, A4, A5, A6>, Dom>
>+ {
>+   typedef typename MultiArgView6<A1, A2, A3, A4, A5, A6, 
>Dom>::Type_t Type_t;
>+ };
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7, class Dom>
>   struct View1<MultiArg7<A1, A2, A3, A4, A5, A6, A7>, Dom>
>   {
>*************** struct MultiArg3
>*** 214,219 ****
>--- 268,348 ----
>     A3 a3_m;
>   };
>
>+ template<class A1, class A2, class A3, class A4>
>+ struct MultiArg4
>+ {
>+   enum { size = 4 };
>+
>+   MultiArg4(const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4)
>+     : a1_m(a1), a2_m(a2), a3_m(a3), a4_m(a4)
>+   {
>+   }
>+
>+   template<class Dom>
>+   typename View1<MultiArg4<A1, A2, A3, A4>, Dom>::Type_t
>+   operator()(Dom &dom) const
>+   {
>+     typedef typename View1<MultiArg4<A1, A2, A3, A4>, Dom>::Type_t Ret_t;
>+     return Ret_t(a1_m(dom), a2_m(dom), a3_m(dom), a4_m(dom));
>+   }
>+
>+   A1 a1_m;
>+   A2 a2_m;
>+   A3 a3_m;
>+   A4 a4_m;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5>
>+ struct MultiArg5
>+ {
>+   enum { size = 5 };
>+
>+   MultiArg5(const A1 &a1, const A2 &a2, const A3 &a3, const A4 
>&a4, const A5 &a5)
>+     : a1_m(a1), a2_m(a2), a3_m(a3), a4_m(a4), a5_m(a5)
>+   {
>+   }
>+
>+   template<class Dom>
>+   typename View1<MultiArg5<A1, A2, A3, A4, A5>, Dom>::Type_t
>+   operator()(Dom &dom) const
>+   {
>+     typedef typename View1<MultiArg5<A1, A2, A3, A4, A5>, 
>Dom>::Type_t Ret_t;
>+     return Ret_t(a1_m(dom), a2_m(dom), a3_m(dom), a4_m(dom), a5_m(dom));
>+   }
>+
>+   A1 a1_m;
>+   A2 a2_m;
>+   A3 a3_m;
>+   A4 a4_m;
>+   A5 a5_m;
>+ };
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class A6>
>+ struct MultiArg6
>+ {
>+   enum { size = 6 };
>+
>+   MultiArg6(const A1 &a1, const A2 &a2, const A3 &a3, const A4 
>&a4, const A5 &a5, const A6 &a6)
>+     : a1_m(a1), a2_m(a2), a3_m(a3), a4_m(a4), a5_m(a5), a6_m(a6)
>+   {
>+   }
>+
>+   template<class Dom>
>+   typename View1<MultiArg6<A1, A2, A3, A4, A5, A6>, Dom>::Type_t
>+   operator()(Dom &dom) const
>+   {
>+     typedef typename View1<MultiArg6<A1, A2, A3, A4, A5, A6>, 
>Dom>::Type_t Ret_t;
>+     return Ret_t(a1_m(dom), a2_m(dom), a3_m(dom), a4_m(dom), 
>a5_m(dom), a6_m(dom));
>+   }
>+
>+   A1 a1_m;
>+   A2 a2_m;
>+   A3 a3_m;
>+   A4 a4_m;
>+   A5 a5_m;
>+   A6 a6_m;
>+ };
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7>
>   struct MultiArg7
>   {
>*************** void applyMultiArg(const MultiArg3<A1, A
>*** 283,288 ****
>--- 412,459 ----
>     f(node.a1_m, node.a2_m, node.a3_m, i1, i2);
>   }
>
>+ template<class A1, class A2, class A3, class A4, class Function>
>+ void applyMultiArg(const MultiArg4<A1, A2, A3, A4> &node,
>+	       const Function &f, int i1)
>+ {
>+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, i1);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class Function>
>+ void applyMultiArg(const MultiArg4<A1, A2, A3, A4> &node,
>+	       const Function &f, int i1, int i2)
>+ {
>+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, i1, i2);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class Function>
>+ void applyMultiArg(const MultiArg5<A1, A2, A3, A4, A5> &node,
>+	       const Function &f, int i1)
>+ {
>+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, i1);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class Function>
>+ void applyMultiArg(const MultiArg5<A1, A2, A3, A4, A5> &node,
>+	       const Function &f, int i1, int i2)
>+ {
>+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, i1, i2);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class Function>
>+ void applyMultiArg(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
>+	       const Function &f, int i1)
>+ {
>+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, node.a6_m, i1);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class Function>
>+ void applyMultiArg(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
>+	       const Function &f, int i1, int i2)
>+ {
>+   f(node.a1_m, node.a2_m, node.a3_m, node.a4_m, node.a5_m, 
>node.a6_m, i1, i2);
>+ }
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7, class Function>
>   void applyMultiArg(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &node,
>  	       const Function &f, int i1)
>*************** void applyMultiArg(const MultiArg3<A1, A
>*** 324,329 ****
>--- 495,536 ----
>     f(node.a3_m, condition[2]);
>   }
>
>+ template<class A1, class A2, class A3, class A4, class Function>
>+ void applyMultiArg(const MultiArg4<A1, A2, A3, A4> &node,
>+	       const Function &f,
>+	       const std::vector<bool> &condition)
>+ {
>+   f(node.a1_m, condition[0]);
>+   f(node.a2_m, condition[1]);
>+   f(node.a3_m, condition[2]);
>+   f(node.a4_m, condition[3]);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class Function>
>+ void applyMultiArg(const MultiArg5<A1, A2, A3, A4, A5> &node,
>+	       const Function &f,
>+	       const std::vector<bool> &condition)
>+ {
>+   f(node.a1_m, condition[0]);
>+   f(node.a2_m, condition[1]);
>+   f(node.a3_m, condition[2]);
>+   f(node.a4_m, condition[3]);
>+   f(node.a5_m, condition[4]);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class Function>
>+ void applyMultiArg(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
>+	       const Function &f,
>+	       const std::vector<bool> &condition)
>+ {
>+   f(node.a1_m, condition[0]);
>+   f(node.a2_m, condition[1]);
>+   f(node.a3_m, condition[2]);
>+   f(node.a4_m, condition[3]);
>+   f(node.a5_m, condition[4]);
>+   f(node.a6_m, condition[5]);
>+ }
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7, class Function>
>   void applyMultiArg(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &node,
>  	       const Function &f,
>*************** void applyMultiArgIf(const MultiArg3<A1,
>*** 374,379 ****
>--- 581,649 ----
>       f(node.a3_m);
>   }
>
>+ template<class A1, class A2, class A3, class A4, class Function>
>+ void applyMultiArgIf(const MultiArg4<A1, A2, A3, A4> &node,
>+		 const Function &f,
>+		 const std::vector<bool> &condition)
>+ {
>+   if (condition[0])
>+     f(node.a1_m);
>+
>+   if (condition[1])
>+     f(node.a2_m);
>+
>+   if (condition[2])
>+     f(node.a3_m);
>+
>+   if (condition[3])
>+     f(node.a4_m);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class Function>
>+ void applyMultiArgIf(const MultiArg5<A1, A2, A3, A4, A5> &node,
>+		 const Function &f,
>+		 const std::vector<bool> &condition)
>+ {
>+   if (condition[0])
>+     f(node.a1_m);
>+
>+   if (condition[1])
>+     f(node.a2_m);
>+
>+   if (condition[2])
>+     f(node.a3_m);
>+
>+   if (condition[3])
>+     f(node.a4_m);
>+
>+   if (condition[4])
>+     f(node.a5_m);
>+ }
>+
>+ template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class Function>
>+ void applyMultiArgIf(const MultiArg6<A1, A2, A3, A4, A5, A6> &node,
>+		 const Function &f,
>+		 const std::vector<bool> &condition)
>+ {
>+   if (condition[0])
>+     f(node.a1_m);
>+
>+   if (condition[1])
>+     f(node.a2_m);
>+
>+   if (condition[2])
>+     f(node.a3_m);
>+
>+   if (condition[3])
>+     f(node.a4_m);
>+
>+   if (condition[4])
>+     f(node.a5_m);
>+
>+   if (condition[5])
>+     f(node.a6_m);
>+ }
>+
>   template<class A1, class A2, class A3, class A4, class A5, class 
>A6, class A7, class Function>
>   void applyMultiArgIf(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &node,
>  		 const Function &f,
>*************** void applyMultiArgIf(const MultiArg7<A1,
>*** 406,411 ****
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: MultiArg.h,v $   $Author: jxyh $
>! // $Revision: 1.4 $   $Date: 2001/03/04 06:47:18 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>--- 676,681 ----
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>   // $RCSfile: MultiArg.h,v $   $Author: jxyh $
>! // $Revision: 1.5 $   $Date: 2001/03/11 00:34:29 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>Index: src/Pooma/PETE/AssertEquals.h
>===================================================================
>RCS file: /usr/local/pooma/repository/r2/src/Pooma/PETE/AssertEquals.h,v
>retrieving revision 1.2
>retrieving revision 1.3
>diff -c -p -r1.2 -r1.3
>*** AssertEquals.h	2000/03/07 13:18:06	1.2
>--- AssertEquals.h	2001/03/19 22:23:48	1.3
>*************** struct Combine2<int, int, Op, AssertEqua
>*** 79,86 ****
>   {
>     typedef int Type_t;
>     inline static
>!   Type_t combine(const int &a, const int &b,
>!		 const Op &, const AssertEquals &ae)
>     {
>       int ret = a;
>       if ((a != ae.ignore_m) && (b != ae.ignore_m))
>--- 79,85 ----
>   {
>     typedef int Type_t;
>     inline static
>!   Type_t combine(const int &a, const int &b, const AssertEquals &ae)
>     {
>       int ret = a;
>       if ((a != ae.ignore_m) && (b != ae.ignore_m))
>*************** struct Combine2<int, int, Op, AssertEqua
>*** 101,107 ****
>
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>! // $RCSfile: AssertEquals.h,v $   $Author: swhaney $
>! // $Revision: 1.2 $   $Date: 2000/03/07 13:18:06 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo
>--- 100,106 ----
>
>   // ACL:rcsinfo
>   // ----------------------------------------------------------------------
>! // $RCSfile: AssertEquals.h,v $   $Author: jxyh $
>! // $Revision: 1.3 $   $Date: 2001/03/19 22:23:48 $
>   // ----------------------------------------------------------------------
>   // ACL:rcsinfo



From mark at codesourcery.com  Wed Apr  4 03:58:49 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Tue, 03 Apr 2001 20:58:49 -0700
Subject: POOMA Changes from LANL
In-Reply-To: <p04320401b6f031ac5527@[128.165.16.39]>
References: <20010403120610Z.mitchell@codesourcery.com>
	<p04320401b6f031ac5527@[128.165.16.39]>
Message-ID: <20010403205849O.mitchell@codesourcery.com>

>>>>> "John" == John Hall <jxyh at lanl.gov> writes:

    John> Mark: I have already discussed the changes with Stephen
    John> Smith. They boil down to one missed change in removing the

Okie-dokie.

Stephen, since you're on top of this stuff, would you check in
whatever parts of John's stuff are still needed?

Thanks much,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From drnuke at lanl.gov  Wed Apr  4 17:19:43 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Wed, 4 Apr 2001 11:19:43 -0600
Subject: Boundary Conditions
Message-ID: <NDBBIAJIJKLEAIAEGGACMEOPCFAA.drnuke@lanl.gov>

serious question here folks.
Do the particles own their boundary conditions?  i'm running into a problem
where i'm adding the boundary conditions in a simple initialize type
function and then trying (unsuccessfully) to use the later in another
function.  I successfully built and added the boundary conditions ( printed
out particle objects using "out << Neutrons <<std::endl" ), but when i ask
to print out the particle information in the other function, it printed
garbage for the ranges on the boundary conditions.

-steve



From stephens at proximation.com  Wed Apr  4 17:27:11 2001
From: stephens at proximation.com (Stephen Smith)
Date: Wed, 4 Apr 2001 10:27:11 -0700 
Subject: Patch: Evaluator/ScalarCode.h
Message-ID: <F871BB04B0EA224A821A5274C31DF3150216B4@proxim-sf001.santafe.proximation.com>

These are a subset of the changes John Hall had made
to accomodate their use of ScalarCode where the function
objects contained quantaties that are modified.

Reviewed by myself and John Hall.
Tested on linux, serial, gcc-2.95.2

    Stephen




 <<difs_0404.txt>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010404/98330501/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: difs_0404.txt
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010404/98330501/attachment.txt>

From oldham at codesourcery.com  Wed Apr  4 18:55:24 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 4 Apr 2001 11:55:24 -0700
Subject: RFC: Hydrodynamics Kernel
Message-ID: <20010404115524.A15316@codesourcery.com>

Attached is a partially-completed hydrodynamics kernel program.  Upto
now, I have tried to program clean code, using Pooma abstractions and
trying to determine (and implement) the additional Pooma abstractions
needed to produce clean code.  Given the 15April deadline, soon, I
will begin hacking unclean code to ensure we have working code by the
deadline.

Comments regarding the two conceptual choices at the top of the code
are solicited.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
// Oldham, Jeffrey D.
// 2001Mar27
// Pooma

// Hydrodynamics Kernel Written Using POOMA

// Following is pseudocode for the hydrodynamics kernel program.  When
// the pseudocode is replaced by Pooma code, the program should
// perform one iteration of a predictor, but not corrector, scheme.
// The program should compile since unimplemented portions are protected by
// "PSEUDOCODE" preprocessor symbols.
// 
// To complete the problem, two conceptual choices remain.
// 1. How should corner masses and corner forces be implemented?
// 
//    Central to the staggered grid concept, a corner is the intersection
//    of two overlapping grids, one shifted half a unit in all dimensions
//    from the other.  For example, in a cell from a two-dimensional (2-D)
//    grid, there are four corner values, which I have marked using
//    2-D binary numbers.
// 
// 			|-------------------|
// 			|01               11|
// 			|         c         |
// 			|00               10|
// 			|-------------------|
// 
//    In three dimensions, there are eight corners in a cell.  Note that
//    referring to a corner value requires both (a cell and a binary
//    number) or (a vertex and a binary number).
// 
//    The pseudocode has ??? operations on these corner fields:
//    1. sumAroundCell(CornerField): For each cell, add together all its
//       corners.  Form a ConstField with the sums at each cell.
//    2. sumAroundVertex(CornerField): For each vertex, add together all
//       its corners.  Form a ConstField with the sums at each vertex.
//    3. computeCornerVolumes(coordinates): Form a CornerField using the
//       coordinates Field as input.  This involves one computation per
//       corner.
//    4. computeCornerForces(pressure, coordinates): Form a CornerField
//       using the two given Fields as input.  This involves one
//       computation per corner.  Pseudocode, which is repetitious, is
//       given.
//    5. Mathematical operation \dot(CornerField, vertex-centered-field).
//       Note the two operands have different number of values, but the
//       "right thing" should happen, i.e., each all corner values around
//       a vertex should each be dotted with the corresponding vertex
//       value.
// 
// 2. Field Stenciling.
// 
//    vertex-centered-field = computeVolumes(cell-centered-field)
// 
//    Scott Haney says that NewField stencils are either broken or
//    difficult (I do not remember which).  Instead he suggested using
//    data-parallel statements, but this requires producing a "parallel"
//    version of the product operation.  Will NewField stencils be fully
//    supported in Pooma 2.4?
// 
// Unfinished Coding Tasks:
// 1. Decide corner field implementation and then implement the
//    operations on it.
// 2. Finish implementing computeVolumes() Field operation.
// 3. Convert to cylindrical or Lagrangian coordinates.
// 4. Improve initialization of "coordinates" Field.
// 5. Improve the implementation of velocity boundary conditions.


// *******************************************************************

#include <iostream>
#include <stdlib.h>
#include <cmath>
#include "Pooma/NewFields.h"

// This hydrodynamics program implements "The Construction of
// Compatible Hydrodynamics Algorithms Utilizing Conservation of Total
// Energy," by E.J. Caramana, D.E. Burton, M.J. Shashkov, and
// P.P. Whalen, \emph{Journal of Computational Physics}, vol. 146
// (1998), pp. 227-262.


// Forward Declarations
template <class Geometry, class VtxT, class T, class Engine>
void computeVolumes(const Field<Geometry,VtxT,Engine> & vtxCentered,
		    Field<Geometry,T,Engine> & output);

template <class Geometry, class VtxT, class Engine>
void enforceZeroPerpendicularComponent(Field<Geometry,VtxT,Engine> & f,
				       const Interval<1> & xInterval,
				       const Interval<1> & yInterval);


// The Hydrodynamics Program
int main(int argc, char *argv[])
{
  // Set up the Pooma library.
  Pooma::initialize(argc,argv);
#ifdef DEBUG
  std::cout << "Hello, world." << std::endl;
#endif // DEBUG

  // Values
  const double gamma = 4.0/3;		// gas pressure constant $\gamma$
  const double timeStep = 0.01;		// $\Delta t$
  unsigned nuIterations = 1;		// number of iterations

  // Create a simple layout.
  // TODO: Change to Cylindrical coordinates?
  const unsigned Dim = 2;		// Work in a 2D world.
  const unsigned nHorizVerts = 11;	// number of horizontal vertices
  const unsigned nAngles = 5;		// number of angles
  Interval<Dim> vertexDomain;
  vertexDomain[0] = Interval<1>(nHorizVerts);
  vertexDomain[1] = Interval<1>(nAngles);
  DomainLayout<Dim> layout(vertexDomain, GuardLayers<2>(1));

  // Preparation for Field creation.
  Vector<Dim> origin(0.0);
  Vector<Dim> spacings(1.0,1.0);  // TODO: What does this do?
  typedef UniformRectilinear<Dim, double, Cartesian<Dim> > Geometry_t;
  typedef Field<Geometry_t, double,      Brick> Fields_t;
  typedef Field<Geometry_t, double,      Brick> ConstFields_t; // TODO: Change to ConstField when ConstField is available.
  typedef Field<Geometry_t, Vector<Dim>, Brick> Fieldv_t;
  typedef Field<Geometry_t, Vector<Dim>, Brick> ConstFieldv_t; // TODO: Change to ConstField when ConstField is available.

  // Cell-centered Fields.
  Cell cell;
  Fields_t internalEnergy  (cell, layout, origin, spacings);
  ConstFields_t zoneMass   (cell, layout, origin, spacings);
  Fields_t pressure	   (cell, layout, origin, spacings);
  Fields_t pressureDensity (cell, layout, origin, spacings);
  Fields_t volume	   (cell, layout, origin, spacings);

  // Vertex-centered Fields.
  Vert vert;
  ConstFields_t pointMass  (vert, layout, origin, spacings);
  Fieldv_t coordinates	   (vert, layout, origin, spacings);
  Fieldv_t velocity	   (vert, layout, origin, spacings);
  Fieldv_t velocityChange  (vert, layout, origin, spacings);

  // Corner Fields.
#ifdef PSEUDOCODE
  // TODO: How should I implement corner Fields?
  Fieldv_t cornerForce	   (ReplicateSubFields<Cell>(1<<Dim), layout,
			    origin, spacings);
  Fields_t cornerMass      (ReplicateSubFields<Cell>(1<<Dim), layout,
			    origin, spacings);
#endif // PSEUDOCODE

  // Initialization
  // TODO: Is coordinates initialization necessary?  What is the best way to do this?
  for (unsigned xIndex = 0; xIndex <= vertexDomain[0].last (); ++xIndex)
    for (unsigned yIndex = 0; yIndex <= vertexDomain[1].last (); ++yIndex)
      coordinates(xIndex,yIndex) = Vector<2>(xIndex,yIndex);
#ifdef DEBUG
  std::cout << "initial coordinates:\n" << coordinates << std::endl;
#endif // DEBUG
  internalEnergy = 1.0;
  pressureDensity = 1.0;
#ifdef PSEUDOCODE
  cornerMass = pressureDensity * computeCornerVolumes(coordinates);
  pointMass = sumAroundCell(cornerMass);
  zoneMass = sumAroundVertex(cornerMass);
#endif // PSEUDOCODE
  velocity = Vector<Dim>(0.0);
  velocityChange.addUpdaters(AllConstantFaceBC<Vector<Dim> >(Vector<Dim>(0.0), false));

  // Iterations
  for (; nuIterations > 0; --nuIterations) {
    pressure = (gamma - 1.0) * pressureDensity * internalEnergy;
    
#ifdef PSEUDOCODE
    cornerForce = computeCornerForces(pressure, coordinates);
    velocityChange =
      (timeStep / pointMass) * sumAroundCell(cornerForce);
    // TODO: Is there a better way to enforce boundary conditions?
    velocityChange.update();
    enforceZeroPerpendicularComponent(velocityChange,
				      vertexDomain[0], vertexDomain[1]);
    internalEnergy +=
      -(timeStep / pointMass) *
      sumAroundVertex(\dot(cornerForce, velocity + 0.5*velocityChange));
#endif // PSEUDOCODE

    coordinates += (velocity + 0.5*velocityChange) * timeStep;
    velocity += velocityChange;
#ifdef PSEUDOCODE
    volume = computeVolumes(coordinates);
#endif // PSEUDOCODE
    pressureDensity = zoneMass / volume;
  }

  // Termination
  std::cout << "final coordinates:\n" << coordinates << std::endl;

#ifdef DEBUG
  std::cout << "Goodbye, world." << std::endl;
#endif // DEBUG
  Pooma::finalize();
  return EXIT_SUCCESS;
}


// Helper Functions

// This Vector operation proves useful, but I do not know the name of
// the corresponding mathematical operation.
// TODO: Change to specialization for Dim=2.
template <int Dim, class T, class E>
Vector<Dim,T,E>
product(const Vector<Dim,T,E> &v, const Vector<Dim,T,E> &w)
{
  Vector<2,T,E> answer;
  answer(0) = v(0) * w(1);
  answer(1) = -v(1) * w(0);
  return answer;
}


// Compute each cell's volume.
// TODO: Change to handle any dimension or even 2D better.
// TODO: Rewrite using a FieldStencil.
// Geometry: Geometry of the two Field's.
// VtxT: Vector type of Vertex-centered Field
// T: scalar type of Cell-centered Field
// Engine: Engine of the two Field's.
// output should be cell-centered.
template <class Geometry, class VtxT, class T, class Engine>
void computeVolumes(const Field<Geometry,VtxT,Engine> & vtxCentered,
		    Field<Geometry,T,Engine> & output)
{
  // TODO: Check this computation for off-by-one issues.
  Field<Geometry,T,Engine>::Domain_t range = output.physicalCellDomain();
  output(range) = 0.5 *
    std::abs (sum (product (vtxCentered(range+Loc<2>(1,1))-vtxCentered(range+Loc<2>(0,0)),
			    vtxCentered(range+Loc<2>(1,0))-vtxCentered(range+Loc<2>(0,1)))));
  return;
}


// Ensure the field's boundaries' vectors have zero perpendicular
// components.
// TODO: Change to handle any dimension or even 2D better.
template <class Geometry, class VtxT, class Engine>
void enforceZeroPerpendicularComponent(Field<Geometry,VtxT,Engine> & f,
				       const Interval<1> & xInterval,
				       const Interval<1> & yInterval)
{
  f(0,yInterval).comp(0) = 0.0;
  f(xInterval,0).comp(1) = 0.0;
  return;
}


#ifdef PSEUDOCODE
// Compute the corner forces.
computeCornerForces(const Field & pressure, const Field & coordinates,
		    Field & cornerForces)
{
  Field<Geometry2,T,Engine>::Domain_t range = input.physicalCellDomain();
  Loc<Dim> previous_loc, loc, next_loc;
  previous_loc = Loc<2>(1,0); loc = Loc<2>(1,1); next_loc = Loc<2>(0,1);
  cornerForces[zoneToBinaryCorner(loc)](range) =
    pressure(range) * 0.5 *
    product(Vector<Dim>(1.0),
	    coordinates(range+next_loc) - coordinates(range+previous_loc));
  previous_loc = loc; loc = next_loc; next_loc = Loc<2>(0,0);
  cornerForces[zoneToBinaryCorner(loc)](range) =
    pressure(range) * 0.5 *
    product(Vector<Dim>(1.0),
	    coordinates(range+next_loc) - coordinates(range+previous_loc));
  previous_loc = loc; loc = next_loc; next_loc = Loc<2>(1,0);
  cornerForces[zoneToBinaryCorner(loc)](range) =
    pressure(range) * 0.5 *
    product(Vector<Dim>(1.0),
	    coordinates(range+next_loc) - coordinates(range+previous_loc));
  previous_loc = loc; loc = next_loc; next_loc = Loc<2>(1,1);
  cornerForces[zoneToBinaryCorner(loc)](range) =
    pressure(range) * 0.5 *
    product(Vector<Dim>(1.0),
	    coordinates(range+next_loc) - coordinates(range+previous_loc));
  return;
}
#endif // PSEUDOCODE

From drnuke at lanl.gov  Wed Apr  4 19:53:08 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Wed, 4 Apr 2001 13:53:08 -0600
Subject: Example of bad behavior from particle boundary conditions
Message-ID: <NDBBIAJIJKLEAIAEGGACEEPACFAA.drnuke@lanl.gov>

I have made a small adjustment to 'Bounce.cpp' to show the problem i'm
seeing.  i am compiling under Metrowerks 6.1 for the PC.  if I move the new
call, addBCs, around it exhibits different behavior.

i believe the problem may originate from a call in ParticleBC.h shown below.

  // Factory method to create the boundary condition.
  template <class Subject, class Object>
  ParticleBCItem* create(const Subject& s, const Object& o) const
  {
    typedef ParticleBC<Subject,Object,BCType> PBC_t;
    return new PBC_t(s, o, static_cast<const BCType&>(*this));
  }

the pointer is stored in a stl vector of bc pointers within the particle
base class.

something about this doesn't look quite right.

-steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bounce.cpp
Type: application/octet-stream
Size: 6402 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010404/ef4a891d/attachment.obj>

From drnuke at lanl.gov  Wed Apr  4 21:39:25 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Wed, 4 Apr 2001 15:39:25 -0600
Subject: Bugs
Message-ID: <NDBBIAJIJKLEAIAEGGACKEPACFAA.drnuke@lanl.gov>

1.  Code is crashing when I try to call

DynamicArray<int> kill;
kill.create( Neutrons.size() );

create call generates an error.  Neutrons in this case is just a Particle
object.


2.  sync() called with no parameters makes the code immediately exit with no
error messages

-steve



From jhall at swcp.com  Thu Apr  5 06:00:05 2001
From: jhall at swcp.com (John Hall)
Date: Thu, 5 Apr 2001 00:00:05 -0600
Subject: Should we make a branch for POOMA
Message-ID: <v04220800b6f1b80c5d44@[10.0.1.16]>

Scott,et al.:
Jean, Don, and I have a critical deadline of April 15 (yes, that's 
when it finally turned out to be) and we are making tremendous 
progress towards it. We have already coded the majority of the 
relevant parts to meet this deadline using Pooma R2. We need to be 
sure that we can keep moving forward at least until then. So I was 
thinking that we might need to tag the repository soon so that we 
could keep working and minor fixes could be made to the branch while 
you guys undertake the major changes you require as you start to 
remove the old field.
Take care,
John Hall


From cummings at linkline.com  Thu Apr  5 08:29:30 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 5 Apr 2001 01:29:30 -0700
Subject: [pooma-dev] particle suggestion
In-Reply-To: <NDBBIAJIJKLEAIAEGGACAEOOCFAA.drnuke@lanl.gov>
Message-ID: <NEBBLCJDELMDOJLGLNJGCEHJCBAA.cummings@linkline.com>

Steve,

The create() function already does something similar to push_back(),
and there is no need for the user to keep track of the end of the list.
You just say create(n), and n new slots get added to the end of every
particle attribute.  (That's a little different from push_back(), which
requires that you provide the item to be stored as an argument.)  You
do have to be a bit careful with create() in the multi-patch world,
specifying on which patch to add particles or whether to create the new
elements globally across all patches.  Is there a specific scenario
you have in mind where this functionality is not adequate?

I'm not sure what you want first() and last() to do.  Keep in mind 
that there is a global domain across all patches, and the particles
are numbered from 0 to N-1, where N is the global number of particles.
This numbering is updated by the renumber() method, which is invoked
during a sync() operation.  This global domain exists mainly to allow
Array data-parallel expressions to be evaluated properly.  Then there
is a local numbering on each patch, from 0 to n-1, where n is the size
of the given patch.  You can view a particular local patch of a
particle attribute using the method patchLocal(i).  You can query the 
size of this local patch using the size() method.  The size() method
of Particles gives you the global size N.

I hope I have answered your questions.
-- Julian C.


-----Original Message-----
From: Steve Nolen [mailto:drnuke at lanl.gov]
Sent: Tuesday, April 03, 2001 3:30 PM
To: Pooma
Subject: [pooma-dev] particle suggestion


would it be possible to add a particle by simply calling a push_back type
function.  this would avoid the user having to keep track of where the end
of a growing list of particles is.  a supported call for first() or last()
would also be nice, and would also solve the previous problem (maybe not if
the last() is only valid after a call to sync()?)

-steve




From cummings at linkline.com  Thu Apr  5 08:49:41 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 5 Apr 2001 01:49:41 -0700
Subject: [pooma-dev] Example of bad behavior from particle boundary conditions
In-Reply-To: <NDBBIAJIJKLEAIAEGGACEEPACFAA.drnuke@lanl.gov>
Message-ID: <NEBBLCJDELMDOJLGLNJGMEHJCBAA.cummings@linkline.com>

Hmmm... I took your modified version of
Bounce.cpp from the attachment and built
it under the Intel VTune compiler.  It
seems to compile and run just fine.

Unfortunately, I do not have a copy of
CW Pro 6.1 for the PC to test with.  Are
you able to run the CW debugger and see
what is going wrong?

-- Julian C.


-----Original Message-----
From: Steve Nolen [mailto:drnuke at lanl.gov]
Sent: Wednesday, April 04, 2001 12:53 PM
To: Pooma
Subject: [pooma-dev] Example of bad behavior from particle boundary
conditions


I have made a small adjustment to 'Bounce.cpp' to show the problem i'm
seeing.  i am compiling under Metrowerks 6.1 for the PC.  if I move the new
call, addBCs, around it exhibits different behavior.

i believe the problem may originate from a call in ParticleBC.h shown below.

  // Factory method to create the boundary condition.
  template <class Subject, class Object>
  ParticleBCItem* create(const Subject& s, const Object& o) const
  {
    typedef ParticleBC<Subject,Object,BCType> PBC_t;
    return new PBC_t(s, o, static_cast<const BCType&>(*this));
  }

the pointer is stored in a stl vector of bc pointers within the particle
base class.

something about this doesn't look quite right.

-steve



From cummings at linkline.com  Thu Apr  5 08:59:49 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 5 Apr 2001 01:59:49 -0700
Subject: [pooma-dev] Bugs
In-Reply-To: <NDBBIAJIJKLEAIAEGGACKEPACFAA.drnuke@lanl.gov>
Message-ID: <NEBBLCJDELMDOJLGLNJGAEHKCBAA.cummings@linkline.com>

Hi Steve,

>> 1.  Code is crashing when I try to call

>> DynamicArray<int> kill;
>> kill.create( Neutrons.size() );

>> create call generates an error.  Neutrons in this case is just a Particle
>> object.

What is the error message?  Have you checked the
value of Neutrons.size()?  This might be bad if
Neutrons.size() returns zero, for example.

>> 2.  sync() called with no parameters makes the code immediately exit with
>> no error messages

Yes, sync() with no arguments is basically unusable
and should be removed, IMO.  The original thought
here was that a ParticleSpatialLayout depends upon
the particle positions, and thus the user must pass
to sync() an attribute representing position.
Meanwhile, for ParticleUniformLayout no such particle
attribute is needed, because the distribution strategy
relies solely on balancing the number of particles
in each patch.  The problem is, you need to have a
particle attribute (i.e., a DynamicArray with its
DynamicLayout) to tell you how many particles there
are on each patch and let you create, destroy and
swap particle data.  So, in effect, you still need an
attribute argument to sync().

Maybe there is a way to fix this by allowing the
Particles object itself be an Observer of the
DynamicLayout that manages distribution of the
multi-patch DynamicArrays.  It would be nice to have
layout information without needing an attribute.
For now, though, pass an attribute to sync() even
when using ParticleUniformLayout.

-- Julian C.




From jcrotinger at mac.com  Thu Apr  5 14:02:00 2001
From: jcrotinger at mac.com (James Crotinger)
Date: Thu, 05 Apr 2001 08:02:00 -0600
Subject: [pooma-dev] Example of bad behavior from particle boundary
	conditions
In-Reply-To: <NEBBLCJDELMDOJLGLNJGMEHJCBAA.cummings@linkline.com>
Message-ID: <B6F1D6F8.4A26%jcrotinger@mac.com>

on 4/5/01 2:49 AM, Julian C. Cummings at cummings at linkline.com wrote:

> Unfortunately, I do not have a copy of
> CW Pro 6.1 for the PC to test with.  Are
> you able to run the CW debugger and see
> what is going wrong?

I've been attempting to do my development (working on the version of destroy
with iterator pairs) using CW 6.1 for the PC, and I've got to say that it
SUCKS. 

I'm planning to install VTUNE today and give it a try.

I've got the full cygwin32 installation - is there enough there to do
configure? Does that version of the compiler compile Pooma (its 2.95.2, I
think). 

    Jim



From drnuke at lanl.gov  Thu Apr  5 14:20:48 2001
From: drnuke at lanl.gov (Steve Nolen)
Date: Thu, 5 Apr 2001 08:20:48 -0600
Subject: [pooma-dev] Example of bad behavior from particle boundaryconditions
In-Reply-To: <B6F1D6F8.4A26%jcrotinger@mac.com>
Message-ID: <NDBBIAJIJKLEAIAEGGACAEPDCFAA.drnuke@lanl.gov>

has anyone tried running purify on this stuff?  Unfortunately, i'm not sure
i have access to a license for it. But if purify likes it, then i wouldn't
have much problem reporting it to Metrowerks as a bug.

-steve

> -----Original Message-----
> From: James Crotinger [mailto:jcrotinger at mac.com]
> Sent: Thursday, April 05, 2001 8:02 AM
> To: cummings at linkline.com; Steve Nolen; Pooma
> Subject: Re: [pooma-dev] Example of bad behavior from particle
> boundaryconditions
>
>
> on 4/5/01 2:49 AM, Julian C. Cummings at cummings at linkline.com wrote:
>
> > Unfortunately, I do not have a copy of
> > CW Pro 6.1 for the PC to test with.  Are
> > you able to run the CW debugger and see
> > what is going wrong?
>
> I've been attempting to do my development (working on the version
> of destroy
> with iterator pairs) using CW 6.1 for the PC, and I've got to say that it
> SUCKS.
>
> I'm planning to install VTUNE today and give it a try.
>
> I've got the full cygwin32 installation - is there enough there to do
> configure? Does that version of the compiler compile Pooma (its 2.95.2, I
> think).
>
>     Jim
>



From mark at codesourcery.com  Thu Apr  5 22:32:39 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 05 Apr 2001 15:32:39 -0700
Subject: [pooma-dev] Should we make a branch for POOMA
In-Reply-To: <v04220800b6f1b80c5d44@[10.0.1.16]>
References: <v04220800b6f1b80c5d44@[10.0.1.16]>
Message-ID: <20010405153239B.mitchell@codesourcery.com>


John --

  Yes, we can definitely tag and branch whenever you request.  Let me
know when is a good time, or give me a particular instant in time when
things worked well for you, and I will create the branch.

  Yours,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From mark at codesourcery.com  Thu Apr  5 22:46:16 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 05 Apr 2001 15:46:16 -0700
Subject: POOMA CVS log messages
In-Reply-To: <B6F1DF3E.5EC%scotth@proxim-sf001.santafe.proximation.com>
References: <B6F1DF3E.5EC%scotth@proxim-sf001.santafe.proximation.com>
Message-ID: <20010405154616X.mitchell@codesourcery.com>


Scott pointed out to me that there is a nice `log.pl' script that
comes with CVS that sends better log messages than the thing I cobbled
together.  I didn't know about this script because Red Hat chooses not
to install it with CVS.

Anyhow, I believe that I have now activated it, and that the pooma-cvs
messages should be a little better now.

Thanks,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From oldham at codesourcery.com  Thu Apr  5 23:32:27 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 5 Apr 2001 16:32:27 -0700
Subject: Dotting Two Vector Fields to Form a Scalar Field
Message-ID: <200104052332.QAA25892@oz.codesourcery.com>


The dot product of two vectors yields a scalar.  What syntax do I use
to form the dot product of two Vector Field's to form a scalar Field?
The two operands and the result should have the same domain size.

Thanks for the information,
Jeffrey D. Oldham
oldham at codesourcery.com


From jcrotinger at mac.com  Fri Apr  6 03:55:46 2001
From: jcrotinger at mac.com (James Crotinger)
Date: Thu, 05 Apr 2001 21:55:46 -0600
Subject: [pooma-dev] POOMA CVS log messages
In-Reply-To: <20010405154616X.mitchell@codesourcery.com>
Message-ID: <B6F29A62.4A36%jcrotinger@mac.com>

on 4/5/01 4:46 PM, Mark Mitchell at mark at codesourcery.com wrote:
> Anyhow, I believe that I have now activated it, and that the pooma-cvs
> messages should be a little better now.

They are.

Is there a way we could get the names of the modified files into the subject
line. We used to do that at LANL, but I don't remember exactly how. Here's
an example, though:

r2 log -  'r2/src/Evaluator/tests makefile evaluatorTest2.cpp'

Anyway, this helps give a heads up as to whether the log message is
particularly interesting or not (depending on what I might be working on).

  Jim



From cummings at linkline.com  Fri Apr  6 16:42:18 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 09:42:18 -0700
Subject: [pooma-dev] POOMA CVS log messages
In-Reply-To: <B6F29A62.4A36%jcrotinger@mac.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGAEIACBAA.cummings@linkline.com>

I set up our CVS repository at LANL to do what
Jim is talking about.  The way I did it is by
modifying the loginfo file in the CVSROOT
directory.  There is usually a command in there
that invokes the mail program to send an e-mail
with the cvs log message in it to the mailing
list.  You can use the -s option to the mail
program to set the subject line of this e-mail.
There should be a comment line in the cvs loginfo
file with instructions on exactly how to do this.

-- Julian C.

P.S.  I will see if I have access to this CVSROOT
module and can make this change.  Otherwise, Mark
can take care of it.



-----Original Message-----
From: James Crotinger [mailto:jcrotinger at mac.com]
Sent: Thursday, April 05, 2001 8:56 PM
To: Mark Mitchell; pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] POOMA CVS log messages


on 4/5/01 4:46 PM, Mark Mitchell at mark at codesourcery.com wrote:
> Anyhow, I believe that I have now activated it, and that the pooma-cvs
> messages should be a little better now.

They are.

Is there a way we could get the names of the modified files into the subject
line. We used to do that at LANL, but I don't remember exactly how. Here's
an example, though:

r2 log -  'r2/src/Evaluator/tests makefile evaluatorTest2.cpp'

Anyway, this helps give a heads up as to whether the log message is
particularly interesting or not (depending on what I might be working on).

  Jim




From mark at codesourcery.com  Fri Apr  6 17:05:24 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Fri, 06 Apr 2001 10:05:24 -0700
Subject: Status Reports
Message-ID: <20010406100524Y.mitchell@codesourcery.com>


Please post your weekly status reports.

Thank you,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From cummings at linkline.com  Fri Apr  6 18:24:02 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 11:24:02 -0700
Subject: [pooma-dev] POOMA CVS log messages
In-Reply-To: <NEBBLCJDELMDOJLGLNJGAEIACBAA.cummings@linkline.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGCEIBCBAA.cummings@linkline.com>

Well, I have access to the CVSROOT module,
but I'm not sure how to modify loginfo in
light of the use of this log.pl script.  I
don't have this script, so I don't know how
it works or how to tell it what subject line
to put on the e-mails.  Somehow we need to
pass it "r2 log - %s".  %s is turned into
the filename by cvs.  I'll let Mark fix this.

-- Julian C.


-----Original Message-----
From: Julian C. Cummings [mailto:cummings at linkline.com]
Sent: Friday, April 06, 2001 9:42 AM
To: pooma-dev at pooma.codesourcery.com
Subject: RE: [pooma-dev] POOMA CVS log messages


I set up our CVS repository at LANL to do what
Jim is talking about.  The way I did it is by
modifying the loginfo file in the CVSROOT
directory.  There is usually a command in there
that invokes the mail program to send an e-mail
with the cvs log message in it to the mailing
list.  You can use the -s option to the mail
program to set the subject line of this e-mail.
There should be a comment line in the cvs loginfo
file with instructions on exactly how to do this.

-- Julian C.

P.S.  I will see if I have access to this CVSROOT
module and can make this change.  Otherwise, Mark
can take care of it.



-----Original Message-----
From: James Crotinger [mailto:jcrotinger at mac.com]
Sent: Thursday, April 05, 2001 8:56 PM
To: Mark Mitchell; pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] POOMA CVS log messages


on 4/5/01 4:46 PM, Mark Mitchell at mark at codesourcery.com wrote:
> Anyhow, I believe that I have now activated it, and that the pooma-cvs
> messages should be a little better now.

They are.

Is there a way we could get the names of the modified files into the subject
line. We used to do that at LANL, but I don't remember exactly how. Here's
an example, though:

r2 log -  'r2/src/Evaluator/tests makefile evaluatorTest2.cpp'

Anyway, this helps give a heads up as to whether the log message is
particularly interesting or not (depending on what I might be working on).

  Jim





From cummings at linkline.com  Fri Apr  6 18:24:03 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 11:24:03 -0700
Subject: [pooma-dev] Dotting Two Vector Fields to Form a Scalar Field
In-Reply-To: <200104052332.QAA25892@oz.codesourcery.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGEEIBCBAA.cummings@linkline.com>

Jeffrey,

It *should* just be "dot(A,B)", where A and B
are the two vector Fields.  I have not tried 
this with NewFields to verify, but I'm pretty
sure it has been tested with Array.

-- Julian C.


-----Original Message-----
From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
Sent: Thursday, April 05, 2001 4:32 PM
To: pooma-dev at pooma.codesourcery.com
Subject: [pooma-dev] Dotting Two Vector Fields to Form a Scalar Field



The dot product of two vectors yields a scalar.  What syntax do I use
to form the dot product of two Vector Field's to form a scalar Field?
The two operands and the result should have the same domain size.

Thanks for the information,
Jeffrey D. Oldham
oldham at codesourcery.com



From cummings at linkline.com  Fri Apr  6 18:43:26 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 11:43:26 -0700
Subject: more on VC++ ide files
Message-ID: <NEBBLCJDELMDOJLGLNJGCEICCBAA.cummings@linkline.com>

Mark,

I think I know what the format problem
is with these files.  cvs is supposed to
automatically convert line endings in 
files to the proper form for the machine
where files get checked out (unless you 
use the -kb flag for binary files like the
CW Pro project files).  Since I am using 
cvs under cygwin, it is choosing to check
files out in Unix format.

I have not yet been able to get WinCVS to
work correctly with my cygwin ssh, so I 
cannot get these files checked out with
Dos line endings.  Hence, there is no way
to update these files either.

Has anyone managed to solve this problem?

-- Julian C.




From cummings at linkline.com  Fri Apr  6 18:43:27 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 11:43:27 -0700
Subject: [pooma-dev] Example of bad behavior from particle boundaryconditions
In-Reply-To: <B6F1D6F8.4A26%jcrotinger@mac.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGEEICCBAA.cummings@linkline.com>

Hi Jim,

I managed to build libpooma under cygwin.
I used --arch LINUXEGCS since the compiler
is older than the version Jeffrey is using
with LINUXgcc.  You may have to say
"perl configure ..." instead of "configure ..."
if perl is not found correctly.  I found that
I had to create the directory lib/$POOMASUITE
by hand.  Finally, the "which" command does
not exist in the Bash shell, so you will see
a bunch of ignorable errors about that.

Other than that, it seems to work OK.

-- Julian

P.S.  If you are working with Intel VTune, perhaps
you have solved the problem of Unix vs. Dos line
endings in the VC++ ide files.  If so, please share
your wisdom on this!


-----Original Message-----
From: James Crotinger [mailto:jcrotinger at mac.com]
Sent: Thursday, April 05, 2001 7:02 AM
To: cummings at linkline.com; Steve Nolen; Pooma
Subject: Re: [pooma-dev] Example of bad behavior from particle
boundaryconditions


on 4/5/01 2:49 AM, Julian C. Cummings at cummings at linkline.com wrote:

> Unfortunately, I do not have a copy of
> CW Pro 6.1 for the PC to test with.  Are
> you able to run the CW debugger and see
> what is going wrong?

I've been attempting to do my development (working on the version of destroy
with iterator pairs) using CW 6.1 for the PC, and I've got to say that it
SUCKS.

I'm planning to install VTUNE today and give it a try.

I've got the full cygwin32 installation - is there enough there to do
configure? Does that version of the compiler compile Pooma (its 2.95.2, I
think).

    Jim




From wdn at lanl.gov  Fri Apr  6 17:59:15 2001
From: wdn at lanl.gov (Dave Nystrom)
Date: Fri,  6 Apr 2001 11:59:15 -0600 (MDT)
Subject: [pooma-dev] goofy Domain constructors
In-Reply-To: <20010402101817K.mitchell@codesourcery.com>
References: <20010402094651A.mitchell@codesourcery.com>
	<200104021713.KAA10428@gandalf.codesourcery.com>
	<20010402101817K.mitchell@codesourcery.com>
Message-ID: <15054.441.950583.287476@mutley.lanl.gov>

Mark Mitchell writes:
 > Note that I'd feel differently if Blanca used aCC -- but as far as I
 > know they don't.

We do not currently use aCC and I don't anticipate us needing to any time
soon.  We use CodeWarrior, KCC and SGI CC right now.  We will need to use the 
Compaq C++ compiler although Kuck has said they will support KCC on that
platform.  Also, we might need to use the IBM compiler for the Livermore
machines although KCC is an option there also.  I noticed that KCC-4.0d is
available for both IBM and HP machines.  We'd like to be able to use gcc also 
but Mark says it is not up to the task yet.  Finally, we are compiling all of 
our stuff with KCC using the various "strict" flags and it is compiling fine
- and of course, that is including alot of Pooma 2 code.  So, it seems that
at least the parts of Pooma 2 that we are using must be pretty ANSI
compliant.  Of course, I'm all for cleaning up code implementation where it
is appropriate.

Just my 2 cents worth,

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


From cummings at linkline.com  Fri Apr  6 19:23:33 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 12:23:33 -0700
Subject: [pooma-dev] goofy Domain constructors
In-Reply-To: <15054.441.950583.287476@mutley.lanl.gov>
Message-ID: <NEBBLCJDELMDOJLGLNJGCEIDCBAA.cummings@linkline.com>

Hi Dave,

Thanks for your comments.  Yes, I don't expect
Blanca to use aCC, since you're not targeting
HP platforms.  That is only for our benefit at
Caltech, where we have several parallel HP boxes.
I am doing that work outside the LANL contract,
but obviously I want changes folded in to the
official Pooma code, rather than carrying around
a separate "Caltech" version.  So I'm making
changes that will enhance portability but avoiding
ugly hacks that should not be necessary under the
ANSI C++ standard.

I just recently got an account on the new Compaq
TeraScale machine at Pittsburgh Supercomputing
Center.  I plan to take Pooma 2 over there at some
point and check things out under the Compaq compiler.
Also, I don't think my LLNL account is still active,
but I do have an account on the IBM SP machine at
San Diego Supercomputer Center.  Caltech has been
using the IBM Visual Age C++ compiler there for its
C++ code, and it seems to be fairly standard-compliant.
So again, I will take Pooma 2 there at some point and
see how things are looking under that compiler.  (By
the way, the Visual Age C++ compiler is usually in
/usr/vacpp/bin, rather than /usr/bin, so you need to
make sure you use the right one!)  This portability
testing will be done as part of the LANL contract.

-- Julian C.


-----Original Message-----
From: Dave Nystrom [mailto:wdn at lanl.gov]
Sent: Friday, April 06, 2001 10:59 AM
To: Mark Mitchell
Cc: scotth at proximation.com; cummings at cacr.caltech.edu;
pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] goofy Domain constructors


Mark Mitchell writes:
 > Note that I'd feel differently if Blanca used aCC -- but as far as I
 > know they don't.

We do not currently use aCC and I don't anticipate us needing to any time
soon.  We use CodeWarrior, KCC and SGI CC right now.  We will need to use
the
Compaq C++ compiler although Kuck has said they will support KCC on that
platform.  Also, we might need to use the IBM compiler for the Livermore
machines although KCC is an option there also.  I noticed that KCC-4.0d is
available for both IBM and HP machines.  We'd like to be able to use gcc
also
but Mark says it is not up to the task yet.  Finally, we are compiling all
of
our stuff with KCC using the various "strict" flags and it is compiling fine
- and of course, that is including alot of Pooma 2 code.  So, it seems that
at least the parts of Pooma 2 that we are using must be pretty ANSI
compliant.  Of course, I'm all for cleaning up code implementation where it
is appropriate.

Just my 2 cents worth,

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



From allan at stokes.ca  Fri Apr  6 19:36:45 2001
From: allan at stokes.ca (Allan Stokes)
Date: Fri, 6 Apr 2001 12:36:45 -0700
Subject: [pooma-dev] more on VC++ ide files
In-Reply-To: <NEBBLCJDELMDOJLGLNJGCEICCBAA.cummings@linkline.com>
Message-ID: <NABBJEAOKIDHLPHKHPDLKEGGEAAA.allan@stokes.ca>


Julian,

Now that you have identified the problem I'll find a solution that works
under/with Cygwin over the next couple of days.

On the subject of configure under Cygwin, I've been annoyed before by the
absence of which.  I even found a toolkit claiming to offer a which
replacement, but which was missing.  The GNU manuals at fsf.org do not
include documentation for this utility either.  Hmm.  I just looked at my
FreeBSD which and I discovered that it's a Perl script.  It's
redistributable and it worked, so I've included it below.

Under Cygwin bash the current directory is not a default part of the path.
On my installation either "perl configure" or "./configure" works.

Allan


I copied the following FreeBSD which script into c:\cygwin\bin and it works
under Cygwin (but not under a normal WinNT CMD shell because it uses ':' as
the default path separator).


#!/usr/bin/perl
#
# Copyright (c) 1995 Wolfram Schneider <wosch at FreeBSD.org>. Berlin.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/usr.bin/which/which.pl,v 1.14 1999/08/28 01:07:39 peter Exp
$

$all = $silent = $found = 0;
@path = split(/:/, $ENV{'PATH'});
if ($ENV{'PATH'} =~ /:$/) {
	$#path = $#path + 1;
	$path[$#path] = "";
}

if ($ARGV[0] eq "-a") {
    $all = 1; shift @ARGV;
} elsif ($ARGV[0] eq "-s") {
    $silent = 1; shift @ARGV;
} elsif ($ARGV[0] =~ /^-(h|help|\?)$/) {
    die "usage: which [-a] [-s] program ...\n";
}

foreach $prog (@ARGV) {
    if ("$prog" =~ '/' && -x "$prog" && -f "$prog") {
	print "$prog\n" unless $silent;
	$found = 1;
    } else {
	foreach $e (@path) {
	    $e = "." if !$e;
	    if (-x "$e/$prog" && -f "$e/$prog") {
		print "$e/$prog\n" unless $silent;
		$found = 1;
		last unless $all;
	    }
	}
    }
}

exit (!$found);




From JimC at proximation.com  Fri Apr  6 20:30:59 2001
From: JimC at proximation.com (James Crotinger)
Date: Fri, 6 Apr 2001 13:30:59 -0700 
Subject: [pooma-dev] Example of bad behavior from particle boundarycon
	ditions
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BC0@proxim-sf001.santafe.proximation.com>

I don't have these problems. I've only used the Cygwin CVS for Pooma work,
and my line-endings are the DOS ones.

Question: when you installed cygwin it asks if you are installing for UNIX
or DOS. I selected DOS. Did you select UNIX? Perhaps that is the difference?

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

 -----Original Message-----
From: 	Julian C. Cummings [mailto:cummings at linkline.com] 
Sent:	Friday, April 06, 2001 12:43 PM
To:	James Crotinger; Steve Nolen; Pooma
Subject:	RE: [pooma-dev] Example of bad behavior from particle
boundaryconditions

Hi Jim,

I managed to build libpooma under cygwin.
I used --arch LINUXEGCS since the compiler
is older than the version Jeffrey is using
with LINUXgcc.  You may have to say
"perl configure ..." instead of "configure ..."
if perl is not found correctly.  I found that
I had to create the directory lib/$POOMASUITE
by hand.  Finally, the "which" command does
not exist in the Bash shell, so you will see
a bunch of ignorable errors about that.

Other than that, it seems to work OK.

-- Julian

P.S.  If you are working with Intel VTune, perhaps
you have solved the problem of Unix vs. Dos line
endings in the VC++ ide files.  If so, please share
your wisdom on this!


-----Original Message-----
From: James Crotinger [mailto:jcrotinger at mac.com]
Sent: Thursday, April 05, 2001 7:02 AM
To: cummings at linkline.com; Steve Nolen; Pooma
Subject: Re: [pooma-dev] Example of bad behavior from particle
boundaryconditions


on 4/5/01 2:49 AM, Julian C. Cummings at cummings at linkline.com wrote:

> Unfortunately, I do not have a copy of
> CW Pro 6.1 for the PC to test with.  Are
> you able to run the CW debugger and see
> what is going wrong?

I've been attempting to do my development (working on the version of destroy
with iterator pairs) using CW 6.1 for the PC, and I've got to say that it
SUCKS.

I'm planning to install VTUNE today and give it a try.

I've got the full cygwin32 installation - is there enough there to do
configure? Does that version of the compiler compile Pooma (its 2.95.2, I
think).

    Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010406/45b19bed/attachment.html>

From JimC at proximation.com  Fri Apr  6 23:03:40 2001
From: JimC at proximation.com (James Crotinger)
Date: Fri, 6 Apr 2001 16:03:40 -0700 
Subject: [pooma-dev] POOMA CVS log messages
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BC1@proxim-sf001.santafe.proximation.com>

You can
add source files to a project manually using the menu item
Project/Add to Project/Files, but this is tedious.  Welcome to 
the fun world of VC++!  
I tried adding the header file in question to the Headers list, modifying
it, and rebuilding, and it still didn't rebuild. I just checked - I added
DynamicArrays.h to the Headers folder of my DynamicArray/DynamicArrayTest5
project. Built the test, made a modification to DynamicArrays.h, and hit
rebuild. Nothing happened. 
I think this is actually a problem with templates. I've become a heavy user
of VC++ over the past 8 months (with Microsoft's compiler) and I've
occasionally seen a dependency screw-up, but mostly it works correctly. It
appears to do a proper dependency analysis. For instance, have a Proximation
test code (which uses not complicated templates, though there are some
traits classes and template functions here and there) with the following
projects:
            CSum
            CSumProxy
            CsumStub
            ProxLib
            TestCreateInstance
These are all in the same workspace and TestCreateInstance depends on the
first four projects. Furthermore, the first three projects have files that
depend on a header file ISum.h, as does the main program in
TestCreateInstance. ProxLib does not depend on this file. If I modify ISum.h
and hit the rebuild button, it rebuilds CSum.dll, CSumProxy.dll,
CSumStub.dll, and finally the TestCreateInstance object and executable (but
not anything in ProxLib). This happens in spite of the fact that ISum.h is
not in any of the "Headers" folders in these various projects. There is a
folder that is automatically created by Visual Studio called "External
Dependencies" and ISum.h shows up there. 
VC++ does this correctly with and without the VTune C++ compiler selected.
Unfortunately, I can't test Pooma with VC++ sans VTune, so I don't know if
the dependency analysis breaks because of something Pooma is doing (like
file-naming conventions?), something VTune is doing, or if it is just a bug
in VC++ when using templates. Hmmm. Indeed, there is NO External
Dependencies folder in the DynamicArrayTest5 project, which indicates that,
for whatever reason, it is completely blowing its dependency analysis. I'm
guessing that the templates are confusing it. All I know is that it is a
major pain in the butt.
            Jim
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010406/46932ef6/attachment.html>

From cummings at linkline.com  Fri Apr  6 23:47:27 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 16:47:27 -0700
Subject: [pooma-dev] Example of bad behavior from particle boundaryconditions
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BC0@proxim-sf001.santafe.proximation.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGIEIGCBAA.cummings@linkline.com>

RE: [pooma-dev] Example of bad behavior from particle boundaryconditionsHi
Jim,

A-ha!  This was indeed my problem.  Thanks for pointing it out.
I have reinstalled cygwin and now I get Dos-style text files when
I checkout r2.  Great!

My only remaining problem now is that when I do a cvs command,
it executes the command but then hangs, rather than returning me
back to the command-line prompt.  Any ideas on this one?  Mark
thinks it is a cygwin bug, but I kind of doubt it because I don't think
you and Allan are seeing this behavior.

Julian

P.S.  Thanks for updating the VC++ Pooma project file.

  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Friday, April 06, 2001 1:31 PM
  To: 'cummings at linkline.com'; 'James Crotinger'; 'Steve Nolen'; 'Pooma'
  Subject: RE: [pooma-dev] Example of bad behavior from particle
boundaryconditions


  I don't have these problems. I've only used the Cygwin CVS for Pooma work,
and my line-endings are the DOS ones.

  Question: when you installed cygwin it asks if you are installing for UNIX
or DOS. I selected DOS. Did you select UNIX? Perhaps that is the difference?

          Jim




From cummings at linkline.com  Sat Apr  7 00:57:59 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Fri, 6 Apr 2001 17:57:59 -0700
Subject: [pooma-dev] POOMA CVS log messages
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BC1@proxim-sf001.santafe.proximation.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGEEIHCBAA.cummings@linkline.com>

RE: [pooma-dev] POOMA CVS log messagesHi Jim,

Yeah, you're right.  The files in the "Header files" folder are
completely ignored, as far as I can tell.  The only ones that
matter are "Source files" and "External Dependencies".  I
noticed that the Pooma project has one file in "External
Dependencies": src/IO/CTTI.h.  So I guess something did
some dependency analysis at some point and put this file
here.  But clearly the dependency analysis fails early on.

It shouldn't really have anything at all to do with templates,
right?  All you do is preprocess and see what files get included.
How hard can it be? <sigh>

-- Julian


  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Friday, April 06, 2001 4:04 PM
  To: 'cummings at linkline.com'
  Cc: 'pooma-dev at pooma.codesourcery.com'
  Subject: RE: [pooma-dev] POOMA CVS log messages


  You can

  add source files to a project manually using the menu item

  Project/Add to Project/Files, but this is tedious.  Welcome to

  the fun world of VC++!

  I tried adding the header file in question to the Headers list, modifying
it, and rebuilding, and it still didn?t rebuild. I just checked ? I added
DynamicArrays.h to the Headers folder of my DynamicArray/DynamicArrayTest5
project. Built the test, made a modification to DynamicArrays.h, and hit
rebuild. Nothing happened.

  I think this is actually a problem with templates. I?ve become a heavy
user of VC++ over the past 8 months (with Microsoft?s compiler) and I?ve
occasionally seen a dependency screw-up, but mostly it works correctly. It
appears to do a proper dependency analysis. For instance, have a Proximation
test code (which uses not complicated templates, though there are some
traits classes and template functions here and there) with the following
projects:

              CSum

              CSumProxy

              CsumStub

              ProxLib

              TestCreateInstance

  These are all in the same workspace and TestCreateInstance depends on the
first four projects. Furthermore, the first three projects have files that
depend on a header file ISum.h, as does the main program in
TestCreateInstance. ProxLib does not depend on this file. If I modify ISum.h
and hit the rebuild button, it rebuilds CSum.dll, CSumProxy.dll,
CSumStub.dll, and finally the TestCreateInstance object and executable (but
not anything in ProxLib). This happens in spite of the fact that ISum.h is
not in any of the ?Headers? folders in these various projects. There is a
folder that is automatically created by Visual Studio called ?External
Dependencies? and ISum.h shows up there.

  VC++ does this correctly with and without the VTune C++ compiler selected.
Unfortunately, I can?t test Pooma with VC++ sans VTune, so I don?t know if
the dependency analysis breaks because of something Pooma is doing (like
file-naming conventions?), something VTune is doing, or if it is just a bug
in VC++ when using templates. Hmmm. Indeed, there is NO External
Dependencies folder in the DynamicArrayTest5 project, which indicates that,
for whatever reason, it is completely blowing its dependency analysis. I?m
guessing that the templates are confusing it. All I know is that it is a
major pain in the butt.

              Jim





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010406/e3b99624/attachment.html>

From oldham at codesourcery.com  Sat Apr  7 02:54:49 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 6 Apr 2001 19:54:49 -0700
Subject: RFC: src: Spelling and Initialization Order Changes
Message-ID: <20010406195449.A4104@codesourcery.com>

I attached the wrong file in my previous posting.

Ok to commit?

2001-04-03  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Domain/DomainIterator.h (DomainIterator::DomainIterator):
	Reorder initializers to reflect class declaration order.
	* Domain/Loc.h: Fix spelling in comment.
	* Engine/ConstantFunctionEngine.h (Engine::Engine):
	Reorder initializers to reflect class declaration order.
	* Engine/IndexFunctionEngine.h (Engine::Engine): Likewise.
	* Evaluator/WhereProxy.h: Fix spelling in comment.
	* Layout/Node.h (Node::Node): Reorder initializers to reflect
	class declaration order.
	* NewField/FieldCreateLeaf.h: Fix spelling in comment.
	* NewField/FieldInitializers.h: Likewise.
	* NewField/FieldReductions.h: Likewise.
	* NewField/DiffOps/Div.UR.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comments.
	* NewField/DiffOps/Div.h: Fix spelling in comment.
	* NewField/DiffOps/FieldStencil.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comment.
	* NewField/Updater/PeriodicFaceBC.h: Fix typo in comment.
	* NewField/Updater/PosReflectFaceBC.h: Likewise.
	* NewField/tests/VectorTest.cpp (main): Fix test's name in the
	source code.
	* Pooma/Pooma.cmpl.cpp (initialize): Fix spelling in comment.
	* Utilities/RefCountedBlockPtr.h
	(RefBlockController::RefBlockController): Reorder initializers to
	reflect class declaration order.
	(RefCountedBlockPtr::RefCountedBlockPtr): Likewise.

Tested on	sequential Linux using gcc 3.1
Approved by	???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Domain/DomainIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainIterator.h,v
retrieving revision 1.7
diff -c -p -r1.7 DomainIterator.h
*** Domain/DomainIterator.h	2000/04/01 00:26:22	1.7
--- Domain/DomainIterator.h	2001/04/03 22:46:43
*************** public:
*** 99,105 ****
    // iterators to the start. This constructor sets up a "begin" iterator.
  
    DomainIterator(const Dom &d, int size = 0)
!     : index_m(size), domain_m(d), loc_m(d.firsts())
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
--- 99,105 ----
    // iterators to the start. This constructor sets up a "begin" iterator.
  
    DomainIterator(const Dom &d, int size = 0)
!     : domain_m(d), loc_m(d.firsts()), index_m(size)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
*************** public:
*** 109,115 ****
    // Copy constructor.
  
    DomainIterator(const This_t &model)
!     : index_m(model.index_m), domain_m(model.domain_m), loc_m(model.loc_m)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
--- 109,115 ----
    // Copy constructor.
  
    DomainIterator(const This_t &model)
!     : domain_m(model.domain_m), loc_m(model.loc_m), index_m(model.index_m)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
Index: Domain/Loc.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/Loc.h,v
retrieving revision 1.22
diff -c -p -r1.22 Loc.h
*** Domain/Loc.h	2000/06/27 02:48:17	1.22
--- Domain/Loc.h	2001/04/03 22:46:44
***************
*** 110,116 ****
  //   comparison operators: <, >, !=, ==, <=, >= : compare a Loc<N> to
  //      another domain object.  The compared domains must have the same
  //      number of dimensions.
! //   arithmetic accumulation operators +=, -= : add or substract in a
  //      given domain.  The added domain must have the same number of
  //      dimensions, or a dimension of 1 (in which case, the same value
  //      is used for all dimensions), and be known to be single-valued (which
--- 110,116 ----
  //   comparison operators: <, >, !=, ==, <=, >= : compare a Loc<N> to
  //      another domain object.  The compared domains must have the same
  //      number of dimensions.
! //   arithmetic accumulation operators +=, -= : add or subtract in a
  //      given domain.  The added domain must have the same number of
  //      dimensions, or a dimension of 1 (in which case, the same value
  //      is used for all dimensions), and be known to be single-valued (which
Index: Engine/ConstantFunctionEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/ConstantFunctionEngine.h,v
retrieving revision 1.16
diff -c -p -r1.16 ConstantFunctionEngine.h
*** Engine/ConstantFunctionEngine.h	2000/07/20 15:39:26	1.16
--- Engine/ConstantFunctionEngine.h	2001/04/03 22:46:45
*************** public:
*** 100,106 ****
    // Construct from a domain object.
  
    Engine(const Domain_t &domain, T val = T())
!   : domain_m(domain), val_m(val) 
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain[d].first();
--- 100,106 ----
    // Construct from a domain object.
  
    Engine(const Domain_t &domain, T val = T())
!   : val_m(val), domain_m(domain)
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain[d].first();
Index: Engine/IndexFunctionEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/IndexFunctionEngine.h,v
retrieving revision 1.20
diff -c -p -r1.20 IndexFunctionEngine.h
*** Engine/IndexFunctionEngine.h	2001/03/29 17:09:26	1.20
--- Engine/IndexFunctionEngine.h	2001/04/03 22:46:45
*************** public:
*** 129,135 ****
    }
  
    Engine(const Layout_t &layout, const Functor &f = Functor())
!   : domain_m(layout.domain()), funct_m(f) 
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain_m[d].first();
--- 129,135 ----
    }
  
    Engine(const Layout_t &layout, const Functor &f = Functor())
!   : funct_m(f), domain_m(layout.domain())
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain_m[d].first();
Index: Evaluator/WhereProxy.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/WhereProxy.h,v
retrieving revision 1.3
diff -c -p -r1.3 WhereProxy.h
*** Evaluator/WhereProxy.h	2000/07/20 15:39:26	1.3
--- Evaluator/WhereProxy.h	2001/04/03 22:46:45
*************** struct ConvertWhereProxy
*** 67,73 ****
  // A = where(f,B);
  //
  // Rather than have where(f,B) return an array that could be combined in
! // an expression, we return a WhereProxy that is recognized by assingment
  // operators.
  //
  // The WhereProxy is also necessary because the elements returned by
--- 67,73 ----
  // A = where(f,B);
  //
  // Rather than have where(f,B) return an array that could be combined in
! // an expression, we return a WhereProxy that is recognized by assignment
  // operators.
  //
  // The WhereProxy is also necessary because the elements returned by
Index: Layout/Node.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v
retrieving revision 1.33
diff -c -p -r1.33 Node.h
*** Layout/Node.h	2001/03/20 23:42:48	1.33
--- Layout/Node.h	2001/04/03 22:46:45
*************** public:
*** 142,148 ****
    Node(int affinity, const Domain_t &owned, const AllocatedDomain_t &allocated, 
         Context_t c, ID_t gid, ID_t lid = (-1))
      : domain_m(owned), allocated_m(allocated), 
!       context_m(c), global_m(gid), local_m(lid),
        affinity_m(affinity)
    {
      PAssert(owned.size() >= 0);
--- 142,148 ----
    Node(int affinity, const Domain_t &owned, const AllocatedDomain_t &allocated, 
         Context_t c, ID_t gid, ID_t lid = (-1))
      : domain_m(owned), allocated_m(allocated), 
!       local_m(lid), global_m(gid), context_m(c),
        affinity_m(affinity)
    {
      PAssert(owned.size() >= 0);
Index: NewField/FieldCreateLeaf.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldCreateLeaf.h,v
retrieving revision 1.4
diff -c -p -r1.4 FieldCreateLeaf.h
*** NewField/FieldCreateLeaf.h	2000/08/08 17:31:33	1.4
--- NewField/FieldCreateLeaf.h	2001/04/03 22:46:45
*************** template<class G, class T, class E> clas
*** 89,95 ****
  
  //-----------------------------------------------------------------------------
  // Fields are leaf objects, we just pass them through unless they have
! // Expression engines. Then, we remove the expresion from the field and form
  // leaves with tree-nodes. 
  
  template<class GeometryTag, class T, class Expr>
--- 89,95 ----
  
  //-----------------------------------------------------------------------------
  // Fields are leaf objects, we just pass them through unless they have
! // Expression engines. Then, we remove the expression from the field and form
  // leaves with tree-nodes. 
  
  template<class GeometryTag, class T, class Expr>
Index: NewField/FieldInitializers.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldInitializers.h,v
retrieving revision 1.3
diff -c -p -r1.3 FieldInitializers.h
*** NewField/FieldInitializers.h	2000/07/24 23:36:22	1.3
--- NewField/FieldInitializers.h	2001/04/03 22:46:45
***************
*** 43,49 ****
  // Overview: 
  // 
  // POOMA supports a hierarchy of multiple centering points per 
! // cell. The centering information, manageed by the FieldEngineBase
  // class, is initialized using a flexible set of functors. Below are some
  // pre-defined functors that set up some common centerings along with some
  // versions for building multi-material and multi-centered fields.
--- 43,49 ----
  // Overview: 
  // 
  // POOMA supports a hierarchy of multiple centering points per 
! // cell. The centering information, managed by the FieldEngineBase
  // class, is initialized using a flexible set of functors. Below are some
  // pre-defined functors that set up some common centerings along with some
  // versions for building multi-material and multi-centered fields.
Index: NewField/FieldReductions.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldReductions.h,v
retrieving revision 1.1
diff -c -p -r1.1 FieldReductions.h
*** NewField/FieldReductions.h	2000/07/24 23:36:22	1.1
--- NewField/FieldReductions.h	2001/04/03 22:46:46
*************** T max(const Field<GeometryTag, T, Engine
*** 115,121 ****
    return ret;
  }
  
! // Report if all of the elments of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool all(const Field<GeometryTag, T, EngineTag> &f)
--- 115,121 ----
    return ret;
  }
  
! // Report if all of the elements of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool all(const Field<GeometryTag, T, EngineTag> &f)
*************** bool all(const Field<GeometryTag, T, Eng
*** 129,135 ****
    return ret;
  }
  
! // Report if some of the elments of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool any(const Field<GeometryTag, T, EngineTag> &f)
--- 129,135 ----
    return ret;
  }
  
! // Report if some of the elements of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool any(const Field<GeometryTag, T, EngineTag> &f)
Index: NewField/DiffOps/Div.UR.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/Div.UR.h,v
retrieving revision 1.3
diff -c -p -r1.3 Div.UR.h
*** NewField/DiffOps/Div.UR.h	2000/07/26 22:27:27	1.3
--- NewField/DiffOps/Div.UR.h	2001/04/03 22:46:46
***************
*** 71,77 ****
  // Div:
  // 
  // Partial specializations of the generic Div (divergence) functor. See Div.h
! // for general comments. These are for UniformRectilinearMesh-based 
  // DiscreteGeometry.
  // 
  // Div is a functor class serving as the "Functor" template parameter for
--- 71,77 ----
  // Div:
  // 
  // Partial specializations of the generic Div (divergence) functor. See Div.h
! // for general comments. These are for UniformRectilinear-based 
  // DiscreteGeometry.
  // 
  // Div is a functor class serving as the "Functor" template parameter for
***************
*** 90,96 ****
  // OutputCentering_t - Centering parameter of the output DiscreteGeometry class
  // InputField_t      - Type of the input Field, which is restricted to 
  //                     something from the
! //                     DiscreteGeometry<Centering, UniformRectilinearMesh<Dim...> >
  //                     geometry and a vector or tensor type..
  // OutputElement_t   - Type of the elements in the output ConstField; 
  //                     restricted to a scalar type (vector input) or vector
--- 90,96 ----
  // OutputCentering_t - Centering parameter of the output DiscreteGeometry class
  // InputField_t      - Type of the input Field, which is restricted to 
  //                     something from the
! //                     DiscreteGeometry<Centering, UniformRectilinear<Dim...> >
  //                     geometry and a vector or tensor type..
  // OutputElement_t   - Type of the elements in the output ConstField; 
  //                     restricted to a scalar type (vector input) or vector
Index: NewField/DiffOps/Div.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/Div.h,v
retrieving revision 1.2
diff -c -p -r1.2 Div.h
*** NewField/DiffOps/Div.h	2000/07/26 22:27:27	1.2
--- NewField/DiffOps/Div.h	2001/04/03 22:46:46
***************
*** 82,88 ****
  // FieldStencil<Functor,Expression>, which implements a discrete 
  // divergence operator.
  // Partial specializations implement various combinations of input and output
! // centerings, for specific coordinate systems, and different finite-differenc
  // orders, are defined in other headers like Div.[URM,RM].h .
  // 
  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
--- 82,88 ----
  // FieldStencil<Functor,Expression>, which implements a discrete 
  // divergence operator.
  // Partial specializations implement various combinations of input and output
! // centerings, for specific coordinate systems, and different finite-difference
  // orders, are defined in other headers like Div.[URM,RM].h .
  // 
  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Index: NewField/DiffOps/FieldStencil.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/FieldStencil.h,v
retrieving revision 1.4
diff -c -p -r1.4 FieldStencil.h
*** NewField/DiffOps/FieldStencil.h	2000/09/20 16:22:17	1.4
--- NewField/DiffOps/FieldStencil.h	2001/04/03 22:46:46
*************** struct FieldStencilSimple
*** 474,480 ****
  //  
  // template<int Dim, class T1, class T2>
  // class Div<Cell,
! //   DiscreteGeometry<Vert, UniformRectilinearMesh<Dim, Cartesian<Dim>, T1> >, 
  //   Vector<Dim, T2> >
  // {
  // public:
--- 474,480 ----
  //  
  // template<int Dim, class T1, class T2>
  // class Div<Cell,
! //   DiscreteGeometry<Vert, UniformRectilinear<Dim, Cartesian<Dim>, T1> >, 
  //   Vector<Dim, T2> >
  // {
  // public:
Index: NewField/Updater/PeriodicFaceBC.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/Updater/PeriodicFaceBC.h,v
retrieving revision 1.2
diff -c -p -r1.2 PeriodicFaceBC.h
*** NewField/Updater/PeriodicFaceBC.h	2000/12/12 15:53:03	1.2
--- NewField/Updater/PeriodicFaceBC.h	2001/04/03 22:46:46
***************
*** 39,45 ****
  // Overview: 
  // 
  // PeriodicFaceBC:  Updater setting all guard layers beyond a
! //                   specified (logically) rectilinear mesh face to a the value
  //                   from the non-guard element symmetrically across the face
  //                   (the face is defined at the last vertex).
  //-----------------------------------------------------------------------------
--- 39,45 ----
  // Overview: 
  // 
  // PeriodicFaceBC:  Updater setting all guard layers beyond a
! //                   specified (logically) rectilinear mesh face to the value
  //                   from the non-guard element symmetrically across the face
  //                   (the face is defined at the last vertex).
  //-----------------------------------------------------------------------------
Index: NewField/Updater/PosReflectFaceBC.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/Updater/PosReflectFaceBC.h,v
retrieving revision 1.3
diff -c -p -r1.3 PosReflectFaceBC.h
*** NewField/Updater/PosReflectFaceBC.h	2001/02/19 21:21:07	1.3
--- NewField/Updater/PosReflectFaceBC.h	2001/04/03 22:46:46
***************
*** 37,43 ****
  // Overview: 
  // PosReflectFaceBC: BCondCategory class setting all guard layers beyond a
  //                 specified (logically) rectilinear mesh face to a positively 
! //                 relected value.
  //-----------------------------------------------------------------------------
  
  //-----------------------------------------------------------------------------
--- 37,43 ----
  // Overview: 
  // PosReflectFaceBC: BCondCategory class setting all guard layers beyond a
  //                 specified (logically) rectilinear mesh face to a positively 
! //                 reflected value.
  //-----------------------------------------------------------------------------
  
  //-----------------------------------------------------------------------------
Index: NewField/tests/VectorTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/VectorTest.cpp,v
retrieving revision 1.1
diff -c -p -r1.1 VectorTest.cpp
*** NewField/tests/VectorTest.cpp	2000/12/13 20:04:14	1.1
--- NewField/tests/VectorTest.cpp	2001/04/03 22:46:47
*************** int main(int argc, char *argv[])
*** 104,110 ****
  
    tester.out() << a << std::endl;
  
!   int ret = tester.results("WhereTest");
    Pooma::finalize();
    return ret;
  }
--- 104,110 ----
  
    tester.out() << a << std::endl;
  
!   int ret = tester.results("VectorTest");
    Pooma::finalize();
    return ret;
  }
Index: Pooma/Pooma.cmpl.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Pooma/Pooma.cmpl.cpp,v
retrieving revision 1.36
diff -c -p -r1.36 Pooma.cmpl.cpp
*** Pooma/Pooma.cmpl.cpp	2000/06/08 22:16:34	1.36
--- Pooma/Pooma.cmpl.cpp	2001/04/03 22:46:47
*************** bool initialize(Options &opts, bool init
*** 365,371 ****
  
  #endif
  
!   // Enable logging too a file, if requested.
  
    logstream_s = 0;
    logMessages(opts.logfile().c_str());
--- 365,371 ----
  
  #endif
  
!   // Enable logging to a file, if requested.
  
    logstream_s = 0;
    logMessages(opts.logfile().c_str());
Index: Utilities/RefCountedBlockPtr.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v
retrieving revision 1.58
diff -c -p -r1.58 RefCountedBlockPtr.h
*** Utilities/RefCountedBlockPtr.h	2001/03/29 17:09:26	1.58
--- Utilities/RefCountedBlockPtr.h	2001/04/03 22:46:48
*************** public: 
*** 164,170 ****
    // RefCountedBlockPtr.
    
    RefBlockController(size_t size, const NoInitTag &)
!     : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0)
    {
      // Allocate memory, and set pointers to beginning and ending.  This
      // also sets the dealloc_m flag to true.
--- 164,170 ----
    // RefCountedBlockPtr.
    
    RefBlockController(size_t size, const NoInitTag &)
!     : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false)
    {
      // Allocate memory, and set pointers to beginning and ending.  This
      // also sets the dealloc_m flag to true.
*************** public:
*** 639,646 ****
    // which adds to compile time.)
  
    inline RefCountedBlockPtr(const This_t & model, Offset_t offset)
!     : blockControllerPtr_m(model.blockControllerPtr_m),
!       offset_m(model.offset_m + offset)
    { }
  
    // Inline destructor for better performance
--- 639,646 ----
    // which adds to compile time.)
  
    inline RefCountedBlockPtr(const This_t & model, Offset_t offset)
!     : offset_m(model.offset_m + offset),
!       blockControllerPtr_m(model.blockControllerPtr_m)
    { }
  
    // Inline destructor for better performance

From cummings at linkline.com  Sat Apr  7 18:04:39 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Sat, 7 Apr 2001 11:04:39 -0700
Subject: [pooma-dev] more on VC++ ide files
In-Reply-To: <NABBJEAOKIDHLPHKHPDLKEGGEAAA.allan@stokes.ca>
Message-ID: <NEBBLCJDELMDOJLGLNJGOEIHCBAA.cummings@linkline.com>

Allan, 

Thanks for the where Perl script.
Do you have anything to replace "makedepend"?

Jim Crotinger pointed out my mistake in
installing Cygwin, and that fixed my problem
with Unix line endings in VC++ project files.
My only remaining annoyance is that cvs commands
from my PC under cygwin execute, but never return
to the command line prompt when finished.

-- Julian C.


-----Original Message-----
From: Allan Stokes [mailto:allan at stokes.ca]
Sent: Friday, April 06, 2001 12:37 PM
To: Poomadev
Subject: RE: [pooma-dev] more on VC++ ide files



Julian,

Now that you have identified the problem I'll find a solution that works
under/with Cygwin over the next couple of days.

On the subject of configure under Cygwin, I've been annoyed before by the
absence of which.  I even found a toolkit claiming to offer a which
replacement, but which was missing.  The GNU manuals at fsf.org do not
include documentation for this utility either.  Hmm.  I just looked at my
FreeBSD which and I discovered that it's a Perl script.  It's
redistributable and it worked, so I've included it below.

Under Cygwin bash the current directory is not a default part of the path.
On my installation either "perl configure" or "./configure" works.

Allan





From allan at stokes.ca  Sat Apr  7 21:07:38 2001
From: allan at stokes.ca (Allan Stokes)
Date: Sat, 7 Apr 2001 14:07:38 -0700
Subject: [pooma-dev] more on VC++ ide files
In-Reply-To: <NEBBLCJDELMDOJLGLNJGOEIHCBAA.cummings@linkline.com>
Message-ID: <NABBJEAOKIDHLPHKHPDLIEGKEAAA.allan@stokes.ca>



Julian,

My CVS under Cygwin bash on W2K works fine.

Here is a chunk of my Cygwin setup.log.full

<<<
[prev] ver 1.10.8-2 inst contrib/cvs/cvs-1.10.8-2.tar.gz 886813 src
contrib/cvs/cvs-1.10.8-2-src.tar.gz 2346757
[curr] ver 1.11.0-1 inst contrib/cvs/cvs-1.11.0-1.tar.gz 886467 src
contrib/cvs/cvs-1.11.0-1-src.tar.gz 2372294
[cygwin] action=new trust=curr src? no
[prev] ver 1.1.8-1 inst latest/cygwin/cygwin-1.1.8-1.tar.gz 666085 src
latest/cygwin/cygwin-1.1.8-1-src.tar.gz 4897786
[curr] ver 1.1.8-2 inst latest/cygwin/cygwin-1.1.8-2.tar.gz 666115 src
latest/cygwin/cygwin-1.1.8-2-src.tar.gz 4900399
>>>

Here is my cvs --version output:
<<<
Concurrent Versions System (CVS) 1.11 (client/server)

Copyright (c) 1989-2000 Brian Berliner, david d `zoo' zuhn,
                        Jeff Polk, and other authors
>>>

These are the bash commands I use before running a cvs session:
<<<
export CVSROOT=:ext:pooma:/home/pooma/Repository
export CVS_RSH="/usr/bin/ssh"
>>>

This is my ssh -V output:

<<<
SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).
>>>

This is are my ENV settings that seem to matter:
<<<
HOME=/cygdrive/g/users/allan
HOMEDRIVE=C:
HOMEPATH='\'
USER=administrator
USERNAME=Administrator
USERPROFILE='C:\Documents and Settings\Administrator'
>>>

For some reason SSH does not use HOME, but instead manufactures a path
"/home/$USERNAME"  I have no idea how or why it does this.  It's somewhat
psycho.

This is my ssh config file at /home/Administrator/.ssh/config
<<<
Host pooma
  Hostname pooma.codesourcery.com
  EscapeChar none
  IdentityFile ~/.ssh/pooma
  User pooma
>>>

Here is the output of "ssh -v -v pooma" with everything set up as before:
<<<
SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).
debug: Reading configuration data /home/Administrator/.ssh/config
debug: Applying options for pooma
debug: Seeding random number generator
debug: ssh_connect: getuid 500 geteuid 500 anon 0
debug: Connecting to pooma.codesourcery.com [206.168.99.1] port 22.
debug: Seeding random number generator
debug: Allocated local port 924.
debug: Connection established.
debug: Remote protocol version 1.5, remote software version 1.2.27
debug: no match: 1.2.27
debug: Local version string SSH-1.5-OpenSSH_2.3.0p1
debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Host 'pooma.codesourcery.com' is known and matches the RSA host key.
debug: Seeding random number generator
debug: Encryption type: 3des
debug: Sent encrypted session key.
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Remote: Server does not permit empty password login.
debug: Trying RSA authentication with key 'allan at camel.wloo.nat'
debug: Received RSA challenge from server.
Enter passphrase for RSA key 'allan at camel.wloo.nat':
>>>

If you can't get the same behaviour from the same configuration, you'll have
to debug this at the plumbing level.

Allan



-----Original Message-----
From: Julian C. Cummings [mailto:cummings at linkline.com]
Sent: Saturday 7 April 2001 11:05
To: Allan Stokes; Poomadev
Subject: RE: [pooma-dev] more on VC++ ide files


Allan,

Thanks for the where Perl script.
Do you have anything to replace "makedepend"?

Jim Crotinger pointed out my mistake in
installing Cygwin, and that fixed my problem
with Unix line endings in VC++ project files.
My only remaining annoyance is that cvs commands
from my PC under cygwin execute, but never return
to the command line prompt when finished.

-- Julian C.





From jcrotinger at mac.com  Sun Apr  8 01:10:00 2001
From: jcrotinger at mac.com (James Crotinger)
Date: Sat, 07 Apr 2001 19:10:00 -0600
Subject: [pooma-dev] more on VC++ ide files
In-Reply-To: <NEBBLCJDELMDOJLGLNJGOEIHCBAA.cummings@linkline.com>
Message-ID: <B6F51688.4A5B%jcrotinger@mac.com>

on 4/7/01 12:04 PM, Julian C. Cummings at cummings at linkline.com wrote:
> My only remaining annoyance is that cvs commands
> from my PC under cygwin execute, but never return
> to the command line prompt when finished.

You wouldn't, by chance, be attempting to use the tcsh, would you? I gave it
a try (I really like it better than bash in general) and it hung constantly.

  Jim



From mark at codesourcery.com  Mon Apr  9 03:48:23 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Sun, 08 Apr 2001 20:48:23 -0700
Subject: Test
Message-ID: <20010408204823Y.mitchell@vaio.codesourcery.com>


We have just upgraded our mailing list software in order to provide a
web-based archive of the `pooma-dev' mailing list.  This is a test
messagae to see whether basic list functionality still works.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From cummings at linkline.com  Mon Apr  9 17:17:45 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 9 Apr 2001 10:17:45 -0700
Subject: [pooma-dev] more on VC++ ide files
In-Reply-To: <B6F51688.4A5B%jcrotinger@mac.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGEEILCBAA.cummings@linkline.com>

Hi Jim,

No, I am using the lame default Bash shell.
I'll go through the configuration details
that Allan sent and see if I can find any
critical discrepancies in my setup.

Thanks, Julian C.


-----Original Message-----
From: James Crotinger [mailto:jcrotinger at mac.com]
Sent: Saturday, April 07, 2001 6:10 PM
To: cummings at linkline.com; Allan Stokes; Poomadev
Subject: Re: [pooma-dev] more on VC++ ide files


on 4/7/01 12:04 PM, Julian C. Cummings at cummings at linkline.com wrote:
> My only remaining annoyance is that cvs commands
> from my PC under cygwin execute, but never return
> to the command line prompt when finished.

You wouldn't, by chance, be attempting to use the tcsh, would you? I gave it
a try (I really like it better than bash in general) and it hung constantly.

  Jim




From JimC at proximation.com  Mon Apr  9 17:21:38 2001
From: JimC at proximation.com (James Crotinger)
Date: Mon, 9 Apr 2001 10:21:38 -0700 
Subject: [pooma-dev] more on VC++ ide files
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BC6@proxim-sf001.santafe.proximation.com>

I get an error when trying to do "make" that is apparently due to spaces in
the path names ("Documents and Users"...). Is there anything that can be
done to make this work, or do I just have to move the files into a path that
has no spaces (~/r2 or something).

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

 -----Original Message-----
From: 	Allan Stokes [mailto:allan at stokes.ca] 
Sent:	Friday, April 06, 2001 1:37 PM
To:	Poomadev
Subject:	RE: [pooma-dev] more on VC++ ide files


Julian,

Now that you have identified the problem I'll find a solution that works
under/with Cygwin over the next couple of days.

On the subject of configure under Cygwin, I've been annoyed before by the
absence of which.  I even found a toolkit claiming to offer a which
replacement, but which was missing.  The GNU manuals at fsf.org do not
include documentation for this utility either.  Hmm.  I just looked at my
FreeBSD which and I discovered that it's a Perl script.  It's
redistributable and it worked, so I've included it below.

Under Cygwin bash the current directory is not a default part of the path.
On my installation either "perl configure" or "./configure" works.

Allan


I copied the following FreeBSD which script into c:\cygwin\bin and it works
under Cygwin (but not under a normal WinNT CMD shell because it uses ':' as
the default path separator).


#!/usr/bin/perl
#
# Copyright (c) 1995 Wolfram Schneider <wosch at FreeBSD.org>. Berlin.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/usr.bin/which/which.pl,v 1.14 1999/08/28 01:07:39 peter Exp
$

$all = $silent = $found = 0;
@path = split(/:/, $ENV{'PATH'});
if ($ENV{'PATH'} =~ /:$/) {
	$#path = $#path + 1;
	$path[$#path] = "";
}

if ($ARGV[0] eq "-a") {
    $all = 1; shift @ARGV;
} elsif ($ARGV[0] eq "-s") {
    $silent = 1; shift @ARGV;
} elsif ($ARGV[0] =~ /^-(h|help|\?)$/) {
    die "usage: which [-a] [-s] program ...\n";
}

foreach $prog (@ARGV) {
    if ("$prog" =~ '/' && -x "$prog" && -f "$prog") {
	print "$prog\n" unless $silent;
	$found = 1;
    } else {
	foreach $e (@path) {
	    $e = "." if !$e;
	    if (-x "$e/$prog" && -f "$e/$prog") {
		print "$e/$prog\n" unless $silent;
		$found = 1;
		last unless $all;
	    }
	}
    }
}

exit (!$found);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010409/02ff97e1/attachment.html>

From cummings at linkline.com  Mon Apr  9 18:08:14 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 9 Apr 2001 11:08:14 -0700
Subject: [pooma-dev] more on VC++ ide files
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BC6@proxim-sf001.santafe.proximation.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGAEINCBAA.cummings@linkline.com>

RE: [pooma-dev] more on VC++ ide filesAllan will correct me if I am wrong,
but I think cygwin has
some weird problems with directory names that have spaces
in them.  So I avoid that completely within the cygwin realm
of my hard drive.

Another "make" problem under cygwin is the step where the
executable gets copied to a file with "_$(PASS)" appended to
the name.  It throws an error because it thinks the two arguments
to cp are the same.  I think the problem is that we do not have
the appropriate .exe filename extension included.  This could
be fixed by defining some symbol for the application filename
extension and adding that to the build system.  I will see what
I can do to fix this.

-- Julian C.

  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Monday, April 09, 2001 10:22 AM
  To: 'Allan Stokes'; 'Poomadev'
  Subject: RE: [pooma-dev] more on VC++ ide files


  I get an error when trying to do "make" that is apparently due to spaces
in the path names ("Documents and Users"...). Is there anything that can be
done to make this work, or do I just have to move the files into a path that
has no spaces (~/r2 or something).

          Jim

  ---------------------------------------------------
  James A. Crotinger
  Software Research Scientist
  Proximation, LLC

   -----Original Message-----
  From:   Allan Stokes [mailto:allan at stokes.ca]
  Sent:   Friday, April 06, 2001 1:37 PM
  To:     Poomadev
  Subject:        RE: [pooma-dev] more on VC++ ide files



  Julian,

  Now that you have identified the problem I'll find a solution that works
  under/with Cygwin over the next couple of days.

  On the subject of configure under Cygwin, I've been annoyed before by the
  absence of which.  I even found a toolkit claiming to offer a which
  replacement, but which was missing.  The GNU manuals at fsf.org do not
  include documentation for this utility either.  Hmm.  I just looked at my
  FreeBSD which and I discovered that it's a Perl script.  It's
  redistributable and it worked, so I've included it below.

  Under Cygwin bash the current directory is not a default part of the path.
  On my installation either "perl configure" or "./configure" works.

  Allan



  I copied the following FreeBSD which script into c:\cygwin\bin and it
works
  under Cygwin (but not under a normal WinNT CMD shell because it uses ':'
as
  the default path separator).



  #!/usr/bin/perl
  #
  # Copyright (c) 1995 Wolfram Schneider <wosch at FreeBSD.org>. Berlin.
  # All rights reserved.
  #
  # Redistribution and use in source and binary forms, with or without
  # modification, are permitted provided that the following conditions
  # are met:
  # 1. Redistributions of source code must retain the above copyright
  #    notice, this list of conditions and the following disclaimer.
  # 2. Redistributions in binary form must reproduce the above copyright
  #    notice, this list of conditions and the following disclaimer in the
  #    documentation and/or other materials provided with the distribution.
  #
  # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
  # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
  # ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
  # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT
  # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY
  # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  # SUCH DAMAGE.
  #
  # $FreeBSD: src/usr.bin/which/which.pl,v 1.14 1999/08/28 01:07:39 peter
Exp
  $

  $all = $silent = $found = 0;
  @path = split(/:/, $ENV{'PATH'});
  if ($ENV{'PATH'} =~ /:$/) {
          $#path = $#path + 1;
          $path[$#path] = "";
  }

  if ($ARGV[0] eq "-a") {
      $all = 1; shift @ARGV;
  } elsif ($ARGV[0] eq "-s") {
      $silent = 1; shift @ARGV;
  } elsif ($ARGV[0] =~ /^-(h|help|\?)$/) {
      die "usage: which [-a] [-s] program ...\n";
  }

  foreach $prog (@ARGV) {
      if ("$prog" =~ '/' && -x "$prog" && -f "$prog") {
          print "$prog\n" unless $silent;
          $found = 1;
      } else {
          foreach $e (@path) {
              $e = "." if !$e;
              if (-x "$e/$prog" && -f "$e/$prog") {
                  print "$e/$prog\n" unless $silent;
                  $found = 1;
                  last unless $all;
              }
          }
      }
  }

  exit (!$found);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010409/f090da91/attachment.html>

From cummings at linkline.com  Mon Apr  9 21:52:36 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 9 Apr 2001 14:52:36 -0700
Subject: adapting Particles to NewFields
Message-ID: <NEBBLCJDELMDOJLGLNJGOEJBCBAA.cummings@linkline.com>

Hi All,

OK, I have done some preliminary investigation
of the work required to adapt the Particles 
classes from our old Fields to NewFields (which
will then become "Field"!).  It's not too bad.

There are two main places where Fields come up
with respect to Particles.  One is in SpatialLayout,
where the particle data distribution is based upon
particle position and the field decomposition.
Fortunately, we are still using the same FieldLayouts
as before.  What's new is that the geometry does not
have a centering template parameter.  So we just 
drop that extra parameter here.  The other place 
where Fields appear prominently is in the interpolators.

In both of these places, it mostly boils down to the
implementation of the pointIndex() and indexPoint()
conversion functions.  These functions are used to 
convert a position in coordinate space to the index of
the nearest field element, or to get the position in
coordinate space of a field element.  With the old
Fields, these functions were members of the geometry 
class.  They were implemented using functionality of
the mesh object contained inside.  The centering 
template argument of the geometry was used to select 
the appropriate implementation.

In the new implementation, the FieldEngine stores the 
mesh information, and centering information is stored 
in FieldEngineBase as a set of offsets for each dimension.
It seems to me that FieldEngine would be a reasonable
place to resurrect and reimplement the pointIndex() and
indexPoint() conversion functions (with the public API
to these functions being through Field).  All of the 
necessary information is there.  With these functions 
in place, the switch of Particles to NewField should be
fairly smooth.

One thing I am not so clear on is how to handle Fields
that have multiple subFields inside.  What I am worried
about is how to differentiate the case of multiple 
subFields that all have one centering from the case of 
a Vector Field where different components have different
centerings.  I would need to distinguish these two cases
when it comes to particle/field interpolation.  Is there
a simple way to do that?

Comments on the plan I have outlined here?

-- Julian C.




From oldham at codesourcery.com  Tue Apr 10 03:10:55 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Mon, 9 Apr 2001 20:10:55 -0700
Subject: Proposal to Add Interpolation and Restriction Operators
Message-ID: <20010409201055.A4134@codesourcery.com>

Attached are PostScript and PDF versions of a proposal to add
interpolation and restriction operators to Pooma.

interpolation operator: maps from coarse-grain field to a fine-grain field
restriction operator: maps from fine-grain field to a coarse-grain field

coarse grain field:

    -------
    |     |
    |     |
    |     |
    -------

fine-grain field:

    -------
    |  |  |
    -------
    |  |  |
    -------

Adding these operators eases implementation of the Pooma hydrodynamics
kernel.  It also adds support for working with fields with different
geometries.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: field-granularity.ps
Type: application/postscript
Size: 115901 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010409/a6139051/attachment.ps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: field-granularity.pdf
Type: application/pdf
Size: 42481 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010409/a6139051/attachment.pdf>

From mark at codesourcery.com  Tue Apr 10 05:54:15 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Mon, 09 Apr 2001 22:54:15 -0700
Subject: Mailing list archives
Message-ID: <20010409225415E.mitchell@vaio.codesourcery.com>


I've set up an (extremely minimal) POOMA web-site at www.pooma.com.

The only item of substance there is an archive of the pooma-dev
mailing list.  

Enjoy,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From sasmith at proximation.com  Tue Apr 10 22:00:24 2001
From: sasmith at proximation.com (Stephen A. Smith)
Date: Tue, 10 Apr 2001 16:00:24 -0600
Subject: Patch: Get NewField to work with messaging.
Message-ID: <3AD38278.EE0CF993@proximation.com>

I'll be checking the following changes in later today to get the
new field class working with messaging.  The changes were
reviewed by Scott H.  They were tested using Cheetah with
shared-memory transport on a dual-processor linux box,
compiled with egcs-2.95.2.
(configure with --arch LINUXEGCS --messaging --bounds)
(run with -shmem -np 2)

src/NewField/tests:
  *ExpressionTest.cpp
  *FieldTour1.cpp
  *ScalarCode.cpp
  *VectorTest.cpp
  *WhereTest.cpp
  -changes to use Remote engines and distributed
   layouts when compiled with Cheetah.  (Also, added
  ExpressionTest to the default targets and commented
  out tests corresponding to unimplemented functionality.)

Field changes:
  *NewField/Field.h
  *FieldEngine.Lagrangian.h
  *FieldEngine.NoGeometry.h
  *FieldEngine.UR.h
  *FieldEngineBase.h
  *Engine/ViewEngine.h
  *Evaluator/MultiArgEvaluator.h
  *PETE/Functors.h
  -code to enable remote view for the new field classes:
    1) added a leaf functor for taking the view of the field and
       a set of constructors in the field engines.
    2) added leaf functor for views of MultiArgs (used by
       ScalarCode with remote fields).
    3) two bug fixes in previously unused code (in ViewEngine
      and in MultiArgEvaluator)
    4) the change in PETE just makes some of the leaf functor
      code cleaner.

    Stephen

-------------- next part --------------
Index: ExpressionTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/ExpressionTest.cpp,v
retrieving revision 1.1
diff -r1.1 ExpressionTest.cpp
59a60,69
> #if POOMA_CHEETAH
>   typedef DistributedTag LayoutTag_t;
>   typedef Remote<Brick> BrickTag_t;
>   typedef Remote<CompressibleBrick> CompBrickTag_t;
> #else
>   typedef ReplicatedTag LayoutTag_t;
>   typedef Brick BrickTag_t;
>   typedef CompressibleBrick CompBrickTag_t;
> #endif
> 
107c117
<   UserFunction<Norm> norm;
---
>   //  UserFunction<Norm> norm;
109c119
<   return (sum(norm(a)) < epsilon);
---
>   return (sum(abs(a)) < epsilon);
369,409d378
< template<class A1,class A2,class A3,class A4, class AInit>
< void test7(Pooma::Tester& tester, int test,
< 	   const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4,
< 	   const AInit &initial, const Interval<1> &I)
< {
<   //---------------------------------------------------------------------
<   // test #7
<   // Simple indirection test.
< 
<   int from = I.first();
<   int to = I.last();
<   int i;
< 
<   Array<1, int, Brick> b(I);
< 
<   for (i = from; i < to; ++i)
<   {
<     b(i) = i + 1;
<   }
<   b(to) = from;
< 
<   a1 = initial;
<   a2 = initial;
<   a3 = initial;
<   a4 = initial;
< 
<   Pooma::blockAndEvaluate();
< 
<   for (i = from; i <= to; ++i)
<   {
<     a2(b(i)) = a1(i);
<   }
< 
<   a4(b) = a3;
< 
<   Pooma::blockAndEvaluate();
< 
<   tester.check(checkTest(tester, test, a2, a4));
< }
< 
< 
421c390
< 			      ReplicatedTag());
---
> 			      LayoutTag_t());
423,424c392,393
<   std::cout << layout << std::endl;
<   std::cout << layout.domain() << std::endl;
---
>   tester.out() << layout << std::endl;
>   tester.out() << layout.domain() << std::endl;
431c400
<     Field<UniformRectilinear<1>, double, MultiPatch<UniformTag, Brick> >
---
>     Field<UniformRectilinear<1>, double, MultiPatch<UniformTag, BrickTag_t> >
440,441c409,410
<   std::cout << "physical domain:" << a1.physicalDomain() << std::endl;
<   std::cout << "interior domain:" << cellInterior << std::endl;
---
>   tester.out() << "physical domain:" << a1.physicalDomain() << std::endl;
>   tester.out() << "interior domain:" << cellInterior << std::endl;
451,453c420,425
<   test2(tester, 2, a1, a2, a3, a4, initial, cellInterior);
<   test3(tester, 3, a1, a2, a3, a4, initial, cellInterior);
<   test4(tester, 4, a1, a2, a3, a4, initial, cellInterior);
---
>   // No UserFunction for Field yet.
>   //  test2(tester, 2, a1, a2, a3, a4, initial, cellInterior);
> 
>   // Need to replace the stencil code above with Field Stencil code.
>   //  test3(tester, 3, a1, a2, a3, a4, initial, cellInterior);
>   //  test4(tester, 4, a1, a2, a3, a4, initial, cellInterior);
457c429
<                                                     CompressibleBrick> >
---
>                                                     CompBrickTag_t> >
474,476c446,449
<   test2(tester, 2, ca1, ca2, ca3, ca4, cinit, cellInterior);
<   test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior);
<   test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior);
---
>   //  test2(tester, 2, ca1, ca2, ca3, ca4, cinit, cellInterior);
>   //  test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior);
>   //  test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior);
> 
477a451
>   int ret = tester.results("ScalarCode");
479c453
<   return 0; 
---
>   return ret;
Index: FieldTour1.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/FieldTour1.cpp,v
retrieving revision 1.3
diff -r1.3 FieldTour1.cpp
34a35,42
> #if POOMA_CHEETAH
>   typedef DistributedTag LayoutTag_t;
>   typedef Remote<Brick> BrickTag_t;
> #else
>   typedef ReplicatedTag LayoutTag_t;
>   typedef Brick BrickTag_t;
> #endif
> 
50c58
<   UniformGridLayout<2> layout(physicalVertexDomain, partition, ReplicatedTag());
---
>   UniformGridLayout<2> layout(physicalVertexDomain, partition, LayoutTag_t());
60c68,69
<     Field<UniformRectilinear<2>, double, MultiPatch<UniformTag, Brick> > Field_t;
---
>     Field<UniformRectilinear<2>, double,
>     MultiPatch<UniformTag, BrickTag_t> > Field_t;
135c144,145
<     Field<Lagrangian<2>, double, MultiPatch<UniformTag, Brick> > 
---
>     Field<Lagrangian<2>, double,
>     MultiPatch<UniformTag, BrickTag_t> > 
146c156
<   
---
>    
155,157c165,178
<   std::cout << f[0].patchLocal(0) << std::endl;
<   std::cout << f[0].patchLocal(1) << std::endl;
<   
---
>   int nLocal = f[0].numPatchesLocal();
>   std::cout << "context " << Pooma::context() << " has "
> 	    << nLocal << " patches" << std::endl;
>   if (nLocal > 0)
>     {
>       std::cout << "context " << Pooma::context()
> 		<< " local patch 0: " << f[0].patchLocal(0) << std::endl;
>     }
>   if (nLocal > 1)
>     {
>       std::cout << "context " << Pooma::context()
> 		<< " local patch 1: " << f[0].patchLocal(1) << std::endl;
>     }
> 
168c189,190
<     Field<UniformRectilinear<2>, Vector<2>, MultiPatch<UniformTag, Brick> > 
---
>     Field<UniformRectilinear<2>, Vector<2>,
>     MultiPatch<UniformTag, BrickTag_t> > 
176c198
<    
---
> 
Index: ScalarCode.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/ScalarCode.cpp,v
retrieving revision 1.5
diff -r1.5 ScalarCode.cpp
44a45,52
> #if POOMA_CHEETAH
>   typedef DistributedTag LayoutTag_t;
>   typedef Remote<Brick> BrickTag_t;
> #else
>   typedef ReplicatedTag LayoutTag_t;
>   typedef Brick BrickTag_t;
> #endif
> 
275,281d282
< // switch the definitions here to test the distributed case.
< 
< typedef ReplicatedTag LayoutTag_t;
< typedef Brick BrickTag_t;
< //typedef DistributedTag LayoutTag_t;
< //typedef Remote<Brick> BrickTag_t;
< 
447a449
>   // 2) Lagrangian fields
Index: VectorTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/VectorTest.cpp,v
retrieving revision 1.1
diff -r1.1 VectorTest.cpp
59a60,67
> #if POOMA_CHEETAH
>   typedef DistributedTag LayoutTag_t;
>   typedef Remote<Brick> BrickTag_t;
> #else
>   typedef ReplicatedTag LayoutTag_t;
>   typedef Brick BrickTag_t;
> #endif
> 
72,75c80,83
<   //  Loc<2> blocks(2, 2);
<   //  UniformGridPartition<2> partition(blocks, GuardLayers<2>(1));   
<   //  UniformGridLayout<2> layout(physicalVertexDomain, partition,
<   //			      ReplicatedTag());
---
>   Loc<2> blocks(2, 2);
>   UniformGridPartition<2> partition(blocks, GuardLayers<2>(1));   
>   UniformGridLayout<2> layout(physicalVertexDomain, partition,
>   			      LayoutTag_t());
77a86
>   tester.out() << "layout domain: " << layout.domain() << std::endl;
84,85c93,94
<   typedef Brick EngineTag_t;
<   //  typedef MultiPatch<UniformTag, Brick> EngineTag_t;
---
>   typedef MultiPatch<UniformTag, BrickTag_t> EngineTag_t;
>   //  typedef BrickTag_t EngineTag_t;
93,95c102,107
<   Field_t a(allFace, layoutDom, origin, spacings);
<   VField_t b(allFace, layoutDom, origin, spacings);
<   VField_t c(allFace, layoutDom, origin, spacings);
---
>   Field_t a(allFace, layout, origin, spacings);
>   VField_t b(allFace, layout, origin, spacings);
>   VField_t c(allFace, layout, origin, spacings);
>   //  Field_t a(allFace, layoutDom, origin, spacings);
>   //  VField_t b(allFace, layoutDom, origin, spacings);
>   //  VField_t c(allFace, layoutDom, origin, spacings);
Index: WhereTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/WhereTest.cpp,v
retrieving revision 1.2
diff -r1.2 WhereTest.cpp
59a60,67
> #if POOMA_CHEETAH
>   typedef DistributedTag LayoutTag_t;
>   typedef Remote<Brick> BrickTag_t;
> #else
>   typedef ReplicatedTag LayoutTag_t;
>   typedef Brick BrickTag_t;
> #endif
> 
74c82
< 			      ReplicatedTag());
---
> 			      LayoutTag_t());
85c93
<     Field<Geometry_t, double, MultiPatch<UniformTag, Brick> >
---
>     Field<Geometry_t, double, MultiPatch<UniformTag, BrickTag_t> >
89c97
<     Field<Geometry_t, Vector<2>, MultiPatch<UniformTag, Brick> >
---
>     Field<Geometry_t, Vector<2>, MultiPatch<UniformTag, BrickTag_t> >
Index: makefile
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/makefile,v
retrieving revision 1.8
diff -r1.8 makefile
54a55
> 	$(ODIR)/ExpressionTest $(TSTOPTS) 1>ExpressionTest.out 2>&1
59c60
< 	$(ODIR)/ScalarCode
---
> 	$(ODIR)/ScalarCode $(ODIR)/ExpressionTest
105a107,108
> .PHONY: WhereTest
> 
110a114,115
> .PHONY: VectorTest
> 
114a120,121
> 
> .PHONY: CrossBox
-------------- next part --------------
Index: Field.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/Field.h,v
retrieving revision 1.10
diff -r1.10 Field.h
1122a1123,1127
>   inline int
>   numPatchesLocal() const
>   {
>     return engineFunctor(engine(), EngineNumPatches());
>   }
1465a1471,1491
> template<class GeometryTag, class T, class EngineTag, class Tag>
> struct LeafFunctor<Field<GeometryTag, T, EngineTag>, EngineView<Tag> >
> {
>   typedef Field<GeometryTag, T, EngineTag> Subject_t;
>   typedef typename Subject_t::Engine_t Engine_t;
>   typedef typename LeafFunctor<Engine_t, EngineView<Tag> >::Type_t NewEngine_t;
>   typedef typename NewEngine_t::Tag_t NewEngineTag_t;
> 
>   // Don't bother computing NewGeometry tag yet.
>   // For now all EngineView operations are equivalent to Interval views.
> 
>   typedef Field<GeometryTag, T, NewEngineTag_t> Type_t;
> 
>   inline static
>   Type_t apply(const Subject_t &field,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(field, tag);
>   }
> };
> 
1751c1777,1778
< assign(const Field<GeometryTag, T, EngineTag> &lhs, const T1 &rhs, const Op &op)
---
> assign(const Field<GeometryTag, T, EngineTag> &lhs, const T1 &rhs,
>        const Op &op)
Index: FieldEngine/FieldEngine.Lagrangian.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.Lagrangian.h,v
retrieving revision 1.3
diff -r1.3 FieldEngine.Lagrangian.h
183a184,193
>   // Note there is no change to the vertex positions, because EngineView
>   // currently is only used to support RemoteView operations which don't
>   // change the domain.
>   template<class T2, class ET2, class Tag>  
>   FieldEngine(const FieldEngine<GeometryTag_t, T2, ET2> &model, 
>     const EngineView<Tag> &engineView)
>   : Base_t(model, engineView),
>     positions_m(forEach(model.vertexPositions(), engineView, TreeCombine()))
>   { }
> 
Index: FieldEngine/FieldEngine.NoGeometry.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v
retrieving revision 1.3
diff -r1.3 FieldEngine.NoGeometry.h
188a189
>   // EngineView version used for remote computations.
189a191,197
>   template<class G2, class T2, class ET2, class Tag>  
>   FieldEngine(const FieldEngine<G2, T2, ET2> &model, 
> 	      const EngineView<Tag> &engineView)
>     : engine_m(leafFunctor(model.engine(), engineView)),
>     updaters_m(model.updaters())
>   { }
>     
Index: FieldEngine/FieldEngine.UR.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.UR.h,v
retrieving revision 1.4
diff -r1.4 FieldEngine.UR.h
212a213,222
>   template<class T2, class ET2, class Tag>  
>   FieldEngine(const FieldEngine<GeometryTag_t, T2, ET2> &model, 
> 	      const EngineView<Tag> &engineView)
>   : Base_t(model, engineView),
>     origin_m(model.origin()),
>     spacings_m(model.spacings())
>   {
>     // Will need to fix up origin_m if EnginView replaces INode<> view.
>   }
> 
Index: FieldEngine/FieldEngineBase.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.h,v
retrieving revision 1.9
diff -r1.9 FieldEngineBase.h
280a281,306
>   template<int Dim2, class T2, class EngineTag2, class Tag>
>   void initialize(This_t &s, 
> 		  const FieldEngineBase<Dim2, T2, EngineTag2> &model,
> 		  const EngineView<Tag> &ev)
>   {
>     typedef typename FieldEngineBase<Dim2, T2, EngineTag2>::Engine_t EngIn_t;
>     int n = model.numSubFields();
>     if (n == 0)
>     {
>       s.physicalCellDomain_m = model.physicalCellDomain();
>       s.guards_m = model.guardLayers();
>       s.initialize(model.offsets(),
> 		   LeafFunctor<EngIn_t,
> 		   EngineView<Tag> >::apply(model.engine(), ev),
> 		   model.updaters());
>     }
>     else
>     {
>       s.physicalCellDomain_m = model.physicalCellDomain();
>       s.guards_m = model.guardLayers();
>       s.addSubFields(n);
>       for (int i = 0; i < n; i++)
> 	initialize(s.subFields_m[i], model.subField(i), ev);
>     }
>   }
> 

Index: Engine/ViewEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/ViewEngine.h,v
retrieving revision 1.20
diff -r1.20 ViewEngine.h
655c655,657
<   typedef LeafFunctor<E, ExpressionApply<Tag> > LeafFunctor_t;
---
>   typedef Engine<D, T, ViewEngine<D2, E> > Subject_t;
>   typedef typename Subject_t::ViewedEngine_t Engine_t;
>   typedef LeafFunctor<Engine_t, ExpressionApply<Tag> > LeafFunctor_t;
659,660c661
<   Type_t apply(const Engine<D, T, ViewEngine<D2, E> > &engine,
< 	       const ExpressionApply<Tag> &tag)
---
>   Type_t apply(const Subject_t &engine, const ExpressionApply<Tag> &tag)
Index: Evaluator/MultiArgEvaluator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/MultiArgEvaluator.h,v
retrieving revision 1.7
diff -r1.7 MultiArgEvaluator.h
377c377
< 		 function, domain, info, kernel);
---
> 		 function, evalDom, info, kernel);
466a467,757
> };
> 
> 
> 
> //----------------------------------------------------------------------------
> // LeafFunctor Specializations for ExpressionApply and EngineView
> //
> 
> 
> template<class A1, class Tag>
> struct LeafFunctor<MultiArg1<A1>, ExpressionApply<Tag> >
> {
>   typedef int Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg1<A1> &multiarg,
> 	       const ExpressionApply<Tag> &tag)
>   {
>     leafFunctor(multiarg.a1_m, tag);
>     return 0;
>   }
> };
> 
> template<class A1, class Tag>
> struct LeafFunctor<MultiArg1<A1>, EngineView<Tag> >
> {
>   typedef typename LeafFunctor<A1, EngineView<Tag> >::Type_t Type1_t;
>   typedef MultiArg1<Type1_t> Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg1<A1> &multiarg,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(
> 		  leafFunctor(multiarg.a1_m, tag)
> 		  );
>   }
> };
> 
> template<class A1, class A2, class Tag>
> struct LeafFunctor<MultiArg2<A1, A2>, ExpressionApply<Tag> >
> {
>   typedef int Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg2<A1, A2> &multiarg,
> 	       const ExpressionApply<Tag> &tag)
>   {
>     leafFunctor(multiarg.a1_m, tag);
>     leafFunctor(multiarg.a2_m, tag);
>     return 0;
>   }
> };
> 
> template<class A1, class A2, class Tag>
> struct LeafFunctor<MultiArg2<A1, A2>, EngineView<Tag> >
> {
>   typedef typename LeafFunctor<A1, EngineView<Tag> >::Type_t Type1_t;
>   typedef typename LeafFunctor<A2, EngineView<Tag> >::Type_t Type2_t;
>   typedef MultiArg2<Type1_t, Type2_t> Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg2<A1, A2> &multiarg,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(
> 		  leafFunctor(multiarg.a1_m, tag),
> 		  leafFunctor(multiarg.a2_m, tag)
> 		  );
>   }
> };
> 
> template<class A1, class A2, class A3, class Tag>
> struct LeafFunctor<MultiArg3<A1, A2, A3>,
>   ExpressionApply<Tag> >
> {
>   typedef int Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg3<A1, A2, A3> &multiarg,
> 	       const ExpressionApply<Tag> &tag)
>   {
>     leafFunctor(multiarg.a1_m, tag);
>     leafFunctor(multiarg.a2_m, tag);
>     leafFunctor(multiarg.a3_m, tag);
>     return 0;
>   }
> };
> 
> template<class A1, class A2, class A3, class Tag>
> struct LeafFunctor<MultiArg3<A1, A2, A3>, EngineView<Tag> >
> {
>   typedef typename LeafFunctor<A1, EngineView<Tag> >::Type_t Type1_t;
>   typedef typename LeafFunctor<A2, EngineView<Tag> >::Type_t Type2_t;
>   typedef typename LeafFunctor<A3, EngineView<Tag> >::Type_t Type3_t;
>   typedef MultiArg3<Type1_t, Type2_t, Type3_t> Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg3<A1, A2, A3> &multiarg,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(
> 		  leafFunctor(multiarg.a1_m, tag),
> 		  leafFunctor(multiarg.a2_m, tag),
> 		  leafFunctor(multiarg.a3_m, tag)
> 		  );
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class Tag>
> struct LeafFunctor<MultiArg4<A1, A2, A3, A4>,
>   ExpressionApply<Tag> >
> {
>   typedef int Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg4<A1, A2, A3, A4> &multiarg,
> 	       const ExpressionApply<Tag> &tag)
>   {
>     leafFunctor(multiarg.a1_m, tag);
>     leafFunctor(multiarg.a2_m, tag);
>     leafFunctor(multiarg.a3_m, tag);
>     leafFunctor(multiarg.a4_m, tag);
>     return 0;
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class Tag>
> struct LeafFunctor<MultiArg4<A1, A2, A3, A4>, EngineView<Tag> >
> {
>   typedef typename LeafFunctor<A1, EngineView<Tag> >::Type_t Type1_t;
>   typedef typename LeafFunctor<A2, EngineView<Tag> >::Type_t Type2_t;
>   typedef typename LeafFunctor<A3, EngineView<Tag> >::Type_t Type3_t;
>   typedef typename LeafFunctor<A4, EngineView<Tag> >::Type_t Type4_t;
>   typedef MultiArg4<Type1_t, Type2_t, Type3_t, Type4_t> Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg4<A1, A2, A3, A4> &multiarg,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(
> 		  leafFunctor(multiarg.a1_m, tag),
> 		  leafFunctor(multiarg.a2_m, tag),
> 		  leafFunctor(multiarg.a3_m, tag),
> 		  leafFunctor(multiarg.a4_m, tag)
> 		  );
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class A5, class Tag>
> struct LeafFunctor<MultiArg5<A1, A2, A3, A4, A5>,
>   ExpressionApply<Tag> >
> {
>   typedef int Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg5<A1, A2, A3, A4, A5> &multiarg,
> 	       const ExpressionApply<Tag> &tag)
>   {
>     leafFunctor(multiarg.a1_m, tag);
>     leafFunctor(multiarg.a2_m, tag);
>     leafFunctor(multiarg.a3_m, tag);
>     leafFunctor(multiarg.a4_m, tag);
>     leafFunctor(multiarg.a5_m, tag);
>     return 0;
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class A5, class Tag>
> struct LeafFunctor<MultiArg5<A1, A2, A3, A4, A5>, EngineView<Tag> >
> {
>   typedef typename LeafFunctor<A1, EngineView<Tag> >::Type_t Type1_t;
>   typedef typename LeafFunctor<A2, EngineView<Tag> >::Type_t Type2_t;
>   typedef typename LeafFunctor<A3, EngineView<Tag> >::Type_t Type3_t;
>   typedef typename LeafFunctor<A4, EngineView<Tag> >::Type_t Type4_t;
>   typedef typename LeafFunctor<A5, EngineView<Tag> >::Type_t Type5_t;
>   typedef MultiArg5<Type1_t, Type2_t, Type3_t, Type4_t, Type5_t> Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg5<A1, A2, A3, A4, A5> &multiarg,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(
> 		  leafFunctor(multiarg.a1_m, tag),
> 		  leafFunctor(multiarg.a2_m, tag),
> 		  leafFunctor(multiarg.a3_m, tag),
> 		  leafFunctor(multiarg.a4_m, tag),
> 		  leafFunctor(multiarg.a5_m, tag)
> 		  );
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class A5,
>   class A6, class Tag>
> struct LeafFunctor<MultiArg6<A1, A2, A3, A4, A5, A6>,
>   ExpressionApply<Tag> >
> {
>   typedef int Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg6<A1, A2, A3, A4, A5, A6> &multiarg,
> 	       const ExpressionApply<Tag> &tag)
>   {
>     leafFunctor(multiarg.a1_m, tag);
>     leafFunctor(multiarg.a2_m, tag);
>     leafFunctor(multiarg.a3_m, tag);
>     leafFunctor(multiarg.a4_m, tag);
>     leafFunctor(multiarg.a5_m, tag);
>     leafFunctor(multiarg.a6_m, tag);
>     return 0;
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class A5,
>   class A6, class Tag>
> struct LeafFunctor<MultiArg6<A1, A2, A3, A4, A5, A6>, EngineView<Tag> >
> {
>   typedef typename LeafFunctor<A1, EngineView<Tag> >::Type_t Type1_t;
>   typedef typename LeafFunctor<A2, EngineView<Tag> >::Type_t Type2_t;
>   typedef typename LeafFunctor<A3, EngineView<Tag> >::Type_t Type3_t;
>   typedef typename LeafFunctor<A4, EngineView<Tag> >::Type_t Type4_t;
>   typedef typename LeafFunctor<A5, EngineView<Tag> >::Type_t Type5_t;
>   typedef typename LeafFunctor<A6, EngineView<Tag> >::Type_t Type6_t;
>   typedef MultiArg6<Type1_t, Type2_t, Type3_t, Type4_t, Type5_t,
>     Type6_t> Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg6<A1, A2, A3, A4, A5, A6> &multiarg,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(
> 		  leafFunctor(multiarg.a1_m, tag),
> 		  leafFunctor(multiarg.a2_m, tag),
> 		  leafFunctor(multiarg.a3_m, tag),
> 		  leafFunctor(multiarg.a4_m, tag),
> 		  leafFunctor(multiarg.a5_m, tag),
> 		  leafFunctor(multiarg.a6_m, tag)
> 		  );
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class A5,
>   class A6, class A7, class Tag>
> struct LeafFunctor<MultiArg7<A1, A2, A3, A4, A5, A6, A7>,
>   ExpressionApply<Tag> >
> {
>   typedef int Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiarg,
> 	       const ExpressionApply<Tag> &tag)
>   {
>     leafFunctor(multiarg.a1_m, tag);
>     leafFunctor(multiarg.a2_m, tag);
>     leafFunctor(multiarg.a3_m, tag);
>     leafFunctor(multiarg.a4_m, tag);
>     leafFunctor(multiarg.a5_m, tag);
>     leafFunctor(multiarg.a6_m, tag);
>     leafFunctor(multiarg.a7_m, tag);
>     return 0;
>   }
> };
> 
> template<class A1, class A2, class A3, class A4, class A5,
>   class A6, class A7, class Tag>
> struct LeafFunctor<MultiArg7<A1, A2, A3, A4, A5, A6, A7>, EngineView<Tag> >
> {
>   typedef typename LeafFunctor<A1, EngineView<Tag> >::Type_t Type1_t;
>   typedef typename LeafFunctor<A2, EngineView<Tag> >::Type_t Type2_t;
>   typedef typename LeafFunctor<A3, EngineView<Tag> >::Type_t Type3_t;
>   typedef typename LeafFunctor<A4, EngineView<Tag> >::Type_t Type4_t;
>   typedef typename LeafFunctor<A5, EngineView<Tag> >::Type_t Type5_t;
>   typedef typename LeafFunctor<A6, EngineView<Tag> >::Type_t Type6_t;
>   typedef typename LeafFunctor<A7, EngineView<Tag> >::Type_t Type7_t;
>   typedef MultiArg7<Type1_t, Type2_t, Type3_t, Type4_t, Type5_t,
>     Type6_t, Type7_t> Type_t;
> 
>   inline static
>   Type_t apply(const MultiArg7<A1, A2, A3, A4, A5, A6, A7> &multiarg,
> 	       const EngineView<Tag> &tag)
>   {
>     return Type_t(
> 		  leafFunctor(multiarg.a1_m, tag),
> 		  leafFunctor(multiarg.a2_m, tag),
> 		  leafFunctor(multiarg.a3_m, tag),
> 		  leafFunctor(multiarg.a4_m, tag),
> 		  leafFunctor(multiarg.a5_m, tag),
> 		  leafFunctor(multiarg.a6_m, tag),
> 		  leafFunctor(multiarg.a7_m, tag)
> 		  );
>   }
Index: PETE/Functors.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/PETE/Functors.h,v
retrieving revision 1.7
diff -r1.7 Functors.h
76a77,83
> template<class LeafType, class LeafTag>
> inline
> typename LeafFunctor<LeafType, LeafTag>::Type_t
> leafFunctor(const LeafType &leaf, const LeafTag &tag)
> {
>   return LeafFunctor<LeafType, LeafTag>::apply(leaf, tag);
> }

From oldham at codesourcery.com  Tue Apr 10 22:10:29 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Tue, 10 Apr 2001 15:10:29 -0700
Subject: Hydrodynamics Kernel
Message-ID: <20010410151029.A9083@codesourcery.com>

One of the Pooma deliverables is a hydrodynamics kernel to test the
Field class and to use for timings.  Attached is

1) the main hydrodynamics kernel file (also included in the archive)
2) a uuencoded gzipped tar archive with all the source files

To compile the program,
a. uudecode foo.uu		# produces hydrodynamics.tgz
b. tar xzvf hydrodynamics.tgz	# extracts the five files
c. In Makefile, modify the compiler definitions as necessary.
d. make				# produces hydrodynamics

****************

There are several ways the code could be improved:

1) The two sequential portions of the code could be replaced by
   data-parallel code.  Modifying the initialization code should be
   easy, but I do not know how to produce a data-parallel version of
   the "product" operator.

2) Corner fields could be better supported.  See my previously posted
   proposal.

Please send suggestions, comments, and questions.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
// Oldham, Jeffrey D.
// 2001Mar27
// Pooma

// Hydrodynamics Kernel Written Using POOMA

#include <iostream>
#include <stdlib.h>
#include <cmath>
#include "Pooma/NewFields.h"
#include "ComputeVolumes.h"
#include "Product.h"
#include "ConstantVectorComponentBC.h"

// This hydrodynamics program implements "The Construction of
// Compatible Hydrodynamics Algorithms Utilizing Conservation of Total
// Energy," by E.J. Caramana, D.E. Burton, M.J. Shashkov, and
// P.P. Whalen, \emph{Journal of Computational Physics}, vol. 146
// (1998), pp. 227-262.

// The code uses fields with two different granularities: coarse and
// fine.  Both grid conceptually cover the same domain, but the
// fine-grain one has twice the number of values for each dimension.
// Currently, Pooma does not nicely support operations between fields
// with different granularities.  The code occurring between
// `CORNER_FIELD_TEMPORARY' preprocessor values substitutes for this
// lack of support.  See the separately distributed proposal for
// details.

// Preprocessor symbols:
// CORNER_FIELD_TEMPORARY: Define this symbol.  Include code to deal
// 			   with different granularity fields.
// PSEUDOCODE: Do not define this symbol.  Surrounds desired code to
//	       deal with different granularity fields.
// DEBUG: If defined, print some information about internal program
//	  values.
// DEBUG2: If defined, print much more information about internal
//	   program values.

// Sample compilation command:
// g++ -g -DCORNER_FIELD_TEMPORARY -I/nfs/oz/home/oldham/pooma/r2/src/ -I/nfs/oz/home/oldham/pooma/r2/lib/LINUXgcc/ -L. hydrodynamics.cc -lpooma-gcc -o hydrodynamics

#ifdef CORNER_FIELD_TEMPORARY

/** FORWARD DECLARATIONS **/

template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundCell (const Field<InputGeometry, T, EngineTag> & input,
	       Field<OutputGeometry, T, EngineTag> & output);

template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundVertex(const Field<InputGeometry, T, EngineTag> & input,
		Field<OutputGeometry, T, EngineTag> & output);

template<class InputGeometry1,
         class InputT1, class InputT2,
         class InputEngineTag1, class InputEngineTag2,
         class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerMasses(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressureDensity,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & fineCoordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output);

template <class InputGeometry1,
          class InputT1, class InputT2,
          class InputEngineTag1, class InputEngineTag2,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerForces(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressure,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & coordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output);

template <class InputGeometry1,
          class InputT1,
          class InputEngineTag1,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
copyVelocities(const Field<InputGeometry1, InputT1, InputEngineTag1> & input1,
	       const Field<InputGeometry1, InputT1, InputEngineTag1> & input2,
	       Field<OutputGeometry, OutputT, OutputEngineTag> & output);
#endif // CORNER_FIELD_TEMPORARY



/** THE HYDRODYNAMICS PROGRAM **/

int main(int argc, char *argv[])
{
  // Set up the Pooma library.
  Pooma::initialize(argc,argv);
#ifdef DEBUG
  std::cout << "Hello, world." << std::endl;
#endif // DEBUG

  /* DECLARATIONS */

  // Values
  const double gamma = 4.0/3;		// gas pressure constant $\gamma$
  const double timeStep = 0.01;		// $\Delta t$
  unsigned nuIterations = 1;		// number of iterations

  // Create a simple layout.
  const unsigned Dim = 2;		// Work in a 2D world.
  const unsigned nHorizVerts = 11;	// number of horizontal vertices
  const unsigned nAngles = 5;		// number of angles
  Interval<Dim> vertexDomain;
  vertexDomain[0] = Interval<1>(nHorizVerts);
  vertexDomain[1] = Interval<1>(nAngles);
  DomainLayout<Dim> layout(vertexDomain, GuardLayers<2>(1));

  // Preparation for Field creation.
  Vector<Dim> origin(0.0);
  Vector<Dim> spacings(1.0,1.0);  // TODO: What does this do?
  typedef UniformRectilinear<Dim, double, Cartesian<Dim> > Geometry_t;
  typedef Field<Geometry_t, double,      Brick> Fields_t;
  typedef Field<Geometry_t, double,      Brick> ConstFields_t; // TODO: Change to ConstField when ConstField is available.
  typedef Field<Geometry_t, Vector<Dim>, Brick> Fieldv_t;
  typedef Field<Geometry_t, Vector<Dim>, Brick> ConstFieldv_t; // TODO: Change to ConstField when ConstField is available.

  // Cell-centered Fields.
  Cell cell;
  Fields_t internalEnergy  (cell, layout, origin, spacings);
  ConstFields_t zoneMass   (cell, layout, origin, spacings);
  Fields_t pressure	   (cell, layout, origin, spacings);
  Fields_t pressureDensity (cell, layout, origin, spacings);
  Fields_t volume	   (cell, layout, origin, spacings);

  // Vertex-centered Fields.
  Vert vert;
  ConstFields_t pointMass  (vert, layout, origin, spacings);
  Fieldv_t coordinates	   (vert, layout, origin, spacings);
  Fieldv_t velocity	   (vert, layout, origin, spacings);
  Fieldv_t velocityChange  (vert, layout, origin, spacings);

  // Corner Fields.
  // TODO: How should I implement corner Fields?
#ifdef CORNER_FIELD_TEMPORARY
  // For now, implement corner Fields using a Field with twice as many
  // entries in each dimension.
  Interval<Dim> cornerVertexDomain;
  for (unsigned d = 0; d < Dim; ++d)
    cornerVertexDomain[d] = Interval<1>(2*vertexDomain[d].min(),2*vertexDomain[d].max());
  DomainLayout<Dim> cornerLayout(cornerVertexDomain, GuardLayers<2>(1));
  Fieldv_t cornerForces	   (cell, cornerLayout, origin, spacings);
  Fields_t cornerMasses    (cell, cornerLayout, origin, spacings);
  Fieldv_t cornerCoordinates(vert, cornerLayout, origin, spacings);
  Fieldv_t cornerVelocities(vert, cornerLayout, origin, spacings);
  Fields_t tmp1		   (cell, cornerLayout, origin, spacings);
  Fields_t tmp2		   (cell, cornerLayout, origin, spacings);
#endif // CORNER_FIELD_TEMPORARY

  /* INITIALIZATION */

  // TODO: Is coordinates initialization necessary?  What is the best way to do this?
  for (unsigned xIndex = 0; xIndex <= vertexDomain[0].last (); ++xIndex)
    for (unsigned yIndex = 0; yIndex <= vertexDomain[1].last (); ++yIndex)
      coordinates(xIndex,yIndex) =
	Vector<2>(static_cast<double>(xIndex)/(nHorizVerts-1) * cos(yIndex*M_PI/(2*(nAngles-1))),
		  static_cast<double>(xIndex)/(nHorizVerts-1) * sin(yIndex*M_PI/(2*(nAngles-1))));
  for (unsigned xIndex = 0; xIndex <= cornerVertexDomain[0].last (); ++xIndex)
    for (unsigned yIndex = 0; yIndex <= cornerVertexDomain[1].last (); ++yIndex)
      cornerCoordinates(xIndex,yIndex) =
	Vector<2>(0.5*xIndex/(nHorizVerts-1) * cos(0.5*yIndex*M_PI/(2*(nAngles-1))),
		  0.5*xIndex/(nHorizVerts-1) * sin(0.5*yIndex*M_PI/(2*(nAngles-1))));
#ifdef DEBUG
  std::cout << "initial coordinates:\n" << coordinates << std::endl;
#endif // DEBUG
  internalEnergy = 1.0;
  pressureDensity = 1.0;
#ifdef PSEUDOCODE
  // This is the desired code:
  cornerMasses = replicate<2>(pressureDensity) *
    computeVolumes(interpolate<2>(coordinates));
  pointMass = total<2>(cornerMasses);
  zoneMass = total<2>(cornerMasses);
  // This is the code that Pooma currently supports:
#endif // PSEUDOCODE
#ifdef CORNER_FIELD_TEMPORARY
  computeCornerMasses(pressureDensity, cornerCoordinates, cornerMasses);
  sumAroundVertex(cornerMasses, pointMass);
  sumAroundCell(cornerMasses, zoneMass);
#endif // CORNER_FIELD_TEMPORARY
  PInsist(min(pointMass) > 0.0, "Zero masses are not supported.");
#ifdef DEBUG2
  std::cout << "pointMass:\n" << pointMass << std::endl;
  std::cout << "zoneMass:\n" << zoneMass << std::endl;
#endif // DEBUG2
  velocity = Vector<Dim>(0.0);
  velocityChange.addUpdaters(AllConstantFaceBC<Vector<Dim> >(Vector<Dim>(0.0), false));
  for (int d = 0; d < Dim; ++d)
    velocityChange.addUpdater(ConstantVectorComponentBC<Vector<Dim>::Element_t>(2*d, d, 0.0, true));
  velocityChange.addUpdater(ConstantVectorComponentBC<Vector<Dim>::Element_t>(3, 0, 0.0, true));

  /* ITERATIONS */

  for (; nuIterations > 0; --nuIterations) {
#ifdef DEBUG
    std::cout << "Begin an iteration." << std::endl;
#endif // DEBUG
    pressure = (gamma - 1.0) * pressureDensity * internalEnergy;
#ifdef DEBUG2
    std::cout << "pressure:\n" << pressure << std::endl;
#endif // DEBUG2
#ifdef PSEUDOCODE
    // This is the desired code.
    forces = replicate<2>(pressure) * addNormals(coordinates);
    velocityChange = (timeStep / pointMass) * total<2>(cornerForces);
    // This is the code that Pooma currently supports:
#endif // PSEUDOCODE
#ifdef CORNER_FIELD_TEMPORARY
    computeCornerForces(pressure, coordinates, cornerForces);
    sumAroundVertex(cornerForces, velocityChange);
    velocityChange *= timeStep / pointMass;
#endif // CORNER_FIELD_TEMPORARY
#ifdef DEBUG2
    std::cout << "corner forces:\n" << cornerForces << std::endl;
    std::cout << "velocity changes:\n" << velocityChange << std::endl;
#endif // DEBUG2
    velocityChange.update();
#ifdef PSEUDOCODE
    // This is the desired code.
    internalEnergy +=
      -(timeStep / pointMass) *
      total<2>(dot(cornerForces, replicate<2>(velocity + 0.5*velocityChange)));
    // This is the code that Pooma currently supports:
#endif // PSEUDOCODE
#ifdef CORNER_FIELD_TEMPORARY
    copyVelocities(velocity, velocityChange, cornerVelocities);
    tmp1 = dot(cornerForces, cornerVelocities);
    sumAroundCell(tmp1, tmp2);
    internalEnergy += -(timeStep / pointMass) * tmp2;
#endif // CORNER_FIELD_TEMPORARY
    coordinates += (velocity + 0.5*velocityChange) * timeStep;
    velocity += velocityChange;
    volume = computeVolumes(coordinates);
    pressureDensity = zoneMass / volume;
#ifdef DEBUG2
    std::cout << "pressure density:\n" << pressureDensity << std::endl;
#endif // DEBUG2
  }

  /* TERMINATION */

  std::cout << "final coordinates:\n" << coordinates << std::endl;
#ifdef DEBUG
  std::cout << "Goodbye, world." << std::endl;
#endif // DEBUG
  Pooma::finalize();
  return EXIT_SUCCESS;
}


/** HELPER FUNCTIONS **/

#ifdef CORNER_FIELD_TEMPORARY
// Following is temporary code to permit compilation using the current
// Pooma code.  Adding new Pooma abstractions may eliminate the need
// for this code.
static Loc<2> offset[] = { Loc<2>(0,0), Loc<2>(0,1),
			     Loc<2>(1,0), Loc<2>(1,1) };

// Given a Field with twice the refinement, form a cell-centered Field
// by summing the 1<<Dim corresponding corners.
template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundCell(const Field<InputGeometry, T, EngineTag> & input,
	      Field<OutputGeometry, T, EngineTag> & output)
{
  const int dim = Field<OutputGeometry, T, EngineTag>::dimensions;
  Field<OutputGeometry,T,EngineTag>::Domain_t range = output.physicalDomain();
  output(range) = 0;
  for (unsigned counter = 0; counter < (1<<dim); ++counter)
    output(range) += input(2*range+offset[counter]);
  return;
}


// Given a Field with twice the refinement, form a vertex-centered Field
// by summing the 1<<Dim corresponding corners.
template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundVertex(const Field<InputGeometry, T, EngineTag> & input,
		Field<OutputGeometry, T, EngineTag> & output)
{
  const int dim = Field<OutputGeometry, T, EngineTag>::dimensions;
  Field<OutputGeometry,T,EngineTag>::Domain_t range = output.physicalDomain();
  output(range) = 0;
  for (unsigned counter = 0; counter < (1<<dim); ++counter)
    output(range) += input(2*range-offset[counter]);
  return;
}


// Given a quadrilateral's two diagonals as vectors, return the
// quadrilateral's volume.
template <int Dim, class T, class E>
inline
double
quadrilateralVolume (const Vector<Dim,T,E> &v, const Vector<Dim,T,E> &w)
{
  return 0.5 * std::abs (sum (product (v, w)));
}


// Given a pressure density Field and a fine-mesh coordinate Field, compute
// corner masses, placing in "output".
// TODO: Extend to multiple dimensions.
template<class InputGeometry1,
         class InputT1, class InputT2,
         class InputEngineTag1, class InputEngineTag2,
         class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerMasses(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressureDensity,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & fineCoordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output)
{
  // Assume the temporary finer coordinates Field fineCoordinates
  // already has values.

  // Compute the volumes in fineCoordinates.
  output = computeVolumes(fineCoordinates);

  // Multiply each volume by the pressure density.
  Field<InputGeometry1,InputT1,InputEngineTag1>::Domain_t range = pressureDensity.physicalDomain();
  const unsigned corners =
    (1 << (Field<InputGeometry1, InputT1, InputEngineTag1>::dimensions));;
  for (unsigned c = 0; c < corners; ++c)
    output(2*range+offset[c]) *= pressureDensity(range);

  return;
}


// Given a pressure Field and a coordinate Field, compute the corner
// forces in a fine-mesh Field.
template <class InputGeometry1,
          class InputT1, class InputT2,
          class InputEngineTag1, class InputEngineTag2,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerForces(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressure,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & coordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output)
{
  Field<InputGeometry1,InputT1,InputEngineTag1>::Domain_t range = pressure.physicalDomain();
  for (unsigned xIndex = 0; xIndex <= range.unwrap()[0].last(); ++xIndex)
    for (unsigned yIndex = 0; yIndex <= range.unwrap()[1].last(); ++yIndex) {
      Loc<2> range (xIndex, yIndex);
      output(2*range + offset[0]) =
	pressure(range) *
	0.5 * product(InputT2(1.0),
		      coordinates(range+offset[2])
		      - coordinates(range+offset[1]));
      output(2*range+offset[1]) =
	pressure(range) *
	0.5 * product(InputT2(1.0),
		      coordinates(range+offset[0])
		      - coordinates(range+offset[3]));
      output(2*range+offset[2]) =
	pressure(range) *
	0.5 * product(InputT2(1.0),
		      coordinates(range+offset[3])
		      - coordinates(range+offset[0]));
      output(2*range+offset[3]) =
	pressure(range) *
	0.5 * product(InputT2(1.0),
		      coordinates(range+offset[1])
		      - coordinates(range+offset[2]));
    }
  return;

#ifdef PSEUDOCODE
  // TODO: I really wanted to use "range" in a data-parallel
  // statement, but I do not know how to extend "product" to work
  // on Fields for such a statement.
  Field<InputGeometry1,InputT1,InputEngineTag1>::Domain_t range = pressure.physicalDomain();
  output(2*range+offset[0]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[2])
		  - coordinates(range+offset[1]));
  output(2*range+offset[1]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[0])
		  - coordinates(range+offset[3]));
  output(2*range+offset[2]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[3])
		  - coordinates(range+offset[0]));
  output(2*range+offset[3]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[1])
		  - coordinates(range+offset[2]));
#endif // PSEUDOCODE
}


template <class InputGeometry, class InputT, class InputEngineTag,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
copyVelocities(const Field<InputGeometry, InputT, InputEngineTag> & input1,
	       const Field<InputGeometry, InputT, InputEngineTag> & input2,
	       Field<OutputGeometry, OutputT, OutputEngineTag> & output)
{
  Field<InputGeometry,InputT,InputEngineTag>::Domain_t range =
    input1.physicalDomain();
  output(2*range-offset[0]) =
  output(2*range-offset[1]) =
  output(2*range-offset[2]) =
  output(2*range-offset[3]) = input1(range) + 0.5*input2(range);
  return;
}

#endif // CORNER_FIELD_TEMPORARY
-------------- next part --------------
begin 660 hydrodynamics.tgz
M'XL(`&Z"TSH``^P]:W/;MK+]:OT*C-LYE1R*>CBQ3V7'O8ZL).JU)8\M)Z>G
MS?A")"3QAB)U2$J*FLE_O[L+\"GJX51.TSM1)V.2`!:+W<5B=[%`1PO3<\V%
MP\>6X>N&\=TC_*JU:O7HJ/I=M5JM'3][BG^KQT?']+=:/3P^KD+9<?WH*3P\
M?78$]0]KU:??L>IC()/]3?V`>XQ]Y]KFB(]7US-\^TN@\Z5_E0KKTL at U]HL8
M##RQ8!=Z`;[6 at 5E7W*L?X\NUZXYY`9]>)^6%_;?P'&&SMYX5!,)A=[[E#-EU
MMWMU7BA\;SF&/34%.[5</_`$'Y\EOOF!:5M]?93\9HQYD/RP3]U6.F+^TA*V
MZ>NC_41ATQU/IH%XX]K3L<B470..4R/(-G"`UT[P1AB!ZV%SUQ%.\**)U7!L
MO9'ELU%J@!//'7I\S*SQQ!9CJ.VS_=Y(,(+E01>6ZS!W@*T1(`^LOBTR1#JW
MARX0:#3VV5U at V=8?2"0$(+P95P!8SPVXC6!:CO"&"VV?]1>LI?^BLR8'!+C#
M-6!,2V<OIE[@.AJ[PK+;$?='[]V9QKAC$J/T:YV]'7%;0)7?Q7 at R^OB+._4<
M;F,GDF34)WRX'BU\P.^3QF:NK;/:TR.$4*S]]-,_2QJ;3'16KQ^7ZT=U75%'
M,,,%0DY]X;,!<83-85PLF+O,M`8#X0&!&-#+F=H<1FP)OP%-N.>+$+^!Y0B=
ML1<N-!MZE at G%CB$FP93;]@)>9L)C`73D\[%@)G#?@G'TIP%^#-N7H0<+B.8(
M!L.'WBU#4"-G.NY#>QCHC-M31-+UF.#&"+`#WODP;!+MYM1#3.V%)@4;.H+*
MCALP!T`!'OYT,G&]@+D3X1&U?-87P5R`B,MQ(Q0:^HIAPQ`C<KF&`?TASQ4,
M;/P_S>Y-IW5S_[+=NKRX[[6NKKLWYS>__@@")T#F#.'[@+L:AC_M^X$5 at +#+
M(04 at IPC$YL9['*U"%SJ]%9(2OIB`U`0X%M,"0;6`A,)$:9ZX/K`>H"``4P3<
MLGW)W^MDS_YBW'=MOT'DRD6UP2X$<H.P4?4!@[::;33T`.1"2+'>V]MC;#7-
M%HJPQ)_KV];=1;?9O6A!)RXQQLSKZQ;HZDX=$$-3^)8GS+!7`(*]X0_[W[+;
MB]:+NU<-UAZHWDR8!,"W@/DN"*/E`-'&<K[RO at LB"46"9I92$K)7R;,88#T/
MXG@*0CEVO75 at U2!"#13"1<"W'-41C'8\L6S9%IY!29C$L.&3)ZP\9.6+?,ZQ
M<KOB#/R*^T=E!".KR)6O,B%EZ]4KOF=4-M4!W5VY;'?N_C4TL/*EGM:;8$BP
MLDVURT-\=M/EN#H,@"8K9`L&>7#`7G9OWI[?7``9FY?G-^>]=K=SRPX.*H5"
M`(H-QBU.#9O[/L@<:+57`O`,/)C3\F-W&N1\[84/+6<(#.GQX5G!<FQX+,Q<
MRRSXT_$YR513V#8K&JCF&:T^IYE>`%(, at _T#V`;%6B&4.]DFBT2VD4OEI9,O
M,J0WP at O$A\\9T]XN1U/3"BS\)8I[-2WU6L^O%G68KAY]7FZ63S7YM9=^74%!
M0UH:31>,'>\*J at M_-14!KV@\&8R11J#??7_JB0M<CX(%$I=038#+(AS2(SM2
M!(=:I>FZGFDY0&X_!)</*!IS=K2YO&.;F+<M]SZ7?8_#OY>N9^R`?W^6<<;7
MP;2-7'H4=DP6;X3M&F0J?38G2#G58HW[I^#4-VGNK=CPO7#`RF`K;:9"0:YL
MO=<M]OK7BYONQ:^=\ZMV\Y9=WW1?W9Q?R>6-+`0P<8OXP+VA`60=@9-Z`,^S
MW]Z5"A^!*V@&B(!-)V3P23L65F6/>PL=BNE#HV$Y0&0./H<H$B"$@(C*U9<,
M%*@,SEBC8:#Q<7K*]E_#TN=J;.YZMJGOXR<JA['9R2'*QHC)06:)KA0D?F_(
M9"F$K#'=*3I'0PZ6"GO.GNK5RN')WAX:+-R/)I:L#&X:^^%WJOI#%D``QOQM
M("8`HZI7:Q+$#[]?"#O at +,#J4]"M0S"WP"-H!Y$)_YRINK&?8$6E"N4F^*DP
MBSCSR>,#$WL!9-$C%"+(%]88`-8EP+>N]Q[D")K5+Q3=EELXK\$+_`,784(%
M<$FA,L)2UP$OD($3%(`CXN?`.'>&ML#VS[)#X5120`L\0,?2/@44SPB6^'!!
MGM0)E";??ZN^`TA1_=I9,8%C::EV;:FVQ(9JRCJ71"[9LR1=,0E"8Z^FW#.A
MEO#\T_I9L59"Y4641_>#2V:0DT/3D!G(#_+;&)-^NP0.:,($+`+_J?=DD3_A
M!GA;?K&F5[4:5B#XO>Y%MX&N<2#=/7(E3/=G:!TL)@*GPYUCH3%^`\`L5%><
M(&I*[C3TQ$%=6]R1'9VQ4#W<!R<),%*!Q&4Q`/J]\"SC_9FLY7].2XH]1,WC
ML35'(`/D=,4UV'P$3FOB'0;-9^#T<0"KK^TZ05,MA?1L$])Y+6,49G\6:353
M04N5#8'B"!-#!8B at B`QW\.)MQ#&D4N14R>@*`\L>:FA*1C4E3EHD.R14*3HS
MF)L";3^V7>.H7:C7]CZWH;(4']9X1E&Q[?I4RIKF:1Y%L80TP3)1)BX05E*%
M)OHVZ`'_D]8/X?B0MC-I.BP^NZ$2N2T:*TDCNS%!D$AX7[MSYH_<*8AH.PX1
MPN at 2#7[>X.H2.#!*F>/.M55`V)0BJUQI115UP[@7K)S@]R\D&&CG at 4F%2U$V
M[)5=%R3X-YG5`15O,5IM3%QA3^#/*2YW)^S)$[-4D*96MO%O9G9QJ!_,TN7Z
M&!1V2<OYSC\42RL6$=F3_%)<[C9_04D)6FSS)V9#$NRFJ60DW#[V<!`Q%@D_
M38G>PV$D[.:'@<"1!.-);>\SJ0!MZP]JN]D6)LNQW6GWVN>7[7^3\1C;CG*"
MM?VDJF"1-2O-!$=@M!(,WI^97- at MGXSAO@";:<X7%']T::7_>4FX/[0=4WR0
M$JZ>3Y]GS2,=O)F`%4LH^[*2G`!I4(L$J$4^J%H*U"(!BB5'6)2=:*H">U[8
M4XLIR+:/D7OCW@`XI](N.%/U2Y6DY5:NE=@!0/6+$LS!U?UUNP(3,C38H$*I
M)+W.A\$$);069FE9A^23.4>!_#EBYP!<3_+LA%Q'^*K^[$"6KZ`S5MA,Z[5@
M?+)FUX/9Y+BIZ9$4J,;O#GEPR5FTWJ%C65L)?!6]BHS-&B2J0*$4!^W5!$;[
M6DW(9'B^46!IE?J<@>5O6P:&"X'8F5Z`-FK)2>[V%0G'B6NK1HGA22&,#9/G
MH`7`J9*UXFZI5F33K:N4&8O<8D!M(WUN(]Q,"K=A_$:"I at FJ;#(#\J*,V6CA
MLN!J;`GAY8!O7$&+*9.NBV9SIF9(G6V4.6/7;4#1#XJXRL=]@),$/IK&]O\M
M/!<L%>(X!R\?-W44P82I[V=$N[XDVQ'(4*)C#J?E.=LP'$78+N+YVFE0)^=7
MVHL@'0F/)O(YT^:DSDWS;F("2SR_>&[;X6;S2VZ(%\W3I(-Z5LR"T]B`V[Y(
MZ$^,_*PTOU;V7%RYQ9U$H-%H21OS/D`SS00O4Y-<"KRI0F*771P"]$P':NWO
MM=(Q(QKZ23IJ<X8T*)>3WTKL8U819KG^0 at PQ'N/$$9Z-D2P$$@6AGK.BC%.5
M4<FA at LYJOX.,GEP6X"415A`B"0X[VR")>0IVK8K5PV736*U><4C`U0YN/MI^
M2H&>Y`@9$B2*NU422 at 3`9%2G-+85E"^E/#/J4P7YHV!]*MS.<O#,UYFRBI:A
M13Z!#IZS/`)MH3LWR8WR!"4_XP4]1G!)`V8A1)K,(%PC()DA;-2(2WIA2DJA
M6,JW`K80THRM\>2Y,M#*JZ1-E4<R9[I!AEDI<8]&_H3,KPPC2W^!E*;V/D)\
MLB*F+;E["E-TX6`N+H]Z1?WT^HZM-7+E5/$2^5<3GIIM90FD/!J$N8$+"%OU
MF9Y9V#9=5Y63$<B>9XW"926V;+)&RW]%@=E>;X/X$I2L_ at Z!;YP^G]2Z!\O>
M5;N3='C3'0XLY\%6_#J_X)7KFOV%V'9+)]H\(CQPZXBHZ8E at ZCFL]:]V[_[V
MKMELW=Z>%#ZI':W7K<OKU at U[>==I)O(TUL\'BGO9MCO'T!9./0&V!.Y?1<E#
M$^&-K2"5YR(#831+Y:R,TA.E5F'LW#2QBB/FZCOO^X''#6E.C/F""=L:$Q5E
MUI at 0,C5-958I[20]8W;I&J!'F#L8^"+X#8-<']6W8E5#RRUZJ9&;)W<1U<=:
MLD8-:K!/)Y3`\\J:"2<OG(<(>90KA-:3ADB-H9ZQ'.Q&,'W42.-Q2)':*1I?
MJ`I`,L$L(SI(Q>#K7RIIYO-S9AZ49$)[H+(KLI5I.VX+"(U&%!3UHP!7MDE/
M2S:0\83[@'G*$I(HZ!/*G^2V+)>31!85/:G8T'Y?BHC`M$0^2N,^?#EE1>`>
MH$;!"O556OMID*`2B6I at N-.7)THR59-WB:FJ9N?#I6V6MQ7P-<K;E\IH^B9L
M4MC*#Q"V_TRYZ:'6!O_+_M%72<)\B*G'/FY;S,A=)(.-%A:5X9MM)U=I/9'A
M at BR@?=FLM$12(B.9A10H:22$*7VQKXKT!U;/-+:B9"[9K[`$^P6C=;AZPKK"
MBB"+#/P,2C<'0P?66+(J,\3(FA!J*G('_LF<9K!?1HGU75;00 at L'82DW8!S&
M<6P*M>->S[[DVCXEG<K`>>M#`*LZKJ'CJ1U8F,H0B^+ZN?DM/^\KSL\+4W_.
M`<FQ5."QV82=>2DC48I9!@D)@=N>X.:"4NBCW&*UWTGD).!R]M&.8@:*'BF@
M94,\4S7:2;V2LKB0NY/*C(=%!7O*3A$]TI<9]H7<RS(O1W=FF)FK1#,9-FKY
M8M(1+=;05BX^4(R2:A^408Y65OJ8A7Z\3XHXI8*SZ_N[$H88,B-2BIKHNT(/
M1W1-JIR5BD;YOXB3LHD-R?VDFJ(F^K=$T;]=HBAICUU-JMS9M,WFGR=#1\[<
MXY-B*=SX^[Q]OPRL6A)6N)?W44F*<N7D.,(-/P5+Q0NRLX\]"3V_ZCO:%`P'
M'UI(!X4]:1$H$Z"H6(G)9Z607^DMWM2TKK\K197*JZO5WI568)BH\1CX5;?#
M[W`C?O7'P>]P._RJ&_$[?!S\:MOA5X_P^Y30Y"NW5F5N!-2C4W-S[N#A+K#U
MIKY@^P1X7^ILDP>\C&F5MBULV1CC&LK=PW-U;<R0P,VX]XX[9R/X!W"$M![W
MU:#W\=O<]=Y+"*X39B7A#/7Q*!./P>YRW5[G]63X)^=G,N87LQ"_;N+BQAFZ
MQ>Q<-S,?`;/J9LP.UV)6?RS,#C=C5EV+V>%C85;;C)F<B[GQ?32MUEH]:=LF
MWW+Y*X]4:!%F:9P>=)YB(Y!='*989:HH-9+1(CE*1.UOX)BV4"/EC!K)+ZVM
M+:VO+2615 at A%\17:#I$TBTSYE"6_<;OESY[_SYZBW\6=`MG?^OL?:O7Z45W>
M_W!T?/P4Z]4.JT??[G_X(K]*I;S+'YT7MRD$0T>1&4L+&'FFMMOG-GLY=>3U
M"3VE4<,61K;%;C%$J\HALPKOJ;A/G<.ZO^VU.LWVY?WKPO?JR/GZ6H#=+GZ%
MG8\2[_68"6]FB7F#P5N&,84XSJ/HS%B#,?E<-N)[(M0=".B*#9!AKE="`U!M
M$>`9]=`$SAX<D)V4=_@?PMLL0#)6FHI'E6!L;\%#G&`:1=B*TQ9"8 at 2$^"U8
MOH9EGZ:)`^M+3(>2O-TAT3)#244HGW%#76P!AKF):6^)-F"54[*F/Q%&G-,L
M+PY(_'8O_H\@:3UY%(CHOUO at CX&MNJ+B,;"-+YL)+ZVIR&!9ZB*:=%D[.J+I
M^2OJ75B#07?B5Y(2NO+"F\<@V4O7FW//9!<"C%&5A?>W8#8A/[5MP-PW/&N"
MF$=:8JT^7*$E\2A:.,&598[W^-#I')D]M/]2ENZST%5`,.B$@P$K\[C2JD;5
MUUH?R-D!#,\T-A]9X%<GKAWB=&&+!:,`*&'L/%1*\MJ4?(V2.%.4W=@ERS.\
MFB>=8Z"V';\V+1Y&M7.WJ*.M1)[2S?&Q0MSY3 at _3!Z\`S#]U<"K13/P'-7>4
M:P*-_!_#W1!%E=W**I%YEP"1Q,+!K4]YN51*''?:4W8[$2/9\BGTVLX*\CT]
MF4X*CS+J5?, at N@`K:8SNM//'&$U&_\CMZ0J=R2R?L5N2WPHFWGQ-;,UIF=VU
MOPJ?FK?Y8!+YY!I``)VXZGPVP@(H[*SPL3"9]FW+:."&6'A`N5>'^:PB#6%6
M.NV8T5%AJ>B:I!!@NH.6H<`'%,M]`Z52*+6)O'/*XL.]!$KF)Q7:)1??7VH+
M')$JU at C!X_J!O&LD88?`BK6X`U2!:C=6W33G>N'A4U4.8^-3F[0Z+AH(V at .U
M11FV_454[,ME!G0<!DLDAA(>;?@VLTJ6?9089'CXLG6V7%O%B%KL'W2/EHS'
ME$((H"7EMJ\(1FYX=!8+4!9L=RX\2E,(Y&D'13QH'*9:G%`T'`NG:+JOK5R3
ME<ED7L;]C."@S&0%`>,U:A$MEL+QP'"DP%JU%>(P*%JU)U!8ED_5F'&[ZUK]
MK:]`85TF"B8B[A4EDII5!TS+$D]\D4%26.CB3V%Y39:KQ.A'&H_Z>Y at S6^Y\
MP6`EQG05M3*'J36 at O,-*$:8:P-#HE<:0>H47&)6>()B2CE3K8C5.*6?%%"28
MC`<I6$5D=V$O7:F^7"D\8UC.[;"VNL-J%E9]FPZK48=/<CNL/Z##O!$ND:$:
M"L>G1UJ_-QJ'C[[2;9.0B*N+`R9](6G+WY*MG0D>G$+S:,74HK#VJJS#LT8#
M_6F83TOI[7%`?F7*XD!&SL.U;PTFTBK,N<LC/1952]N$-;L1 at 02F]!.]-QIC
M_EX4%9#B0$^L$\423M=2*LY]L#[>ANGR?W7$]/_7;\VEN#OK8WW\OUY_^JQ&
M\?_Z<>WI\3'&_Y_5#K_%_[_(#U7I09DU\<K0`U*_Y\W+!IC0PO%WZ"E&URO[
M[B"8XP%@2D1#/6-CZF+R&M3B"%QSRV$&9BV8;/^V^[+W]ORFM5^BH(#\2FJ"
M%:]5;@/K]O\7)+C<!3>>LB&4S4G=G$_DB3!Y=E3>G3OFIH at O%6)3QU0W#X.=
M/J8+90W/Z@, at 1$9=YQLB0CF3?763+Y^`B3*#BAC7\80M.- at P%&F`!<,%!Q2Q
MN3PO-YNL(R_KHI?R3_\L'SW3P_7NSK$%K"\N8.#-+1_OA37I$)NIR4,I2WTS
M/H41*EN?$RJXB+D+(1A>>ZR>R>W%<8'S1(Y"L"!'&/QB0-BQN!9'^&5-A'3I
MXK75?`Q_.N%UT9>\[U*]A:(6J`XZ5\,ZKL[>EH^?5I^56YU7Y<,C&C_"H8[U
M6YU=X.5>`06AH!=YW$Q1E<I?X<W/#I7C`#UK.`I\E=*B(22ZG!@L04%772=N
M-4Z31R>0T at FDLSZX,ZXEJA.P"=TUAJFFGH57<,\$I;=(:9&-Y<W)8!0L,O3'
MH>'!*I+%$??PL!Y*@&5B#@X>&J3Z'3>@ZWE(RA=Q>@Q=U4:<\T?6A(["IX9G
MXNX*QRNLW(F\2+HC+)0*HF6"3([K9?DJY?H]GK!W,"W(\T"QP^B%#"RB6.":
M;J%0P3.G'&)9V;9X'WQJ%`Y/(80G.GQ+?1VHWC##B,0D2?-0B-N#F$Q0/G9A
M2;=D9I(:W1+%-9D_%%:ERXU#$.IFI3[XK#"K/.#(F'OO$7G?Q6`K9BT!:#"+
M!HB6%:BC+5*$0Z\XGN,#SQW#Y.M<1 at CCM4LK;F$F_0(]81Z4*(\!!@W#=<?\
MO[AAZS9W;'WHSDB>\*IN"U@@KV(DS307?3;A0Y``D.@@F#0JE?E\KB>;JMN4
M]=UJV;3ZW at W<!'B*F4=;N\D[#AY[H[;3>BN3'^ZN+\Y[K9O[9K=SVSOO]-ZT
MFKWN3;-[==WMM#J]%\VEW=L'-7WTK5BVTN9JL!=09C9!5PQ1SX;["T&@`M%A
M@)I"FS2WY"D:"I43$,K[`_4QQ'NQ\&XS3&;OBX6+BBBSMTB_&%31=H>8)6,O
M2C#]HQ@;HYSO`3?H2":/[^?, at T8G"?2_P\[0MTU+!3RQBTC_>PK,(*MT7-R6
M3.\QQJ77Y[XO/+G;F+-=J:X*"?^NV-3,U'H!=M/??/MR110!<_Y6!Q+4!Z*)
M#*CL%JNU&Z"K%)'<YDQOH."ZKW at 5*JC_:^_8?]HVPC_'?\6G0C.[8`>2;I6@
MJ08):ZF at 5".L_#"MRL-)/$*"XM*)H>YOW_>X.Y_CQ`%$F#KYQ,/QO;_O<O>]
M+SGYOS`%$\:BJH0.F5:()S?2L5*;U'9FA[$W&%9LLF4>!?Z<*L<CVDBH2[KF
M([/)3<9":O&N%"GEJ-Z8A`;$75-/S_42JP]%JM$@+\/VF&G,81O)$6Z"XA#X
MO?`*3WWJ!KE@@#U;9`XQTAAD\$Q^ZZ+O16B1R?28?66$Z&T+)4`;IV]`(3/"
MP?X=3B>[0D*U^WV<&E)FX]&-(EJR:DWEGE4QTZ<-O=LFFH>CW>D.A+%1-TW0
MF#I2@*. at 2<L&802AEI'M6MII%0*#!$*:<S`;_JHV]UF3VE:B$%JP/M.*GD<=
MT!RM"TF>'5@\&E9)T%(4R?;7=+Z)"B#RNQ:4-4!-3F<R&>D5I'O9UVBMJ^!0
M-(0=[N;SI4O_/+$DGND.,V?>J'*Z5RR@'[U-$:HOZ!I++LCQ0"K>*J5++G1D
MWHOWFC)2_^$H/3]^%<@'/<KL1*54YGUVPE(P>;%\XE)C8;YGIK^B!8 at G;#00
M3L\8>4"3`E?WPO"*>#>5'2Q9G%#6]>O+,3$=QI[1QPCT*8#4,%:HV)V/"%4F
M\WYW!@^J7/)B-Q\+JOS"?-;B&H'S"]I2E=YJ14CIRO5(<44QK%/Q at 2$W&]SM
M2;H3*WSH+<'-:"H5)(UN<P9JV0I9L'+=E@%LMHH%82Z;M\%D:R^&M]%-G\7L
MBB[.1\R%JSC>UGGQ at W(LWH0P&`2;(D.P#]BN!/,F#X;4<=VBX"WZ$VF34RO(
MRI/)T<\5BQ7"'<<"O2RO.2"6C!:DUV$>C*C$JM1=>V-E)SJ/:I)SD""W^"Q\
M*FU8/AVKCFQ%(;Y.:XNX:DIA9'O!`.3L7Z^UH at U:=E1!>`-D0Z$D?18/<>^>
M'SR`^=8F#P7``X'`K9!D/:W(>P2`/'@TU&G>%0'9$<#I-8OOI9;\K)JH(YSI
MF):R_YE!0#EF#Z8EQ^4B,)0[[,F_HP#AQIN`;P3*PN<@?:%";`F?[2H=OO94
MULH28 at N41#<F at 1Y$0I'',E(6E8\G]-'7]]@IW*G_BE%W5077"\;7ESA/L=''
MG;]>ARWC&9OT;MTL(R,.TD7T-'`[3IKFF'RVBU6ZS;>A<$6]B'D_"DJO,G6P
MTTXW4$=F!:J[C at V,4%0C2>688HV/;6A0C!FV<U0CAE3]:8B;*(5`"^'/:\1J
M=SBY(MLO;L$6EFW"E_8%!S(BV3R>;$DS>,3U1NJ,8RT/<ZO8(I64DT.B]!.'
ME^SF20,N*XOPK")FAY%+.SNQ9KZQ$/-F0,UW`/5HS!JDN`A<!-7BX[Q<!O.5
M3M"3TKP'$VVRQI'[Z[#M)76D.QU0B%*(#$@V>UM]6\VB&=&B)/`,H\&0I.+(
M)/-1G*!:QJ[07$YU>VN>N+EWU(94AG2.7DG)Y3<I:6<DRX)MQN:L- at W4,5\=
M$*>6<!I&@^1N`?S$[;D]L[(M'*EQ[0E at LM^:5++>Z:]1]O8$*T?N1P#?#'A#
M80!Y&!UO;D[*M&`-_!M8>%V(@".#O/G3O1L:V,[O$='`[3T"&DKWQP/?7P%B
M.S<+8<I#S.C9^`I'-M`=^;LBWJ09ILPZ_]%GF[=*+M58=BK^Z(J"^Z2$4H:4
MU8P14_LZ;FSJU#/X-U#W`I)YN5TE;D3L9Y at ECMI@%4AXHB2>`O:;8A#,N6U.
M?,M]6/=M"/Y'!)HB^)/HX`L$KVG_$I8GTF;-BAW2'PM!A0?>?B-6 at KY<<>X*
M97:S(KN\R:4)YKR2[CPY6HX`#>XH0V.R[`X",^DJ)2D3246WDR<4N]7\Z'(.
MRF*<U'?"LIU=2B^7^XGQ;/(%>ABY;6V@)O1\)'%V(G at -57AA?T^L@(80;6QX
M9GOKWRU(?.N-&VUF42`6R25-=.,+ at 742%B7#XN<Q]39'3\W(E]F*Z7!_M?!_
M;:BUHF0<!U?81[[]WU:M]E/-^/_77E6Q_/:/U>W"_N\IT at K.MV7^_=I'X4D=
M^S_B\UFCM<2Q/RGE?$^._<M=*76H'`_8S_^RC40:V3MU^;I1)C;D_,'J,W8=
MWX5Y1&',(8U;AA:M:'Q3D0-X1785N;8%]UF3._`QG*K at T[E+,X!TP#)J)D+"
MF*AYB6<6\2UPUW'8OQ[)/:+B1:$]>;7C=)^$-NUX):9*(KS[;6;L;'H0ZK'-
MB[[&S'2;1Z>-9].QM5.P28#"7<[<ICICNT&473.ZK%?O&$AY)@JRHW'UT.C)
M^C(U>=L>Q\C$$XDF3^2&58>O[(T%?RDW2)6U35G^5W:<PKPM^RX"W<Y2!Q*S
MKQ<.)#/IN'V!Q^$H7&4?3/]M+:3_ME_6Q/_CY2NB_,C_8[M6JQ;TWU.DM;4U
M..&I;\+[L-^?AC?0#!QZ7474'+>GU5?\B146],2?&GPE1\A^(\A"#*;M2\?Y
MU/CE:._M:;WD?R))A?]I//')3('C"5'T&YU?\@>P[JKB'OR.S)_?Y,M'P&_.
M#W0FA0[7;]^='!]\4Z;3TVHEGG8K,.?]*.I4C at X_G)T/NMV*TVA at I[H,OO$C
MXD]'(WJN53K1F!Z<QOFYGD#S[/3@\]'A_MOS\\^''["A at U,<L1HP%5S:WL:&
M<]34S1T%I378.ST].SX0&W$:)N`8IV*XI86EZDX3)2YE"SL<!$-LQ%/S:9PX
MG=.3LU\;.*8Z#&]ZN#??X+D1=>.`<D_VWR/_2GDX8EURYSGFU9\'$\]QG.<[
M@$]."?//SSW@?PH7ZZX:-3[^09^P>P_\":S_K.IA%_>N2`;\2!J4\(3W^_`B
MF.!O%.&?V'&&8;L73A.C@(A(A!+.$_SCXP3H]F3X at W[&O1]AVVR"-`2TFX'=
M&N4WZ!YY5MU<JBMDG at U(L0;^!<P9P+. at ."6*5*0B%:E(12I2D8I4I"(5J4C_
+I_0O9"OC<`"@````
`
end

From cummings at cacr.caltech.edu  Tue Apr 10 23:37:33 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Tue, 10 Apr 2001 16:37:33 -0700
Subject: reference loop with updaters
Message-ID: <3AD3993D.D1477259@cacr.caltech.edu>

Hi All,

I got a little sidetracked today when I noticed that a few
of the NewField test codes (BasicTest1 and FieldTour1)
dump core at the end, during object cleanup.  This happens
because the Pool class detects that not all the pooled memory
has been freed.  After a fair bit of detective work, I have
determined that this is due to a reference-counting loop
between Fields and Updaters.

When you add an Updater to a Field, the Updater stores a
copy of the Field in UpdaterRetargetBase.  The Updater is
added to an UpdaterList stored in the FieldEngineBase
base class of the FieldEngine inside the Field.  Thus, there
is a circular loop in the reference counting.  When the Field
is destroyed at the end of the program, it calls the destructor
for its FieldEngineBase.  The FieldEngineBaseData referred
to by the FieldEngineBase does not get destroyed, however,
because there are outstanding references to it which correspond
to the copies of the Field in each Updater.

I think this is a fairly significant problem that should be fixed.
I'm not sure what the proper solution is though.  Calling
removeUpdaters() in the Field destructor causes an infinite
recursion.  Perhaps this recursion could be broken by making
the FieldEngine the subject of an Updater, rather than the Field.
Would that work?  I'm going crazy just thinking about it...

-- Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125




From stephens at proximation.com  Wed Apr 11 00:32:07 2001
From: stephens at proximation.com (Stephen Smith)
Date: Tue, 10 Apr 2001 17:32:07 -0700
Subject: [pooma-dev] reference loop with updaters
Message-ID: <F871BB04B0EA224A821A5274C31DF3150216B7@proxim-sf001.santafe.proximation.com>

I thought I'd mentioned this issue already in a previous
email.  Anyway, the solution to this issue in the old field
code was to not copy the updaters when the boundary condition
copies the subject field.  (FieldBCondBase uses the tag
DontCopyBoundaryConditions when initializing the subject
member.)  This solution would cause problems for Blanca,
because they use updaters for relationships and the
relationships are supposed to trigger the updaters of
their subjects to make sure all the necessary relationships
are fired.  I believe that Scott is working on incorporating
the Blanca relationship code into the r2 updaters, and will
probably have to address this issue at some point.

A complete solution would have to examine the Blanca
relationship code.  Supporting weak references for
the ref-counted block pointer from a field to its
updaters for those fields inside other updaters would
probably work.

This problem is serious and on the list of issues to
be addressed.  You can always configure with --no-pool,
to test codes with the new field for now.  (Purify will
still complain about the pile of fields that aren't deleted,
though.)

    Stephen


-----Original Message-----
From: Julian Cummings [mailto:cummings at cacr.caltech.edu]
Sent: Tuesday, April 10, 2001 5:38 PM
To: pooma-dev at pooma.codesourcery.com
Subject: [pooma-dev] reference loop with updaters


Hi All,

I got a little sidetracked today when I noticed that a few
of the NewField test codes (BasicTest1 and FieldTour1)
dump core at the end, during object cleanup.  This happens
because the Pool class detects that not all the pooled memory
has been freed.  After a fair bit of detective work, I have
determined that this is due to a reference-counting loop
between Fields and Updaters.

When you add an Updater to a Field, the Updater stores a
copy of the Field in UpdaterRetargetBase.  The Updater is
added to an UpdaterList stored in the FieldEngineBase
base class of the FieldEngine inside the Field.  Thus, there
is a circular loop in the reference counting.  When the Field
is destroyed at the end of the program, it calls the destructor
for its FieldEngineBase.  The FieldEngineBaseData referred
to by the FieldEngineBase does not get destroyed, however,
because there are outstanding references to it which correspond
to the copies of the Field in each Updater.

I think this is a fairly significant problem that should be fixed.
I'm not sure what the proper solution is though.  Calling
removeUpdaters() in the Field destructor causes an infinite
recursion.  Perhaps this recursion could be broken by making
the FieldEngine the subject of an Updater, rather than the Field.
Would that work?  I'm going crazy just thinking about it...

-- Julian C.


--
Dr. Julian C. Cummings                       E-mail:
cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010410/08fa6b7d/attachment.html>

From cummings at cacr.caltech.edu  Wed Apr 11 01:44:45 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Tue, 10 Apr 2001 18:44:45 -0700
Subject: Domain traits
Message-ID: <3AD3B70D.E03A4831@cacr.caltech.edu>

Hi All,

I rewrote a lot of the Domain code to eliminate the use
of enums to represent traits in favor of static typed data.
Jeffrey is reviewing my changes.  As part of my changes,
I removed these traits values from the Domain classes
themselves because that's what DomainTraits is for.

However, testing has uncovered that there are several
places in BrickEngine and Evaluator where traits such
as dimensions and unitStride are being extracted from
a Domain type.  Is it OK with folks if I change these
spots to get the traits from DomainTraits?  An example
of this is rewriting

Domain_t::dimensions

as

DomainTraits<Domain_t>::dimensions

I think people are used to the first notation because we
do that with objects like Array and NewField.  If people
are really annoyed by this, I suppose I could put the traits
values back into the Domain classes.  It just seemed kind
of silly to me to have the traits values repeated in two
different places.  What do you think?

Thanks, Julian C.

P.S.  There are a few pseudo-Domain classes such as
IndirectionList that do not have a DomainTraits specialization
defined at the moment, but they really should.  These
classes are never used in Evaluators, however, so there
is no problem in practice.

--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From mark at codesourcery.com  Wed Apr 11 02:05:02 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Tue, 10 Apr 2001 19:05:02 -0700
Subject: Patch: Get NewField to work with messaging.
In-Reply-To: <3AD38278.EE0CF993@proximation.com>
References: <3AD38278.EE0CF993@proximation.com>
Message-ID: <20010410190502N.mitchell@codesourcery.com>


FWIW, I recommend that everyone put the following lines in their
~/.cvsrc file:

  update -d -P
  diff -c -p -N
  cvs -z6

The first line ensures that when new directories appear or old ones go
away the right thing will happen.

The second uses a much prettier format for `diff' than the standard
one -- and one that `patch' can handle even if things have changed a
little from the time of the original diff.

The last turns on compression when using remove CVS, which is probably
a good idea since bandwidth is usually harder to come by than CPU.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From jcrotinger at mac.com  Wed Apr 11 14:38:45 2001
From: jcrotinger at mac.com (James Crotinger)
Date: Wed, 11 Apr 2001 08:38:45 -0600
Subject: [pooma-dev] Domain traits
In-Reply-To: <3AD3B70D.E03A4831@cacr.caltech.edu>
Message-ID: <B6F9C895.4A88%jcrotinger@mac.com>

on 4/10/01 7:44 PM, Julian Cummings at cummings at cacr.caltech.edu wrote:

> I think people are used to the first notation because we
> do that with objects like Array and NewField.  If people
> are really annoyed by this, I suppose I could put the traits
> values back into the Domain classes.  It just seemed kind
> of silly to me to have the traits values repeated in two
> different places.  What do you think?

ACK!

>From a usability standpoint, these should stay in the domains. I think we
went way overboard in generalizing domains, and part of that is
DomainTraits.

Aside from "int", we don't use any non-"src/Domain" classes as Domains, and
I suspect that most things that get a Domain really aren't expecting an int.
Thus we don't need the extra layer of indirection (which does have a cost in
both compile time and code complexity). Further, since we have Loc<1> for to
represent single points, we don't even need to provide the capability of
using Domains as ints. The main exception is in user interfaces where ints
are expected (Array::operator()).

Also, I'm not even sure what I'm supposed to include if I'm going to use the
DomainTraits class. Do I just include "Domain/DomainTraits.h" (which is just
the general template). Do I include every one? What if someone later adds
another?? Whoever instantiates our template will have included the
appropriate Domain header, and thus will have the appropriate DomainTraits
header, so maybe I only need the general template to get things to compile,
although this seems like a physical design mistake to me. And what about our
friend "int" (the only reason to provide the indirection in the first
place). There is no "int.h" that includes "DomainTraits.int.h", so that
specialization will not be there. So I do need to include
DomainTraits.int.h. What if someone tries using an int[] as a 1D domain? We
could probably make that work (if we can't, then DomainTraits really is
pretty worthless 8-). Etc...

So...

I'd say changing enums to static const's in order to eliminate some compiler
warnings is cool. But I don't think we want to start cleaning up the Domain
design unless we're ready to jump in whole hog and basically do

  % rm -rf Domain

and make a fresh start.

    Jim



From scotth at proximation.com  Wed Apr 11 16:07:32 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 11 Apr 2001 10:07:32 -0600
Subject: Chevron Flow Scenario
Message-ID: <mailman.9.1331172041.20475.pooma-dev@codesourcery.com>

Hi everyone,

I have attached a PDF file summarizing my take on a paper [1] describing 
a finite-difference approach to a flow simulation that was of interest 
to Chevron. If people would like copies of the original paper, please 
supply a FAX number.

This simulation is interesting for a couple of reasons. First, it 
requires a staggered, non-orthogonal grid and a flux field with a unique 
face-like centering. Ultimately, it introduces multi-block meshes and 
fields to obtain geometries that are locally structured, but globally 
unstructured. Second, their paper shows how complicated, inflexible, and 
hard-to-follow things can get if you use the wrong abstractions (they 
linearized indices of control volumes, thereby locking them to 3D and 
forcing the use of indirection lists).

While the authors clearly messed up the abstractions, it isn't so clear 
what the correct abstractions are. After thinking about this a long 
time, I think I have at least some of the vocabulary:

mesh
sub-mesh
cells
faces
edges
sub-cells
sub-faces
sub-edges
vertices
centering points
neighborhoods
orientation
nearest
reduction

Note that there are no array-like concepts in here like Intervals, 
Ranges, etc. One reason is that field operations inherently involve 
centering points and, specifically, mappings between centering points 
and our rectangular domains are not the very good at expressing this. 
Another reason is that if one expresses operations in terms of 
geometrical concepts, the code is born dimension independent.

Based on Jeffrey's excellent discussion, I think that the Caramana 
hydrodynamics kernel has a similar flavor and is therefore described by 
similar language.

Let me emphasize that I'm talking about USER interface here. When push 
comes to shove, everything needs to turn into indexing.

Questions? Comments?

Scott

<Attachment missing>
--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1866 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/c3f72ef9/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flow.pdf
Type: application/pdf
Size: 25433 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/c3f72ef9/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 150 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/c3f72ef9/attachment-0001.bin>

From cummings at cacr.caltech.edu  Wed Apr 11 18:14:37 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Wed, 11 Apr 2001 11:14:37 -0700
Subject: [pooma-dev] Domain traits
References: <B6F9C895.4A88%jcrotinger@mac.com>
Message-ID: <3AD49F0D.C7100BFE@cacr.caltech.edu>

Hi Jim,

I feel your pain with regard to the whole design of Domains.
However, you are overstating the difficulties here a fair bit.
You are correct that the main reason for the existence of
DomainTraits is to handle int's as a Domain.  We need that
capability for the Array interface.  As a result, it is sensible
to standardize the method of obtaining traits info by having
all Domains do this via a DomainTraits specialization.  I
don't think DomainTraits can or should be eliminated at
this point.  My only question was whether it was OK to
require that code pull these traits from DomainTraits, and
not assume that the traits info is duplicated in the Domain
class itself.  Obviously, not using DomainTraits fails if the
"Domain" is actually an int, but then again, the code may not
be expecting an int anyway.

There are not many changes required to existing code.  I found
a few spots in BrickBase.h, the MakeReturn functors for Array
and NewField, and some of the Evaluator classes where we
were extracting a trait from a Domain rather than DomainTraits.
I have already sent Jeffrey all the changes so he can double-check
me on that.  To address your comments about usability: the Domain
header files such as Interval.h already include the corresponding
DomainTraits.Interval.h header for the DomainTraits specialization.
So no new includes are required beyond what is already done.  The
DomainTraits.int.h file is sneakily included by Loc.h and/or Interval.h
as well, mainly because we define arithmetic interactions between
int and these two Domain types primarily.  I agree that this is crummy
physical design, but it is functional, and we are not likely to add further
DomainTraits specializations for other non-Domain types.

The main motivation here is not to clean up the design of Domains.
It is to avoid unnecessary duplication of static traits data in both Domains
and DomainTraits, given the necessary evil of a DomainTraits class.

-- Julian C.

P.S. This issue of a separate traits class doesn't apply to Layouts or Engines.
In those cases, I would like to convert the enums to static data members,
but we can just leave the data where it is.  I'll do those changes later.


James Crotinger wrote:

> on 4/10/01 7:44 PM, Julian Cummings at cummings at cacr.caltech.edu wrote:
>
> > I think people are used to the first notation because we
> > do that with objects like Array and NewField.  If people
> > are really annoyed by this, I suppose I could put the traits
> > values back into the Domain classes.  It just seemed kind
> > of silly to me to have the traits values repeated in two
> > different places.  What do you think?
>
> ACK!
>
> >From a usability standpoint, these should stay in the domains. I think we
> went way overboard in generalizing domains, and part of that is
> DomainTraits.
>
> Aside from "int", we don't use any non-"src/Domain" classes as Domains, and
> I suspect that most things that get a Domain really aren't expecting an int.
> Thus we don't need the extra layer of indirection (which does have a cost in
> both compile time and code complexity). Further, since we have Loc<1> for to
> represent single points, we don't even need to provide the capability of
> using Domains as ints. The main exception is in user interfaces where ints
> are expected (Array::operator()).
>
> Also, I'm not even sure what I'm supposed to include if I'm going to use the
> DomainTraits class. Do I just include "Domain/DomainTraits.h" (which is just
> the general template). Do I include every one? What if someone later adds
> another?? Whoever instantiates our template will have included the
> appropriate Domain header, and thus will have the appropriate DomainTraits
> header, so maybe I only need the general template to get things to compile,
> although this seems like a physical design mistake to me. And what about our
> friend "int" (the only reason to provide the indirection in the first
> place). There is no "int.h" that includes "DomainTraits.int.h", so that
> specialization will not be there. So I do need to include
> DomainTraits.int.h. What if someone tries using an int[] as a 1D domain? We
> could probably make that work (if we can't, then DomainTraits really is
> pretty worthless 8-). Etc...
>
> So...
>
> I'd say changing enums to static const's in order to eliminate some compiler
> warnings is cool. But I don't think we want to start cleaning up the Domain
> design unless we're ready to jump in whole hog and basically do
>
>   % rm -rf Domain
>
> and make a fresh start.
>
>     Jim

--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From oldham at codesourcery.com  Wed Apr 11 17:53:09 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 11 Apr 2001 10:53:09 -0700
Subject: RFA: src: Spelling and Initialization Order Changes
Message-ID: <20010411105309.A13326@codesourcery.com>

Ok to commit?  Reviewing these changes should not take more than ten
minutes.  Would you please consider reviewing them?
  
2001-04-03  Jeffrey D. Oldham  <oldham at codesourcery.com>
  
        * Domain/DomainIterator.h (DomainIterator::DomainIterator):
        Reorder initializers to reflect class declaration order.
        * Domain/Loc.h: Fix spelling in comment.
        * Engine/ConstantFunctionEngine.h (Engine::Engine):
        Reorder initializers to reflect class declaration order.
        * Engine/IndexFunctionEngine.h (Engine::Engine): Likewise.
        * Evaluator/WhereProxy.h: Fix spelling in comment.
        * Layout/Node.h (Node::Node): Reorder initializers to reflect
        class declaration order.
        * NewField/FieldCreateLeaf.h: Fix spelling in comment.
        * NewField/FieldInitializers.h: Likewise.
        * NewField/FieldReductions.h: Likewise.
        * NewField/DiffOps/Div.UR.h:
        s/UniformRectilinearMesh/UniformRectilinear/g in comments.
        * NewField/DiffOps/Div.h: Fix spelling in comment.
        * NewField/DiffOps/FieldStencil.h:
        s/UniformRectilinearMesh/UniformRectilinear/g in comment.
        * NewField/Updater/PeriodicFaceBC.h: Fix typo in comment.
        * NewField/Updater/PosReflectFaceBC.h: Likewise.
        * NewField/tests/VectorTest.cpp (main): Fix test's name in the
        source code.
        * Pooma/Pooma.cmpl.cpp (initialize): Fix spelling in comment.
        * Utilities/RefCountedBlockPtr.h
        (RefBlockController::RefBlockController): Reorder initializers to
        reflect class declaration order.
        (RefCountedBlockPtr::RefCountedBlockPtr): Likewise.
  
Tested on       sequential Linux using gcc 3.1
Approved by     ???you???

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Domain/DomainIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainIterator.h,v
retrieving revision 1.7
diff -c -p -r1.7 DomainIterator.h
*** Domain/DomainIterator.h	2000/04/01 00:26:22	1.7
--- Domain/DomainIterator.h	2001/04/03 22:46:43
*************** public:
*** 99,105 ****
    // iterators to the start. This constructor sets up a "begin" iterator.
  
    DomainIterator(const Dom &d, int size = 0)
!     : index_m(size), domain_m(d), loc_m(d.firsts())
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
--- 99,105 ----
    // iterators to the start. This constructor sets up a "begin" iterator.
  
    DomainIterator(const Dom &d, int size = 0)
!     : domain_m(d), loc_m(d.firsts()), index_m(size)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
*************** public:
*** 109,115 ****
    // Copy constructor.
  
    DomainIterator(const This_t &model)
!     : index_m(model.index_m), domain_m(model.domain_m), loc_m(model.loc_m)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
--- 109,115 ----
    // Copy constructor.
  
    DomainIterator(const This_t &model)
!     : domain_m(model.domain_m), loc_m(model.loc_m), index_m(model.index_m)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
Index: Domain/Loc.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/Loc.h,v
retrieving revision 1.22
diff -c -p -r1.22 Loc.h
*** Domain/Loc.h	2000/06/27 02:48:17	1.22
--- Domain/Loc.h	2001/04/03 22:46:44
***************
*** 110,116 ****
  //   comparison operators: <, >, !=, ==, <=, >= : compare a Loc<N> to
  //      another domain object.  The compared domains must have the same
  //      number of dimensions.
! //   arithmetic accumulation operators +=, -= : add or substract in a
  //      given domain.  The added domain must have the same number of
  //      dimensions, or a dimension of 1 (in which case, the same value
  //      is used for all dimensions), and be known to be single-valued (which
--- 110,116 ----
  //   comparison operators: <, >, !=, ==, <=, >= : compare a Loc<N> to
  //      another domain object.  The compared domains must have the same
  //      number of dimensions.
! //   arithmetic accumulation operators +=, -= : add or subtract in a
  //      given domain.  The added domain must have the same number of
  //      dimensions, or a dimension of 1 (in which case, the same value
  //      is used for all dimensions), and be known to be single-valued (which
Index: Engine/ConstantFunctionEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/ConstantFunctionEngine.h,v
retrieving revision 1.16
diff -c -p -r1.16 ConstantFunctionEngine.h
*** Engine/ConstantFunctionEngine.h	2000/07/20 15:39:26	1.16
--- Engine/ConstantFunctionEngine.h	2001/04/03 22:46:45
*************** public:
*** 100,106 ****
    // Construct from a domain object.
  
    Engine(const Domain_t &domain, T val = T())
!   : domain_m(domain), val_m(val) 
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain[d].first();
--- 100,106 ----
    // Construct from a domain object.
  
    Engine(const Domain_t &domain, T val = T())
!   : val_m(val), domain_m(domain)
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain[d].first();
Index: Engine/IndexFunctionEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/IndexFunctionEngine.h,v
retrieving revision 1.20
diff -c -p -r1.20 IndexFunctionEngine.h
*** Engine/IndexFunctionEngine.h	2001/03/29 17:09:26	1.20
--- Engine/IndexFunctionEngine.h	2001/04/03 22:46:45
*************** public:
*** 129,135 ****
    }
  
    Engine(const Layout_t &layout, const Functor &f = Functor())
!   : domain_m(layout.domain()), funct_m(f) 
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain_m[d].first();
--- 129,135 ----
    }
  
    Engine(const Layout_t &layout, const Functor &f = Functor())
!   : funct_m(f), domain_m(layout.domain())
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain_m[d].first();
Index: Evaluator/WhereProxy.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/WhereProxy.h,v
retrieving revision 1.3
diff -c -p -r1.3 WhereProxy.h
*** Evaluator/WhereProxy.h	2000/07/20 15:39:26	1.3
--- Evaluator/WhereProxy.h	2001/04/03 22:46:45
*************** struct ConvertWhereProxy
*** 67,73 ****
  // A = where(f,B);
  //
  // Rather than have where(f,B) return an array that could be combined in
! // an expression, we return a WhereProxy that is recognized by assingment
  // operators.
  //
  // The WhereProxy is also necessary because the elements returned by
--- 67,73 ----
  // A = where(f,B);
  //
  // Rather than have where(f,B) return an array that could be combined in
! // an expression, we return a WhereProxy that is recognized by assignment
  // operators.
  //
  // The WhereProxy is also necessary because the elements returned by
Index: Layout/Node.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v
retrieving revision 1.33
diff -c -p -r1.33 Node.h
*** Layout/Node.h	2001/03/20 23:42:48	1.33
--- Layout/Node.h	2001/04/03 22:46:45
*************** public:
*** 142,148 ****
    Node(int affinity, const Domain_t &owned, const AllocatedDomain_t &allocated, 
         Context_t c, ID_t gid, ID_t lid = (-1))
      : domain_m(owned), allocated_m(allocated), 
!       context_m(c), global_m(gid), local_m(lid),
        affinity_m(affinity)
    {
      PAssert(owned.size() >= 0);
--- 142,148 ----
    Node(int affinity, const Domain_t &owned, const AllocatedDomain_t &allocated, 
         Context_t c, ID_t gid, ID_t lid = (-1))
      : domain_m(owned), allocated_m(allocated), 
!       local_m(lid), global_m(gid), context_m(c),
        affinity_m(affinity)
    {
      PAssert(owned.size() >= 0);
Index: NewField/FieldCreateLeaf.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldCreateLeaf.h,v
retrieving revision 1.4
diff -c -p -r1.4 FieldCreateLeaf.h
*** NewField/FieldCreateLeaf.h	2000/08/08 17:31:33	1.4
--- NewField/FieldCreateLeaf.h	2001/04/03 22:46:45
*************** template<class G, class T, class E> clas
*** 89,95 ****
  
  //-----------------------------------------------------------------------------
  // Fields are leaf objects, we just pass them through unless they have
! // Expression engines. Then, we remove the expresion from the field and form
  // leaves with tree-nodes. 
  
  template<class GeometryTag, class T, class Expr>
--- 89,95 ----
  
  //-----------------------------------------------------------------------------
  // Fields are leaf objects, we just pass them through unless they have
! // Expression engines. Then, we remove the expression from the field and form
  // leaves with tree-nodes. 
  
  template<class GeometryTag, class T, class Expr>
Index: NewField/FieldInitializers.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldInitializers.h,v
retrieving revision 1.3
diff -c -p -r1.3 FieldInitializers.h
*** NewField/FieldInitializers.h	2000/07/24 23:36:22	1.3
--- NewField/FieldInitializers.h	2001/04/03 22:46:45
***************
*** 43,49 ****
  // Overview: 
  // 
  // POOMA supports a hierarchy of multiple centering points per 
! // cell. The centering information, manageed by the FieldEngineBase
  // class, is initialized using a flexible set of functors. Below are some
  // pre-defined functors that set up some common centerings along with some
  // versions for building multi-material and multi-centered fields.
--- 43,49 ----
  // Overview: 
  // 
  // POOMA supports a hierarchy of multiple centering points per 
! // cell. The centering information, managed by the FieldEngineBase
  // class, is initialized using a flexible set of functors. Below are some
  // pre-defined functors that set up some common centerings along with some
  // versions for building multi-material and multi-centered fields.
Index: NewField/FieldReductions.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldReductions.h,v
retrieving revision 1.1
diff -c -p -r1.1 FieldReductions.h
*** NewField/FieldReductions.h	2000/07/24 23:36:22	1.1
--- NewField/FieldReductions.h	2001/04/03 22:46:46
*************** T max(const Field<GeometryTag, T, Engine
*** 115,121 ****
    return ret;
  }
  
! // Report if all of the elments of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool all(const Field<GeometryTag, T, EngineTag> &f)
--- 115,121 ----
    return ret;
  }
  
! // Report if all of the elements of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool all(const Field<GeometryTag, T, EngineTag> &f)
*************** bool all(const Field<GeometryTag, T, Eng
*** 129,135 ****
    return ret;
  }
  
! // Report if some of the elments of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool any(const Field<GeometryTag, T, EngineTag> &f)
--- 129,135 ----
    return ret;
  }
  
! // Report if some of the elements of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool any(const Field<GeometryTag, T, EngineTag> &f)
Index: NewField/DiffOps/Div.UR.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/Div.UR.h,v
retrieving revision 1.3
diff -c -p -r1.3 Div.UR.h
*** NewField/DiffOps/Div.UR.h	2000/07/26 22:27:27	1.3
--- NewField/DiffOps/Div.UR.h	2001/04/03 22:46:46
***************
*** 71,77 ****
  // Div:
  // 
  // Partial specializations of the generic Div (divergence) functor. See Div.h
! // for general comments. These are for UniformRectilinearMesh-based 
  // DiscreteGeometry.
  // 
  // Div is a functor class serving as the "Functor" template parameter for
--- 71,77 ----
  // Div:
  // 
  // Partial specializations of the generic Div (divergence) functor. See Div.h
! // for general comments. These are for UniformRectilinear-based 
  // DiscreteGeometry.
  // 
  // Div is a functor class serving as the "Functor" template parameter for
***************
*** 90,96 ****
  // OutputCentering_t - Centering parameter of the output DiscreteGeometry class
  // InputField_t      - Type of the input Field, which is restricted to 
  //                     something from the
! //                     DiscreteGeometry<Centering, UniformRectilinearMesh<Dim...> >
  //                     geometry and a vector or tensor type..
  // OutputElement_t   - Type of the elements in the output ConstField; 
  //                     restricted to a scalar type (vector input) or vector
--- 90,96 ----
  // OutputCentering_t - Centering parameter of the output DiscreteGeometry class
  // InputField_t      - Type of the input Field, which is restricted to 
  //                     something from the
! //                     DiscreteGeometry<Centering, UniformRectilinear<Dim...> >
  //                     geometry and a vector or tensor type..
  // OutputElement_t   - Type of the elements in the output ConstField; 
  //                     restricted to a scalar type (vector input) or vector
Index: NewField/DiffOps/Div.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/Div.h,v
retrieving revision 1.2
diff -c -p -r1.2 Div.h
*** NewField/DiffOps/Div.h	2000/07/26 22:27:27	1.2
--- NewField/DiffOps/Div.h	2001/04/03 22:46:46
***************
*** 82,88 ****
  // FieldStencil<Functor,Expression>, which implements a discrete 
  // divergence operator.
  // Partial specializations implement various combinations of input and output
! // centerings, for specific coordinate systems, and different finite-differenc
  // orders, are defined in other headers like Div.[URM,RM].h .
  // 
  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
--- 82,88 ----
  // FieldStencil<Functor,Expression>, which implements a discrete 
  // divergence operator.
  // Partial specializations implement various combinations of input and output
! // centerings, for specific coordinate systems, and different finite-difference
  // orders, are defined in other headers like Div.[URM,RM].h .
  // 
  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Index: NewField/DiffOps/FieldStencil.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/FieldStencil.h,v
retrieving revision 1.4
diff -c -p -r1.4 FieldStencil.h
*** NewField/DiffOps/FieldStencil.h	2000/09/20 16:22:17	1.4
--- NewField/DiffOps/FieldStencil.h	2001/04/03 22:46:46
*************** struct FieldStencilSimple
*** 474,480 ****
  //  
  // template<int Dim, class T1, class T2>
  // class Div<Cell,
! //   DiscreteGeometry<Vert, UniformRectilinearMesh<Dim, Cartesian<Dim>, T1> >, 
  //   Vector<Dim, T2> >
  // {
  // public:
--- 474,480 ----
  //  
  // template<int Dim, class T1, class T2>
  // class Div<Cell,
! //   DiscreteGeometry<Vert, UniformRectilinear<Dim, Cartesian<Dim>, T1> >, 
  //   Vector<Dim, T2> >
  // {
  // public:
Index: NewField/Updater/PeriodicFaceBC.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/Updater/PeriodicFaceBC.h,v
retrieving revision 1.2
diff -c -p -r1.2 PeriodicFaceBC.h
*** NewField/Updater/PeriodicFaceBC.h	2000/12/12 15:53:03	1.2
--- NewField/Updater/PeriodicFaceBC.h	2001/04/03 22:46:46
***************
*** 39,45 ****
  // Overview: 
  // 
  // PeriodicFaceBC:  Updater setting all guard layers beyond a
! //                   specified (logically) rectilinear mesh face to a the value
  //                   from the non-guard element symmetrically across the face
  //                   (the face is defined at the last vertex).
  //-----------------------------------------------------------------------------
--- 39,45 ----
  // Overview: 
  // 
  // PeriodicFaceBC:  Updater setting all guard layers beyond a
! //                   specified (logically) rectilinear mesh face to the value
  //                   from the non-guard element symmetrically across the face
  //                   (the face is defined at the last vertex).
  //-----------------------------------------------------------------------------
Index: NewField/Updater/PosReflectFaceBC.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/Updater/PosReflectFaceBC.h,v
retrieving revision 1.3
diff -c -p -r1.3 PosReflectFaceBC.h
*** NewField/Updater/PosReflectFaceBC.h	2001/02/19 21:21:07	1.3
--- NewField/Updater/PosReflectFaceBC.h	2001/04/03 22:46:46
***************
*** 37,43 ****
  // Overview: 
  // PosReflectFaceBC: BCondCategory class setting all guard layers beyond a
  //                 specified (logically) rectilinear mesh face to a positively 
! //                 relected value.
  //-----------------------------------------------------------------------------
  
  //-----------------------------------------------------------------------------
--- 37,43 ----
  // Overview: 
  // PosReflectFaceBC: BCondCategory class setting all guard layers beyond a
  //                 specified (logically) rectilinear mesh face to a positively 
! //                 reflected value.
  //-----------------------------------------------------------------------------
  
  //-----------------------------------------------------------------------------
Index: NewField/tests/VectorTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/tests/VectorTest.cpp,v
retrieving revision 1.1
diff -c -p -r1.1 VectorTest.cpp
*** NewField/tests/VectorTest.cpp	2000/12/13 20:04:14	1.1
--- NewField/tests/VectorTest.cpp	2001/04/03 22:46:47
*************** int main(int argc, char *argv[])
*** 104,110 ****
  
    tester.out() << a << std::endl;
  
!   int ret = tester.results("WhereTest");
    Pooma::finalize();
    return ret;
  }
--- 104,110 ----
  
    tester.out() << a << std::endl;
  
!   int ret = tester.results("VectorTest");
    Pooma::finalize();
    return ret;
  }
Index: Pooma/Pooma.cmpl.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Pooma/Pooma.cmpl.cpp,v
retrieving revision 1.36
diff -c -p -r1.36 Pooma.cmpl.cpp
*** Pooma/Pooma.cmpl.cpp	2000/06/08 22:16:34	1.36
--- Pooma/Pooma.cmpl.cpp	2001/04/03 22:46:47
*************** bool initialize(Options &opts, bool init
*** 365,371 ****
  
  #endif
  
!   // Enable logging too a file, if requested.
  
    logstream_s = 0;
    logMessages(opts.logfile().c_str());
--- 365,371 ----
  
  #endif
  
!   // Enable logging to a file, if requested.
  
    logstream_s = 0;
    logMessages(opts.logfile().c_str());
Index: Utilities/RefCountedBlockPtr.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v
retrieving revision 1.58
diff -c -p -r1.58 RefCountedBlockPtr.h
*** Utilities/RefCountedBlockPtr.h	2001/03/29 17:09:26	1.58
--- Utilities/RefCountedBlockPtr.h	2001/04/03 22:46:48
*************** public: 
*** 164,170 ****
    // RefCountedBlockPtr.
    
    RefBlockController(size_t size, const NoInitTag &)
!     : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0)
    {
      // Allocate memory, and set pointers to beginning and ending.  This
      // also sets the dealloc_m flag to true.
--- 164,170 ----
    // RefCountedBlockPtr.
    
    RefBlockController(size_t size, const NoInitTag &)
!     : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false)
    {
      // Allocate memory, and set pointers to beginning and ending.  This
      // also sets the dealloc_m flag to true.
*************** public:
*** 639,646 ****
    // which adds to compile time.)
  
    inline RefCountedBlockPtr(const This_t & model, Offset_t offset)
!     : blockControllerPtr_m(model.blockControllerPtr_m),
!       offset_m(model.offset_m + offset)
    { }
  
    // Inline destructor for better performance
--- 639,646 ----
    // which adds to compile time.)
  
    inline RefCountedBlockPtr(const This_t & model, Offset_t offset)
!     : offset_m(model.offset_m + offset),
!       blockControllerPtr_m(model.blockControllerPtr_m)
    { }
  
    // Inline destructor for better performance

From oldham at codesourcery.com  Wed Apr 11 18:17:37 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 11 Apr 2001 11:17:37 -0700
Subject: [pooma-dev] Chevron Flow Scenario
In-Reply-To: <200104111510.IAA09985@oz.codesourcery.com>; from scotth@proximation.com on Wed, Apr 11, 2001 at 10:07:32AM -0600
References: <200104111510.IAA09985@oz.codesourcery.com>
Message-ID: <20010411111737.A16977@codesourcery.com>

On Wed, Apr 11, 2001 at 10:07:32AM -0600, Scott Haney wrote:
> 
> I have attached a PDF file summarizing my take on a paper [1] describing 
> a finite-difference approach to a flow simulation that was of interest 
> to Chevron. If people would like copies of the original paper, please 
> supply a FAX number.

Does the refined mesh S on page 2 correspond to the upper left cell in
M on page 1?

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From JimC at proximation.com  Wed Apr 11 19:28:10 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 11 Apr 2001 12:28:10 -0700
Subject: [pooma-dev] Chevron Flow Scenario
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BCD@proxim-sf001.santafe.proximation.com>

I pretty sure that's the case.

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

-----Original Message-----
From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
Sent: Wednesday, April 11, 2001 12:18 PM
To: Scott Haney
Cc: pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] Chevron Flow Scenario

On Wed, Apr 11, 2001 at 10:07:32AM -0600, Scott Haney wrote:
>
> I have attached a PDF file summarizing my take on a paper [1] describing
> a finite-difference approach to a flow simulation that was of interest
> to Chevron. If people would like copies of the original paper, please
> supply a FAX number.

Does the refined mesh S on page 2 correspond to the upper left cell in
M on page 1?

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/0ce9471a/attachment.html>

From JimC at proximation.com  Wed Apr 11 19:32:26 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 11 Apr 2001 12:32:26 -0700
Subject: [pooma-dev] Domain traits
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BCE@proxim-sf001.santafe.proximation.com>

The main motivation here is not to clean up the design of Domains.
It is to avoid unnecessary duplication of static traits data in both Domains
and DomainTraits, given the necessary evil of a DomainTraits class.
I guess that's one of the main things I hate about DomainTraits - why all
the duplication? To me, the right way to have done this would have been for
the default traits template to get all of its traits from the actual class
(not the other way around, as it is now, which creates some very strange
circular and cross dependencies), and then there would only be
specializations for not Pooma/src/Domain classes, things like int. 
Anyway, my 2 cents is to leave the traits in the class. 
	Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/eca54e1d/attachment.html>

From scotth at proximation.com  Wed Apr 11 20:03:47 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 11 Apr 2001 14:03:47 -0600
Subject: [pooma-dev] Chevron Flow Scenario
In-Reply-To: <20010411111737.A16977@codesourcery.com>
Message-ID: <mailman.10.1331172041.20475.pooma-dev@codesourcery.com>

Hi Jeffrey,

Jim is correct. The idea is that one constructs a finer mesh whose 
vertices (in 3D relative to mesh M) are:

  the cell centers
a corner vertex
3 face centers
3 edge centers

You described essentially the same thing in your discussion.

Scott

On Wednesday, April 11, 2001, at 12:17 PM, Jeffrey Oldham wrote:

> On Wed, Apr 11, 2001 at 10:07:32AM -0600, Scott Haney wrote:
>>
>> I have attached a PDF file summarizing my take on a paper [1] 
>> describing
>> a finite-difference approach to a flow simulation that was of interest
>> to Chevron. If people would like copies of the original paper, please
>> supply a FAX number.
>
> Does the refined mesh S on page 2 correspond to the upper left cell in
> M on page 1?
>
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com

--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161


From scotth at proximation.com  Wed Apr 11 20:43:18 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 11 Apr 2001 14:43:18 -0600
Subject: [pooma-dev] Re: RFA: src: Spelling and Initialization Order Changes
In-Reply-To: <20010411105309.A13326@codesourcery.com>
Message-ID: <mailman.11.1331172041.20475.pooma-dev@codesourcery.com>

These look OK.

Scott

On Wednesday, April 11, 2001, at 11:53 AM, Jeffrey Oldham wrote:

> Ok to commit?  Reviewing these changes should not take more than ten
> minutes.  Would you please consider reviewing them?


From cummings at cacr.caltech.edu  Wed Apr 11 21:25:10 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Wed, 11 Apr 2001 14:25:10 -0700
Subject: [pooma-dev] Domain traits
References: <F871BB04B0EA224A821A5274C31DF3152BCE@proxim-sf001.santafe.proximation.com>
Message-ID: <3AD4CBB5.42F9EAF0@cacr.caltech.edu>

James Crotinger wrote:

> I guess that's one of the main things I hate about DomainTraits - why all the
> duplication? To me, the right way to have done this would have been for the
> default traits template to get all of its traits from the actual class (not
> the other way around, as it is now, which creates some very strange circular
> and cross dependencies), and then there would only be specializations for not
> Pooma/src/Domain classes, things like int.

The trouble is that when you "get the traits" from somewhere else,
you are in fact duplicating them.  If you write something like


template <class Dom>

struct DomainTraits {

  static const int dimensions = Dom::dimensions;

  // ...

};

then you are once again duplicating all the traits data.
Given that we cannot easily make DomainTraits go away
without a major redesign, I chose to sweep all the Domain
class traits into one place: DomainTraits.  At least that
way, the duplication issue is solved and there is one standard
way to access the traits.

> Anyway, my 2 cents is to leave the traits in the class.
>         Jim

OK, but can I commit these changes anyway??  ;-)
Seriously, I'd like to finish this and move on to other
stuff.  Unless there are technical reasons why this
would prevent new Pooma code development, break
existing code, cause a painful burning sensation, etc.,
I'd like to check in my changes later today.

Thanks, Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From cummings at cacr.caltech.edu  Wed Apr 11 21:31:02 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Wed, 11 Apr 2001 14:31:02 -0700
Subject: cheetah
Message-ID: <3AD4CD16.F362E66E@cacr.caltech.edu>

Has the cheetah library package been checked in
as a module in the cvs repository at codesourcery?

-- Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From JimC at proximation.com  Wed Apr 11 21:38:41 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 11 Apr 2001 14:38:41 -0700
Subject: [pooma-dev] Domain traits
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BD0@proxim-sf001.santafe.proximation.com>





The trouble is that when you "get the traits" from somewhere else,
you are in fact duplicating them.  If you write something like


template <class Dom>

struct DomainTraits {

  static const int dimensions = Dom::dimensions;

  // ...

};

then you are once again duplicating all the traits data.
Oh pshaw. 8-) 
Here you'd have one template and the data would be defined in each domain.
The template could get the data from the domain if someone tried to use the
traits class. Right now we have specializations of the traits class for
every concrete class (but using forward declarations to "avoid" the circular
reference), and then we have the concrete classes themselves. Doing it the
other way you'd only specialize for "int" so there would be one general
template and (currently) one specilization (for int). Yes, the actual data
gets duplicated if you use the traits class, at least in appearance. It is
not clear to me that any data is duplicated in practice (as in taking up
separate memory). Perhaps it is, but this is pretty unimportant. The
important thing is the complexity of the software and it would be
considerably less complex the other way.
 > Anyway, my 2 cents is to leave the traits in the class.
>         Jim

OK, but can I commit these changes anyway??  ;-)
No. Stephen and I both like to say things like "Domain::dimensions" so leave
it there. I only want to use DomainTraits if I want to program for the
possibility of someone passing me an "int" as a domain.

Seriously, I'd like to finish this and move on to other
stuff.  Unless there are technical reasons why this
would prevent new Pooma code development, break
existing code, cause a painful burning sensation, etc.,
I'd like to check in my changes later today.
Definitely falls into the "painful burning sensation" category. Change the
enums to static consts, but don't remove the traits from the domains.
Granted there may not be that many places in the Pooma source where this
occurs, but it has been part of the user interface, at least two "users"
like it, and indeed other users may have used this idiom and changing it
would break their code (Pooma 2 code exists that is not checked into our
repository, remember, so it also falls into the "breaks existing code"
category.). 
Thanks, Julian C.
You're welcome.
	Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/2e7f730b/attachment.html>

From JimC at proximation.com  Wed Apr 11 21:40:44 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 11 Apr 2001 14:40:44 -0700
Subject: [pooma-dev] Domain traits
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BD1@proxim-sf001.santafe.proximation.com>





What is the mailer doing to my email? It appears to be stripping out
indentation. Must I nuke HTML mail in order for my mail to this list to be
intelligible? 
	Jim

The trouble is that when you "get the traits" from somewhere else,
you are in fact duplicating them.  If you write something like


template <class Dom>

struct DomainTraits {

  static const int dimensions = Dom::dimensions;

  // ...

};

then you are once again duplicating all the traits data.
Oh pshaw. 8-)
        Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/9981de97/attachment.html>

From oldham at codesourcery.com  Wed Apr 11 20:45:23 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 11 Apr 2001 13:45:23 -0700
Subject: Patch: src: Spelling and Initialization Order
Message-ID: <20010411134523.A20871@codesourcery.com>

2001-04-11  Jeffrey D. Oldham  <oldham at codesourcery.com>

	* Domain/DomainIterator.h (DomainIterator::DomainIterator):
	Reorder initializers to reflect class declaration order.
	* Domain/Loc.h: Fix spelling in comment.
	* Engine/ConstantFunctionEngine.h (Engine::Engine):
	Reorder initializers to reflect class declaration order.
	* Engine/IndexFunctionEngine.h (Engine::Engine): Likewise.
	* Evaluator/WhereProxy.h: Fix spelling in comment.
	* Layout/Node.h (Node::Node): Reorder initializers to reflect
	class declaration order.
	* NewField/FieldCreateLeaf.h: Fix spelling in comment.
	* NewField/FieldInitializers.h: Likewise.
	* NewField/FieldReductions.h: Likewise.
	* NewField/DiffOps/Div.UR.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comments.
	* NewField/DiffOps/Div.h: Fix spelling in comment.
	* NewField/DiffOps/FieldStencil.h:
	s/UniformRectilinearMesh/UniformRectilinear/g in comment.
	* NewField/Updater/PeriodicFaceBC.h: Fix typo in comment.
	* NewField/Updater/PosReflectFaceBC.h: Likewise.
	* Pooma/Pooma.cmpl.cpp (initialize): Fix spelling in comment.
	* Utilities/RefCountedBlockPtr.h
	(RefBlockController::RefBlockController): Reorder initializers to
	reflect class declaration order.
	(RefCountedBlockPtr::RefCountedBlockPtr): Likewise.

Tested on	sequential Linux using gcc 3.1
Reviewed by	Scott Haney

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Domain/DomainIterator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/DomainIterator.h,v
retrieving revision 1.7
diff -c -p -r1.7 DomainIterator.h
*** Domain/DomainIterator.h	2000/04/01 00:26:22	1.7
--- Domain/DomainIterator.h	2001/04/11 21:37:06
*************** public:
*** 99,105 ****
    // iterators to the start. This constructor sets up a "begin" iterator.
  
    DomainIterator(const Dom &d, int size = 0)
!     : index_m(size), domain_m(d), loc_m(d.firsts())
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
--- 99,105 ----
    // iterators to the start. This constructor sets up a "begin" iterator.
  
    DomainIterator(const Dom &d, int size = 0)
!     : domain_m(d), loc_m(d.firsts()), index_m(size)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
*************** public:
*** 109,115 ****
    // Copy constructor.
  
    DomainIterator(const This_t &model)
!     : index_m(model.index_m), domain_m(model.domain_m), loc_m(model.loc_m)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
--- 109,115 ----
    // Copy constructor.
  
    DomainIterator(const This_t &model)
!     : domain_m(model.domain_m), loc_m(model.loc_m), index_m(model.index_m)
      {
        PAssert(index_m >= 0 && index_m <= domain_m.size());
        for (int i=0; i < dimensions; ++i)
Index: Domain/Loc.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/Loc.h,v
retrieving revision 1.22
diff -c -p -r1.22 Loc.h
*** Domain/Loc.h	2000/06/27 02:48:17	1.22
--- Domain/Loc.h	2001/04/11 21:37:06
***************
*** 110,116 ****
  //   comparison operators: <, >, !=, ==, <=, >= : compare a Loc<N> to
  //      another domain object.  The compared domains must have the same
  //      number of dimensions.
! //   arithmetic accumulation operators +=, -= : add or substract in a
  //      given domain.  The added domain must have the same number of
  //      dimensions, or a dimension of 1 (in which case, the same value
  //      is used for all dimensions), and be known to be single-valued (which
--- 110,116 ----
  //   comparison operators: <, >, !=, ==, <=, >= : compare a Loc<N> to
  //      another domain object.  The compared domains must have the same
  //      number of dimensions.
! //   arithmetic accumulation operators +=, -= : add or subtract in a
  //      given domain.  The added domain must have the same number of
  //      dimensions, or a dimension of 1 (in which case, the same value
  //      is used for all dimensions), and be known to be single-valued (which
Index: Engine/ConstantFunctionEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/ConstantFunctionEngine.h,v
retrieving revision 1.16
diff -c -p -r1.16 ConstantFunctionEngine.h
*** Engine/ConstantFunctionEngine.h	2000/07/20 15:39:26	1.16
--- Engine/ConstantFunctionEngine.h	2001/04/11 21:37:06
*************** public:
*** 100,106 ****
    // Construct from a domain object.
  
    Engine(const Domain_t &domain, T val = T())
!   : domain_m(domain), val_m(val) 
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain[d].first();
--- 100,106 ----
    // Construct from a domain object.
  
    Engine(const Domain_t &domain, T val = T())
!   : val_m(val), domain_m(domain)
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain[d].first();
Index: Engine/IndexFunctionEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/IndexFunctionEngine.h,v
retrieving revision 1.20
diff -c -p -r1.20 IndexFunctionEngine.h
*** Engine/IndexFunctionEngine.h	2001/03/29 17:09:26	1.20
--- Engine/IndexFunctionEngine.h	2001/04/11 21:37:06
*************** public:
*** 129,135 ****
    }
  
    Engine(const Layout_t &layout, const Functor &f = Functor())
!   : domain_m(layout.domain()), funct_m(f) 
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain_m[d].first();
--- 129,135 ----
    }
  
    Engine(const Layout_t &layout, const Functor &f = Functor())
!   : funct_m(f), domain_m(layout.domain())
    { 
      for (int d = 0; d < Dim; ++d)
        firsts_m[d] = domain_m[d].first();
Index: Evaluator/WhereProxy.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/WhereProxy.h,v
retrieving revision 1.3
diff -c -p -r1.3 WhereProxy.h
*** Evaluator/WhereProxy.h	2000/07/20 15:39:26	1.3
--- Evaluator/WhereProxy.h	2001/04/11 21:37:06
*************** struct ConvertWhereProxy
*** 67,73 ****
  // A = where(f,B);
  //
  // Rather than have where(f,B) return an array that could be combined in
! // an expression, we return a WhereProxy that is recognized by assingment
  // operators.
  //
  // The WhereProxy is also necessary because the elements returned by
--- 67,73 ----
  // A = where(f,B);
  //
  // Rather than have where(f,B) return an array that could be combined in
! // an expression, we return a WhereProxy that is recognized by assignment
  // operators.
  //
  // The WhereProxy is also necessary because the elements returned by
Index: Layout/Node.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v
retrieving revision 1.33
diff -c -p -r1.33 Node.h
*** Layout/Node.h	2001/03/20 23:42:48	1.33
--- Layout/Node.h	2001/04/11 21:37:06
*************** public:
*** 142,148 ****
    Node(int affinity, const Domain_t &owned, const AllocatedDomain_t &allocated, 
         Context_t c, ID_t gid, ID_t lid = (-1))
      : domain_m(owned), allocated_m(allocated), 
!       context_m(c), global_m(gid), local_m(lid),
        affinity_m(affinity)
    {
      PAssert(owned.size() >= 0);
--- 142,148 ----
    Node(int affinity, const Domain_t &owned, const AllocatedDomain_t &allocated, 
         Context_t c, ID_t gid, ID_t lid = (-1))
      : domain_m(owned), allocated_m(allocated), 
!       local_m(lid), global_m(gid), context_m(c),
        affinity_m(affinity)
    {
      PAssert(owned.size() >= 0);
Index: NewField/FieldCreateLeaf.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldCreateLeaf.h,v
retrieving revision 1.4
diff -c -p -r1.4 FieldCreateLeaf.h
*** NewField/FieldCreateLeaf.h	2000/08/08 17:31:33	1.4
--- NewField/FieldCreateLeaf.h	2001/04/11 21:37:08
*************** template<class G, class T, class E> clas
*** 89,95 ****
  
  //-----------------------------------------------------------------------------
  // Fields are leaf objects, we just pass them through unless they have
! // Expression engines. Then, we remove the expresion from the field and form
  // leaves with tree-nodes. 
  
  template<class GeometryTag, class T, class Expr>
--- 89,95 ----
  
  //-----------------------------------------------------------------------------
  // Fields are leaf objects, we just pass them through unless they have
! // Expression engines. Then, we remove the expression from the field and form
  // leaves with tree-nodes. 
  
  template<class GeometryTag, class T, class Expr>
Index: NewField/FieldInitializers.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldInitializers.h,v
retrieving revision 1.3
diff -c -p -r1.3 FieldInitializers.h
*** NewField/FieldInitializers.h	2000/07/24 23:36:22	1.3
--- NewField/FieldInitializers.h	2001/04/11 21:37:08
***************
*** 43,49 ****
  // Overview: 
  // 
  // POOMA supports a hierarchy of multiple centering points per 
! // cell. The centering information, manageed by the FieldEngineBase
  // class, is initialized using a flexible set of functors. Below are some
  // pre-defined functors that set up some common centerings along with some
  // versions for building multi-material and multi-centered fields.
--- 43,49 ----
  // Overview: 
  // 
  // POOMA supports a hierarchy of multiple centering points per 
! // cell. The centering information, managed by the FieldEngineBase
  // class, is initialized using a flexible set of functors. Below are some
  // pre-defined functors that set up some common centerings along with some
  // versions for building multi-material and multi-centered fields.
Index: NewField/FieldReductions.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/FieldReductions.h,v
retrieving revision 1.1
diff -c -p -r1.1 FieldReductions.h
*** NewField/FieldReductions.h	2000/07/24 23:36:22	1.1
--- NewField/FieldReductions.h	2001/04/11 21:37:08
*************** T max(const Field<GeometryTag, T, Engine
*** 115,121 ****
    return ret;
  }
  
! // Report if all of the elments of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool all(const Field<GeometryTag, T, EngineTag> &f)
--- 115,121 ----
    return ret;
  }
  
! // Report if all of the elements of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool all(const Field<GeometryTag, T, EngineTag> &f)
*************** bool all(const Field<GeometryTag, T, Eng
*** 129,135 ****
    return ret;
  }
  
! // Report if some of the elments of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool any(const Field<GeometryTag, T, EngineTag> &f)
--- 129,135 ----
    return ret;
  }
  
! // Report if some of the elements of the Field are true.
  
  template<class GeometryTag, class T, class EngineTag>
  bool any(const Field<GeometryTag, T, EngineTag> &f)
Index: NewField/DiffOps/Div.UR.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/Div.UR.h,v
retrieving revision 1.3
diff -c -p -r1.3 Div.UR.h
*** NewField/DiffOps/Div.UR.h	2000/07/26 22:27:27	1.3
--- NewField/DiffOps/Div.UR.h	2001/04/11 21:37:08
***************
*** 71,77 ****
  // Div:
  // 
  // Partial specializations of the generic Div (divergence) functor. See Div.h
! // for general comments. These are for UniformRectilinearMesh-based 
  // DiscreteGeometry.
  // 
  // Div is a functor class serving as the "Functor" template parameter for
--- 71,77 ----
  // Div:
  // 
  // Partial specializations of the generic Div (divergence) functor. See Div.h
! // for general comments. These are for UniformRectilinear-based 
  // DiscreteGeometry.
  // 
  // Div is a functor class serving as the "Functor" template parameter for
Index: NewField/DiffOps/Div.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/Div.h,v
retrieving revision 1.2
diff -c -p -r1.2 Div.h
*** NewField/DiffOps/Div.h	2000/07/26 22:27:27	1.2
--- NewField/DiffOps/Div.h	2001/04/11 21:37:08
***************
*** 82,88 ****
  // FieldStencil<Functor,Expression>, which implements a discrete 
  // divergence operator.
  // Partial specializations implement various combinations of input and output
! // centerings, for specific coordinate systems, and different finite-differenc
  // orders, are defined in other headers like Div.[URM,RM].h .
  // 
  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
--- 82,88 ----
  // FieldStencil<Functor,Expression>, which implements a discrete 
  // divergence operator.
  // Partial specializations implement various combinations of input and output
! // centerings, for specific coordinate systems, and different finite-difference
  // orders, are defined in other headers like Div.[URM,RM].h .
  // 
  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Index: NewField/DiffOps/FieldStencil.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/DiffOps/FieldStencil.h,v
retrieving revision 1.4
diff -c -p -r1.4 FieldStencil.h
*** NewField/DiffOps/FieldStencil.h	2000/09/20 16:22:17	1.4
--- NewField/DiffOps/FieldStencil.h	2001/04/11 21:37:08
*************** struct FieldStencilSimple
*** 474,480 ****
  //  
  // template<int Dim, class T1, class T2>
  // class Div<Cell,
! //   DiscreteGeometry<Vert, UniformRectilinearMesh<Dim, Cartesian<Dim>, T1> >, 
  //   Vector<Dim, T2> >
  // {
  // public:
--- 474,480 ----
  //  
  // template<int Dim, class T1, class T2>
  // class Div<Cell,
! //   DiscreteGeometry<Vert, UniformRectilinear<Dim, Cartesian<Dim>, T1> >, 
  //   Vector<Dim, T2> >
  // {
  // public:
Index: NewField/Updater/PeriodicFaceBC.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/Updater/PeriodicFaceBC.h,v
retrieving revision 1.2
diff -c -p -r1.2 PeriodicFaceBC.h
*** NewField/Updater/PeriodicFaceBC.h	2000/12/12 15:53:03	1.2
--- NewField/Updater/PeriodicFaceBC.h	2001/04/11 21:37:08
***************
*** 39,45 ****
  // Overview: 
  // 
  // PeriodicFaceBC:  Updater setting all guard layers beyond a
! //                   specified (logically) rectilinear mesh face to a the value
  //                   from the non-guard element symmetrically across the face
  //                   (the face is defined at the last vertex).
  //-----------------------------------------------------------------------------
--- 39,45 ----
  // Overview: 
  // 
  // PeriodicFaceBC:  Updater setting all guard layers beyond a
! //                   specified (logically) rectilinear mesh face to the value
  //                   from the non-guard element symmetrically across the face
  //                   (the face is defined at the last vertex).
  //-----------------------------------------------------------------------------
Index: NewField/Updater/PosReflectFaceBC.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/NewField/Updater/PosReflectFaceBC.h,v
retrieving revision 1.3
diff -c -p -r1.3 PosReflectFaceBC.h
*** NewField/Updater/PosReflectFaceBC.h	2001/02/19 21:21:07	1.3
--- NewField/Updater/PosReflectFaceBC.h	2001/04/11 21:37:08
***************
*** 37,43 ****
  // Overview: 
  // PosReflectFaceBC: BCondCategory class setting all guard layers beyond a
  //                 specified (logically) rectilinear mesh face to a positively 
! //                 relected value.
  //-----------------------------------------------------------------------------
  
  //-----------------------------------------------------------------------------
--- 37,43 ----
  // Overview: 
  // PosReflectFaceBC: BCondCategory class setting all guard layers beyond a
  //                 specified (logically) rectilinear mesh face to a positively 
! //                 reflected value.
  //-----------------------------------------------------------------------------
  
  //-----------------------------------------------------------------------------
Index: Pooma/Pooma.cmpl.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Pooma/Pooma.cmpl.cpp,v
retrieving revision 1.36
diff -c -p -r1.36 Pooma.cmpl.cpp
*** Pooma/Pooma.cmpl.cpp	2000/06/08 22:16:34	1.36
--- Pooma/Pooma.cmpl.cpp	2001/04/11 21:37:09
*************** bool initialize(Options &opts, bool init
*** 365,371 ****
  
  #endif
  
!   // Enable logging too a file, if requested.
  
    logstream_s = 0;
    logMessages(opts.logfile().c_str());
--- 365,371 ----
  
  #endif
  
!   // Enable logging to a file, if requested.
  
    logstream_s = 0;
    logMessages(opts.logfile().c_str());
Index: Utilities/RefCountedBlockPtr.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v
retrieving revision 1.58
diff -c -p -r1.58 RefCountedBlockPtr.h
*** Utilities/RefCountedBlockPtr.h	2001/03/29 17:09:26	1.58
--- Utilities/RefCountedBlockPtr.h	2001/04/11 21:37:09
*************** public: 
*** 164,170 ****
    // RefCountedBlockPtr.
    
    RefBlockController(size_t size, const NoInitTag &)
!     : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0)
    {
      // Allocate memory, and set pointers to beginning and ending.  This
      // also sets the dealloc_m flag to true.
--- 164,170 ----
    // RefCountedBlockPtr.
    
    RefBlockController(size_t size, const NoInitTag &)
!     : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false)
    {
      // Allocate memory, and set pointers to beginning and ending.  This
      // also sets the dealloc_m flag to true.
*************** public:
*** 639,646 ****
    // which adds to compile time.)
  
    inline RefCountedBlockPtr(const This_t & model, Offset_t offset)
!     : blockControllerPtr_m(model.blockControllerPtr_m),
!       offset_m(model.offset_m + offset)
    { }
  
    // Inline destructor for better performance
--- 639,646 ----
    // which adds to compile time.)
  
    inline RefCountedBlockPtr(const This_t & model, Offset_t offset)
!     : offset_m(model.offset_m + offset),
!       blockControllerPtr_m(model.blockControllerPtr_m)
    { }
  
    // Inline destructor for better performance

From scotth at proximation.com  Wed Apr 11 21:59:34 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 11 Apr 2001 15:59:34 -0600
Subject: [pooma-dev] Domain traits
In-Reply-To: <3AD4CBB5.42F9EAF0@cacr.caltech.edu>
Message-ID: <mailman.12.1331172041.20475.pooma-dev@codesourcery.com>


On Wednesday, April 11, 2001, at 03:25 PM, Julian Cummings wrote:

> OK, but can I commit these changes anyway??  ;-)

Hi Julian,

I agree with Jim and Stephen on the basis that (1) it makes code uglier 
and (2) it represents a significant change to the Domain user interface. 
The Proximation crew is solidly against this, so please do not commit 
these changes, except for the enum to static const modification. Let's 
move on.

Scott

--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161


From JimC at proximation.com  Wed Apr 11 22:34:04 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 11 Apr 2001 15:34:04 -0700
Subject: question...
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BD3@proxim-sf001.santafe.proximation.com>

Is it safe to convert a vector<int>::const_iterator to a const int *
via something like 
 
   void foo(const vector<int> &a)
   {
     const int *pBegin = &(a.begin()[0]);
   }
 
In particular, is it allowable for operator[] for a const_iterator to return
by value instead of reference, in which case this would be taking the
address of a temporary. 
 
I'm trying to figure out a way to get the DynamicArray::destroy(begin, end,
...) stuff to work reliably for both vector<int> iterators and for int
pointers. Currently it is explicitly written for int pointers (there is a
virtual function call in the execution path, so I can't rely on templates
here). Since vector iterators are usually typedefs to pointers, the current
code will usually work for vector iterators. But on some systems, or with
some compile options, it might not compile (if the iterators are implemented
as classes). However, I do know that vector guarantees contiguous storage,
so if there is a way to convert the iterator to an address of the
corresponding element in the container, this will work regardless of the way
iterators are implemented.
 
   Jim
 
---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010411/1d6f1f37/attachment.html>

From oldham at codesourcery.com  Wed Apr 11 22:25:34 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 11 Apr 2001 15:25:34 -0700
Subject: [pooma-dev] Chevron Flow Scenario
In-Reply-To: <200104111510.IAA09985@oz.codesourcery.com>; from scotth@proximation.com on Wed, Apr 11, 2001 at 10:07:32AM -0600
References: <200104111510.IAA09985@oz.codesourcery.com>
Message-ID: <20010411152534.A22079@codesourcery.com>

	I enjoyed reading your Chevron code description, which is much
more understandable than the original paper.

	As you noted, the Chevron flow (Lee et al.) algorithm is very
similar to the Carmana et al. hydrodynamics code.  To ease programming
the latter, I have previously proposed adding interpolation and
restriction operators to convert between coarser and finer-grain
fields.  To program the Lee et al. algorithm, the only additional
necessary Pooma tool is these operators although this algorithm points
to the need for these operators to work on face-centered fields.

      The two algorithms are similar:

o Both work on logically rectangular but non-orthogonal meshes.
o Both use fields with two different granularities: n x n x n and 2n x
2n x 2n.

	To implement the algorithm, first we would need to solve for
the pressure gradients \grad(P), which are cell-centered on the
finer-granularity field.  To compute the face-centered fluxes q on the
more refined field, use a C++ statement like

q = dot( dot( replicate<2>(K), \grad(P)), replicate<2>(normals));

replicate<2>(K) copies the cell-centered K values on a coarser grid
to the same cell-centered values on a finer grid.  Thus, the inner
dot product between two cell-centered finer-granularity fields makes
sense.  replicate<2>(normals) copies the face-centered normal values
from a coarser grid to the same values on a finer grid.  Thus, the
outer dot product is between two fields using the same granularity,
albeit with different centerings.

	To implement the computation

\[ Q = \sum_{faces} s_f A_f \sum_{sub-faces} q_{sf}, \]

we could use the C++ statement

Q = adder(A, sum<2>(q));

sum<2>(q) restricts the face-centered values from the
finer-granularity field q to a coarser field by summing the values
along each face.  Note this restriction operator discards the inner
face-centered values.  The user-defined adder field stencil performs
the outer-most sum using the coarser face-centered field A and the
coarser face-centered field sum<2>(q).

	Thus I believe interpolation and restriction operators are the
right abstraction to will support fields with differing granularities.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From cummings at cacr.caltech.edu  Thu Apr 12 00:07:13 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Wed, 11 Apr 2001 17:07:13 -0700
Subject: gcc bug with static members of class templates?
Message-ID: <3AD4F1B1.F8F6F8B5@cacr.caltech.edu>

Hi All,

This is mainly directed at Jeffrey, since I know he has
access to the latest and greatest gcc.  Compiling with
gcc 2.95.2 on an HP in debug mode, I get a compile
error from array_test22.  The loader complains that


TensorEngine<2, double, Antisymmetric>::Zero(data)

is an unsatisfied symbol.  It doesn't pick up on the
assignment of the static data member Zero to 0.0
in Tensor.h.  Is this just a bug in gcc?  I checked that
this test is A-OK with the SGI compiler.

Regards, Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From scotth at proximation.com  Thu Apr 12 00:39:14 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 11 Apr 2001 18:39:14 -0600
Subject: [pooma-dev] Chevron Flow Scenario
In-Reply-To: <20010411152534.A22079@codesourcery.com>
Message-ID: <mailman.13.1331172041.20475.pooma-dev@codesourcery.com>


On Wednesday, April 11, 2001, at 04:25 PM, Jeffrey Oldham wrote:

> q = dot( dot( replicate<2>(K), \grad(P)), replicate<2>(normals));
>

Hi Jeffrey,

In 2D there are 4 values of \grad(P) and K (after replication) per cell. 
The inner dot makes sense.

I don't know fully what it means to replicate an all-face centered field 
like normals, but I'll assume it means to double the number of normals 
in each direction. Then, I don't understand the counting since there are 
8 normals per cell in 2D and 24 in 3D, compared to 4 and 8 cell-centers 
(on the sub-mesh) per cell respectively. This illustrates my primary 
concern with the proposal as currently written. It is centering-free and 
don't think you can get things to work out in general unless you specify 
this information. I also don't think we need to replicate values if we 
are  precise about which one's we're talking about.

Scott


From jcrotinger at mac.com  Thu Apr 12 02:17:31 2001
From: jcrotinger at mac.com (James Crotinger)
Date: Wed, 11 Apr 2001 20:17:31 -0600
Subject: [pooma-dev] Chevron Flow Scenario
In-Reply-To: <20010411152534.A22079@codesourcery.com>
Message-ID: <B6FA6C5B.4AAB%jcrotinger@mac.com>

on 4/11/01 4:25 PM, Jeffrey Oldham at oldham at codesourcery.com wrote:

> I enjoyed reading your Chevron code description, which is much
> more understandable than the original paper.
> 
> As you noted, the Chevron flow (Lee et al.) algorithm is very
> similar to the Carmana et al. hydrodynamics code.  To ease programming
> the latter, I have previously proposed adding interpolation and
> restriction operators to convert between coarser and finer-grain
> fields.  To program the Lee et al. algorithm, the only additional
> necessary Pooma tool is these operators although this algorithm points
> to the need for these operators to work on face-centered fields.

Lee's algorithm also requires a linear solve in the neighborhood of every
vertex, unless further approximation is made. This can be done in parallel
by making iterates on each patch that then go through and run the solver on
each neighborhood in the patch. This sounds pretty slow to me, for a variety
of reasons. Lee's paper discusses lagging the off-diagonal terms to avoid
the solve. Doing this would be much more amenable to parallelization, I
think, but it makes the code fairly ugly.

> To implement the algorithm, first we would need to solve for
> the pressure gradients \grad(P), which are cell-centered on the
> finer-granularity field.  To compute the face-centered fluxes q on the
> more refined field, use a C++ statement like
> 
> q = dot( dot( replicate<2>(K), \grad(P)), replicate<2>(normals));

One problem with this representation is that calculating \grad(P) on the
fine mesh in the manner of their paper requires twice as much storage as
there is information content. The reason is that the neighboring \grad(P)'s
are related. 

I think that what one would want to do is to have the vertex-neighborhood
solve result directly in the evaluation of the q's. I look at this as a
mapping, basically, of the four cell-centered P's in the neighborhood of a
vertex into four q's on the half-face/edge neighborhood of the vertex.
\grad(P) is calculated at the centers of the sub-mesh in the process, but
this is 8 values (two at each sub-cell-center), so there is obviously some
duplicate information.

This is not meant to take anything away from the expressiveness of the
interpolation/restriction stuff. At first glance the syntax looks good. I
think a more general mapping within a neighborhood would be nice to develop
as well (as per above).

  Jim



From jcrotinger at mac.com  Thu Apr 12 02:20:38 2001
From: jcrotinger at mac.com (James Crotinger)
Date: Wed, 11 Apr 2001 20:20:38 -0600
Subject: [pooma-dev] Chevron Flow Scenario
In-Reply-To: <20010411152534.A22079@codesourcery.com>
Message-ID: <B6FA6D16.4AAC%jcrotinger@mac.com>

on 4/11/01 4:25 PM, Jeffrey Oldham at oldham at codesourcery.com wrote:

> I enjoyed reading your Chevron code description, which is much
> more understandable than the original paper.

BTW, I went through their development using more standard coordinate
notation, rather than linearizing things into 1D arrays, and found that even
though the notation was messy, it was much easier to understand what was
going on. I did not TeX this up, though, which is why only Scott has seen
it. I could scan the notes in and send around JPEGs if there is interest.

  Jim



From jcrotinger at mac.com  Thu Apr 12 03:34:19 2001
From: jcrotinger at mac.com (James Crotinger)
Date: Wed, 11 Apr 2001 21:34:19 -0600
Subject: [pooma-dev] Chevron Flow Scenario
In-Reply-To: <B6FA6D16.4AAC%jcrotinger@mac.com>
Message-ID: <B6FA7E5B.4AAF%jcrotinger@mac.com>

on 4/11/01 8:20 PM, James Crotinger at jcrotinger at mac.com wrote:

> I could scan the notes in and send around JPEGs if there is interest.

I went ahead and scanned the first two pages in and put them on my web site.
Those who are interested can get them at

  http://homepage.mac.com/jcrotinger/Lee1.jpe
  http://homepage.mac.com/jcrotinger/Lee2.jpe

These give the derivation in 2D of the 8 equations in 8 unknowns that are
solved in the neighborhood of every vertex on the mesh. I then rambled on
and derived the effective permeability given in the paper for the case of a
diagonal permeability, made a stab at expanding out some equations that
lagged the off diagonal terms (messy and not carefully done - didn't see
much insight coming), and finally applied the same technique in 1D and
compared to the centered difference I'd write down in 1D. (I think it would
be interesting to solve these numerically as I don't understand what really
makes this algorithm special/different. Indeed, this is my major criticism
of the paper - I get no feeling for the algorithm, either qualitatively or
from a more formal numerical analysis perspective. How does it converge?
They show that in simple cases it reduces to using an effective permeability
that is a harmonic average - is that good? Does it deal better with
discontinuities? Why is this algorithm better than some sort of normal
finite difference or other sort of boundary element method?)

    Jim



From oldham at codesourcery.com  Thu Apr 12 15:00:09 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 12 Apr 2001 08:00:09 -0700
Subject: How Write Data Parallel Statement?
Message-ID: <20010412080009.A20893@codesourcery.com>

How do I write a Pooma data-parallel statement for this assignment to
2-D array c?

    #include <cmath>
    #include "Pooma/NewFields.h"

    int main(int argc, char *argv[])
    {
      Pooma::initialize(argc,argv);

      Array<2,Vector<2> > c(5,4);

      // How do I write a data-parallel statement equivalent to?
      for (unsigned i = all values in c's domain's first component)
	for (unsigned j = all values in c's domain's second component)
	  c(i,j) = Vector<2>(i * cos (j), i * sin (j));

      Pooma::finalize();
      return 0;
    }

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From stephens at proximation.com  Thu Apr 12 16:11:10 2001
From: stephens at proximation.com (Stephen Smith)
Date: Thu, 12 Apr 2001 09:11:10 -0700
Subject: [pooma-dev] How Write Data Parallel Statement?
Message-ID: <F871BB04B0EA224A821A5274C31DF3150216B8@proxim-sf001.santafe.proximation.com>

There's a function that provides indices called Iota
that can be used for this:

    #include <cmath>
    #include "Pooma/NewFields.h"

    int main(int argc, char *argv[])
    {
      Pooma::initialize(argc,argv);

      Array<2,Vector<2> > c(5,4);
	Iota<2>::Iota_t ij(c.domain());

	c.comp(0) = ij.comp(0) * cos(ij.comp(1));
	c.comp(1) = ij.comp(0) * sin(ij.comp(1));

      // How do I write a data-parallel statement equivalent to?
      for (unsigned i = all values in c's domain's first component)
	for (unsigned j = all values in c's domain's second component)
	  c(i,j) = Vector<2>(i * cos (j), i * sin (j));

      Pooma::finalize();
      return 0;
    }

Of course this isn't too efficient.  It would be better to just
compute the vector at each location.  We don't have a data-parallel
operation to create a vector from components... (it would be easy to
write though).

You could use the IndexFunction engine to perform an arbitrary
computation on the indices and get the compuation you want in one
step.  You'd need to write the expression
Vector<2>(i * cos (j), i * sin (j));
out-of-line in a functor object.  See the file src/Pooma/Indices.h
to see how to use an index function engine.

    Stephen
-----Original Message-----
From: Jeffrey Oldham [mailto:oldham at codesourcery.com]
Sent: Thursday, April 12, 2001 9:00 AM
To: pooma-dev at pooma.codesourcery.com
Subject: [pooma-dev] How Write Data Parallel Statement?


How do I write a Pooma data-parallel statement for this assignment to
2-D array c?

    #include <cmath>
    #include "Pooma/NewFields.h"

    int main(int argc, char *argv[])
    {
      Pooma::initialize(argc,argv);

      Array<2,Vector<2> > c(5,4);

      // How do I write a data-parallel statement equivalent to?
      for (unsigned i = all values in c's domain's first component)
	for (unsigned j = all values in c's domain's second component)
	  c(i,j) = Vector<2>(i * cos (j), i * sin (j));

      Pooma::finalize();
      return 0;
    }

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010412/ff715fc4/attachment.html>

From cummings at linkline.com  Thu Apr 12 16:19:36 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 12 Apr 2001 09:19:36 -0700
Subject: [pooma-dev] Domain traits
In-Reply-To: <20010411215934.8A11E163542@smtp1.linkline.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGCEJOCBAA.cummings@linkline.com>

Hi Scott,

OK, I will go ahead and replicate the DomainTraits
traits info in the Domain subclasses.  Just be aware
that code written using the traits this way will fail
when the object is not actually a Domain subclass
(e.g., an int).  I would prefer to eliminate such
potential pitfalls now, while the changes are easy
to make and the code base is small.  But I am clearly
in the minority on that point.  I will document the
potential problem here with code comments, in case 
this bites us later.

By the way, I made an attempt to implement Jim's idea
of eliminating DomainTraits specializations for Domain
subclasses and making the general DomainTraits<T> get
all traits from T.  Alas, it doesn't work.  There's
one really important reason for DomainTraits: to define
Storage_t, the type of storage for the Domain's actual
data.  This data lives in DomainBase, a parent class
to Domain.  A Domain subclass cannot provide the type 
for this data member of DomainBase, so it must come from
an external class: hence DomainTraits.  I forgot about
that.  Somewhere, Bill Humphrey is laughing fiendishly...

I'll check stuff in later today.

-- Julian C.


> -----Original Message-----
> From: Scott Haney [mailto:scotth at proximation.com]
> Sent: Wednesday, April 11, 2001 3:00 PM
> To: pooma-dev at pooma.codesourcery.com
> Subject: Re: [pooma-dev] Domain traits
> 
> 
> 
> On Wednesday, April 11, 2001, at 03:25 PM, Julian Cummings wrote:
> 
> > OK, but can I commit these changes anyway??  ;-)
> 
> Hi Julian,
> 
> I agree with Jim and Stephen on the basis that (1) it makes code uglier 
> and (2) it represents a significant change to the Domain user interface. 
> The Proximation crew is solidly against this, so please do not commit 
> these changes, except for the enum to static const modification. Let's 
> move on.
> 
> Scott
> 
> --
> Scott W. Haney
> Development Manager
> Proximation LLC
> 2960 Rodeo Park Drive West
> Santa Fe, NM 87505
> Voice: 505-424-3809 x101
> FAX: 505-438-4161
> 


From JimC at proximation.com  Thu Apr 12 17:48:35 2001
From: JimC at proximation.com (James Crotinger)
Date: Thu, 12 Apr 2001 10:48:35 -0700
Subject: [pooma-dev] Domain traits
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BD9@proxim-sf001.santafe.proximation.com>

By the way, I made an attempt to implement Jim's idea
of eliminating DomainTraits specializations for Domain
subclasses and making the general DomainTraits<T> get
all traits from T.  Alas, it doesn't work. 

It won't work with the current architecture. This is fairly obvious since
the concrete domains depend on DomainTraits in a twisted way:

  template<int Dim>
  class Interval : public Domain<Dim, DomainTraits<Interval<Dim> > >

Trying to make DomainTraits get anything from the ultimate Domain would
clearly create a real circular dependency. The problem, however, is with the
current architecture, not with the idea. 8-)

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010412/cace0fbe/attachment.html>

From mark at codesourcery.com  Thu Apr 12 18:41:50 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 12 Apr 2001 11:41:50 -0700
Subject: [pooma-dev] Domain traits
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BD1@proxim-sf001.santafe.proximation.com>
References: <F871BB04B0EA224A821A5274C31DF3152BD1@proxim-sf001.santafe.proximation.com>
Message-ID: <20010412114150G.mitchell@codesourcery.com>

>>>>> "James" == James Crotinger <JimC at proximation.com> writes:

    James> What is the mailer doing to my email? It appears to be
    James> stripping out indentation. Must I nuke HTML mail in order
    James> for my mail to this list to be intelligible? 

I dunno.

Your messages are coming through in both formats, but I'm not sure
what conversions are being done where.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From mark at codesourcery.com  Thu Apr 12 18:42:59 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Thu, 12 Apr 2001 11:42:59 -0700
Subject: cheetah
In-Reply-To: <3AD4CD16.F362E66E@cacr.caltech.edu>
References: <3AD4CD16.F362E66E@cacr.caltech.edu>
Message-ID: <20010412114259D.mitchell@codesourcery.com>

>>>>> "Julian" == Julian Cummings <cummings at cacr.caltech.edu> writes:

    Julian> Has the cheetah library package been checked in as a
    Julian> module in the cvs repository at codesourcery?

No.  Nor do I know what that even *is* or where to get it from at
LANL.

Rather than me asking LANL for each of these repositories piecemeal,
we should probably figure out what the complete list is up front.
Also, are we really the right people to maintain the master repository
for all of these units?

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From JimC at proximation.com  Thu Apr 12 19:05:23 2001
From: JimC at proximation.com (James Crotinger)
Date: Thu, 12 Apr 2001 12:05:23 -0700
Subject: [pooma-dev] Re: cheetah
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BDA@proxim-sf001.santafe.proximation.com>


    Julian> Has the cheetah library package been checked in as a
    Julian> module in the cvs repository at codesourcery?

Actually, LANL is allegedly still developing Cheetah, so it isn't clear that
we want to just swipe the CVS repository. Is Craig in charge of this? It
would make sense to move the repository outside if they don't have a problem
with it. On the other hand, they may not want their CVS repository to be at
pooma.codesourcery.com. 
	Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010412/98edce00/attachment.html>

From JimC at proximation.com  Thu Apr 12 19:13:21 2001
From: JimC at proximation.com (James Crotinger)
Date: Thu, 12 Apr 2001 12:13:21 -0700
Subject: cygwin builds..
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BDC@proxim-sf001.santafe.proximation.com>

Has anyone made progress on building under Cygwin? I built the library
(after manually creating the lib/LINUXEGCS directory - it didn't get created
by the script and then failed because the directory didn't exist). But
trying to build an application results in the "cp: test and test_APP are the
same file" error, which causes the build to abort. (It does build one file,
but the make fails so I'd have to build one test at a time). 
 
Why does this copy even exist - I've always wondered what it was for. 
 
            Jim
 
---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010412/8ce9ef30/attachment.html>

From stephens at proximation.com  Thu Apr 12 19:29:41 2001
From: stephens at proximation.com (Stephen Smith)
Date: Thu, 12 Apr 2001 12:29:41 -0700
Subject: [pooma-dev] Re: cheetah
Message-ID: <F871BB04B0EA224A821A5274C31DF3150216BA@proxim-sf001.santafe.proximation.com>

I downloaded the version I'm using from the Pooma web-page at LANL:
www.acl.lanl.gov/pooma/download.html
<http://www.acl.lanl.gov/pooma/download.html> 
There were a couple of minor patches necessary to get it to work with
shared-memory on Linux.  We should definitely contact them to find
out what the current status of the project is as far as support goes.
 
Pooma, Smarts and Cheetah are the only packages we should need
for the contract work.  Other packages that might get used with
Pooma codes, like ULM and the viz framework are definitely under
active development at the lab.
 
    Stephen

-----Original Message-----
From: James Crotinger [mailto:JimC at proximation.com]
Sent: Thursday, April 12, 2001 1:05 PM
To: 'Mark Mitchell'; cummings at cacr.caltech.edu
Cc: pooma-dev at pooma.codesourcery.com
Subject: RE: [pooma-dev] Re: cheetah




    Julian> Has the cheetah library package been checked in as a 
    Julian> module in the cvs repository at codesourcery? 

Actually, LANL is allegedly still developing Cheetah, so it isn't clear that
we want to just swipe the CVS repository. Is Craig in charge of this? It
would make sense to move the repository outside if they don't have a problem
with it. On the other hand, they may not want their CVS repository to be at
pooma.codesourcery.com. 

        Jim 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010412/8e8a1da4/attachment.html>

From oldham at codesourcery.com  Thu Apr 12 19:03:30 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 12 Apr 2001 12:03:30 -0700
Subject: [pooma-dev] gcc bug with static members of class templates?
In-Reply-To: <3AD4F1B1.F8F6F8B5@cacr.caltech.edu>; from cummings@cacr.caltech.edu on Wed, Apr 11, 2001 at 05:07:13PM -0700
References: <3AD4F1B1.F8F6F8B5@cacr.caltech.edu>
Message-ID: <20010412120330.A32372@codesourcery.com>

On Wed, Apr 11, 2001 at 05:07:13PM -0700, Julian Cummings wrote:
> Hi All,
> 
> This is mainly directed at Jeffrey, since I know he has
> access to the latest and greatest gcc.  Compiling with
> gcc 2.95.2 on an HP in debug mode, I get a compile
> error from array_test22.  The loader complains that
> 
> 
> TensorEngine<2, double, Antisymmetric>::Zero(data)
> 
> is an unsatisfied symbol.  It doesn't pick up on the
> assignment of the static data member Zero to 0.0
> in Tensor.h.  Is this just a bug in gcc?  I checked that
> this test is A-OK with the SGI compiler.

array_test22 compiled without complaint using gcc 2.95.3, 3.0, and 3.1
(aka development version).  I recommend using gcc 3.0, which
represents a large step forward toward satisfying the C++ standard.
It is not yet officially released, but I can email you a copy.
Officially released is gcc 2.95.3, available at
ftp://ftp.gnu.org/pub/gnu/gcc/gcc-2.95.3.tar.gz.

I recommend you upgrade to at least 2.95.3.

If you need help obtaining, compiling, or installing gcc, please feel
free to contact me.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Thu Apr 12 20:16:33 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 12 Apr 2001 13:16:33 -0700
Subject: [pooma-dev] gcc bug with static members of class templates?
In-Reply-To: <3AD4F1B1.F8F6F8B5@cacr.caltech.edu>; from cummings@cacr.caltech.edu on Wed, Apr 11, 2001 at 05:07:13PM -0700
References: <3AD4F1B1.F8F6F8B5@cacr.caltech.edu>
Message-ID: <20010412131633.A1917@codesourcery.com>

On Wed, Apr 11, 2001 at 05:07:13PM -0700, Julian Cummings wrote:
> 
> gcc 2.95.2 on an HP in debug mode, I get a compile

When I tested the three gcc's, I used the following patch, which is
necessary to avoid gcc warnings.

To apply, go to the src/ directory and type "patch <
insert-patch-name-here".  When it complains that the files cannot be
found, just retype the files' names.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
Index: Partition/UniformMapper.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Partition/UniformMapper.h,v
retrieving revision 1.3
diff -c -p -r1.3 UniformMapper.h
*** Partition/UniformMapper.h	2000/06/07 23:36:46	1.3
--- Partition/UniformMapper.h	2001/04/12 20:12:47
*************** public:
*** 84,89 ****
--- 84,91 ----
    {
    }
  
+   virtual ~UniformMapper(){}
+ 
    void map(const List_t&) const;
  
    // member data
Index: Utilities/Observer.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Utilities/Observer.h,v
retrieving revision 1.11
diff -c -p -r1.11 Observer.h
*** Utilities/Observer.h	2001/03/29 19:06:45	1.11
--- Utilities/Observer.h	2001/04/12 20:12:48
*************** public:
*** 126,135 ****
    // Destructors
    //============================================================
  
!   // The destructor is not made virtual, since we should not ever need
!   // to delete an object via its Observer base class.
! 
!   ~Observer()
      {
      }
  
--- 126,132 ----
    // Destructors
    //============================================================
  
!   virtual ~Observer()
      {
      }
  

From oldham at codesourcery.com  Thu Apr 12 20:23:51 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 12 Apr 2001 13:23:51 -0700
Subject: [pooma-dev] How Write Data Parallel Statement?
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3150216B8@proxim-sf001.santafe.proximation.com>; from stephens@proximation.com on Thu, Apr 12, 2001 at 09:11:10AM -0700
References: <F871BB04B0EA224A821A5274C31DF3150216B8@proxim-sf001.santafe.proximation.com>
Message-ID: <20010412132351.C32372@codesourcery.com>

On Thu, Apr 12, 2001 at 09:11:10AM -0700, Stephen Smith wrote:
> There's a function that provides indices called Iota
> that can be used for this:
> 
>     #include <cmath>
>     #include "Pooma/NewFields.h"
> 
>     int main(int argc, char *argv[])
>     {
>       Pooma::initialize(argc,argv);
> 
>       Array<2,Vector<2> > c(5,4);
> 	Iota<2>::Iota_t ij(c.domain());
> 
> 	c.comp(0) = ij.comp(0) * cos(ij.comp(1));
> 	c.comp(1) = ij.comp(0) * sin(ij.comp(1));
> 
>       // How do I write a data-parallel statement equivalent to?
>       for (unsigned i = all values in c's domain's first component)
> 	for (unsigned j = all values in c's domain's second component)
> 	  c(i,j) = Vector<2>(i * cos (j), i * sin (j));
> 
>       Pooma::finalize();
>       return 0;
>     }

Compiling the attached program, basically the same as you suggested,
using gcc 3.1 causes numerous compilation errors.  Do you also see
these errors?  I will now look into their sources.

> You could use the IndexFunction engine to perform an arbitrary
> computation on the indices and get the compuation you want in one
> step.  You'd need to write the expression
> Vector<2>(i * cos (j), i * sin (j));
> out-of-line in a functor object.  See the file src/Pooma/Indices.h
> to see how to use an index function engine.

I am looking into Engine/IndexFunctionEngine.h because an index
function engine looks promising.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
#include <cmath>
#include "Pooma/NewFields.h"

int main(int argc, char *argv[])
{
  Pooma::initialize(argc,argv);

  Array<2,Vector<2> > c(5,4);

  // How do I write a data-parallel statement equivalent to?
  //  for (unsigned i = all values in c's domain's first component)
  //    for (unsigned j = all values in c's domain's second component)
  //      c(i,j) = Vector<2>(i * cos (j), i * sin (j));

  Iota<2>::Iota_t ij(c.domain());
  c.comp(0) = ij.comp(0) * cos(ij.comp(1));
  c.comp(1) = ij.comp(0) * sin(ij.comp(1));
  std::cout << c << std::endl;

  Pooma::finalize();
  return 0;
}
-------------- next part --------------
cd /nfs/oz/home/oldham/pooma/kernel/
make -j 2 goo
/nfs/oz/home/oldham/gcc-install/gcc3/bin/g++ -DUSE_LIBGXX_INLINES -g -Wall -Wno-sign-compare -DDEBUG -DCORNER_FIELD_TEMPORARY -I/nfs/oz/home/oldham/pooma/pooma0/src/ -I/nfs/oz/home/oldham/pooma/pooma0/lib/LINUXgcc/ -L.	 goo.cc -lpooma-gcc -o goo
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/OperatorTags.h: In member function 
   `typename UnaryReturn<T, FnCos>::Type_t FnCos::operator()(const T&) const 
   [with T = int]':
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/Combiners.h:227:   instantiated from `static typename UnaryReturn<T, Op>::Type_t Combine1<A, Op, OpCombine>::combine(A, OpCombine) [with A = int, Op = FnCos]'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/ForEach.h:101:   instantiated from `static typename Combine1<typename ForEach<A, FTag, CTag>::Type_t, Op, CTag>::Type_t ForEach<UnaryNode<Op, A>, FTag, CTag>::apply(const UnaryNode<Op, A>&, const FTag&, const CTag&) [with Op = FnCos, A = Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, FTag = EvalLeaf<2>, CTag = OpCombine]'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/ForEach.h:116:   instantiated from `static typename Combine2<typename ForEach<A, FTag, CTag>::Type_t, typename ForEach<B, FTag, CTag>::Type_t, Op, CTag>::Type_t ForEach<BinaryNode<Op, A, B>, FTag, CTag>::apply(const BinaryNode<Op, A, B>&, const FTag&, const CTag&) [with Op = OpMultiply, A = Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, B = UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > >, FTag = EvalLeaf<2>, CTag = OpCombine]'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/ForEach.h:89:   instantiated from `typename ForEach<Expr, FTag, CTag>::Type_t forEach(const Expr&, const FTag&, const CTag&) [with Expr = BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > >, FTag = EvalLeaf<2>, CTag = OpCombine]'
/nfs/oz/home/oldham/pooma/pooma0/src/Engine/ExpressionEngine.h:553:   instantiated from `T Engine<Dim, T, ExpressionTag<expr> >::read(int, int) const [with int Dim = 2, T = int, Expr = BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:827:   instantiated from `static typename Array<D1, T1, E1>::Element_t View2<Array<D1, T1, E1>, int, int>::makeRead(const Array<D1, T1, E1>&, int, int) [with int Dim = 2, T = int, EngineTag = ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:1812:   instantiated from `typename View2<Array<Dim, T, EngineTag>, Sub1, Sub2>::ReadType_t Array<Dim, T, EngineTag>::read(const Sub1&, const Sub2&) const [with Sub1 = int, Sub2 = int, int Dim = 2, T = int, EngineTag = ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/InlineEvaluator.h:176:   instantiated from `static void KernelEvaluator<InlineKernelTag>::evaluate(const LHS&, const Op&, const RHS&, const Domain&, WrappedInt<2>) [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, BrickView>, Loc<1> > >, Op = OpAssign, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > > >, Domain = Interval<2>]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/InlineEvaluator.h:101:   instantiated from `static void KernelEvaluator<InlineKernelTag>::evaluate(const LHS&, const Op&, const RHS&) [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, BrickView>, Loc<1> > >, Op = OpAssign, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/Evaluator.h:167:   instantiated from `void Evaluator<SinglePatchEvaluatorTag>::evaluate(const LHS&, const Op&, const RHS&) const [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, BrickView>, Loc<1> > >, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnCos, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > > >, Op = OpAssign]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/Evaluator.h:108:   instantiated from `void Evaluator<MainEvaluatorTag>::evaluate(const LHS&, const Op&, const RHS&) const [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, Brick>, Loc<1> > >, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > >, UnaryNode<FnCos, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > > > > > >, Op = OpAssign]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:2435:   instantiated from `const Array<D1, T1, E1>& assign(const Array<D1, T1, E1>&, const Array<D2, T2, E2>&, const Op&) [with int Dim = 2, T = double, EngineTag = CompFwd<Engine<2, Vector<2, double, Full>, Brick>, Loc<1> >, int OtherDim = 2, OtherT = int, OtherEngineTag = ExpressionTag<BinaryNode<OpMultiply, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > >, UnaryNode<FnCos, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > > > > >, Op = OpAssign]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:2067:   instantiated from `const Array<Dim, T, EngineTag>& Array<Dim, T, EngineTag>::operator=(const T1&) const [with T1 = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > >, UnaryNode<FnCos, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > > > > > >, int Dim = 2, T = double, EngineTag = CompFwd<Engine<2, Vector<2, double, Full>, Brick>, Loc<1> >]'
goo.cc:16:   instantiated from here
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/OperatorTags.h:96: warning: return to 
   `int' from `double'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/OperatorTags.h:96: warning: argument 
   to `int' from `double'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/OperatorTags.h: In member function 
   `typename UnaryReturn<T, FnSin>::Type_t FnSin::operator()(const T&) const 
   [with T = int]':
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/Combiners.h:227:   instantiated from `static typename UnaryReturn<T, Op>::Type_t Combine1<A, Op, OpCombine>::combine(A, OpCombine) [with A = int, Op = FnSin]'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/ForEach.h:101:   instantiated from `static typename Combine1<typename ForEach<A, FTag, CTag>::Type_t, Op, CTag>::Type_t ForEach<UnaryNode<Op, A>, FTag, CTag>::apply(const UnaryNode<Op, A>&, const FTag&, const CTag&) [with Op = FnSin, A = Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, FTag = EvalLeaf<2>, CTag = OpCombine]'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/ForEach.h:116:   instantiated from `static typename Combine2<typename ForEach<A, FTag, CTag>::Type_t, typename ForEach<B, FTag, CTag>::Type_t, Op, CTag>::Type_t ForEach<BinaryNode<Op, A, B>, FTag, CTag>::apply(const BinaryNode<Op, A, B>&, const FTag&, const CTag&) [with Op = OpMultiply, A = Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, B = UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > >, FTag = EvalLeaf<2>, CTag = OpCombine]'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/ForEach.h:89:   instantiated from `typename ForEach<Expr, FTag, CTag>::Type_t forEach(const Expr&, const FTag&, const CTag&) [with Expr = BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > >, FTag = EvalLeaf<2>, CTag = OpCombine]'
/nfs/oz/home/oldham/pooma/pooma0/src/Engine/ExpressionEngine.h:553:   instantiated from `T Engine<Dim, T, ExpressionTag<expr> >::read(int, int) const [with int Dim = 2, T = int, Expr = BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:827:   instantiated from `static typename Array<D1, T1, E1>::Element_t View2<Array<D1, T1, E1>, int, int>::makeRead(const Array<D1, T1, E1>&, int, int) [with int Dim = 2, T = int, EngineTag = ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:1812:   instantiated from `typename View2<Array<Dim, T, EngineTag>, Sub1, Sub2>::ReadType_t Array<Dim, T, EngineTag>::read(const Sub1&, const Sub2&) const [with Sub1 = int, Sub2 = int, int Dim = 2, T = int, EngineTag = ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/InlineEvaluator.h:176:   instantiated from `static void KernelEvaluator<InlineKernelTag>::evaluate(const LHS&, const Op&, const RHS&, const Domain&, WrappedInt<2>) [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, BrickView>, Loc<1> > >, Op = OpAssign, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > > >, Domain = Interval<2>]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/InlineEvaluator.h:101:   instantiated from `static void KernelEvaluator<InlineKernelTag>::evaluate(const LHS&, const Op&, const RHS&) [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, BrickView>, Loc<1> > >, Op = OpAssign, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > > >]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/Evaluator.h:167:   instantiated from `void Evaluator<SinglePatchEvaluatorTag>::evaluate(const LHS&, const Op&, const RHS&) const [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, BrickView>, Loc<1> > >, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > >, UnaryNode<FnSin, Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, ViewEngine<2, IndexFunction<IotaFunctor> > >, Loc<1> > > > > > >, Op = OpAssign]'
/nfs/oz/home/oldham/pooma/pooma0/src/Evaluator/Evaluator.h:108:   instantiated from `void Evaluator<MainEvaluatorTag>::evaluate(const LHS&, const Op&, const RHS&) const [with LHS = Array<2, double, CompFwd<Engine<2, Vector<2, double, Full>, Brick>, Loc<1> > >, RHS = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > >, UnaryNode<FnSin, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > > > > > >, Op = OpAssign]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:2435:   instantiated from `const Array<D1, T1, E1>& assign(const Array<D1, T1, E1>&, const Array<D2, T2, E2>&, const Op&) [with int Dim = 2, T = double, EngineTag = CompFwd<Engine<2, Vector<2, double, Full>, Brick>, Loc<1> >, int OtherDim = 2, OtherT = int, OtherEngineTag = ExpressionTag<BinaryNode<OpMultiply, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > >, UnaryNode<FnSin, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > > > > >, Op = OpAssign]'
/nfs/oz/home/oldham/pooma/pooma0/src/Array/Array.h:2067:   instantiated from `const Array<Dim, T, EngineTag>& Array<Dim, T, EngineTag>::operator=(const T1&) const [with T1 = Array<2, int, ExpressionTag<BinaryNode<OpMultiply, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > >, UnaryNode<FnSin, Reference<Array<2, int, CompFwd<Engine<2, Vector<2, int, Full>, IndexFunction<IotaFunctor> >, Loc<1> > > > > > > >, int Dim = 2, T = double, EngineTag = CompFwd<Engine<2, Vector<2, double, Full>, Brick>, Loc<1> >]'
goo.cc:17:   instantiated from here
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/OperatorTags.h:173: warning: return 
   to `int' from `double'
/nfs/oz/home/oldham/pooma/pooma0/src/PETE/OperatorTags.h:173: warning: argument 
   to `int' from `double'

Compilation finished at Thu Apr 12 13:18:47

From oldham at codesourcery.com  Thu Apr 12 20:34:04 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 12 Apr 2001 13:34:04 -0700
Subject: [pooma-dev] How Write Data Parallel Statement?
In-Reply-To: <20010412132351.C32372@codesourcery.com>; from oldham@codesourcery.com on Thu, Apr 12, 2001 at 01:23:51PM -0700
References: <F871BB04B0EA224A821A5274C31DF3150216B8@proxim-sf001.santafe.proximation.com> <20010412132351.C32372@codesourcery.com>
Message-ID: <20010412133404.A1978@codesourcery.com>

On Thu, Apr 12, 2001 at 01:23:51PM -0700, Jeffrey Oldham wrote:
> On Thu, Apr 12, 2001 at 09:11:10AM -0700, Stephen Smith wrote:
> > There's a function that provides indices called Iota
> > that can be used for this:
> > 
> >     #include <cmath>
> >     #include "Pooma/NewFields.h"
> > 
> >     int main(int argc, char *argv[])
> >     {
> >       Pooma::initialize(argc,argv);
> > 
> >       Array<2,Vector<2> > c(5,4);
> > 	Iota<2>::Iota_t ij(c.domain());
> > 
> > 	c.comp(0) = ij.comp(0) * cos(ij.comp(1));
> > 	c.comp(1) = ij.comp(0) * sin(ij.comp(1));
> > 
> >       // How do I write a data-parallel statement equivalent to?
> >       for (unsigned i = all values in c's domain's first component)
> > 	for (unsigned j = all values in c's domain's second component)
> > 	  c(i,j) = Vector<2>(i * cos (j), i * sin (j));
> > 
> >       Pooma::finalize();
> >       return 0;
> >     }
> 
> Compiling the attached program, basically the same as you suggested,
> using gcc 3.1 causes numerous compilation errors.  Do you also see
> these errors?  I will now look into their sources.

The problem was that I was passing an `int' argument to cos() so it
was returning an `int' and then bitterly complaining.

Oops,
Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Thu Apr 12 23:10:56 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Thu, 12 Apr 2001 16:10:56 -0700
Subject: Hydrodynamics Kernel (12Apr Version)
Message-ID: <20010412161056.A2659@codesourcery.com>

Yesterday, I delivered a hydrodynamics kernel for testing the Field
class and to use for timings.  Today, I replaced the two sequential
computations with parallel versions:

1) changing the initialization of the coordinates Fields
2) changing the computation of corner forces.

There are now no significant sequential computations in the code.
(There are a few; just count the number of semicolons. :)

Attached is

1) the main hydrodynamics kernel file (also included in the archive)
2) a uuencoded gzipped tar archive with all the source files
3) a patch with the differences between yesterday and today's source code

To compile the program,
a. uudecode foo.uu              # produces hydrodynamics.tgz
b. tar xzvf hydrodynamics.tgz   # extracts the five files
c. In Makefile, modify the compiler definitions as necessary.
d. make                         # produces hydrodynamics

Please send suggestions, comments, and questions.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
// Oldham, Jeffrey D.
// 2001Mar27
// Pooma

// Hydrodynamics Kernel Written Using POOMA

#include <iostream>
#include <stdlib.h>
#include <cmath>
#include "Pooma/NewFields.h"
#include "ComputeVolumes.h"
#include "Product.h"
#include "ConstantVectorComponentBC.h"

// This hydrodynamics program implements "The Construction of
// Compatible Hydrodynamics Algorithms Utilizing Conservation of Total
// Energy," by E.J. Caramana, D.E. Burton, M.J. Shashkov, and
// P.P. Whalen, \emph{Journal of Computational Physics}, vol. 146
// (1998), pp. 227-262.

// The code uses fields with two different granularities: coarse and
// fine.  Both grid conceptually cover the same domain, but the
// fine-grain one has twice the number of values for each dimension.
// Currently, Pooma does not nicely support operations between fields
// with different granularities.  The code occurring between
// `CORNER_FIELD_TEMPORARY' preprocessor values substitutes for this
// lack of support.  See the separately distributed proposal for
// details.

// Preprocessor symbols:
// CORNER_FIELD_TEMPORARY: Define this symbol.  Include code to deal
// 			   with different granularity fields.
// PSEUDOCODE: Do not define this symbol.  Surrounds desired code to
//	       deal with different granularity fields.
// DEBUG: If defined, print some information about internal program
//	  values.
// DEBUG2: If defined, print much more information about internal
//	   program values.

// Sample compilation command:
// g++ -g -DCORNER_FIELD_TEMPORARY -I/nfs/oz/home/oldham/pooma/r2/src/ -I/nfs/oz/home/oldham/pooma/r2/lib/LINUXgcc/ -L. hydrodynamics.cc -lpooma-gcc -o hydrodynamics

#ifdef CORNER_FIELD_TEMPORARY

/** FORWARD DECLARATIONS **/

template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundCell (const Field<InputGeometry, T, EngineTag> & input,
	       Field<OutputGeometry, T, EngineTag> & output);

template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundVertex(const Field<InputGeometry, T, EngineTag> & input,
		Field<OutputGeometry, T, EngineTag> & output);

template<class InputGeometry1,
         class InputT1, class InputT2,
         class InputEngineTag1, class InputEngineTag2,
         class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerMasses(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressureDensity,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & fineCoordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output);

template <class InputGeometry1,
          class InputT1, class InputT2,
          class InputEngineTag1, class InputEngineTag2,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerForces(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressure,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & coordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output);

template <class InputGeometry1,
          class InputT1,
          class InputEngineTag1,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
copyVelocities(const Field<InputGeometry1, InputT1, InputEngineTag1> & input1,
	       const Field<InputGeometry1, InputT1, InputEngineTag1> & input2,
	       Field<OutputGeometry, OutputT, OutputEngineTag> & output);
#endif // CORNER_FIELD_TEMPORARY



/** THE HYDRODYNAMICS PROGRAM **/

int main(int argc, char *argv[])
{
  // Set up the Pooma library.
  Pooma::initialize(argc,argv);
#ifdef DEBUG
  std::cout << "Hello, world." << std::endl;
#endif // DEBUG

  /* DECLARATIONS */

  // Values
  const double gamma = 4.0/3;		// gas pressure constant $\gamma$
  const double timeStep = 0.01;		// $\Delta t$
  unsigned nuIterations = 1;		// number of iterations

  // Create a simple layout.
  const unsigned Dim = 2;		// Work in a 2D world.
  const unsigned nHorizVerts = 11;	// number of horizontal vertices
  const unsigned nAngles = 5;		// number of angles
  Interval<Dim> vertexDomain;
  vertexDomain[0] = Interval<1>(nHorizVerts);
  vertexDomain[1] = Interval<1>(nAngles);
  DomainLayout<Dim> layout(vertexDomain, GuardLayers<2>(1));

  // Preparation for Field creation.
  Vector<Dim> origin(0.0);
  Vector<Dim> spacings(1.0,1.0);  // TODO: What does this do?
  typedef UniformRectilinear<Dim, double, Cartesian<Dim> > Geometry_t;
  typedef Field<Geometry_t, double,      Brick> Fields_t;
  typedef Field<Geometry_t, double,      Brick> ConstFields_t; // TODO: Change to ConstField when ConstField is available.
  typedef Field<Geometry_t, Vector<Dim>, Brick> Fieldv_t;
  typedef Field<Geometry_t, Vector<Dim>, Brick> ConstFieldv_t; // TODO: Change to ConstField when ConstField is available.

  // Cell-centered Fields.
  Cell cell;
  Fields_t internalEnergy  (cell, layout, origin, spacings);
  ConstFields_t zoneMass   (cell, layout, origin, spacings);
  Fields_t pressure	   (cell, layout, origin, spacings);
  Fields_t pressureDensity (cell, layout, origin, spacings);
  Fields_t volume	   (cell, layout, origin, spacings);

  // Vertex-centered Fields.
  Vert vert;
  ConstFields_t pointMass  (vert, layout, origin, spacings);
  Fieldv_t coordinates	   (vert, layout, origin, spacings);
  Fieldv_t velocity	   (vert, layout, origin, spacings);
  Fieldv_t velocityChange  (vert, layout, origin, spacings);

  // Corner Fields.
  // TODO: How should I implement corner Fields?
#ifdef CORNER_FIELD_TEMPORARY
  // For now, implement corner Fields using a Field with twice as many
  // entries in each dimension.
  Interval<Dim> cornerVertexDomain;
  for (unsigned d = 0; d < Dim; ++d)
    cornerVertexDomain[d] = Interval<1>(2*vertexDomain[d].min(),2*vertexDomain[d].max());
  DomainLayout<Dim> cornerLayout(cornerVertexDomain, GuardLayers<2>(1));
  Fieldv_t cornerForces	   (cell, cornerLayout, origin, spacings);
  Fields_t cornerMasses    (cell, cornerLayout, origin, spacings);
  Fieldv_t cornerCoordinates(vert, cornerLayout, origin, spacings);
  Fieldv_t cornerVelocities(vert, cornerLayout, origin, spacings);
  Fields_t tmp1		   (cell, cornerLayout, origin, spacings);
  Fields_t tmp2		   (cell, cornerLayout, origin, spacings);
#endif // CORNER_FIELD_TEMPORARY

  /* INITIALIZATION */

  Iota<Dim>::Iota_t range(coordinates.domain());
  #define X (range.comp(0))
  #define Y (range.comp(1))
  coordinates.comp(0) = 1.0*X/(nHorizVerts-1) * cos(Y*M_PI/(2*(nAngles-1)));
  coordinates.comp(1) = 1.0*X/(nHorizVerts-1) * sin(Y*M_PI/(2*(nAngles-1)));
  Iota<Dim>::Iota_t crange(cornerCoordinates.domain());
  #define X (crange.comp(0))
  #define Y (crange.comp(1))
  cornerCoordinates.comp(0) =
    0.5*X/(nHorizVerts-1) * cos(0.5*Y*M_PI/(2*(nAngles-1)));
  cornerCoordinates.comp(1) =
    0.5*X/(nHorizVerts-1) * sin(0.5*Y*M_PI/(2*(nAngles-1)));
#ifdef DEBUG
  std::cout << "initial coordinates:\n" << coordinates << std::endl;
#endif // DEBUG
  internalEnergy = 1.0;
  pressureDensity = 1.0;
#ifdef PSEUDOCODE
  // This is the desired code:
  cornerMasses = replicate<2>(pressureDensity) *
    computeVolumes(interpolate<2>(coordinates));
  pointMass = total<2>(cornerMasses);
  zoneMass = total<2>(cornerMasses);
  // This is the code that Pooma currently supports:
#endif // PSEUDOCODE
#ifdef CORNER_FIELD_TEMPORARY
  computeCornerMasses(pressureDensity, cornerCoordinates, cornerMasses);
  sumAroundVertex(cornerMasses, pointMass);
  sumAroundCell(cornerMasses, zoneMass);
#endif // CORNER_FIELD_TEMPORARY
  PInsist(min(pointMass) > 0.0, "Zero masses are not supported.");
#ifdef DEBUG2
  std::cout << "pointMass:\n" << pointMass << std::endl;
  std::cout << "zoneMass:\n" << zoneMass << std::endl;
#endif // DEBUG2
  velocity = Vector<Dim>(0.0);
  velocityChange.addUpdaters(AllConstantFaceBC<Vector<Dim> >(Vector<Dim>(0.0), false));
  for (int d = 0; d < Dim; ++d)
    velocityChange.addUpdater(ConstantVectorComponentBC<Vector<Dim>::Element_t>(2*d, d, 0.0, true));
  velocityChange.addUpdater(ConstantVectorComponentBC<Vector<Dim>::Element_t>(3, 0, 0.0, true));

  /* ITERATIONS */

  for (; nuIterations > 0; --nuIterations) {
#ifdef DEBUG
    std::cout << "Begin an iteration." << std::endl;
#endif // DEBUG
    pressure = (gamma - 1.0) * pressureDensity * internalEnergy;
#ifdef DEBUG2
    std::cout << "pressure:\n" << pressure << std::endl;
#endif // DEBUG2
#ifdef PSEUDOCODE
    // This is the desired code.
    forces = replicate<2>(pressure) * addNormals(coordinates);
    velocityChange = (timeStep / pointMass) * total<2>(cornerForces);
    // This is the code that Pooma currently supports:
#endif // PSEUDOCODE
#ifdef CORNER_FIELD_TEMPORARY
    computeCornerForces(pressure, coordinates, cornerForces);
    sumAroundVertex(cornerForces, velocityChange);
    velocityChange *= timeStep / pointMass;
#endif // CORNER_FIELD_TEMPORARY
#ifdef DEBUG2
    std::cout << "corner forces:\n" << cornerForces << std::endl;
    std::cout << "velocity changes:\n" << velocityChange << std::endl;
#endif // DEBUG2
    velocityChange.update();
#ifdef PSEUDOCODE
    // This is the desired code.
    internalEnergy +=
      -(timeStep / pointMass) *
      total<2>(dot(cornerForces, replicate<2>(velocity + 0.5*velocityChange)));
    // This is the code that Pooma currently supports:
#endif // PSEUDOCODE
#ifdef CORNER_FIELD_TEMPORARY
    copyVelocities(velocity, velocityChange, cornerVelocities);
    tmp1 = dot(cornerForces, cornerVelocities);
    sumAroundCell(tmp1, tmp2);
    internalEnergy += -(timeStep / pointMass) * tmp2;
#endif // CORNER_FIELD_TEMPORARY
    coordinates += (velocity + 0.5*velocityChange) * timeStep;
    velocity += velocityChange;
    volume = computeVolumes(coordinates);
    pressureDensity = zoneMass / volume;
#ifdef DEBUG2
    std::cout << "pressure density:\n" << pressureDensity << std::endl;
#endif // DEBUG2
  }

  /* TERMINATION */

  std::cout << "final coordinates:\n" << coordinates << std::endl;
#ifdef DEBUG
  std::cout << "Goodbye, world." << std::endl;
#endif // DEBUG
  Pooma::finalize();
  return EXIT_SUCCESS;
}


/** HELPER FUNCTIONS **/

#ifdef CORNER_FIELD_TEMPORARY
// Following is temporary code to permit compilation using the current
// Pooma code.  Adding new Pooma abstractions may eliminate the need
// for this code.
static Loc<2> offset[] = { Loc<2>(0,0), Loc<2>(0,1),
			     Loc<2>(1,0), Loc<2>(1,1) };

// Given a Field with twice the refinement, form a cell-centered Field
// by summing the 1<<Dim corresponding corners.
template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundCell(const Field<InputGeometry, T, EngineTag> & input,
	      Field<OutputGeometry, T, EngineTag> & output)
{
  const int dim = Field<OutputGeometry, T, EngineTag>::dimensions;
  Field<OutputGeometry,T,EngineTag>::Domain_t range = output.physicalDomain();
  output(range) = 0;
  for (unsigned counter = 0; counter < (1<<dim); ++counter)
    output(range) += input(2*range+offset[counter]);
  return;
}


// Given a Field with twice the refinement, form a vertex-centered Field
// by summing the 1<<Dim corresponding corners.
template<class InputGeometry, class OutputGeometry, class T, class EngineTag>
inline
void
sumAroundVertex(const Field<InputGeometry, T, EngineTag> & input,
		Field<OutputGeometry, T, EngineTag> & output)
{
  const int dim = Field<OutputGeometry, T, EngineTag>::dimensions;
  Field<OutputGeometry,T,EngineTag>::Domain_t range = output.physicalDomain();
  output(range) = 0;
  for (unsigned counter = 0; counter < (1<<dim); ++counter)
    output(range) += input(2*range-offset[counter]);
  return;
}


// Given a quadrilateral's two diagonals as vectors, return the
// quadrilateral's volume.
template <int Dim, class T, class E>
inline
double
quadrilateralVolume (const Vector<Dim,T,E> &v, const Vector<Dim,T,E> &w)
{
  return 0.5 * std::abs (sum (product (v, w)));
}


// Given a pressure density Field and a fine-mesh coordinate Field, compute
// corner masses, placing in "output".
// TODO: Extend to multiple dimensions.
template<class InputGeometry1,
         class InputT1, class InputT2,
         class InputEngineTag1, class InputEngineTag2,
         class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerMasses(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressureDensity,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & fineCoordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output)
{
  // Assume the temporary finer coordinates Field fineCoordinates
  // already has values.

  // Compute the volumes in fineCoordinates.
  output = computeVolumes(fineCoordinates);

  // Multiply each volume by the pressure density.
  Field<InputGeometry1,InputT1,InputEngineTag1>::Domain_t range = pressureDensity.physicalDomain();
  const unsigned corners =
    (1 << (Field<InputGeometry1, InputT1, InputEngineTag1>::dimensions));;
  for (unsigned c = 0; c < corners; ++c)
    output(2*range+offset[c]) *= pressureDensity(range);

  return;
}


// Given a pressure Field and a coordinate Field, compute the corner
// forces in a fine-mesh Field.
template <class InputGeometry1,
          class InputT1, class InputT2,
          class InputEngineTag1, class InputEngineTag2,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
computeCornerForces(const Field<InputGeometry1, InputT1, InputEngineTag1> & pressure,
		    const Field<OutputGeometry, InputT2, InputEngineTag2> & coordinates,
		    Field<OutputGeometry, OutputT, OutputEngineTag> & output)
{
  Field<InputGeometry1,InputT1,InputEngineTag1>::Domain_t range = pressure.physicalDomain();
  output(2*range+offset[0]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[2])
		  - coordinates(range+offset[1]));
  output(2*range+offset[1]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[0])
		  - coordinates(range+offset[3]));
  output(2*range+offset[2]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[3])
		  - coordinates(range+offset[0]));
  output(2*range+offset[3]) =
    pressure(range) *
    0.5 * product(InputT2(1.0),
		  coordinates(range+offset[1])
		  - coordinates(range+offset[2]));
  return;
}


template <class InputGeometry, class InputT, class InputEngineTag,
          class OutputGeometry, class OutputT, class OutputEngineTag>
inline
void
copyVelocities(const Field<InputGeometry, InputT, InputEngineTag> & input1,
	       const Field<InputGeometry, InputT, InputEngineTag> & input2,
	       Field<OutputGeometry, OutputT, OutputEngineTag> & output)
{
  Field<InputGeometry,InputT,InputEngineTag>::Domain_t range =
    input1.physicalDomain();
  output(2*range-offset[0]) =
  output(2*range-offset[1]) =
  output(2*range-offset[2]) =
  output(2*range-offset[3]) = input1(range) + 0.5*input2(range);
  return;
}

#endif // CORNER_FIELD_TEMPORARY
-------------- next part --------------
begin 660 hydrodynamics.tgz
M'XL(`(LSUCH``^P]:W<:1[+Y*GY%'R='`7D8'I:E#9*U5P)D*RL+'0G9-R?9
MXQV&!F8]S'!G!A'BX_WMMQ[=\^(A6P8GN3?L)H+I[NKJJNKJ>G1-FOYX,HWD
M&]^=CF5HCK[9PJ=:JU8/#JK?5*O5VN'S??Q;/3PXI+_PJ%X_J']3/:P?[!\<
M'NYCO]JSZL'^-Z*Z#63RGVD868$0W_AN?V2-5_>S0_=KH/.U/Y5*>9.?0J4B
MFJX5AC)LX'<AFAD!PV<O7;]GN>)\ZMF1XWNB*\<3UXKB$79^Q&8Q+'SK#+R^
M'(CK3N?UZ;M7/[5N.JV?KDY?7S1OW]UVVU?-B\MWKPK?0A?'DP_T`NPV\2EL
M?)5`R<Z]#.X=.6L(^)5C#/W,T%F(AA#\O<P<L(@[_D0&5N0'HCA`AOE!2<!3
M`!W)7W&:G1U!'UMZD0QD7YP[TNV'IIJDO,'_(;R'!0C_R8I0L01K>QM8$UB*
M&.A15N!/O7YJ!83X;20]VW&/L\0Y:302.I1,(;HCF1J9HZ0B5"@L.YI:KCL7
MTQ`(8P7I,1,KB!Q813B1-OQU?B-R$]U$ZK-Y\=^"I'7G$PG;A>B_6>#;P/;"
ML]UI7VX#VV\=ABV>7,D9R5.%_FV.GJQLN_"<B`1`!N&*?BUG,.A,PDI:0K-=
MKP._/[4C?+ at -DIW[P<P*^J(E;=<*6%+_%,PFY*>N"YB'=N!,$/-82ZS5ARNT
MI`.[6F]P82,`$:*:]8;""D4T`EZ<<^L3$2F]A&!@NUMC&:$"@H$95:/Z&^U?
M)X$,0\#PQ!"SD6./A`,`Y!@T*\R*4/H.K`*@B'M")U;.I#6NEVN4!(C6VK&J
M=CQ8FK!("X("=]VDR9]&T/:'T^(OG7L)JGMA)4100P!MIH%'M$ITLQ=&U"QF
M3C3*+3.T+1!H`3\#AVP-/4S^#VIN9"OR%`>%WRNJZ[-ML[)*9-XD0"2Q]$`^
M7-'U(_AW6APW.E-!0S[F#=&M&VIKO)0^"'TP/RGP[^QF.BIL9=6K]H$_6&*,
M;G3R;:PFIW_>2-05E3<@_Z)\(FY)?BM-D,\_$EN7C'1`_[2<L0;1?:V_-6^7
M at SGFI1[3H&X==.*=YX#R'-_`<P>VIK1T(\`"*.*D\*$PF?9<QVX4"D)$;)7`
M6-C/'=)G;5:$[Z(C[(!44XJN20H!MCMH&1LU!C1_**`B4"H%^Q9+1_#H(PZ]
M]&V<^X15:&<P"&44+HP%CK"*M35X/#^0=XTT;`VL6$LF0!5(_R;]%4S)H#15
M`_^!M5E3E[0Z'AH(.@"UY:!>Z\WCYI"/&=!Q0_1G[`2>243(*UGQ at 3'(\?"\
M?;+8FX!!D]@=H(9MTQ0E#0&T)"'Z6D8COZ^PQP:4!=>?R:#]*R`7%?%W7Q$/
M!BNR5(\`#'>>HNF^MG.-.Y/)O(C["<%!F<D+`C3H0[18TNN!Y;#`.K45XC`H
M.K6GT%CF;]6$<9N;6OVMKT"A:CX7>\#=?J-A]4)1#*=C49RP'5C8 at 4^1D32<
M.F!:9CSQ1[5D4+M('NGV&K?#9XOK47^?+=DM=Z$4<!*#O:)/9K4 at 5-ZZ4XRI
M`3`,^DEKR/R$'[`J,T4P)1V9T<5J2>RI!E',0(+-N)>!541V%W:RG>J+G4H*
M7GGIA+75$U;SL.J?,F$UGO#IT at GKGS'ALA4ND*&JA>/CEL[O!XW#K9]T^GR+
M#RO]A15<UQJ>%/!T\<"D+Z1M^5NRM7/!@V,8'I^81D$%&HZ32:`]`2Q.&@WT
MIV$_V4N5[=K!NX-2X4/J[%N#"5N%>!0FW9>L1?4R'L):W,B(@2G]1+\;C;'U
M7A85D.+`3)T3Q1)N5Q`FT#/?2J_O#$1E;WV\3>Q5"K]WQ/3_UH?,"\N+V-A"
M<?$]T.9GS0VF`M;'_^OU_><UBO_7#VO[AX<8_W]>>_97_/^K?%"5[I5%\^E3
M_(N:];1YV0`36GKA!CU%BA*.P$(-_4$TLP*)40?X!_0,G/)SL`C0LN>(<W$$
MKKGC"3``7#!EG]QVSKMO3V_:3TH4%."GI"9$$7P]_.V*3N_?(,'E#KCQ8&KW
MM<U)TYQ.)K`@]@)+8"8CF+'5!QSN+<>U>F!M3+V^#,C5!SM]'(+QC.&B'@!"
M9#C@*S0B8F2%HB>EAX"L"9 at H]]`1XSJ!=*4%- at Q%&N#`\,$!16PN3\O-IKB:
MCGLP"_TH__"W\L%S4Y]W=YXKX7SQ`8- at Y@`$!_2AC6,-P`KHMC"WL*:P0F7K
M6X0*'F+^7$H!F.COY/;BNL!Y(D<AFI,C#'XQ(.PYEI%$^+DG0KKT0W'J6F/X
M<T5T@[/XTNKYU&^NJ`6J(PHLL,VN?%.\+1_N5Y^7VU<OR\\.:/T(AR8V;TW1
MDACOIB`4S-+V9#"<*ZI2^TL at 8>!1.RXP<(:C*!21CY%S`R$%DBU!:1!+^PXX
M,4X/CK8L>4P"R4X@\'@.)N8$SJJD.P&;!(B.!"X'SCVL[QXXY@?O65IXL#O'
M06`4S'/TQZ6!S\@!JI$5#`$CE`"G#ZR(1E;$_:_\"/:0DO(YF.G`2[U\YEPX
M<B:8$Q"9Y?4QNP(BC8@[, at 0:74D'I8)HF2*3YP=YOK)<OY<A30F[+`#%#JN7
M'%A$L<`SW4&A at N\@GQ12P,ZN8_7`IT;A"!1"(9P$H:.>#M1LP`X6DS3-M1!?
M#!(R0?O8AR/=0:KXRHQ?I+ at APJD]BKLBE!A$"'1V0;S!9X5=%0!'QE;P'I$/
M?0RV>GZ$H,$L&B!:3L3;3HFP]HJ3/3X(_#%LOJO+&.%S6-48]E!&_8"8`WM)
MO\!,8)<(61X##%J&[X^M_[)LUW0MSS6'_CW)$X"Y=X`%1"+63#/9$Q-K"!(`
M$AU%DT:E,IO-S/30"D&KF)O5LEGUO1FX*?`4,X]3NVP[G%NV/&MN.U%[U7Y[
M?M&^;+V[NVZ==MLW[YJ=J]ONZ57W3;O9[=PT.Z^O.U?MJ^Y9<R%[^UE#MYZ*
M%2MMKH8X@[9^$W3%$/6LSB]$D0I$ZP`UA39I;]U+SD1H("#*I#Z&4\S7@/J"
M;0!;:.ZC(LKE%NF3@"JZ_M#!XW5>@NT?Q]@$Z(B1&`"/<0=8[+0#]F(9M'O+
MG4KSSY`9^BMIJ8"GLHAWR/,(CIW*E8]IR6R.,6F]/@U#&7"V<4FZ\F[2!PD.
M]-\52<U<KS.PF_[DZ<L5403PC]<$$M0#H at D'5#:+U=H$Z"I%Q&G.;`(%SWW%
M*ZV at DI,_(@M&AIRJ%#V\6H%V/2B+OL.C,6T7:YBT at J'$)IR$H+EF:&W3*4J*
M!*<$C!:5'``C4XNTDJ.2HUHQL0T(6E,OKUA*;GTH4PV1'$O+(QMS9($Y0B`B
M9RS+?3F!4Q^G`2]8B--TR%R$8&.`P0)K\&><[P5J`0R)%H0MV>BUV!)`Q5F.
M2<$K`F1_DX%_Q":4-1C`TL`R\]RY,EH6TYH\,JS$RT>%;EMH\^`L\03LV/#!
M1T97CSN`?.G4;\PPI%`WCNVFLM,.+PH#0MISB!7^MI1[C(9.%R4)H17RF4WT
M;!2A)5D7C#P7Q&IL*"6!HLB1[?ML.P7;Z884Q>^Z8E<3-&[I^;ZK)4C/<J;9
M^@)`NZ$L(0H-FN;=N(A_2@;%=7/306/NB>JG9X4.^FO)X*#ZBJFAYXJ6DN"!
M'U3292UU>-VK=<TN6/_2S:Z/'IG\0V.YN%#NM?!\<<'<,7GP\,)YQ,KV4KS\
M+0D at G+#.D#V]^)*':/D20Q-R at KZ;:C8?$$ZQJ\>_>)@3P2 at LQ?D8IC[('SQ5
MK#A:S at C59^'Y48X/JE_RX&@]%U3_E>V4Q8T#SGNH4E7>:DM,L6WPHT$E5)3#
M"K8U>L9P*.)Q at M&=4/%#JX3B0J9243+.;>:HMCA at D:PTMAL3=G%(BL+4=YV"
M61R]FMYQ;OH.[#^*K\SP8$`O?&1Y0YDY+[X/^<0PA#2'IL$QA/0!:TO*0-_[
M3C]S7'>%)V?Z%V:3,Q*4:N/%X?\G%%:0C4**]"Q>2TC,#5V1E<-U-,(>VTIW
MG7KJGN at RJXG/0:3<ZK/P:V7#UMNQZLA6%N)Q-EM$0S,)(T/G)-5GY?*.=:)-
M=!N-.->,"2>\0Z$B?2D?XK-G?C0"RV^;/)8`CR0"0<'(>C:1MP&"/!H;G'1)
M6G$-!N)V2N%['L7_W[91ASQ35%+G8HR$V`W!--,&VV>38;=GE\B684(40T/`
M$Z8R^SE at 7US[\*W18#^[J'+X'Q0G=+($W0(5T0TQH"<<MLA#QI1"Y9Z//\L#
M=>M>\4[]58YZ40THEDQO.H9U\AU]T/PO7 at B^NY(:A#%8B7=N:"[&V,QVT<L`
M=9R`CC#)VZ*6XA*8+R5[17V'?#_?,PNJD6[T`*B>;:HCLR+J1X4T,22G1I+!
M0)&)Y:6I\3WZ<GC/46$L,N,#"4H4CJ*9%/^>`E?MD3_!NU\$(1TL,T1DO<=P
MFXVQ>3C9$C!PQ/5==<91EH>\58"(/?GDH'O`Y.$EVCP!4*1D$9Q5Z.P0<U&S
MHVM6CF^(E7*D1N)8?<19DQ2$H`BD6GV<[^Z*>$LG[,EDWDU?7UG[N?]/E():
M*1G#TP%#JGI*"0[(8G--[=98:%P42B3/R!F.,"H.3C(=Q0FK&7?%YMW,M!_B
M;P3N%<+ at P2+;HB7)XWP:N*F9:*?#8D%WQI9(FR:J]Q('A1D1SM*(H%X24/A%
M\(K]6+)3/%)XG3)A%G=-YI-ZIK<1\4!<H`2`Q71<.RFF6LRQ]6L1;YIIA)\J
M#H`/LZ.O*R]^%B"D$/\H4GQ=R8#+F'G+E_MI;*![?AMD`\';`!MV/I\/J->8
MZ#L+%,8VX(Q>35GQ*$WT`O][2[Y)2V:N=?Y'GVVE;7JI\<U.Y1]-)NX\&Y2*
M35GM&)&U/R7DBME3+^9_3/62B3&OHJW"C<#]!6<)CK#"3JI#XA,=%1*J%S(.
M0GQNQR=^H\'G%IS]>N[8X-\@T93![[H/!%ZS]2443T1E38D=S!^S004'WEDS
M5(&^M>'<+<;L\B&[=8O+&LSK>A:7Q='6!-#$)\;0R"S[A(`93Y6)E'&DPNZM
M"XI]T/[HPQY4RG%2>R)U=_9!>WEWD%R>33;0X\SME`)%:X1([]#A#W^.15WL
MI?=)'QQX#Q/K(30_?5J*U=O`M/I]K716V\S=DZ)C++*`;R3O:*,;'C"M2_$V
M7G#QUSGU:8\>P?!FUI<,*X])"__>%[6V](D+![<XQP/U_]7]6I7N_SW??U:M
MU0^@?VW_L/;7_;^O\=G"^?90?;^N4?BJA?W7\/VNV7V at L#_I5?@S%?8_7$JI
M:([E/5CG/[;`2,/[3C8,4]E5/G]@>.Y>QY_B>L1?ESD8>.JB1=?QYA4^@+=T
MKV+MW8+/D<F&N)8!WL##K/PZT32%N``+G:[^O??\&8)QP#!&:]X0O6F$MP#!
MA)Z&<C!U,4#CJ2IB7<FK"Z<'&+2QPJU<5>+ at W9L<[G3U0&K<&-O,8MB9M@@[
M?7G6]@.^B=G'!61HDQ"%INRT. at W15%D8/W]W`RV[EC-^43=3V?9\269LFYX4
M4K6770-^:UZQ"9YK%;OWVCA?:)EQ/8IZ7N>GEA>"$X\F&G_#,JP7XIZJL<1,
ME4&JIAHVE>^I<`K:.%JIZ[P5G(];<=26BG=*:M4-4^6@,3LPK"?^I=PS?=MB
MLX at 5V,\7YYZRW8C`U^UN^UW[]77W)[9B;^[0A+TMQKU*BVY)MQ:SOIXJZXO=
MXS/'`[?FAFA]C)VQCC<&F"I46E+XUZV)72MVV>IBM[>BC%&7+!8MHY>N+,N[
M4#4C1EI):<T@`:[K!OVE#8O)+^6U]5ZJA?"JKOR^/([78J2C`DU0#)&\E-9`
MITYJ!LS:KE%M%CY_MW+`:1!8\V/`";`!/)(!]#5YPP,0+;NE\C/M"M?@ECS(
M71%D:[Q6+>@12_KL174#*3-57RE"<]N)+@&C7T6:9#TZU-U5'O=Z-*AK0.6J
M'S]-9!)Y_[U$!#;#!J0"M]17%X0LZE^3]SSS"G:3&EC-[)?;U!!**#^=_6K1
MGZ\A\C,ELI`'^86"L79)G[VH+Y:2)>BLDI(E:*S5$-VO(B)P%&Y/*O"<W98@
MY!'_^KQG#![-[O55Q;&S__^YJG at T[X,8S(&ICAV:MKV-.=;'_YX]K^W7=/RO
M5GN.\;]G,.*O^-_7^&`XB59NB!_E8!#(N6B1WU('9KVV at OHAO5+)]\<6N;:O
MTO(B_B$#3[KB;>!$$;C:=R%ZJ;374I&(8\<'ET5:XY/4LS#JNT[/'*6?V>C?
MGJ3?:H?35G3%2.[M>-E7&ZQ\'5YZP,I2]R>)VY[9$.CM#0-KG'X1VQ.\C1)?
M)>+""/VB)G"VL=(P2Z13=^@#@4;C4%`)S6]()`2`669=64%O2$`P7!MK/,&R
MWK;YHRF:>#??\L"9:IEM4YQ-@\CW#/$:VVY'5CAZ[]\;^B5NU^:U*=Z.+%="
MEU_ at M!M]^-$'=6NYR>NO=$'O]6@>`GX?#0R*F**V?X`0BK4??OA;R1"3B2GJ
M]<-R_:!N%G3)@`TG!P8P0L'WC53%Y<P7H&<',L#KRD`O;^I:`94*-6"(%812
MXX>15U.(,Q^&#0.GCSZA+2?J-9DVEK?RG1X\9#@5RY$25=6)X\LP@^-180A>
M@(IF6&B;O8C`%1,4]9"6/1)QUHI$NSD-$%-W;K!@PT22RTD]``5XA-/)Q`^B
M),2"%1?1#*NN>=T(A9:^8MFJM)G(Y=LVS(<\5S!P\+^:G9NK]LT[SC]UP7'O
MW)S>_/0]E28'/E\SULL(I[TP<B(0]E`5XG*IAVO9[W&U"EV8]%8R)4*L;X9C
MDJN85>ES'Z5YXH?`>H#"M2*1Y;@A\_<Z/7,X'_=\EV-URU%MB!;'T:F0A?MC
M>$[M-EIZ!'(A6:PY4;N29G.A+[`A)K?MNU:GV6FU81*.C_67S74+=,7<*Y7K
MTVNOU*Q8)JFO=L#\GSAMJWUV][*!5<RJA at 8+N]&W"/WQLA)A!^^)X$922H)G
M99XE`.O+((ZYZ'EIY;$&JQ:A-9"&2R72%JHCBFPZ+H^%[Z`D^L2P(;[,82C*
MK>6<$^6+BC<(*_YOE1&LK,(GGZI&#NJ5,+`K#_4!W5VYO+BZ^^^AC9TO39$W
M)$39I=[E(7[WL^V4JZ'WTRS%$!:YMR?..S=O3V]:0,;FY>G-:?>B<W4K]L!6
MRYOQ%_B.M?P[>_CE5)_R)A\V\PN8A"^$T_$IR12]&R[CA>=FR27D^45O=&V4
M/CPFCT1^$+]\KK08[MK&DMY0"=ACUK2SR=744O>-4\U),))_UI=WBR?,=H\?
M+PY;3C5^VLW^7$%!]1ZFI at _&3O":WAF[FHJ`5[R>',9((W+DIH%LX7D4S9&X
MA&H*7!YA38_\2A$<:I6F[P=]<.S@>-#@E at .*UYQ?[5+>B8>8]ZG<>RS[ML._
M<[RZ\^7\^U+&V7\,ICW(I:VP8S)_(UW?)E/IT9P at Y51+-.X7P:D_I+D_B0W)
M!:-5YQJ?;-U7;9&)18CKF\[+F]/7?+R1A8"WZ.GN=S"T#7K3C-B#[_<__Y-#
M.ME;^FS'PJD<6%B6+82J+W#BEXL7"1!"0$3Y]"4#!3K32R1M-#Z.C\635W#T
M^0:^G\7MFT_P$;7#VMST$GDP8K*7.Z(KZCKH&S)9"IHU?7^*SM'0`DM%O!#[
M9K7R[&AG!PT6*XPW5E)N_-TOU/6[/`"L(;N-Y`3OJ)G5&H/X[I>6="-+1-A]
MZF%U)-B#WO0BBDUXO+!.?1,_P8E;%<H<7<+:=_+X\"ZS/Z4:2T8AAMQRL/BA
MS@#?^L%[>O&&J+<4W19'>*_`"_P-#V%"!7#)H#+"5M^+*.L=X,N#PB4P3KVA
M*W'\\_Q2+&HIB.3Z,KV?ENN^^78K!N+2OW^NYJ\[IW`L+?2N+?1F;*@G][DD
M<O',3+IB&H0A7B9WN8_K^,+;TI&B_'7`/HO.5G/INXW\(+]-I'++)P+0A`U8
M!/[3[.FF<&)A&498K)E5HX8=N`:$$N1O,55+[AZY$GW_[ZGHZ*KW"[/<&>B)
M@[IV+(\G.HGO=:ZK=L)7)VH`]#D+'/O]B?K/9#QF9/)&<QR>K"U)_J??>8Y7
M(%*_\7ZQ?B.2N7;J%$V-#-+W#R&];&2"POV7(JUV:N8][OH_.J)>ZHSO:T<<
M-95BIXJC*P(L>^AA*!G]W_:.M3>-'/B9_156DDK+8PE+>JI$0^]20EM.(:U*
M<J6]RT4)T!PZ"#E(6D55__MY'O;:WA=$3=H[L5+396V/Q^/Q>#SVC"O,3A7-
M.\A4%IV%')LCT/W$<H5U.277"G<MR)KB:H7IF,MR=;*P3 at H]L:!Q-Z?X$7&B
M7,TD88DJ.-"704_VOZG]((ZKE/U$JL/MG0LRRRU1F#D-]4:#()IY7\T^JRAE
M'>.:A8%9X.><I2Z"@T!DE[//E30 at XF9!GF7&109D]Y(SIUSWWQ(8OL8`IB+7
M[.7."P3^-V=VP`/@>K89TBGPH=B%Z>ZI*)>'=-X[7CCN.5,O?;+3V7\FX;OV
M3HI/(E03??'CU29/*!:C13J_,1I,L'E#:6`L^\3J("(LC'4:L][J,`R]>340
MT)+KZ558N",59-GZ2F7S=6'4'#N'G:/.WD'G`RJ/K#MV9M=GV/^-!KS*ZN<P
M9'U#;%2'[&B*:*HSO7WA8T[R&Z+0V"KMO95&<;I-@%P$=+-JK=3?-I6A`$^?
M#68+_WVI>_JFLRW96ZD_,HV0B`$+LX#)`9T%+$Z"@:*!PTNIE!ADD6*00`L7
ML*8(#OI:]:=4JD!:)F4208=YH!>HXF6`SES'\-K'[)?&'Y>XH#$^Y:QOA*LZ
M8(]"H]SYF1,8I<B&[47^W!Q<R;16-S1Y6,(T(9(6AJL=@4!S:E'!W)W0X(CC
MU6S"A8SF40=$\W23G*0I5U0MYM(J3E8FIRUD<0>MFI:@`[6WHG8E%@W3[R:B
M2MZLF&1T<XUG<<:JB!C"<?MGE*$24<;.B]=]V#D5=9:1;7+]W9$H+JY]F/2B
M.N2:02Y9*F+C`WB(3ZG'P7L<]CB88".YZ'98NQ[C;0U2<734PS8_NP55*U0Y
MW>>9PZ".:T%2GR1W&`J^7H+9VI7A#+;P#4\_"A6Z:Z[7GODNN`I[ZQ6U2J(B
M!"1J(ZDU9[BA&56:L1NDA!G*15>%>NEZ?L-(?,LJ=B1TIP*>"H_:M at D%F_[4
M-F(\`QH$@?FM*+ZX at M#M]>>C"S!/7$8&CUS#CA"1B).4]\EL$X"0`]'L2K^2
M(R?C#!QC88:@.5A5EL.)20(V4\22^S>Z;*:*5VB2[-5#V(N;+"P!^C2!R8`@
MV at RU;0 at 1"<81G:1[,I2'$IZ.^&2;M[9=6]9GD8!GLLRD+!6'%LD$*C5%$H&6
MD)UY?,,+(^K/:$*/$(Q)0!>"EF04M$H#<9J0*Q%C<D&YM2=K`4LPJ:-KE)ML
M?@_2N(W3-<\-9]=.9UGLKEM>1IW+Z<CB=^!2:RM`X>.R6"6V^F%,844CQV*\
MU2GY[?D=2E=P9</),?*G$QZ++:4)6`L#@)G3"P";Z[1'%I2U\W(ZN30U7:4P
M+L3B*JN>_K<9S/)R6[(O0G'EMP*>.WR^\KPGI[UNY]!<_]D5RB7+REI\UKK@
MY6PV/+\=+;O#H?=2$`_823%=D-K]SM%I[[C5:O=Z[(A4*HE7[8,W[;?BQ?%A
MRSBVD#T>T`P$867YFCC8TIO-*88&G:6Y&LVGXVOKV`?9A7"4TJC4I_5(J at BQ
M-T37L<O19_Y^=K[`:QM0G8`0?J/)>(I4I$-4(PK#KPX:L72""PS&`[RJKOY,
M4/2 at W\'F\X6_^;4*:&[Z1UB,HC/PQ]#,$<H<`AQ]P%>0;_6,6;<`H3FN6:<8
M`8)]!`=QVR^`.0>)-)TJBH2[H'PY+G0D&!;5ASI#<O<C)"N=N<`M0:H*=67<
MG5H"@A70P4NI]*AB%M"14N:L"?%5L5=XG-".`$9)9'<IJH!2MI%1#DOH1U+N
MU8]=X<O>DZ at 50<_GKZ3MVR"E2$2J2<4=OY29,[G(B3%4E9O at RMR6&)3Y1^2W
MASK at LV8V8K9@!6;[Y^9L.`>I#1?R0J at Z/#-[=@$G<1=@Q2=7YX6^PY@/O+KE
M:)9>THN7N80V$3T+%"D)XLX.O4M<0BD5'3G'*E\,DQBN"L%#$2_+H2.^>.=$
M-+^K^YU9PZ%H[[@,F"H[S at 0MS[#UL4&]MF'X1>/5H1 at 3?7HSN<;[)2-6S!Z;
MZ^-J/_!Q-7429@^O,N+[NY3:!)7-+261V,Q!@B"<3>:CL^$MGBC71VUY^P_)
M:40/P`TV!TI5"Z"X(NYDU1N+7>+%6]JL8S7^G`*HN4.DJN6ETWVJ]]S.2Y"=
M3F<F"E'GP`E/7VRG]T/0E?T5V<@4^U(8)$AEEL="K>,7*(@M$>S.[R=%,#$X
M+6)!C?1-D<.:KJ;(214T*@:#Q(EUX@'UOBFFL$AU?6[R/W=N$J7'MQI462J)
MP[RU$[7QI0HK#:.DML/0PDI^GDP-.,Y4I"8;-/`MP/63(F8(TK.$)\4,S,+[
MPJR6C]E.)F;U^\)L)Q^S6B9F._>%69B/69TQ,X5=IARRI4VR+/F>9WXK&C,;
MIY4._.8"^1:G?=.$!\L.1W0D2`ZV.$*;EI`=@2,[DE/#S-1Z9BKR,2.D5SQH
MH"2:Z<G58K=<`^CW=G!=/YD/>.1_'$]&]UD'^G_7TOR_:^%CY?\=AH]K81WB
M/^[4GZS]OQ_BV=S<3'(`A\_L`5Y[@K_(!5R^X:\6VJ!'>&_T&W9_]-ZU7ASL
MO>PU"\$[B%0<O+N<!:#B!Z!(GLU'GDHO!!=BR^?L1?&'G.:"?;2VISLM8J;.
MUI=7K[OMK^R(B']KRF$Q,<UR5/1:+5FYRB>_!&/8O9],X'UG^WQ\"2]>J]]7
M#=D_[K5/#SK/7_;[IYU#":C=DY at SXI`Q%UZY[!WL*W`'U<*FV.OUCKOMN-L&
M&/TY:#H;\SEL.MZT)Y%`RD5>E9YL3N_U\=N6Q*D9\[_TO-?/?VVWCB!-8JQR
M-A[)M.:CZJPH585'#2'?O(),[_>+`O_C/MGR&6OY^B?\DM47P8]SZQ<N)ZM8
MN2!<Y'O9\`KSJ0@^BE)U)O^-Q_+/PO/^DNOOT3RZ'`B\Q[T">H]VNQ'1S<;@
M#_4NYR))V_U]08`$2#5A0H-T]N^`,'J\=[)Q`3%#1/"W2$!@H[J>O];/^ED_
3ZV?]K)_U\W][_ at 7#@K2A`*``````
`
end
-------------- next part --------------
*** Product.h	Thu Apr 12 16:07:14 2001
--- Product.h	Thu Apr 12 15:46:46 2001
*************** product(const Vector<Dim,T,E> &v, const 
*** 50,53 ****
--- 50,127 ----
    return answer;
  }
  
+ 
+ //-----------------------------------------------------------------------------
+ //
+ // Full Description: product() versions that operate on `Field's.
+ // 
+ //-----------------------------------------------------------------------------
+ 
+ struct FnProduct
+ {
+   PETE_EMPTY_CONSTRUCTORS(FnProduct)
+   template<class T1, class T2>
+   inline typename BinaryReturn<T1, T2, FnProduct >::Type_t
+   operator()(const T1 &a, const T2 &b) const
+   {
+     return (product(a,b));
+   }
+ };
+ 
+ template<class G1,class T1,class E1,int D2,class T2,class E2>
+ inline typename MakeReturn<BinaryNode<FnProduct,
+   typename CreateLeaf<Field<G1,T1,E1> >::Leaf_t,
+   typename CreateLeaf<Array<D2,T2,E2> >::Leaf_t> >::Expression_t
+ product(const Field<G1,T1,E1> & l,const Array<D2,T2,E2> & r)
+ {
+   typedef BinaryNode<FnProduct,
+     typename CreateLeaf<Field<G1,T1,E1> >::Leaf_t,
+     typename CreateLeaf<Array<D2,T2,E2> >::Leaf_t> Tree_t;
+   return MakeReturn<Tree_t>::make(Tree_t(
+     CreateLeaf<Field<G1,T1,E1> >::make(l),
+     CreateLeaf<Array<D2,T2,E2> >::make(r)));
+ }
+ 
+ template<class G1,class T1,class E1,class T2>
+ inline typename MakeReturn<BinaryNode<FnProduct,
+   typename CreateLeaf<Field<G1,T1,E1> >::Leaf_t,
+   typename CreateLeaf<T2 >::Leaf_t> >::Expression_t
+ product(const Field<G1,T1,E1> & l,const T2 & r)
+ {
+   typedef BinaryNode<FnProduct,
+     typename CreateLeaf<Field<G1,T1,E1> >::Leaf_t,
+     typename CreateLeaf<T2 >::Leaf_t> Tree_t;
+   return MakeReturn<Tree_t>::make(Tree_t(
+     CreateLeaf<Field<G1,T1,E1> >::make(l),
+     CreateLeaf<T2 >::make(r)));
+ }
+ 
+ template<int D1,class T1,class E1,class G2,class T2,class E2>
+ inline typename MakeReturn<BinaryNode<FnProduct,
+   typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t,
+   typename CreateLeaf<Field<G2,T2,E2> >::Leaf_t> >::Expression_t
+ product(const Array<D1,T1,E1> & l,const Field<G2,T2,E2> & r)
+ {
+   typedef BinaryNode<FnProduct,
+     typename CreateLeaf<Array<D1,T1,E1> >::Leaf_t,
+     typename CreateLeaf<Field<G2,T2,E2> >::Leaf_t> Tree_t;
+   return MakeReturn<Tree_t>::make(Tree_t(
+     CreateLeaf<Array<D1,T1,E1> >::make(l),
+     CreateLeaf<Field<G2,T2,E2> >::make(r)));
+ }
+ 
+ template<class T1,class G2,class T2,class E2>
+ inline typename MakeReturn<BinaryNode<FnProduct,
+   typename CreateLeaf<T1 >::Leaf_t,
+   typename CreateLeaf<Field<G2,T2,E2> >::Leaf_t> >::Expression_t
+ product(const T1 & l,const Field<G2,T2,E2> & r)
+ {
+   typedef BinaryNode<FnProduct,
+     typename CreateLeaf<T1 >::Leaf_t,
+     typename CreateLeaf<Field<G2,T2,E2> >::Leaf_t> Tree_t;
+   return MakeReturn<Tree_t>::make(Tree_t(
+     CreateLeaf<T1 >::make(l),
+     CreateLeaf<Field<G2,T2,E2> >::make(r)));
+ }
+ 
  #endif /* POOMA_HYDRODYNAMICS_PRODUCT_H */
*** hydrodynamics.cc	Thu Apr 12 15:51:54 2001
--- hydrodynamics.cc	Thu Apr 12 15:55:42 2001
*************** int main(int argc, char *argv[])
*** 158,174 ****
  
    /* INITIALIZATION */
  
!   // TODO: Is coordinates initialization necessary?  What is the best way to do this?
!   for (unsigned xIndex = 0; xIndex <= vertexDomain[0].last (); ++xIndex)
!     for (unsigned yIndex = 0; yIndex <= vertexDomain[1].last (); ++yIndex)
!       coordinates(xIndex,yIndex) =
! 	Vector<2>(static_cast<double>(xIndex)/(nHorizVerts-1) * cos(yIndex*M_PI/(2*(nAngles-1))),
! 		  static_cast<double>(xIndex)/(nHorizVerts-1) * sin(yIndex*M_PI/(2*(nAngles-1))));
!   for (unsigned xIndex = 0; xIndex <= cornerVertexDomain[0].last (); ++xIndex)
!     for (unsigned yIndex = 0; yIndex <= cornerVertexDomain[1].last (); ++yIndex)
!       cornerCoordinates(xIndex,yIndex) =
! 	Vector<2>(0.5*xIndex/(nHorizVerts-1) * cos(0.5*yIndex*M_PI/(2*(nAngles-1))),
! 		  0.5*xIndex/(nHorizVerts-1) * sin(0.5*yIndex*M_PI/(2*(nAngles-1))));
  #ifdef DEBUG
    std::cout << "initial coordinates:\n" << coordinates << std::endl;
  #endif // DEBUG
--- 158,175 ----
  
    /* INITIALIZATION */
  
!   Iota<Dim>::Iota_t range(coordinates.domain());
!   #define X (range.comp(0))
!   #define Y (range.comp(1))
!   coordinates.comp(0) = 1.0*X/(nHorizVerts-1) * cos(Y*M_PI/(2*(nAngles-1)));
!   coordinates.comp(1) = 1.0*X/(nHorizVerts-1) * sin(Y*M_PI/(2*(nAngles-1)));
!   Iota<Dim>::Iota_t crange(cornerCoordinates.domain());
!   #define X (crange.comp(0))
!   #define Y (crange.comp(1))
!   cornerCoordinates.comp(0) =
!     0.5*X/(nHorizVerts-1) * cos(0.5*Y*M_PI/(2*(nAngles-1)));
!   cornerCoordinates.comp(1) =
!     0.5*X/(nHorizVerts-1) * sin(0.5*Y*M_PI/(2*(nAngles-1)));
  #ifdef DEBUG
    std::cout << "initial coordinates:\n" << coordinates << std::endl;
  #endif // DEBUG
*************** computeCornerForces(const Field<InputGeo
*** 354,390 ****
  		    Field<OutputGeometry, OutputT, OutputEngineTag> & output)
  {
    Field<InputGeometry1,InputT1,InputEngineTag1>::Domain_t range = pressure.physicalDomain();
-   for (unsigned xIndex = 0; xIndex <= range.unwrap()[0].last(); ++xIndex)
-     for (unsigned yIndex = 0; yIndex <= range.unwrap()[1].last(); ++yIndex) {
-       Loc<2> range (xIndex, yIndex);
-       output(2*range + offset[0]) =
- 	pressure(range) *
- 	0.5 * product(InputT2(1.0),
- 		      coordinates(range+offset[2])
- 		      - coordinates(range+offset[1]));
-       output(2*range+offset[1]) =
- 	pressure(range) *
- 	0.5 * product(InputT2(1.0),
- 		      coordinates(range+offset[0])
- 		      - coordinates(range+offset[3]));
-       output(2*range+offset[2]) =
- 	pressure(range) *
- 	0.5 * product(InputT2(1.0),
- 		      coordinates(range+offset[3])
- 		      - coordinates(range+offset[0]));
-       output(2*range+offset[3]) =
- 	pressure(range) *
- 	0.5 * product(InputT2(1.0),
- 		      coordinates(range+offset[1])
- 		      - coordinates(range+offset[2]));
-     }
-   return;
- 
- #ifdef PSEUDOCODE
-   // TODO: I really wanted to use "range" in a data-parallel
-   // statement, but I do not know how to extend "product" to work
-   // on Fields for such a statement.
-   Field<InputGeometry1,InputT1,InputEngineTag1>::Domain_t range = pressure.physicalDomain();
    output(2*range+offset[0]) =
      pressure(range) *
      0.5 * product(InputT2(1.0),
--- 355,360 ----
*************** computeCornerForces(const Field<InputGeo
*** 405,411 ****
      0.5 * product(InputT2(1.0),
  		  coordinates(range+offset[1])
  		  - coordinates(range+offset[2]));
! #endif // PSEUDOCODE
  }
  
  
--- 375,381 ----
      0.5 * product(InputT2(1.0),
  		  coordinates(range+offset[1])
  		  - coordinates(range+offset[2]));
!   return;
  }
  
  

From jcm at lanl.gov  Fri Apr 13 04:15:54 2001
From: jcm at lanl.gov (Jean Marshall)
Date: Thu, 12 Apr 2001 22:15:54 -0600
Subject: [pooma-dev] Hydrodynamics Kernel (12Apr Version)
In-Reply-To: <20010412161056.A2659@codesourcery.com>
Message-ID: <5.0.0.25.2.20010412221510.00a90500@x-mail.lanl.gov>

An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010412/7b454244/attachment.html>

From mark at codesourcery.com  Fri Apr 13 18:10:59 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Fri, 13 Apr 2001 11:10:59 -0700
Subject: Status Reports
Message-ID: <20010413111059H.mitchell@codesourcery.com>


Serve 'em up.

Thanks,

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From scotth at proximation.com  Fri Apr 13 19:07:23 2001
From: scotth at proximation.com (Scott Haney)
Date: Fri, 13 Apr 2001 13:07:23 -0600
Subject: Thoughts on replication & interpolation
Message-ID: <mailman.14.1331172041.20475.pooma-dev@codesourcery.com>

Hi everyone,

This week, I summarized the Chevron Flow scenario and thought a lot 
about compile-time versus run-time issues for field along with 
replication and interpolation. Attached is a PDF file showing where I've 
ended up on the last area.

Scott

<Attachment missing>
-------------- next part --------------
Hi everyone,

This week, I summarized the Chevron Flow scenario and thought a lot 
about compile-time versus run-time issues for field along with 
replication and interpolation. Attached is a PDF file showing where I've 
ended up on the last area.

Scott

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapping.pdf
Type: application/pdf
Size: 12912 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010413/f391f469/attachment.pdf>

From oldham at codesourcery.com  Fri Apr 13 19:27:34 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 13 Apr 2001 12:27:34 -0700
Subject: [pooma-dev] Thoughts on replication & interpolation
In-Reply-To: <200104131910.MAA02914@oz.codesourcery.com>; from scotth@proximation.com on Fri, Apr 13, 2001 at 01:07:23PM -0600
References: <200104131910.MAA02914@oz.codesourcery.com>
Message-ID: <20010413122734.B2923@codesourcery.com>

On Fri, Apr 13, 2001 at 01:07:23PM -0600, Scott Haney wrote:
> Hi everyone,
> 
> This week, I summarized the Chevron Flow scenario and thought a lot 
> about compile-time versus run-time issues for field along with 
> replication and interpolation. Attached is a PDF file showing where I've 
> ended up on the last area.

This is exciting.

Off to go think through Scott's words of wisdom,
Jeffrey D. Oldham
oldham at codesourcery.com


From JimC at proximation.com  Fri Apr 13 22:07:14 2001
From: JimC at proximation.com (James Crotinger)
Date: Fri, 13 Apr 2001 15:07:14 -0700
Subject: [pooma-dev] Status Reports
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BDF@proxim-sf001.santafe.proximation.com>

I finished my work on DynamicArray::destroy, adding the ability to use of
iterators into a container as the kill list (with some limitations - see the
log message for DynamicArray.h). Also spent time discussing Field and the
Lee paper with Scott, discussing DomainTraits with Julian, and discussing
template function specialization quirks with Mark. 

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010413/45bd7132/attachment.html>

From allan at stokes.ca  Sat Apr 14 08:52:22 2001
From: allan at stokes.ca (Allan Stokes)
Date: Sat, 14 Apr 2001 01:52:22 -0700
Subject: Intel 5.0 compilation of Pooma benchmarks: spurious asserts in optimized builds
Message-ID: <NABBJEAOKIDHLPHKHPDLMEIOEAAA.allan@stokes.ca>


Hi everyone,

I re-installed my Cygwin environment with the DOS line discipline and now
I'm able to use the Visual Studio workspaces.  I'm compiling with the Intel
5.0 compiler, which I'm hoping is much improved over 4.5.  The space
efficiency of the compiler during optimized builds has indeed improved
substantially (down from 550MB VM peak to 350MB VM peak).

This test machine is a dual PIII 750.  Most of these benchmarks run on 60%
of one CPU, 40% of the other.  It must be the timing calls that allow the
process to wobble around.  Typically CPU bound threads will stick to a
single CPU.

Under the Release configuration I encountered three errors:

ABCTest      wrong correctness value PoomaII CompBrickUMP Implementation,
N=100
GKPoisson    assert failure in PoomaII MP Implementation, N=10
Krylov       assert failure in PoomaII MP Implementation, N=10

Some additional testing shows that all of these run correctly under the
Debug build.  The results in all cases are exactly the same on a second w2k
test machine (single processor Athlon).

Here are the details of the Release runs which failed:

<<<
d:\work\pooma\r2\ide\VisualC++\benchmarks\ABCTest\Release\ABCTest.exe
Benchmark
----------------------------------------------------------------------------
---
Running sample #1 for C Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for CppTran Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII CompBrick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII BrickUMP Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII CompBrickUMP Implementation:
  N = 100...
    Correctness test value for N = 100 is 6.1409e-318.
                         CppTran       PoomaII       PoomaII       PoomaII
PoomaII
N             C           Brick         Brick       CompBrick      BrickUMP
CompBrickUMP
100        250.00         36.70         36.70        250.00          9.83
36.70
>>>


Running in pooma/r2/ide/VisualC++/benchmarks/GKPoisson/Release
<<<
Running sample #1 for PoomaII MP Implementation:
  N = 10...
### POOMA Assertion Failure ###
### contains(domain_m, v.first)
### File ..\..\..\..\SRC\Domain/DomainMap.h; Line 185.
Pooma::pAbort called.
In default abort handler.
>>>

This comes from within DomainMapNode<Dom,T>::insert(const Value_t &v)


Running in pooma/r2/ide/VisualC++/benchmarks/Solvers/Krylov/Release
<<<
Running sample #1 for PoomaII MP Implementation:
  N = 10...
### POOMA Assertion Failure ###
### node_m != 0
### File ..\..\..\..\..\SRC\Domain/DomainMap.h; Line 507.
Pooma::pAbort called.
In default abort handler.
>>>

This comes from within Value_t& DomainMapTouchIterator<Dom,T>::operator*()


It appears that the problems are due to compiler optimizations.  The ABCTest
could be an issue with numeric stability.      Changing the optimizations to
"custom" (+all -assume_no_aliasing -favor_small_code) lead to this failure:

<<<
.\ABCTest Benchmark
-------------------
Running sample #1 for C Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for CppTran Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII Brick Implementation:
  N = 100...
    Correctness test value for N = 100 is 1.00103.
Running sample #1 for PoomaII CompBrick Implementation:
  N = 100...
### POOMA Assertion Failure ###
### locked_m
### File ..\..\..\..\SRC\Threads/PoomaMutex.h; Line 138.
Pooma::pAbort called.
In default abort handler.
>>>

-assume_aliasing_across_function_calls  (this should make the optimization
more aggressive)

Runs to completion, N=100 correctness value 2.122e-313

-all +favor_fast_code  (/Ot)

Runs to completion, N=100 correctness value 2.122e-313

-all +full_optimization +favor_fast_code  (/Ox /Ot /Oy-)

Runs to completion, N=100 correctness value 2.122e-313

-all +full_optimization +global_optimizations +favor_fast_code  (/Ox /Ot
/Oy-)

Runs to completion, N=100 correctness value 2.122e-313

last +assume_aliasing_across_function_calls

<<<
### POOMA Assertion Failure ###
### locked_m
### File ..\..\..\..\SRC\Threads/PoomaMutex.h; Line 138.
Pooma::pAbort called.
In default abort handler.
>>>

It's behaving as if the sense of this option is reversed from the
description.

I still only have the Debug build producing a correct value for N=100.

Setting optimizations = minimum space (/O1) produces a correct run.

-all +favor_fast_code +improve_floating_point_consistency

This still gives the incorrect result for N=100.  I'm ready to conclude that
the Intel 5.0 optimizer is not to be trusted.  I doubt any of these problems
are Pooma code errors.

Allan



From cummings at linkline.com  Sat Apr 14 18:47:53 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Sat, 14 Apr 2001 11:47:53 -0700
Subject: [pooma-dev] cygwin builds..
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BDC@proxim-sf001.santafe.proximation.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGEEKFCBAA.cummings@linkline.com>

Hi Jim,

I've just checked in a hack to rules.mk that will sidestep
this problem for now.  I put a "-" in front of the cp command,
so that errors will be ignored by make and it will continue.

The problem occurs because we have assumed in the build
system that executable files have no filename extension.
But under cygwin they do have an extension, which is .exe.
The cp command fails because the filenames used are wrong.

I think it is hard to actually fix this problem.  We could define
a make variable for the filename extension add define it as
".exe" under cygwin.  But then we would have to append this
make variable to the name of every executable in every test
code and example code and benchmark code makefile in Pooma.
I believe that would do it, but it's a lot of work and ugliness.

The cp command is there to save each executable in a
PASS-specific file, so that you can build multiple passes
(typically DBG or OPT, with the default being APP) within
the same suite subdirectory.  Seems like overkill, but I think
Blanca used this feature to take advantage of reusing template
instantiation information files from a debug build in a subsequent
optimized build.  The cp is wasteful; I would have done an mv
followed by a symbolic link to the PASS-specific file.

My change at least allows multiple builds to proceed under cygwin.

-- Julian C.


Dr. Julian C. Cummings
Staff Scientist, CACR/Caltech
(626) 395-2543
cummings at cacr.caltech.edu


  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Thursday, April 12, 2001 12:13 PM
  To: 'pooma-dev at pooma.codesourcery.com'
  Subject: [pooma-dev] cygwin builds..


  Has anyone made progress on building under Cygwin? I built the library
(after manually creating the lib/LINUXEGCS directory ? it didn?t get created
by the script and then failed because the directory didn?t exist). But
trying to build an application results in the ?cp: test and test_APP are the
same file? error, which causes the build to abort. (It does build one file,
but the make fails so I?d have to build one test at a time).



  Why does this copy even exist ? I?ve always wondered what it was for.



              Jim



  ---------------------------------------------------

  James A. Crotinger

  Software Research Scientist

  Proximation, LLC



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010414/a5800fae/attachment.html>

From cummings at cacr.caltech.edu  Wed Apr 18 02:34:05 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Tue, 17 Apr 2001 19:34:05 -0700
Subject: question for language gurus
Message-ID: <3ADCFD1D.B8FFA940@cacr.caltech.edu>

Is the code at line 1421 of DynamicLayout.h legit?
This is a templated constructor for DynamicLayoutViewData
that takes a DynamicLayoutView object as its first argument.
The aCC compiler complains about calling member functions
of the DynamicLayoutView argument because the class has
not yet been defined (it is defined further down in the file)
and is thus incomplete.  The aCC compiler swallows the code
if I move this constructor definition outside the class definition
and below the definition of class DynamicLayoutView.

The point of instantiation for this templated constructor clearly
happens later in some other file that is including DynamicLayout.h.
But since DynamicLayoutView is not a templated type, it is not
dependent on the template parameter for the constructor.  So perhaps
this is a legitimate error and the code must be moved out of line and
after the definition of DynamicLayoutView.  Comments?

Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From cummings at cacr.caltech.edu  Wed Apr 18 02:57:07 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Tue, 17 Apr 2001 19:57:07 -0700
Subject: question in Intersector.h
Message-ID: <3ADD0283.F49C2491@cacr.caltech.edu>

The class IntersectorData defined in Intersector.h
has a copy constructor and an assignment operator
defined to just call CTAssert(false).  This is pretty
evil, since it does not compile at all.  Would it be
OK to simply declare the copy constructor and the
assignment operator to be private member functions,
so that no one can call them?  The current code is
giving me grief.

Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From cummings at linkline.com  Wed Apr 18 08:54:17 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Wed, 18 Apr 2001 01:54:17 -0700
Subject: Array size() function
Message-ID: <NEBBLCJDELMDOJLGLNJGCEKMCBAA.cummings@linkline.com>

Hi,

One of the guys at Caltech using Pooma pointed 
out to me that there is no size() function in
the Array interface to return the total number 
of elements.  There is a function length(int d)
that gives the length of axis d.  But for a 1D
Array or a DynamicArray, it seems odd to say
length(0).  The length(int) function is written
using the Domain of the Array, and all Domains
provide a size() function.  So it seems sensible
to add a size() function in Array that would just
pass on the request to the Domain.  Is that OK
with everyone?  We should check that we are 
returning an appropriate size_type, such as long.

Julian C.


Dr. Julian C. Cummings
Staff Scientist, CACR/Caltech
(626) 395-2543
cummings at cacr.caltech.edu
 


From allan at stokes.ca  Wed Apr 18 09:15:22 2001
From: allan at stokes.ca (Allan Stokes)
Date: Wed, 18 Apr 2001 02:15:22 -0700
Subject: HOARD memory allocator
Message-ID: <NABBJEAOKIDHLPHKHPDLOEJPEAAA.allan@stokes.ca>


Hi guys,

This link came to my attention via a mathtools.net bulletin.

ftp://ftp.cs.utexas.edu/pub/emery/papers/asplos2000.pdf

>From the Abstract
<<
Hoard combines one global heap and per-processor heaps with a novel
discipline that provably bounds memory consumption and has very low
synchronization costs in the common case.  Our results on eleven programs
demonstrate that Hoard yields low average fragmentation and improves overall
program performance over the standard Solaris allocator by up to a factor of
60 on 14 processors, and up to a factor of 18 over the next best allocator
we tested.
>>

http://www.cs.utexas.edu/users/emery/hoard/

Available for download under the LGPL.

I noted in an earlier post that the Pooma pool allocator is not doing much
to consider cache line efficiency.  If we wish to revisit allocation
strategies at some point, it would be worth looking at the design of Hoard
in more detail.

Allan





From jcm at lanl.gov  Wed Apr 18 16:25:20 2001
From: jcm at lanl.gov (Jean C. Marshall)
Date: Wed, 18 Apr 2001 10:25:20 -0600
Subject: Views passed into functions do not update properly
Message-ID: <5.0.1.4.2.20010418101923.00a75da0@x-mail.lanl.gov>

Gang:
We have run into a problem in which passing views into a function causes 
the updaters to not be called. Here is an example.
John and Jean

	//======================================================================
	// Function -- QRelations<Traits>::calcEdgeSoundSpeed
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcEdgeSoundSpeed ( const 
ScalarField&  EdgeSoundSpeed,
	                    	   			          const ScalarField&  VertSoundSpeed )
	{
		ENTER("QRelations::calcEdgeSoundSpeed");
		
		int d = getEdgeDirection(EdgeSoundSpeed);
                      // Without this explicit update call, the updaters do 
not get called for VertSoundSpeed
		VertSoundSpeed.update();
		EdgeSoundSpeed(CoarseEdges[d]) =
                        min( 
VertSoundSpeed(CoarseEdges[d]),VertSoundSpeed(EdgeNgbr[d]) );
		
	}           // end function calcEdgeSoundSpeed





From stephens at proximation.com  Wed Apr 18 17:27:14 2001
From: stephens at proximation.com (Stephen Smith)
Date: Wed, 18 Apr 2001 10:27:14 -0700
Subject: [pooma-dev] question in Intersector.h
Message-ID: <F871BB04B0EA224A821A5274C31DF3150216C4@proxim-sf001.santafe.proximation.com>

That change would be fine.  The standard in other
parts of POOMA seems to be to declare them private,
but provide no definition.  If you change it, could
you make the same change in Evaluator/SimpleIntersector.h?

For what it's worth, the C++ standard seems to tell
that code was ok... but I've often seen g++ report
syntax errors in unused member functions of implicitly
instantiated templates before.

    Stephen

-----Original Message-----
From: Julian Cummings [mailto:cummings at cacr.caltech.edu]
Sent: Tuesday, April 17, 2001 8:57 PM
To: pooma-dev at pooma.codesourcery.com
Subject: [pooma-dev] question in Intersector.h


The class IntersectorData defined in Intersector.h
has a copy constructor and an assignment operator
defined to just call CTAssert(false).  This is pretty
evil, since it does not compile at all.  Would it be
OK to simply declare the copy constructor and the
assignment operator to be private member functions,
so that no one can call them?  The current code is
giving me grief.

Julian C.


--
Dr. Julian C. Cummings                       E-mail:
cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010418/4d0087d7/attachment.html>

From oldham at codesourcery.com  Wed Apr 18 20:45:18 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 18 Apr 2001 13:45:18 -0700
Subject: [pooma-dev] Array size() function
In-Reply-To: <NEBBLCJDELMDOJLGLNJGCEKMCBAA.cummings@linkline.com>; from cummings@linkline.com on Wed, Apr 18, 2001 at 01:54:17AM -0700
References: <NEBBLCJDELMDOJLGLNJGCEKMCBAA.cummings@linkline.com>
Message-ID: <20010418134518.A21257@codesourcery.com>

On Wed, Apr 18, 2001 at 01:54:17AM -0700, Julian C. Cummings wrote:
> Hi,
> 
> One of the guys at Caltech using Pooma pointed 
> out to me that there is no size() function in
> the Array interface to return the total number 
> of elements.  There is a function length(int d)
> that gives the length of axis d.  But for a 1D
> Array or a DynamicArray, it seems odd to say
> length(0).  The length(int) function is written
> using the Domain of the Array, and all Domains
> provide a size() function.  So it seems sensible
> to add a size() function in Array that would just
> pass on the request to the Domain.  Is that OK
> with everyone?  We should check that we are 
> returning an appropriate size_type, such as long.

Fine with me.

Jeffrey D. Oldham
oldham at codesourcery.com


From oldham at codesourcery.com  Wed Apr 18 20:53:48 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Wed, 18 Apr 2001 13:53:48 -0700
Subject: [pooma-dev] question for language gurus
In-Reply-To: <3ADCFD1D.B8FFA940@cacr.caltech.edu>; from cummings@cacr.caltech.edu on Tue, Apr 17, 2001 at 07:34:05PM -0700
References: <3ADCFD1D.B8FFA940@cacr.caltech.edu>
Message-ID: <20010418135348.B21257@codesourcery.com>

On Tue, Apr 17, 2001 at 07:34:05PM -0700, Julian Cummings wrote:
> Is the code at line 1421 of DynamicLayout.h legit?
> This is a templated constructor for DynamicLayoutViewData
> that takes a DynamicLayoutView object as its first argument.
> The aCC compiler complains about calling member functions
> of the DynamicLayoutView argument because the class has
> not yet been defined (it is defined further down in the file)
> and is thus incomplete.  The aCC compiler swallows the code
> if I move this constructor definition outside the class definition
> and below the definition of class DynamicLayoutView.
> 
> The point of instantiation for this templated constructor clearly
> happens later in some other file that is including DynamicLayout.h.
> But since DynamicLayoutView is not a templated type, it is not
> dependent on the template parameter for the constructor.  So perhaps
> this is a legitimate error and the code must be moved out of line and
> after the definition of DynamicLayoutView.  Comments?

I prefer to make it compile without complaint.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com


From cummings at cacr.caltech.edu  Wed Apr 18 21:12:55 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Wed, 18 Apr 2001 14:12:55 -0700
Subject: [pooma-dev] question in Intersector.h
References: <F871BB04B0EA224A821A5274C31DF3150216C4@proxim-sf001.santafe.proximation.com>
Message-ID: <3ADE0357.F7000FD8@cacr.caltech.edu>

Hi Stephen,

Stephen Smith wrote:

> That change would be fine.  The standard in other
> parts of POOMA seems to be to declare them private,
> but provide no definition.  If you change it, could
> you make the same change in Evaluator/SimpleIntersector.h?

OK, will do.

> For what it's worth, the C++ standard seems to tell
> that code was ok... but I've often seen g++ report
> syntax errors in unused member functions of implicitly
> instantiated templates before.

Yes, I think the trouble here comes from whether
or not those unused member functions get compiled.

Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From cummings at cacr.caltech.edu  Wed Apr 18 21:25:03 2001
From: cummings at cacr.caltech.edu (Julian Cummings)
Date: Wed, 18 Apr 2001 14:25:03 -0700
Subject: [pooma-dev] question for language gurus
References: <3ADCFD1D.B8FFA940@cacr.caltech.edu> <20010418135348.B21257@codesourcery.com>
Message-ID: <3ADE062F.AFB14A1B@cacr.caltech.edu>

Jeffrey Oldham wrote:

> On Tue, Apr 17, 2001 at 07:34:05PM -0700, Julian Cummings wrote:
> > Is the code at line 1421 of DynamicLayout.h legit?
> > This is a templated constructor for DynamicLayoutViewData
> > that takes a DynamicLayoutView object as its first argument.
> > The aCC compiler complains about calling member functions
> > of the DynamicLayoutView argument because the class has
> > not yet been defined (it is defined further down in the file)
> > and is thus incomplete.  The aCC compiler swallows the code
> > if I move this constructor definition outside the class definition
> > and below the definition of class DynamicLayoutView.
> >
> > The point of instantiation for this templated constructor clearly
> > happens later in some other file that is including DynamicLayout.h.
> > But since DynamicLayoutView is not a templated type, it is not
> > dependent on the template parameter for the constructor.  So perhaps
> > this is a legitimate error and the code must be moved out of line and
> > after the definition of DynamicLayoutView.  Comments?
>
> I prefer to make it compile without complaint.
>
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com

Well, OK.  But I don't know if any other compilers besides aCC are
annoyed by this.  I was really asking whether the code structure here
is legal or not.  BTW, I found another case of this sort of thing in
TensorElements.h.  There is a class Unwritable that is forward declared,
and then defined later on.  Before the definition of Unwritable, there
is a class template defined that uses the Unwritable constructor to
create and return an Unwritable object.  aCC complains unless the
definition of Unwritable is moved ahead of this class template definition.

Even if it is technically legal, would it be OK with folks to do this
amount of modest code reordering, so that a class definition is seen
before an object of the class is used in a class or function template?

Julian C.


--
Dr. Julian C. Cummings                       E-mail: cummings at cacr.caltech.edu
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125





From JimC at proximation.com  Wed Apr 18 22:01:11 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 18 Apr 2001 15:01:11 -0700
Subject: [pooma-dev] HOARD memory allocator
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BE7@proxim-sf001.santafe.proximation.com>

I believe Suvas and Sung looked at Hoard back when we were at LANL. Can't
remember the details, but there was something about it that they didn't
like. Suvas played with a modified version of GLIBC's malloc that maintained
a heap per processor, but I don't believe that was ever enabled in a release
version of SMARTS. 

We've been relying on first-touch and affinity settings to give us locality
(when using threads), but we know there are tons of problems with this. 
	
	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

-----Original Message-----
From: Allan Stokes [mailto:allan at stokes.ca]
Sent: Wednesday, April 18, 2001 3:15 AM
To: Poomadev
Subject: [pooma-dev] HOARD memory allocator


Hi guys,

This link came to my attention via a mathtools.net bulletin.

ftp://ftp.cs.utexas.edu/pub/emery/papers/asplos2000.pdf

>From the Abstract
<<
Hoard combines one global heap and per-processor heaps with a novel
discipline that provably bounds memory consumption and has very low
synchronization costs in the common case.  Our results on eleven programs
demonstrate that Hoard yields low average fragmentation and improves overall
program performance over the standard Solaris allocator by up to a factor of
60 on 14 processors, and up to a factor of 18 over the next best allocator
we tested.
>>

http://www.cs.utexas.edu/users/emery/hoard/

Available for download under the LGPL.

I noted in an earlier post that the Pooma pool allocator is not doing much
to consider cache line efficiency.  If we wish to revisit allocation
strategies at some point, it would be worth looking at the design of Hoard
in more detail.

Allan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010418/145fe731/attachment.html>

From JimC at proximation.com  Wed Apr 18 22:04:52 2001
From: JimC at proximation.com (James Crotinger)
Date: Wed, 18 Apr 2001 15:04:52 -0700
Subject: [pooma-dev] question in Intersector.h
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BE8@proxim-sf001.santafe.proximation.com>


> Yes, I think the trouble here comes from whether
> or not those unused member functions get compiled.

If these are member functions of a templated class, then unused member
functions should not be implicitly instantiated. I'm sure there are plenty
of places where this would cause problems (we've run into a number of these
when we try explicitly instantiating certain classes, which does instantiate
everything).
	Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010418/4a0a0e99/attachment.html>

From JimC at proximation.com  Thu Apr 19 15:52:55 2001
From: JimC at proximation.com (James Crotinger)
Date: Thu, 19 Apr 2001 08:52:55 -0700
Subject: FW: gcc/stl question
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BEA@proxim-sf001.santafe.proximation.com>

Mark suggested continuing this discussion on pooma-dev.

Mark, does this mean that

  vector<int> a(10,5);

will select the template constructor (since 10 is not an unsigned int)? I
could have sworn that special things were supposed to be done to make this
do what people expected it to do, and I just figured that the pointer case
would be similarly handled. 

(BTW, is my recollection correct that I can safely leave the initialization
off in the test below - vector always initializes its memory with the
default constructor, right?)

	Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

-----Original Message-----
From: Mark Mitchell [mailto:mark at codesourcery.com]
Sent: Thursday, April 19, 2001 9:44 AM
To: JimC at proximation.com
Subject: Re: gcc/stl question


  Mark, should the following code work:

  #include <vector>
  using std::vector;

  struct Foo { };

  void main()
  {
    vector<Foo*> table(100,0);
  }

No, that code is broken.

The problem is that there are two relevant constructors required by
the standard:

    explicit vector(size_type n, const T& value = T(),
          const Allocator& = Allocator());
    template <class InputIterator>
    vector(InputIterator first, InputIterator last,
        const Allocator& = Allocator());


The template clearly matches, with InputIterator = `int'.

The other case requires two conversionts "int -> size_t" and "int ->
Foo*".  Those are both "Promotions" according to the overloading
rules, as opposed to "Exact Matches", so the template case wins.

  BTW, does gcc's STL not have a vector<T*> specialization that implements
  everything with a void*? I thought this was fairly common, but the above
  makes it look like it is instantiating things specific for Foo*.

You're correct on both points.  GCC's implementation could/should be
optimized to ue less code space by collapsing some common types in
this way.

By the way, you might as well ask these questions on pooma-dev; I bet
you're not the only one that would benefit from picking up a few more
bits of C++ arcana.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010419/3419a534/attachment.html>

From johnharveyhall at qwest.net  Fri Apr 20 05:22:31 2001
From: johnharveyhall at qwest.net (John Hall)
Date: Thu, 19 Apr 2001 23:22:31 -0600
Subject: Metrowerks and template member functions
Message-ID: <v04220800b70577fa26eb@[10.0.1.13]>

Pooma gang:
Apparently, Metrowerks has a problem with template member functions 
of partially specialized classes inheriting from a partially 
specialized base class being defined external to the class 
declaration. As a result, some code checked in last week caused 
Interval.h, Range.h and Grid.h to stop compiling. Here are versions 
that compile under Metrowerks and should be identical in 
functionality.

Could someone look these over and if they are OK check them in?
John Hall
-------------- next part --------------
// -*- C++ -*-
// ACL:license
// ----------------------------------------------------------------------
// This software and ancillary information (herein called "SOFTWARE")
// called POOMA (Parallel Object-Oriented Methods and Applications) is
// made available under the terms described here.  The SOFTWARE has been
// approved for release with associated LA-CC Number LA-CC-98-65.
//
// Unless otherwise indicated, this SOFTWARE has been authored by an
// employee or employees of the University of California, operator of the
// Los Alamos National Laboratory under Contract No. W-7405-ENG-36 with
// the U.S. Department of Energy.  The U.S. Government has rights to use,
// reproduce, and distribute this SOFTWARE. The public may copy, distribute,
// prepare derivative works and publicly display this SOFTWARE without
// charge, provided that this Notice and any statement of authorship are
// reproduced on all copies.  Neither the Government nor the University
// makes any warranty, express or implied, or assumes any liability or
// responsibility for the use of this SOFTWARE.
//
// If SOFTWARE is modified to produce derivative works, such modified
// SOFTWARE should be clearly marked, so as not to confuse it with the
// version available from LANL.
//
// For more information about POOMA, send e-mail to pooma at acl.lanl.gov,
// or visit the POOMA web page at http://www.acl.lanl.gov/pooma/.
// ----------------------------------------------------------------------
// ACL:license

#ifndef POOMA_DOMAIN_GRID_H
#define POOMA_DOMAIN_GRID_H

//-----------------------------------------------------------------------------
// Class:
// Grid<int Dim>
//-----------------------------------------------------------------------------

//////////////////////////////////////////////////////////////////////

//-----------------------------------------------------------------------------
// Overview:
// Grid is a general type of integer domain, which refers to a set of points
// a0, a1, ... aN for each dimension.  The points can be any ascending or
// descending sequence, there is no fixed stride.  This is basically a set
// of Dim IndirectionList<int>'s, one for each dimension; the total domain
// is the tensor product of these lists.  Grid<Dim> is basically an array
// of Grid<1> objects.
//
// Grid defers most of its implementation to the Domain<DomainTraits<Grid>>
// base class.
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
// Typedefs:
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
// Includes:
//-----------------------------------------------------------------------------

#include "Domain/Domain.h"
#include "Domain/DomainTraits.Grid.h"
#include "Domain/NewDomain.h"
#include "Domain/Loc.h"        // needed for use of operator<<
#include <iosfwd>


//-----------------------------------------------------------------------------
// Forward Declarations:
//-----------------------------------------------------------------------------


//-----------------------------------------------------------------------------
//
// Full Description of Grid:
//
// Grid<N> is a domain representing a set of N numeric sequences, one
// for each dimension N.  The sequences are lists of ascending or descending
// numbers, but without any fixed stride - the list for each dimension is
// an IndirectionList<int>.  It does not have any concept of loop variables,
// however, like Index does, so it cannot be used in any kind of tensor-like
// expression.
//
// You can construct a Grid object using other domain objects.
// The constructors accept up to 7 domain objects of various types.
// Domain types are, for example, Loc, Grid, Interval. int may also be used
// in the constructor for Grid; it acts like a Loc<1> object
// in that context.  The domain arguments for the Grid
// constructors are combined together to form a single domain object with
// a dimension equal to the sum of the arguments dimensions; for example,
// if you try to create a Grid<3> from a Loc<2> and an Interval<1>, e.g.
//   Grid<3> a(Loc<2>(1,2), Interval<1>(3,5));
// the Loc<2> and Interval arguments are combined into a (2+1=3) dimensional
// domain object, used to initialize the Grid<3>.  The number of dimensions
// for the arguments must be <= number of dimensions of the newly constructed
// Grid.
//
// Grid, unlike other domain objects, can also be constructed with
// IndirectionList objects.  IndirectionList's look like 1D domain objects
// to the constructor of Grid, so multiple lists can be used.  Grid's can
// also be used in this same way to construct other Grid's.
//
// For Grid<1>, the list of constructors includes the following:
//   Grid<1> a() - default constructor, which creates an EMPTY Grid
//   Grid<1> a(n) - sets the Grid to the sequence [0 ... (n-1)], stride 1
//   Grid<1> a(m,n) - sets the Grid to the sequence [m ... n], stride 1 or -1
//   Grid<1> a(m,n,s) - sets the Grid to the sequence [m ... n], stride s
//
// The default Grid<1> constructor initializes the Grid to be empty,
// that is, to have a length() of zero.  In that case, the endpoints are
// undefined, as is any operation involving the Grid.
//
// In addition to the constructors, Grid has the following public
// interface, similar to all domain objects.  There are two classes of
// interface methods, one class which includes methods which any Grid<N>
// object has, regardless of dimensions, the other class which includes extra
// interface methods that are available for just Grid<1> objects.
//
// Grid<N> interface:
// -------------------
//   long size() - return the 'volume' of the domain, which is the product
//      of the lenghts of the N 1D Grids
//   bool empty() - return if any of the Grid<1> objects have length == 0
//   Grid<1> operator[](int N) - return the Nth Grid<1> in a
//      multidimensional Grid<M>.  For Grid<1> objects, this just
//      returns the object back.
//   comparison operators: <, >, !=, ==, <=, >= : compare a Grid<N> to
//      another domain object.  The compared domains must have the same
//      number of dimensions.
//   arithmetic accumulation operators +=, -=, *=, /= : add or substract in a
//      given domain.  The added domain must have the same number of
//      dimensions, or a dimension of 1 (in which case, the same value
//      is used for all dimensions), and be known to be single-valued (which
//      is true for Loc and int's).  Note that for Grid, *= and /= ARE
//      allowed, since Grid can have its stride changed at run time.  *=
//      and /= result in scaling of the endpoints and stride, which leaves
//      the length (and size) the same.  += and -= shift the beginning
//      endpoints by the given values, also leaving the length and size the
//      same.  Negation of a Grid negates the endpoints and stride.
//   binary arithmethic operators +, -, *, / : for + and -, adding a Grid
//      to another Loc or int returns a new Grid.  For * and /, scaling
//      by a Loc or int also returns a Grid object, since the stride may
//      change.
//   increment/decrement operator ++, -- : only prefix versions of ++ and --
//      are provided; they act just like += 1 and -= 1 operations.
//
// Grid<1> interface:
// -------------------
//   all of the methods for Grid<N> are also available for Grid<1>. Plus:
//   int length() - number of elements (including endpoints) of the domain.
//     for a non-unit-stride Grid, the length refers to the number of
//     strided points (including the endpoints), NOT the difference between
//     the first and last endpoint.  That is, length = (end-beg)/stride + 1,
//     NOT (end-beg) + 1.
//   int first() - the beginning endpoint.
//   int last() - the ending endpoint.
//   int min(), int max() - min or max of the endpoints.
//   Interval<1>::iterator begin() and end() - return iterators for the 1D
//      domain.  These act like (at least) bidirectional iterators.
//
// For the special case of Grid<1>, there is a specialization given
// after the general case that has different constructors.
//
// Grid inherits much of its activity from Domain<DomainTraits<Grid>>
//
//-----------------------------------------------------------------------------

template<int Dim>
class Grid : public Domain<Dim, DomainTraits<Grid<Dim> > >
{
   // convenience typedefs
   typedef DomainTraits< Grid<Dim> >             DT_t;
   typedef Domain<Dim, DT_t>                     Base_t;

public:
   // Typedefs from parent class and DomainTraits

   typedef typename Base_t::iterator             iterator;
   typedef typename Base_t::const_iterator       const_iterator;
   typedef typename Base_t::blockIterator        blockIterator;
   typedef typename Base_t::const_blockIterator  const_blockIterator;

   typedef typename DT_t::Element_t            Element_t;
   typedef typename DT_t::Domain_t             Domain_t;
   typedef typename DT_t::OneDomain_t          OneDomain_t;
   typedef typename DT_t::BlockDomain_t        BlockDomain_t;
   typedef typename DT_t::AskDomain_t          AskDomain_t;
   typedef typename DT_t::AddResult_t          AddResult_t;
   typedef typename DT_t::MultResult_t         MultResult_t;
   typedef typename DT_t::Storage_t            Storage_t;

   // duplicate static data from traits class

   static const bool domain          = DT_t::domain;
   static const int  dimensions      = DT_t::dimensions;
   static const int  sliceDimensions = DT_t::sliceDimensions;
   static const bool loopAware       = DT_t::loopAware;
   static const bool singleValued    = DT_t::singleValued;
   static const bool unitStride      = DT_t::unitStride;
   static const bool wildcard        = DT_t::wildcard;

   //
   // Constructors.
   //

   // default constructor : initialize to an empty domain
   Grid() { }

   // copy constructor
   Grid(const Grid<Dim> &a) {
     NewDomain1<Grid<Dim> >::fill(*this, a);
   }

   // templated constructors, taking from 1 to 7 different domain objects
   // (or integers).
   template<class T1>
   explicit Grid(const T1 &a) {
     NewDomain1<T1>::fill(*this, a);
   }

   template<class T1, class T2>
   Grid(const T1 &a, const T2 &b) {
     NewDomain2<T1,T2>::fill(*this, a, b);
   }

   template<class T1, class T2, class T3>
   Grid(const T1 &a, const T2 &b, const T3 &c) {
     NewDomain3<T1,T2,T3>::fill(*this, a, b, c);
   }

   template<class T1, class T2, class T3, class T4>
   Grid(const T1 &a, const T2 &b, const T3 &c, const T4 &d) {
     NewDomain4<T1,T2,T3,T4>::fill(*this, a, b, c, d);
   }

   template<class T1, class T2, class T3, class T4, class T5>
   Grid(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e) {
     NewDomain5<T1,T2,T3,T4,T5>::fill(*this, a, b, c, d, e);
   }

   template<class T1, class T2, class T3, class T4, class T5,
            class T6>
   Grid(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e,
        const T6 &f) {
     NewDomain6<T1,T2,T3,T4,T5,T6>::fill(*this, a, b, c, d, e, f);
   }

   template<class T1, class T2, class T3, class T4, class T5,
            class T6, class T7>
   Grid(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e,
        const T6 &f, const T7 &g) {
     NewDomain7<T1,T2,T3,T4,T5,T6,T7>::fill(*this, a, b, c, d, e, f, g);
   }

   //
   // Destructor.  For this class there is nothing to do.
   //

   ~Grid() {
     for (int i=0;i<Dim;++i)
       operator[](i).~OneDomain_t();
   }

   //
   // operator=, templated to allow assignment from other domain objects
   // this uses the same mechanism as the constructors to fill in to this
   // object the data from the given object.  If the new object has too
   // few dimensions, this will only change the first M dimensions of this
   // object, where M is the number of dimensions for newdom
   //

   template<class T>
   Grid<Dim> &operator=(const T &newdom) {
     return NewDomain1<T>::fill(*this, newdom);
   }

   Grid<Dim> &operator=(const Grid<Dim> &newdom) {
     return NewDomain1<Grid<Dim> >::fill(*this, newdom);
   }

   //
   // I/O/
   //

   // print a Grid<N> to a stream, in the format
   //   "[" value1,value2,...,valueN "]"

   template<class Out>
   void print(Out &o) const {
     iterator p    = begin();
     iterator pend = end();
     o << "[";
     while (p != pend)
       {
	o << *p;
	++p;
	if (p != pend)
	  o << ",";
       }
     o << "]";
   }

protected:

private:

};


//-----------------------------------------------------------------------------
//
// Full Description of Grid<1>:
//
// Grid<1> is a 1D specialization of Grid<N>; for the 1D case,
// there are only a restricted set of constructors available.
// For the special case of Grid<1>, the following constructors
// are defined:
//   Grid<1> a() - default constructor, which creates an EMPTY Grid
//   Grid<1> a(n) - sets the Grid to the sequence [0 ... (n-1)], stride 1
//   Grid<1> a(m,n) - sets the Grid to the sequence [m ... n], stride 1 or -1
//   Grid<1> a(m,n,s) - sets the Grid to the sequence [m ... n], stride s
//   Grid<1> a(Domain d) : a Grid copied from d, which must be a
//     1D domain object.
//
//-----------------------------------------------------------------------------

template<>
class Grid<1> : public Domain<1, DomainTraits<Grid<1> > >
{
   // convenience typedef
   typedef DomainTraits< Grid<1> >  DT_t;

public:
   // typedefs from DomainTraits

   typedef DT_t::Element_t            Element_t;
   typedef DT_t::Domain_t             Domain_t;
   typedef DT_t::OneDomain_t          OneDomain_t;
   typedef DT_t::BlockDomain_t        BlockDomain_t;
   typedef DT_t::AskDomain_t          AskDomain_t;
   typedef DT_t::AddResult_t          AddResult_t;
   typedef DT_t::MultResult_t         MultResult_t;
   typedef DT_t::Storage_t            Storage_t;

   // duplicate static data from traits class

   static const bool domain          = DT_t::domain;
   static const int  dimensions      = DT_t::dimensions;
   static const int  sliceDimensions = DT_t::sliceDimensions;
   static const bool loopAware       = DT_t::loopAware;
   static const bool singleValued    = DT_t::singleValued;
   static const bool unitStride      = DT_t::unitStride;
   static const bool wildcard        = DT_t::wildcard;

   //
   // Constructors.
   //

   // default constructor
   Grid() { }

   // copy constructor
   Grid(const Grid<1> &a) {
     NewDomain1<Grid<1> >::fill(*this, a);
   }

   // general argument constructor, to copy from a different domain type
   template<class T1>
   explicit Grid(const T1 &a) {
     NewDomain1<T1>::fill(*this, a);
   }

   // initialize from a single scalar.  must specialize to all scalars.
   Grid(char a) {
     PAssert(a != 0);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - 1);
   }
   Grid(unsigned char a) {
     PAssert(a != 0);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - 1);
   }
   Grid(short a) {
     PAssert(a != 0);
     short s = (a < 0 ? -1 : 1);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - s);
   }
   Grid(unsigned short a) {
     PAssert(a != 0);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - 1);
   }
   Grid(int a) {
     PAssert(a != 0);
     int s = (a < 0 ? -1 : 1);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - s);
   }
   Grid(unsigned int a) {
     PAssert(a != 0);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - 1);
   }
   Grid(long a) {
     PAssert(a != 0);
     long s = (a < 0 ? -1 : 1);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - s);
   }
   Grid(unsigned long a) {
     PAssert(a != 0);
     DomainTraits<Grid<1> >::setDomain(domain_m, 0, a - 1);
   }

   // initialize from a set of endpoints: sets range to [m ..n].
   // domain_m is the domain information storage kept in the base class.
   template<class T1, class T2>
   Grid(const T1 &m, const T2 &n) {
     DomainTraits<Grid<1> >::setDomain(domain_m, m, n);
   }

   // initialize from a set of endpoints and with a given stride.
   // domain_m is the domain information storage kept in the base class.
   template<class T1, class T2, class T3>
   Grid(const T1 &m, const T2 &n, const T3 &s) {
     DomainTraits<Grid<1> >::setDomain(domain_m, m, n, s);
   }

   //
   // Destructor.  For this class there is nothing to do.
   //

   ~Grid() { }

   //
   // operator=, templated to allow assignment from other domain objects
   // this uses the same mechanism as the constructors to fill in to this
   // object the data from the given object.  If the new object has too
   // few dimensions, this will only change the first M dimensions of this
   // object, where M is the number of dimensions for newdom
   //

   template<class T>
   Grid<1> &operator=(const T &newdom) {
     return NewDomain1<T>::fill(*this, newdom);
   }

   Grid<1> &operator=(const Grid<1> &newdom) {
     return NewDomain1<Grid<1> >::fill(*this, newdom);
   }

   //
   // A special function used to initialize one Grid from another.  For
   // this, we need non-modifiable access to the storage.
   //

   const Storage_t &storage() const { return domain_m; }

   //
   // I/O/
   //

   // print a Grid<N> to a stream, in the format
   //   "[" value1,value2,...,valueN "]"

   template<class Out>
   void print(Out &o) const {
     iterator p    = begin();
     iterator pend = end();
     o << "[";
     while (p != pend)
       {
	o << *p;
	++p;
	if (p != pend)
	  o << ",";
       }
     o << "]";
   }
};

//////////////////////////////////////////////////////////////////////
//
// print a Grid<N> to a stream, in the format
//   "[" value1,value2,...,valueN "]"
//
//////////////////////////////////////////////////////////////////////

template<int Dim>
std::ostream& operator<<(std::ostream &o, const Grid<Dim> &grid)
{
   grid.print(o);
   return o;
}

//////////////////////////////////////////////////////////////////////
//
// Specialization of the CHEETAH Serialize class for Grid<1>.
//
//////////////////////////////////////////////////////////////////////

#if POOMA_CHEETAH

#include "Cheetah/Cheetah.h"

namespace Cheetah {

template<>
class Serialize<CHEETAH, Grid<1> >
{
public:

   typedef Grid<1>                    Grid_t;
   typedef Grid_t::Element_t          Element_t;
   typedef IndirectionList<Element_t> List_t;

   static inline long
   size(const Grid_t &a)
   {
     return sizeof(int) + a.length() * sizeof(Element_t);
   }

   static inline int
   pack(const Grid_t &a, char *buffer)
   {
     *reinterpret_cast<int *>(buffer) = a.length();

     long length = a.length() * sizeof(Element_t);

     memcpy(buffer + sizeof(int), &a.storage()(0), length);

     return sizeof(int) + length;
   }

   static inline int
   unpack(Grid_t* &a, char *buffer)
   {
     int length = *reinterpret_cast<int *>(buffer);

     List_t list(length);

     length *= sizeof(Element_t);

     memcpy(&list(0), buffer + sizeof(int), length);

     a = new Grid_t(list);

     return sizeof(int) + length;
   }

   static inline void
   cleanup(Grid_t* a)
   {
     delete a;
   }
};

} // namespace Cheetah

#endif     // POOMA_CHEETAH

#endif     // POOMA_DOMAIN_GRID_H

// ACL:rcsinfo
// ----------------------------------------------------------------------
// $RCSfile: Grid.h,v $   $Author: cummings $
// $Revision: 1.11 $   $Date: 2001/04/13 02:12:59 $
// ----------------------------------------------------------------------
// ACL:rcsinfo
-------------- next part --------------
// -*- C++ -*-
// ACL:license
// ----------------------------------------------------------------------
// This software and ancillary information (herein called "SOFTWARE")
// called POOMA (Parallel Object-Oriented Methods and Applications) is
// made available under the terms described here.  The SOFTWARE has been
// approved for release with associated LA-CC Number LA-CC-98-65.
//
// Unless otherwise indicated, this SOFTWARE has been authored by an
// employee or employees of the University of California, operator of the
// Los Alamos National Laboratory under Contract No. W-7405-ENG-36 with
// the U.S. Department of Energy.  The U.S. Government has rights to use,
// reproduce, and distribute this SOFTWARE. The public may copy, distribute,
// prepare derivative works and publicly display this SOFTWARE without
// charge, provided that this Notice and any statement of authorship are
// reproduced on all copies.  Neither the Government nor the University
// makes any warranty, express or implied, or assumes any liability or
// responsibility for the use of this SOFTWARE.
//
// If SOFTWARE is modified to produce derivative works, such modified
// SOFTWARE should be clearly marked, so as not to confuse it with the
// version available from LANL.
//
// For more information about POOMA, send e-mail to pooma at acl.lanl.gov,
// or visit the POOMA web page at http://www.acl.lanl.gov/pooma/.
// ----------------------------------------------------------------------
// ACL:license

#ifndef POOMA_DOMAIN_INTERVAL_H
#define POOMA_DOMAIN_INTERVAL_H

//-----------------------------------------------------------------------------
// Class:
// Interval<int>
//-----------------------------------------------------------------------------

//////////////////////////////////////////////////////////////////////

//-----------------------------------------------------------------------------
// Overview:
// Interval is a very simple type of domain, which refers to a set of points
// a, a+1, a+2, ..., b.  It has a hard-coded stride of 1.  Interval<N>
// is basically an array of Interval<1> objects.
//
// Interval defers most of its implementation to the
// Domain<DomainTraits<Interval>> base class.
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
// Typedefs:
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
// Includes:
//-----------------------------------------------------------------------------

#include "Domain/Domain.h"
#include "Domain/DomainTraits.Interval.h"
#include "Domain/NewDomain.h"
#include "Utilities/NoInit.h"
#include "Utilities/PAssert.h"

//-----------------------------------------------------------------------------
// Forward Declarations:
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
//
// Full Description of Interval:
//
// Interval<N> is a domain representing a set of N numeric sequences, one
// for each dimension N.  The sequences have endpoints [a,b], and a
// hard-coded stride of +1. It does not have any concept of loop variables,
// however, like Index does, so it cannot be used in any kind of tensor-like
// expression.
//
// You can construct an Interval object using other domain objects.
// The constructors accept up to 7 domain objects of various types.
// Domain types are, for example, Loc, Range, Interval. int may also be used
// in the constructor for Interval; it acts like a Loc<1> object
// in that context.  The domain arguments for the Interval
// constructors are combined together to form a single domain object with
// a dimension equal to the sum of the arguments dimensions; for example,
// if you try to create an Interval<3> from a Loc<2> and an Interval<1>, e.g.
//   Interval<3> a(Loc<2>(1,2), Interval<1>(3,5));
// the Loc<2> and Interval arguments are combined into a (2+1=3) dimensional
// domain object, used to initialize the Interval<3>.  The number of dimensions
// for the arguments must be <= number of dimensions of the newly constructed
// Interval.
//
// For Interval<1>, the list of constructors is limited to just the following:
//   Interval<1> a() - default constructor, which creates an EMPTY Interval
//   Interval<1> a(n) - sets the Interval to the sequence [0 ... (n-1)]
//   Interval<1> a(m,n) - sets the Interval to the sequence [m ... n]
//
// The default Interval<1> constructor initializes the Interval to be empty,
// that is, to have a length() of zero.  In that case, the endpoints are
// undefined, as is any operation involving the Interval.
//
// In addition to the constructors, Interval has the following public
// interface, similar to all domain objects.  There are two classes of
// interface methods, one class which includes methods which any Interval<N>
// object has, regardless of dimensions, the other class which includes extra
// interface methods that are available for just Interval<1> objects.
//
// Interval<N> interface:
// ----------------------
//   long size() - return the 'volume' of the domain, which is the product
//      of the lenghts of the N 1D Intervals
//   bool empty() - return if any of the Interval<1> objects have length == 0
//   Interval<1> operator[](int N) - return the Nth Interval<1> in a
//      multidimensional Interval<M>.  For Interval<1> objects, this just
//      returns the object back.
//   comparison operators: <, >, !=, ==, <=, >= : compare an Interval <N> to
//      another domain object.  The compared domains must have the same
//      number of dimensions.
//   arithmetic accumulation operators +=, -= : add or substract in a
//      given domain.  The added domain must have the same number of
//      dimensions, or a dimension of 1 (in which case, the same value
//      is used for all dimensions), and be known to be single-valued (which
//      is true for Loc and int's).  Note that for Interval, *= and /= are NOT
//      allowed, since these operators would change the stride and that is
//      not allowed for Interval (it has a hard-coded stride of 1).
//      The negation operator (operator-) is also NOT allowed for Interval.
//   binary arithmethic operators +, -, *, / : for + and -, adding an Interval
//      to another Loc or int returns a new Interval.  For * and /, scaling
//      by a Loc or int returns a Range object, since the stride may
//      change.
//   increment/decrement operator ++, -- : only prefix versions of ++ and --
//      are provided; they act just like += 1 and -= 1 operations.
//
// Interval<1> interface:
// ----------------------
//   all of the methods for Interval<N> are also available for Interval<1>.
//   int length() - number of elements (including endpoints) of the domain.
//   int first() - the beginning endpoint.
//   int last() - the ending endpoint.
//   int min(), int max() - min or max of the endpoints.
//   Interval<1>::iterator begin() and end() - return iterators for the 1D
//      domain.  These act like (at least) bidirectional iterators.
//
// Interval inherits much of its activity from Domain<DomainTraits<Interval>>.
//
// For the special case of Interval<1>, there is a specialization given
// after the general case that has different constructors (listed above).
//
//-----------------------------------------------------------------------------

template<int Dim>
class Interval : public Domain<Dim, DomainTraits<Interval<Dim> > >
{
   // convenience typedefs
   typedef DomainTraits< Interval<Dim> >         DT_t;
   typedef Domain<Dim, DT_t>                     Base_t;

public:
   // Typedefs from parent class and DoaminTraits

   typedef typename Base_t::iterator             iterator;
   typedef typename Base_t::const_iterator       const_iterator;
   typedef typename Base_t::blockIterator        blockIterator;
   typedef typename Base_t::const_blockIterator  const_blockIterator;

   typedef typename DT_t::Element_t            Element_t;
   typedef typename DT_t::Domain_t             Domain_t;
   typedef typename DT_t::OneDomain_t          OneDomain_t;
   typedef typename DT_t::BlockDomain_t        BlockDomain_t;
   typedef typename DT_t::AskDomain_t          AskDomain_t;
   typedef typename DT_t::AddResult_t          AddResult_t;
   typedef typename DT_t::MultResult_t         MultResult_t;
   typedef typename DT_t::Storage_t            Storage_t;

   // duplicate static data from traits class

   static const bool domain          = DT_t::domain;
   static const int  dimensions      = DT_t::dimensions;
   static const int  sliceDimensions = DT_t::sliceDimensions;
   static const bool loopAware       = DT_t::loopAware;
   static const bool singleValued    = DT_t::singleValued;
   static const bool unitStride      = DT_t::unitStride;
   static const bool wildcard        = DT_t::wildcard;

   //
   // Constructors.
   //

   // default constructor : initialize to an empty domain
   Interval() { }

   // copy constructor
   Interval(const Interval<Dim> &a)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain1<Interval<Dim> >::fill(*this, a);
   }

   // Uninitialized constructor
   Interval(const Pooma::NoInit &a)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(a)
   { }

   // templated constructors, taking from 1 to 7 different domain objects
   // (or integers).
   template<class T1>
   explicit Interval(const T1 &a)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain1<T1>::fill(*this, a);
   }

   template<class T1, class T2>
   Interval(const T1 &a, const T2 &b)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain2<T1,T2>::fill(*this, a, b);
   }

   template<class T1, class T2, class T3>
   Interval(const T1 &a, const T2 &b, const T3 &c)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain3<T1,T2,T3>::fill(*this, a, b, c);
   }

   template<class T1, class T2, class T3, class T4>
   Interval(const T1 &a, const T2 &b, const T3 &c, const T4 &d)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain4<T1,T2,T3,T4>::fill(*this, a, b, c, d);
   }

   template<class T1, class T2, class T3, class T4, class T5>
   Interval(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain5<T1,T2,T3,T4,T5>::fill(*this, a, b, c, d, e);
   }

   template<class T1, class T2, class T3, class T4, class T5,
            class T6>
   Interval(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e,
       const T6 &f)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain6<T1,T2,T3,T4,T5,T6>::fill(*this, a, b, c, d, e, f);
   }

   template<class T1, class T2, class T3, class T4, class T5,
            class T6, class T7>
   Interval(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e,
       const T6 &f, const T7 &g)
     : Domain<Dim, DomainTraits<Interval<Dim> > >(Pooma::NoInit()) {
     NewDomain7<T1,T2,T3,T4,T5,T6,T7>::fill(*this, a, b, c, d, e, f, g);
   }

   //
   // Destructor.  For this class there is nothing to do.
   //

   ~Interval() { }

   //
   // operator=, templated to allow assignment from other domain objects
   // this uses the same mechanism as the constructors to fill in to this
   // object the data from the given object.  If the new object has too
   // few dimensions, this will only change the first M dimensions of this
   // object, where M is the number of dimensions for newdom
   //

   template<class T>
   Interval<Dim> &operator=(const T &newdom) {
     return NewDomain1<T>::fill(*this, newdom);
   }

   Interval<Dim> &operator=(const Interval<Dim> &newdom) {
     return NewDomain1<Interval<Dim> >::fill(*this, newdom);
   }

protected:

private:

};


//-----------------------------------------------------------------------------
//
// Full Description of Interval<1>:
//
// Interval<1> is a 1D specialization of Interval<N>; for the 1D case,
// there are only a restricted set of constructors available.
// For the special case of Interval<1>, the following constructors
// are defined:
//   Interval<1> a() - default constructor, which creates an EMPTY Interval
//   Interval<1> a(n) - sets the Interval to the sequence [0 ... (n-1)]
//   Interval<1> a(m,n) - sets the Interval to the sequence [m ... n]
//   Interval<1> a(Domain d) - an Interval copied from d, which must be a
//     1D domain object.
//
//-----------------------------------------------------------------------------

template<>
class Interval<1> : public Domain<1, DomainTraits<Interval<1> > >
{
   // convenience typedef
   typedef DomainTraits< Interval<1> >  DT_t;

public:
   // typedefs from DomainTraits

   typedef DT_t::Element_t            Element_t;
   typedef DT_t::Domain_t             Domain_t;
   typedef DT_t::OneDomain_t          OneDomain_t;
   typedef DT_t::BlockDomain_t        BlockDomain_t;
   typedef DT_t::AskDomain_t          AskDomain_t;
   typedef DT_t::AddResult_t          AddResult_t;
   typedef DT_t::MultResult_t         MultResult_t;
   typedef DT_t::Storage_t            Storage_t;

   // duplicate static data from traits class

   static const bool domain          = DT_t::domain;
   static const int  dimensions      = DT_t::dimensions;
   static const int  sliceDimensions = DT_t::sliceDimensions;
   static const bool loopAware       = DT_t::loopAware;
   static const bool singleValued    = DT_t::singleValued;
   static const bool unitStride      = DT_t::unitStride;
   static const bool wildcard        = DT_t::wildcard;

   //
   // Constructors.
   //

   // default constructor
   Interval() { }

   // copy constructor
   Interval(const Interval<1> &a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     NewDomain1<Interval<1> >::fill(*this, a);
   }

   // Uninitialized constructor
   Interval(const Pooma::NoInit &a)
     : Domain<1, DomainTraits<Interval<1> > >(a)
   { }

   // general argument constructor, to copy from a different domain type
   template<class T1>
   explicit Interval(const T1 &a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     NewDomain1<T1>::fill(*this, a);
   }

   // initialize from a single scalar.  must specialize to all scalars.
   Interval(char a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }
   Interval(unsigned char a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }
   Interval(short a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }
   Interval(unsigned short a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }
   Interval(int a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }
   Interval(unsigned int a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }
   Interval(long a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }
   Interval(unsigned long a)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
     DomainTraits<Interval<1> >::setDomain(domain_m, 0, a - 1);
   }

   // initialize from a set of endpoints: sets interval to [m ..n].  Must
   // have m <= n.
   template<class T1, class T2>
   Interval(const T1 &m, const T2 &n)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit() ) {
         DomainTraits<Interval<1> >::setDomain(domain_m, m, n);
   }


   // initialize from three integers: if the stride is not 1,
   // it is an error.
   template<class T1, class T2, class T3>
   Interval(const T1 &m, const T2 &n, const T3 &s)
     : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
         PAssert(s == 1);
         DomainTraits<Interval<1> >::setDomain(domain_m, m, n);
   }

   //
   // Destructor.  For this class there is nothing to do.
   //

   ~Interval() { }

   //
   // operator=, templated to allow assignment from other domain objects
   // this uses the same mechanism as the constructors to fill in to this
   // object the data from the given object.  If the new object has too
   // few dimensions, this will only change the first M dimensions of this
   // object, where M is the number of dimensions for newdom
   //

   template<class T>
   Interval<1> &operator=(const T &newdom) {
     return NewDomain1<T>::fill(*this, newdom);
   }

   Interval<1> &operator=(const Interval<1> &newdom) {
     return NewDomain1<Interval<1> >::fill(*this, newdom);
   }

};

//////////////////////////////////////////////////////////////////////

#endif     // POOMA_DOMAIN_INTERVAL_H

// ACL:rcsinfo
// ----------------------------------------------------------------------
// $RCSfile: Interval.h,v $   $Author: cummings $
// $Revision: 1.17 $   $Date: 2001/04/13 02:12:59 $
// ----------------------------------------------------------------------
// ACL:rcsinfo
-------------- next part --------------
// -*- C++ -*-
// ACL:license
// ----------------------------------------------------------------------
// This software and ancillary information (herein called "SOFTWARE")
// called POOMA (Parallel Object-Oriented Methods and Applications) is
// made available under the terms described here.  The SOFTWARE has been
// approved for release with associated LA-CC Number LA-CC-98-65.
//
// Unless otherwise indicated, this SOFTWARE has been authored by an
// employee or employees of the University of California, operator of the
// Los Alamos National Laboratory under Contract No. W-7405-ENG-36 with
// the U.S. Department of Energy.  The U.S. Government has rights to use,
// reproduce, and distribute this SOFTWARE. The public may copy, distribute,
// prepare derivative works and publicly display this SOFTWARE without
// charge, provided that this Notice and any statement of authorship are
// reproduced on all copies.  Neither the Government nor the University
// makes any warranty, express or implied, or assumes any liability or
// responsibility for the use of this SOFTWARE.
//
// If SOFTWARE is modified to produce derivative works, such modified
// SOFTWARE should be clearly marked, so as not to confuse it with the
// version available from LANL.
//
// For more information about POOMA, send e-mail to pooma at acl.lanl.gov,
// or visit the POOMA web page at http://www.acl.lanl.gov/pooma/.
// ----------------------------------------------------------------------
// ACL:license

#ifndef POOMA_DOMAIN_RANGE_H
#define POOMA_DOMAIN_RANGE_H

//-----------------------------------------------------------------------------
// Class:
// Range<int>
//-----------------------------------------------------------------------------

//////////////////////////////////////////////////////////////////////

//-----------------------------------------------------------------------------
// Overview:
// Range is a general type of integer domain, which refers to a set of points
// a, a+s, a+2s, ..., b.  It has a run-time specified stride value s.  It
// is basically an array of Range<1> objects.
//
// Range defers most of its implementation to the Domain<DomainTraits<Range>>
// base class.
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
// Typedefs:
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
// Includes:
//-----------------------------------------------------------------------------

#include "Domain/Domain.h"
#include "Domain/DomainTraits.Range.h"
#include "Domain/NewDomain.h"
#include "Utilities/NoInit.h"
#include "Utilities/PAssert.h"

//-----------------------------------------------------------------------------
// Forward Declarations:
//-----------------------------------------------------------------------------

template <int Dim> class Range;

template<int Dim>
inline
void fillRangeScalar(Range<Dim> &r, const int &a);

//-----------------------------------------------------------------------------
//
// Full Description of Range:
//
// Range<N> is a domain representing a set of N numeric sequences, one
// for each dimension N.  The sequences have endpoints [a,b], with a stride
// s. It does not have any concept of loop variables,
// however, like Index does, so it cannot be used in any kind of tensor-like
// expression.
//
// You can construct a Range object using other domain objects.
// The constructors accept up to 7 domain objects of various types.
// Domain types are, for example, Loc, Range, Interval. int may also be used
// in the constructor for Range; it acts like a Loc<1> object
// in that context.  The domain arguments for the Range
// constructors are combined together to form a single domain object with
// a dimension equal to the sum of the arguments dimensions; for example,
// if you try to create a Range<3> from a Loc<2> and an Interval<1>, e.g.
//   Range<3> a(Loc<2>(1,2), Interval<1>(3,5));
// the Loc<2> and Interval arguments are combined into a (2+1=3) dimensional
// domain object, used to initialize the Range<3>.  The number of dimensions
// for the arguments must be <= number of dimensions of the newly constructed
// Range.
//
// For Range<1>, the list of constructors is limited to just the following:
//   Range<1> a() - default constructor, which creates an EMPTY Range
//   Range<1> a(n) - sets the Range to the sequence [0 ... (n-1)], stride 1
//   Range<1> a(m,n) - sets the Range to the sequence [m ... n], stride 1 or -1
//   Range<1> a(m,n,s) - sets the Range to the sequence [m ... n], stride s
//
// The default Range<1> constructor initializes the Range to be empty,
// that is, to have a length() of zero.  In that case, the endpoints are
// undefined, as is any operation involving the Range.
//
// In addition to the constructors, Range has the following public
// interface, similar to all domain objects.  There are two classes of
// interface methods, one class which includes methods which any Range<N>
// object has, regardless of dimensions, the other class which includes extra
// interface methods that are available for just Range<1> objects.
//
// Range<N> interface:
// -------------------
//   long size() - return the 'volume' of the domain, which is the product
//      of the lenghts of the N 1D Ranges
//   bool empty() - return if any of the Range<1> objects have length == 0
//   Range<1> operator[](int N) - return the Nth Range<1> in a
//      multidimensional Range<M>.  For Range<1> objects, this just
//      returns the object back.
//   comparison operators: <, >, !=, ==, <=, >= : compare a Range<N> to
//      another domain object.  The compared domains must have the same
//      number of dimensions.
//   arithmetic accumulation operators +=, -=, *=, /= : add or substract in a
//      given domain.  The added domain must have the same number of
//      dimensions, or a dimension of 1 (in which case, the same value
//      is used for all dimensions), and be known to be single-valued (which
//      is true for Loc and int's).  Note that for Range, *= and /= ARE
//      allowed, since Range can have its stride changed at run time.  *=
//      and /= result in scaling of the endpoints and stride, which leaves
//      the length (and size) the same.  += and -= shift the beginning
//      endpoints by the given values, also leaving the length and size the
//      same.  Negation of a Range negates the endpoints and stride.
//   binary arithmethic operators +, -, *, / : for + and -, adding a Range
//      to another Loc or int returns a new Range.  For * and /, scaling
//      by a Loc or int also returns a Range object, since the stride may
//      change.
//   increment/decrement operator ++, -- : only prefix versions of ++ and --
//      are provided; they act just like += 1 and -= 1 operations.
//
// Range<1> interface:
// -------------------
//   all of the methods for Range<N> are also available for Range<1>. Plus:
//   long length() - number of elements (including endpoints) of the domain.
//     for a non-unit-stride Range, the length refers to the number of
//     strided points (including the endpoints), NOT the difference between
//     the first and last endpoint.  That is, length = (end-beg)/stride + 1,
//     NOT (end-beg) + 1.
//   int first() - the beginning endpoint.
//   int last() - the ending endpoint.
//   int min(), int max() - min or max of the endpoints.
//   Interval<1>::iterator begin() and end() - return iterators for the 1D
//      domain.  These act like (at least) bidirectional iterators.
//
// For the special case of Range<1>, there is a specialization given
// after the general case that has different constructors.
//
// Range inherits much of its activity from Domain<DomainTraits<Range>>
//
//-----------------------------------------------------------------------------

template<int Dim>
class Range : public Domain<Dim, DomainTraits<Range<Dim> > >
{
   // convenience typedefs
   typedef DomainTraits< Range<Dim> >            DT_t;
   typedef Domain<Dim, DT_t>                     Base_t;

public:
   // Typedefs from parent class and DomainTraits

   typedef typename Base_t::iterator             iterator;
   typedef typename Base_t::const_iterator       const_iterator;
   typedef typename Base_t::blockIterator        blockIterator;
   typedef typename Base_t::const_blockIterator  const_blockIterator;

   typedef typename DT_t::Element_t            Element_t;
   typedef typename DT_t::Domain_t             Domain_t;
   typedef typename DT_t::OneDomain_t          OneDomain_t;
   typedef typename DT_t::BlockDomain_t        BlockDomain_t;
   typedef typename DT_t::AskDomain_t          AskDomain_t;
   typedef typename DT_t::AddResult_t          AddResult_t;
   typedef typename DT_t::MultResult_t         MultResult_t;
   typedef typename DT_t::Storage_t            Storage_t;

   // duplicate static data from traits class

   static const bool domain          = DT_t::domain;
   static const int  dimensions      = DT_t::dimensions;
   static const int  sliceDimensions = DT_t::sliceDimensions;
   static const bool loopAware       = DT_t::loopAware;
   static const bool singleValued    = DT_t::singleValued;
   static const bool unitStride      = DT_t::unitStride;
   static const bool wildcard        = DT_t::wildcard;

   //
   // Constructors.
   //

   // default constructor : initialize to an empty domain
   Range() { }

   // copy constructor
   Range(const Range<Dim> &a)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain1<Range<Dim> >::fill(*this, a);
   }

   // Uninitialized constructor
   Range(const Pooma::NoInit &a)
     : Domain<Dim, DomainTraits<Range<Dim> > >(a)
   { }

   // templated constructors, taking from 1 to 7 different domain objects
   // (or integers).
   template<class T1>
   explicit Range(const T1 &a)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain1<T1>::fill(*this, a);
   }

   template<class T1, class T2>
   Range(const T1 &a, const T2 &b)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain2<T1,T2>::fill(*this, a, b);
   }

   template<class T1, class T2, class T3>
   Range(const T1 &a, const T2 &b, const T3 &c)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain3<T1,T2,T3>::fill(*this, a, b, c);
   }

   template<class T1, class T2, class T3, class T4>
   Range(const T1 &a, const T2 &b, const T3 &c, const T4 &d)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain4<T1,T2,T3,T4>::fill(*this, a, b, c, d);
   }

   template<class T1, class T2, class T3, class T4, class T5>
   Range(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain5<T1,T2,T3,T4,T5>::fill(*this, a, b, c, d, e);
   }

   template<class T1, class T2, class T3, class T4, class T5,
            class T6>
   Range(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e,
	const T6 &f)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain6<T1,T2,T3,T4,T5,T6>::fill(*this, a, b, c, d, e, f);
   }

   template<class T1, class T2, class T3, class T4, class T5,
            class T6, class T7>
   Range(const T1 &a, const T2 &b, const T3 &c, const T4 &d, const T5 &e,
	const T6 &f, const T7 &g)
     : Domain<Dim, DomainTraits<Range<Dim> > >(Pooma::NoInit()) {
     NewDomain7<T1,T2,T3,T4,T5,T6,T7>::fill(*this, a, b, c, d, e, f, g);
   }

   //
   // Destructor.  For this class there is nothing to do.
   //

   ~Range() { }

   //
   // operator=, templated to allow assignment from other domain objects
   // this uses the same mechanism as the constructors to fill in to this
   // object the data from the given object.  If the new object has too
   // few dimensions, this will only change the first M dimensions of this
   // object, where M is the number of dimensions for newdom
   //

   template<class T>
   Range<Dim> &operator=(const T &newdom) {
     return NewDomain1<T>::fill(*this, newdom);
   }

   Range<Dim> &operator=(const Range<Dim> &newdom) {
     return NewDomain1<Range<Dim> >::fill(*this, newdom);
   }

   Range<Dim> &operator=(const int a) {
     fillRangeScalar(*this,a);
     return *this;
   }

protected:

private:

};


//-----------------------------------------------------------------------------
//
// Full Description of Range<1>:
//
// Range<1> is a 1D specialization of Range<N>; for the 1D case,
// there are only a restricted set of constructors available.
// For the special case of Range<1>, the following constructors
// are defined:
//   Range<1> a() - default constructor, which creates an EMPTY Range
//   Range<1> a(n) - sets the Range to the sequence [0 ... (n-1)], stride 1
//   Range<1> a(m,n) - sets the Range to the sequence [m ... n], stride 1 or -1
//   Range<1> a(m,n,s) - sets the Range to the sequence [m ... n], stride s
//   Range<1> a(Domain d) : a Range copied from d, which must be a
//     1D domain object.
//
//-----------------------------------------------------------------------------

template<>
class Range<1> : public Domain<1, DomainTraits<Range<1> > >
{
   // convenience typedef
   typedef DomainTraits< Range<1> >  DT_t;

public:
   // typedefs from DomainTraits

   typedef DT_t::Element_t            Element_t;
   typedef DT_t::Domain_t             Domain_t;
   typedef DT_t::OneDomain_t          OneDomain_t;
   typedef DT_t::BlockDomain_t        BlockDomain_t;
   typedef DT_t::AskDomain_t          AskDomain_t;
   typedef DT_t::AddResult_t          AddResult_t;
   typedef DT_t::MultResult_t         MultResult_t;
   typedef DT_t::Storage_t            Storage_t;

   // duplicate static data from traits class

   static const bool domain          = DT_t::domain;
   static const int  dimensions      = DT_t::dimensions;
   static const int  sliceDimensions = DT_t::sliceDimensions;
   static const bool loopAware       = DT_t::loopAware;
   static const bool singleValued    = DT_t::singleValued;
   static const bool unitStride      = DT_t::unitStride;
   static const bool wildcard        = DT_t::wildcard;

   //
   // Constructors.
   //

   // default constructor
   Range() { }

   // copy constructor
   Range(const Range<1> &a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     NewDomain1<Range<1> >::fill(*this, a);
   }

   // Uninitialized constructor
   Range(const Pooma::NoInit &a)
     : Domain<1, DomainTraits<Range<1> > >(a)
   { }

   // general argument constructor, to copy from a different domain type
   template<class T1>
   explicit Range(const T1 &a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     NewDomain1<T1>::fill(*this, a);
   }

   // initialize from a single scalar.  must specialize to all scalars.
   Range(char a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - 1);
   }
   Range(unsigned char a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - 1);
   }
   Range(short a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     short s = (a < 0 ? -1 : 1);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - s);
   }
   Range(unsigned short a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - 1);
   }
   Range(int a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     int s = (a < 0 ? -1 : 1);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - s);
   }
   Range(unsigned int a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - 1);
   }
   Range(long a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     long s = (a < 0 ? -1 : 1);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - s);
   }
   Range(unsigned long a)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
     PAssert(a != 0);
     DomainTraits<Range<1> >::setDomain(domain_m, 0, a - 1);
   }

   // initialize from a set of endpoints: sets range to [m ..n].
   // domain_m is the domain information storage kept in the base class.
   template<class T1, class T2>
   Range(const T1 &m, const T2 &n)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
         DomainTraits<Range<1> >::setDomain(domain_m, m, n);
   }

   // initialize from a set of endpoints and with a given stride.
   // domain_m is the domain information storage kept in the base class.
   template<class T1, class T2, class T3>
   Range(const T1 &m, const T2 &n, const T3 &s)
     : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
         DomainTraits<Range<1> >::setDomain(domain_m, m, n, s);
   }

   //
   // Destructor.  For this class there is nothing to do.
   //

   ~Range() { }

   //
   // operator=, templated to allow assignment from other domain objects
   // this uses the same mechanism as the constructors to fill in to this
   // object the data from the given object.  If the new object has too
   // few dimensions, this will only change the first M dimensions of this
   // object, where M is the number of dimensions for newdom
   //

   template<class T>
   Range<1> &operator=(const T &newdom) {
     return NewDomain1<T>::fill(*this, newdom);
   }

   Range<1> &operator=(const Range<1> &newdom) {
     return NewDomain1<Range<1> >::fill(*this, newdom);
   }

};

template<int Dim>
inline
void fillRangeScalar(Range<Dim> &r, const int &a)
{
   for (int i=0; i < Dim; ++i)
     r[i]=Range<1>(a);
}

//////////////////////////////////////////////////////////////////////

#endif     // POOMA_DOMAIN_RANGE_H

// ACL:rcsinfo
// ----------------------------------------------------------------------
// $RCSfile: Range.h,v $   $Author: cummings $
// $Revision: 1.18 $   $Date: 2001/04/13 02:12:59 $
// ----------------------------------------------------------------------
// ACL:rcsinfo

From mark at codesourcery.com  Fri Apr 20 07:35:31 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Fri, 20 Apr 2001 00:35:31 -0700
Subject: FW: gcc/stl question
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BEA@proxim-sf001.santafe.proximation.com>
References: <F871BB04B0EA224A821A5274C31DF3152BEA@proxim-sf001.santafe.proximation.com>
Message-ID: <20010420003531M.mitchell@codesourcery.com>

>>>>> "James" == James Crotinger <JimC at proximation.com> writes:

    James> Mark, does this mean that

    James>   vector<int> a(10,5);

    James> will select the template constructor (since 10 is not an

Yes, I believe so.  If you write 5U then I think the other construtor
will get called.  The really pathological case is:

  vector<size_t> a((size_t) 10, (size_t) 5);

You get lucky in this case because when two functions match equally
well, the non-template version is preferred.

    James> unsigned int)? I could have sworn that special things were
    James> supposed to be done to make this do what people expected it
    James> to do, and I just figured that the pointer case would be
    James> similarly handled.

There was talk of doing something special at some point in the
standardization process, but I don't think that every came to
anything.

    James> (BTW, is my recollection correct that I can safely leave
    James> the initialization off in the test below - vector always
    James> initializes its memory with the default constructor,
    James> right?)

Right.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From johnharveyhall at qwest.net  Fri Apr 20 16:44:20 2001
From: johnharveyhall at qwest.net (John Hall)
Date: Fri, 20 Apr 2001 10:44:20 -0600
Subject: [pooma-dev] Metrowerks and template member functions
In-Reply-To: <200104200836.AA277217474@mail.linkline.com>
References: <200104200836.AA277217474@mail.linkline.com>
Message-ID: <v04220801b70617253132@[10.0.1.16]>

Sorry guys. Here are the diffs to get these three files coompiling 
under metrowerks 6.1.
John

cvs -z9 diff Interval.h (in directory Macintosh HD:Programming:TCode 
?:Blanca:r2:src:Domain:)
Index: Interval.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/Interval.h,v
retrieving revision 1.17
diff -r1.17 Interval.h
385c385,389
<   Interval(const T1 &m, const T2 &n);
---
>    Interval(const T1 &m, const T2 &n)
>      : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit() ) {
>          DomainTraits<Interval<1> >::setDomain(domain_m, m, n);
>    }
>
390c394,398
<   Interval(const T1 &m, const T2 &n, const T3 &s);
---
>    Interval(const T1 &m, const T2 &n, const T3 &s)
>      : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
>          PAssert(s == 1);
>          DomainTraits<Interval<1> >::setDomain(domain_m, m, n);
>    }
416,434d423
<
< // initialize from a set of endpoints: sets interval to [m ..n].  Must
< // have m <= n.
< template <class T1, class T2>
< inline
< Interval<1>::Interval(const T1 &m, const T2 &n)
<   : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
<   DomainTraits<Interval<1> >::setDomain(domain_m, m, n);
< }
<
< // initialize from three integers: if the stride is not 1,
< // it is an error.
< template <class T1, class T2, class T3>
< inline
< Interval<1>::Interval(const T1 &m, const T2 &n, const T3 &s)
<   : Domain<1, DomainTraits<Interval<1> > >(Pooma::NoInit()) {
<   PAssert(s == 1);
<   DomainTraits<Interval<1> >::setDomain(domain_m, m, n);
< }

*****CVS exited normally with code 1*****

cvs -z9 diff Range.h (in directory Macintosh HD:Programming:TCode 
?:Blanca:r2:src:Domain:)
Index: Range.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/Range.h,v
retrieving revision 1.18
diff -r1.18 Range.h
415c415,418
<   Range(const T1 &m, const T2 &n);
---
>    Range(const T1 &m, const T2 &n)
>      : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
>          DomainTraits<Range<1> >::setDomain(domain_m, m, n);
>    }
420c423,426
<   Range(const T1 &m, const T2 &n, const T3 &s);
---
>    Range(const T1 &m, const T2 &n, const T3 &s)
>      : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
>          DomainTraits<Range<1> >::setDomain(domain_m, m, n, s);
>    }
446,464d451
<
< // initialize from a set of endpoints: sets range to [m ..n].
< // domain_m is the domain information storage kept in the base class.
< template <class T1, class T2>
< inline
< Range<1>::Range(const T1 &m, const T2 &n)
<   : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
<   DomainTraits<Range<1> >::setDomain(domain_m, m, n);
< }
<
< // initialize from a set of endpoints and with a given stride.
< // domain_m is the domain information storage kept in the base class.
< template <class T1, class T2, class T3>
< inline
< Range<1>::Range(const T1 &m, const T2 &n, const T3 &s)
<   : Domain<1, DomainTraits<Range<1> > >(Pooma::NoInit()) {
<   DomainTraits<Range<1> >::setDomain(domain_m, m, n, s);
< }
<

*****CVS exited normally with code 1*****

cvs -z9 diff Grid.h (in directory Macintosh HD:Programming:TCode 
?:Blanca:r2:src:Domain:)
Index: Grid.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Domain/Grid.h,v
retrieving revision 1.11
diff -r1.11 Grid.h
412c412,414
<   Grid(const T1 &m, const T2 &n);
---
>    Grid(const T1 &m, const T2 &n) {
>      DomainTraits<Grid<1> >::setDomain(domain_m, m, n);
>    }
417c419,421
<   Grid(const T1 &m, const T2 &n, const T3 &s);
---
>    Grid(const T1 &m, const T2 &n, const T3 &s) {
>      DomainTraits<Grid<1> >::setDomain(domain_m, m, n, s);
>    }
471,487d474
<
< // initialize from a set of endpoints: sets range to [m ..n].
< // domain_m is the domain information storage kept in the base class.
< template <class T1, class T2>
< inline
< Grid<1>::Grid(const T1 &m, const T2 &n) {
<   DomainTraits<Grid<1> >::setDomain(domain_m, m, n);
< }
<
< // initialize from a set of endpoints and with a given stride.
< // domain_m is the domain information storage kept in the base class.
< template <class T1, class T2, class T3>
< inline
< Grid<1>::Grid(const T1 &m, const T2 &n, const T3 &s) {
<   DomainTraits<Grid<1> >::setDomain(domain_m, m, n, s);
< }
<

*****CVS exited normally with code 1*****




>John,
>
>Is it possible for you to send diff's of these files?
>Just glancing at them, I can't tell what has been changed.
>
>Thanks, Julian C.
>
>
>
>
>
>---------- Original Message ----------------------------------
>From: John Hall <johnharveyhall at qwest.net>
>Date: Thu, 19 Apr 2001 23:22:31 -0600
>
>  >Pooma gang:
>  >Apparently, Metrowerks has a problem with template member functions
>  >of partially specialized classes inheriting from a partially
>  >specialized base class being defined external to the class
>  >declaration. As a result, some code checked in last week caused
>  >Interval.h, Range.h and Grid.h to stop compiling. Here are versions
>  >that compile under Metrowerks and should be identical in
>  >functionality.
>  >
>  >Could someone look these over and if they are OK check them in?
>  >John Hall
>  >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 6279 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010420/8228254a/attachment.bin>

From scotth at proximation.com  Fri Apr 20 17:38:44 2001
From: scotth at proximation.com (Scott Haney)
Date: Fri, 20 Apr 2001 11:38:44 -0600
Subject: [pooma-dev] Metrowerks and template member functions
In-Reply-To: <v04220801b70617253132@[10.0.1.16]>
Message-ID: <mailman.15.1331172041.20475.pooma-dev@codesourcery.com>

In the immortal words of the venerable Apple MPW C compiler: "These 
changes are a complete surprise to me." :-)

Why were these changes done?

Scott

On Friday, April 20, 2001, at 10:44 AM, John Hall wrote:

> Sorry guys. Here are the diffs to get these three files coompiling under
> metrowerks 6.1.
> John

--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161


From oldham at codesourcery.com  Fri Apr 20 17:47:56 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Fri, 20 Apr 2001 10:47:56 -0700
Subject: Semantics of Field Operations with Different Centerings?
Message-ID: <20010420104756.A6103@codesourcery.com>

Pooma currently permits adding Fields with different centerings.  What
are the desired semantics?  What are the actual semantics?  See also
the attached program.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
// Oldham, Jeffrey D.
// 2001Apr20
// Pooma

#include <iostream>
#include <stdlib.h>
#include <cmath>
#include "Pooma/NewFields.h"

int main(int argc, char *argv[])
{
  // Set up the Pooma library.
  Pooma::initialize(argc,argv);

  // Create a simple layout.
  const unsigned Dim = 2;		// Work in a 2D world.
  const unsigned nHorizVerts = 4;	// number of horizontal vertices
  const unsigned nAngles = 3;		// number of angles
  Interval<Dim> vertexDomain;
  vertexDomain[0] = Interval<1>(nHorizVerts);
  vertexDomain[1] = Interval<1>(nAngles);
  DomainLayout<Dim> layout(vertexDomain, GuardLayers<2>(1));

  // Preparation for Field creation.
  Vector<Dim> origin(0.0);
  Vector<Dim> spacings(1.0,1.0);
  typedef UniformRectilinear<Dim, double, Cartesian<Dim> > Geometry_t;
  typedef Field<Geometry_t, double,      Brick> Fields_t;

  Cell cell;
  Vert vert;
  AllFace allFace;
  Fields_t internalEnergy  (cell, layout, origin, spacings);
  Fields_t coordinates	   (vert, layout, origin, spacings);

  // Initialize the Fields.
  for (unsigned x = 0; x < nHorizVerts; ++x)
    for (unsigned y = 0; y < nAngles; ++y)
      coordinates (x,y) = x+y;
  for (int x = 0; x < nHorizVerts-1; ++x) // Removing "-1" yields different results.
    for (int y = 0; y < nAngles-1; ++y) // Removing "-1" yields different results.
      internalEnergy (x,y) = -(x+y);

  std::cout << "initial internal energy:\n" << internalEnergy << std::endl;
  std::cout << "initial coordinates:\n" << coordinates << std::endl;

  coordinates += internalEnergy; // THE ONLY INTERESTING LINE

  std::cout << "final coordinates:\n" << coordinates << std::endl;
  Pooma::finalize();
  return EXIT_SUCCESS;
}

From cummings at mail.linkline.com  Fri Apr 20 18:48:57 2001
From: cummings at mail.linkline.com (Julian C. Cummings )
Date: Fri, 20 Apr 2001 11:48:57 -0700
Subject: [pooma-dev] Metrowerks and template member functions
Message-ID: <200104201148.AA143852176@mail.linkline.com>

John,

I had to move the definitions for those template constructors
out of the class definition because of an apparent bug in the
aCC compiler on our HP machine here at Caltech.  It complains
because we are accessing the non-static data member "domain_m"
here, which should be perfectly fine.

I made the change under the impression that it would be OK for
other compilers, but it clearly is not.  So go ahead and change
those files as needed for CodeWarrior.  I will just make a note
of the hack required for the HP compiler.  You should report 
the bug in CodeWarrior to Metrowerks, and I will bug HP about
their (numerous) compiler bugs.

Thanks, Julian C.





---------- Original Message ----------------------------------
From: Scott Haney <scotth at proximation.com>
Date: Fri, 20 Apr 2001 11:38:44 -0600

>In the immortal words of the venerable Apple MPW C compiler: "These 
>changes are a complete surprise to me." :-)
>
>Why were these changes done?
>
>Scott
>
>On Friday, April 20, 2001, at 10:44 AM, John Hall wrote:
>
>> Sorry guys. Here are the diffs to get these three files coompiling under
>> metrowerks 6.1.
>> John
>
>--
>Scott W. Haney
>Development Manager
>Proximation LLC
>2960 Rodeo Park Drive West
>Santa Fe, NM 87505
>Voice: 505-424-3809 x101
>FAX: 505-438-4161
>


From mark at codesourcery.com  Fri Apr 20 20:32:27 2001
From: mark at codesourcery.com (Mark Mitchell)
Date: Fri, 20 Apr 2001 13:32:27 -0700
Subject: Status Reports
Message-ID: <20010420133227H.mitchell@codesourcery.com>


Y'all know the drill. :-)

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


From jcm at lanl.gov  Sun Apr 22 00:10:05 2001
From: jcm at lanl.gov (Jean Marshall)
Date: Sat, 21 Apr 2001 18:10:05 -0600
Subject: Scalar code example 1.
Message-ID: <5.0.0.25.2.20010421150958.00a62760@x-mail.lanl.gov>

An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010421/a7c1eb42/attachment.html>
-------------- next part --------------
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
//  CCSource File: QRelations
//  Author:      jcm 
//  Date:        Sat - Nov 18, 2000 
//  Namespace:   conejo
//  Framework:   Tecolote
//  Copyright:   Los Alamos National Laboratory 
//               Full Copyright=$(TECOLOTE_ROOT)/Doc/Copyright
//  RCS_VERSION_ID: $Id: 
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

#if !defined (__MWERKS__)
#include "Demo_src/include/DemoPCH.hh"
#pragma hdrstop
#endif // !__MWERKS__

#include "Demo_src/Model/CompatibleHydro/QRelations.t.hh"

#include "TecFramework_src/MetaTypes/MetaTypes.hh"
#include "TecFramework_src/Foundation/LoadObject.hh"

namespace conejo
{
   using namespace TecFramework;
   using namespace poomalote;
   using namespace Hydrodynamics;
   using namespace PhysicsBaseClasses;
   using namespace std;

   static MetaClass<ITecoloteTraits<QRelations<ThreeDF<DefaultTraits> >,  RelationPkg> >
                QRelations3DMeta("QRelations3D", QRelations<ThreeDF<DefaultTraits> >::MakePersistents());

   LoadObjectGroup QRelations3DBase_cc = { &QRelations3DMeta };

}          // end namespace conejo

namespace TecFramework
{
    using namespace conejo;

    LoadObjectGroup QRelations3D_cc = { &QRelations3DBase_cc };

}    // end namespace TecFramework

-------------- next part --------------
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
//  Source File: QRelations
//  Author:      jcm
//  Date:        Sat - Nov 18, 2000
//  Namespace:   conejo
//  Framework:   Tecolote
//  Copyright:   Los Alamos National Laboratory
//               Full Copyright=$(TECOLOTE_ROOT)/Doc/Copyright
//  RCS_VERSION_ID: $Id:
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


#ifndef  __conejo_QRelations_t_hh
#define  __conejo_QRelations_t_hh

#include "PhysicsBaseClasses_src/HelperClasses/MMField.hh"
#include "Demo_src/Model/CompatibleHydro/QRelations.hh"
#include "Evaluator/ScalarCode.h"

//#define ENTER(a)
#define ENTER(a) tecout << "Entering " << a << endl;

namespace conejo
{
   using namespace TecFramework;
   using namespace poomalote;
   using namespace PhysicsBaseClasses;
   using namespace Hydrodynamics;
   using namespace std;

   const Real spokeCutoff = 1.0e-12; // We get this value from Ed's code

   // $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
   template <class Traits>
   BEGIN_PERSISTENT(QRelations<Traits>)
      PERSISTENT( linearQ,  "LinearQ" )
      PERSISTENT( quadQ,    "QuadQ"   )
   END_PERSISTENT

   //$ linearQ : Real - linear coefficient for Q
   //
   //$ quadQ   : Real - quadratic coefficient for Q
   //
   // $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

    //-----------------------------------------------------------------------------
    // Test function
    //-----------------------------------------------------------------------------
    template<class Traits>
    struct EdgeQPressureInfo
    {
      void scalarCodeInfo(ScalarCodeInfo &info) const
      {
        info.arguments(5);

        info.write(0, true );
        info.write(1, false);
        info.write(2, false);
        info.write(3, false);
        info.write(4, false);
//        info.write(5, false);
//        info.write(6, false);
 //       info.write(7, false);
        info.useGuards(0, false);
        info.useGuards(1, true);
        info.useGuards(2, true);
        info.useGuards(3, true);
        info.useGuards(4, true);
//        info.useGuards(5, true);
//        info.useGuards(6, true);
//        info.useGuards(7, true);

        info.dimensions(Traits::Dim);

        for (int i = 0; i < Traits::Dim; ++i)
        {
          info.lowerExtent(i) = 2;
          info.upperExtent(i) = 2;
        }
      }
    };

    template<class Traits>
    struct ScalarEdgeQPressure
      : public EdgeQPressureInfo<Traits>
    {
      // Typedefs
      FIELD_TYPEDEFS(Traits)

      ScalarEdgeQPressure(const Real& inLinearQ )
        : EdgeQPressureInfo<Traits>(),
          linearQ(inLinearQ)
      {
      }

      template<class F1, class F2, class F3, class F4, class F5>
      void operator()(const F1& EdgeQPressure,     const F2& EdgeGammaConstant, const F3& EdgeSoundSpeed,
                      const F4& EdgeVelocity,      const F5& EdgePsiLimiter,    const Loc<Traits::Dim> &loc)
      {
		if( EdgePsiLimiter(loc) < eps ) {
		    EdgeQPressure(loc) = 0.0;
		    return;
		}

		Real edgeVelocityMagnitude = sqrt(dot(EdgeVelocity(loc),EdgeVelocity(loc)));
		
		EdgeQPressure(loc) = edgeVelocityMagnitude * EdgePsiLimiter(loc) *
		                     (EdgeGammaConstant(loc) * edgeVelocityMagnitude +
		                      sqrt( linearQ * linearQ * EdgeSoundSpeed(loc) * EdgeSoundSpeed(loc) +
		                      EdgeGammaConstant(loc) * EdgeGammaConstant(loc) * edgeVelocityMagnitude * edgeVelocityMagnitude));
      }

    private:
      Real linearQ;
    };

	//======================================================================
	// Constructor -- QRelations<Traits>::QRelations
	//======================================================================

	template <class Traits>
	QRelations<Traits>::QRelations( DataDirectory* pDataDir, const string& inName )
	 :  CompatibleRelations(pDataDir,inName),
	    Old(pDataDir->strictGet<DataDirectory>("CompatibleHydroOld")),
	    linearQ(1.0),
	    quadQ(1.0)
	{
        VectorField& EdgeLength   = DataDir.get<VectorField>( "EdgeLength",   Mesh.getField<VectorField>    ( AllEdge() ) );
	    for(int d=0;d<Dim;++d) {
	        Interval<1> CVert(CoarseVert[d]);
	        RDomain.push_back(CoarseVert);
	        RDomain[d][d] = Interval<1>(CVert.first(),    CVert.last() - 2);
	        LDomain.push_back(CoarseVert);
	        LDomain[d][d] = Interval<1>(CVert.first() + 1,CVert.last() - 1);
	        Loc<Dim> offset(0); offset[d] = 1;
	        RightEdgeNgbr.push_back(RDomain[d]);
	        RightEdgeNgbr[d] += offset;
	        LeftEdgeNgbr.push_back(LDomain[d]);
	        LeftEdgeNgbr[d] -= offset;
	        CoarseEdges.push_back(Range<Dim>(EdgeLength[d].domain()));
	        LowerVert.push_back(CoarseEdges[d]);
	        UpperVert.push_back(CoarseEdges[d] + offset);
	        EdgeNgbr.push_back( Range<Dim>(EdgeLength[d].domain() + offset) );
	    }
	}          // end constructor

	//======================================================================
	// Destructor -- QRelations<Traits>::~QRelations
	//======================================================================

	template <class Traits>
	QRelations<Traits>::~QRelations( ) { }

	//======================================================================
	// Function -- QRelations<Traits>::createRelations
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::createRelations( ) {
		ENTER("QRelations::createRelations");
		
        gammaConst = 2.6666666666666667 * 0.25 * quadQ;

        // Dt is an Independent Constant Field used in Relationships
        ScalarField& Dt                = DataDir.get<ScalarField>( "Dt",                 Mesh.getField<ScalarField>    ( Vert   () ) );

        // -------------------------------------------------------------------------------------------------------------------------
        // Input Fields to QRelations
        // -------------------------------------------------------------------------------------------------------------------------
        ScalarField& OldDt             = Old.get<ScalarField>    ( "Dt",                 Mesh.getField<ScalarField>    ( Vert   () ) );
        VectorField& OldVelocity       = Old.get<VectorField>    ( "Velocity" ,          Mesh.getField<VectorField>    ( Vert   () ) );
        VectorField& OldEdgeLength     = Old.get<VectorField>    ( "EdgeLength" ,        FineMesh.getField<VectorField>( AllEdge() ) );
	    VectorField& OldEdgeVelocity   = Old.get<VectorField>    ( "EdgeVelocity",       Mesh.getField<VectorField>    ( AllEdge() ) );
        ScalarField& Volume            = DataDir.get<ScalarField>( "Volume",             Mesh.getField<ScalarField>    ( Cell   () ) );
        ScalarField& SubVolume         = DataDir.get<ScalarField>( "SubVolume",          FineMesh.getField<ScalarField>( Cell   () ) );
        VectorField& SubFaceAreas      = DataDir.get<VectorField>( "SubFaceAreas" ,      FineMesh.getField<VectorField>( AllFace() ) );
        VectorField& EdgeLength        = DataDir.get<VectorField>( "EdgeLength" ,        FineMesh.getField<VectorField>( AllEdge() ) );
        VectorField& Velocity          = DataDir.get<VectorField>( "Velocity",           Mesh.getField<VectorField>    ( Vert   () ) );
        ScalarField& CellDensity       = DataDir.get<ScalarField>( "CellDensity",        Mesh.getField<ScalarField>    ( Cell   () ) );
        ScalarField& CellSoundSpeedSq  = DataDir.get<ScalarField>( "CellSoundSpeedSq",   Mesh.getField<ScalarField>    ( Cell   () ) );
        ScalarField& CellGammaConstant = DataDir.get<ScalarField>( "CellGammaConstant",  Mesh.getField<ScalarField>    ( Cell   () ) );
        CellGammaConstant = gammaConst; // Should go away when we use more sophisticated EOSs.
        // -------------------------------------------------------------------------------------------------------------------------
		// Store the sqrt because it is used to calculate the VertSoundSpeed
        // -------------------------------------------------------------------------------------------------------------------------
        ScalarField& CellSoundSpeed    = DataDir.get<ScalarField>( "CellSoundSpeed",     Mesh.getField<ScalarField>    ( Cell   () ) );
		
        // -------------------------------------------------------------------------------------------------------------------------
		// Vertex Fields -- (weighted) sums of SubCell Fields
        // -------------------------------------------------------------------------------------------------------------------------
	    ScalarField& VertVolume        = DataDir.get<ScalarField>( "VertVolume",         Mesh.getField<ScalarField>    ( Vert   () ) );
//	    ScalarField& WeightedVertVol   = DataDir.get<ScalarField>( "WeightedVertVol",    Mesh.getField<ScalarField>    ( Vert   () ) );
	    ScalarField& VertDensity       = DataDir.get<ScalarField>( "VertDensity",        Mesh.getField<ScalarField>    ( Vert   () ) );
        ScalarField& VertSoundSpeed    = DataDir.get<ScalarField>( "VertSoundSpeed",     Mesh.getField<ScalarField>    ( Vert   () ) );
	    ScalarField& VertGammaConstant = DataDir.get<ScalarField>( "VertGammaConstant",  Mesh.getField<ScalarField>    ( Vert   () ) );

        // -------------------------------------------------------------------------------------------------------------------------
        // Edge Fields that hold Q-related quantities
        // -------------------------------------------------------------------------------------------------------------------------
	    VectorField& EdgeVelocity      = DataDir.get<VectorField>( "EdgeVelocity",       Mesh.getField<VectorField>    ( AllEdge() ) );
	    ScalarField& EdgeDensity       = DataDir.get<ScalarField>( "EdgeDensity",        Mesh.getField<ScalarField>    ( AllEdge() ) );
	    ScalarField& EdgeQPressure     = DataDir.get<ScalarField>( "EdgeQPressure",      Mesh.getField<ScalarField>    ( AllEdge() ) );
	    ScalarField& EdgeSoundSpeed    = DataDir.get<ScalarField>( "EdgeSoundSpeed",     Mesh.getField<ScalarField>    ( AllEdge() ) );
	    ScalarField& EdgeGammaConstant = DataDir.get<ScalarField>( "EdgeGammaConstant",  Mesh.getField<ScalarField>    ( AllEdge() ) );
	    ScalarField& EdgeQTmpMax       = DataDir.get<ScalarField>( "EdgeQTmpMax",        Mesh.getField<ScalarField>    ( AllEdge() ) );
	    ScalarField& SpokeDVolDt       = DataDir.get<ScalarField>( "SpokeDVolDt",        FineMesh.getField<ScalarField>( AllFace() ) );
	    ScalarField& SpokeQSwitch      = DataDir.get<ScalarField>( "SpokeQSwitch",       FineMesh.getField<ScalarField>( AllFace() ) );

	
        ScalarField& RightLimiterRatio = DataDir.get<ScalarField>( "RightLimiterRatio",  Mesh.getField<ScalarField>    ( AllEdge() ) );
        ScalarField& LeftLimiterRatio  = DataDir.get<ScalarField>( "LeftLimiterRatio",   Mesh.getField<ScalarField>    ( AllEdge() ) );
	    ScalarField& EdgePsiLimiter    = DataDir.get<ScalarField>( "EdgePsiLimiter",     Mesh.getField<ScalarField>    ( AllEdge() ) );
	
        // -------------------------------------------------------------------------------------------------------------------------
        // Output Fields from QRelations
        // -------------------------------------------------------------------------------------------------------------------------
        ScalarField& CellQ             = DataDir.get<ScalarField>( "CellQ",              Mesh.getField<ScalarField>    ( Cell   () ) );
        VectorField& SubForceQ         = DataDir.get<VectorField>( "SubForceQ",          FineMesh.getField<VectorField>( Cell   () ) );
        ScalarField& SubPressureQMod   = DataDir.get<ScalarField>( "SubPressureQMod",    FineMesh.getField<ScalarField>( Cell   () ) );

		Let::NewRelation( *(pParent)this, &Parent::calcSqrt,                 CellSoundSpeed,      CellSoundSpeedSq );
		Let::NewRelation( *(pParent)this, &Parent::calcWeightedVertAvg,      VertSoundSpeed,      CellSoundSpeed,    SubVolume,        VertVolume );
		Let::NewRelation( *(pParent)this, &Parent::calcWeightedVertAvg,      VertGammaConstant,   CellGammaConstant, SubVolume,        VertVolume );

		Let::NewRelation( *this, &QRelations<Traits>::calcEdgeVelocity,      EdgeVelocity,        OldVelocity );
		Let::NewRelation( *this, &QRelations<Traits>::calcEdgeDensity,       EdgeDensity,         VertDensity );
		Let::NewRelation( *this, &QRelations<Traits>::calcEdgeGammaConstant, EdgeGammaConstant,   VertGammaConstant );
		Let::NewRelation( *this, &QRelations<Traits>::calcEdgeQPressure,     EdgeQPressure,       EdgeGammaConstant, EdgeSoundSpeed,   EdgeVelocity, EdgePsiLimiter );
		Let::NewRelation( *this, &QRelations<Traits>::calcEdgeSoundSpeed,    EdgeSoundSpeed,      VertSoundSpeed );
		Let::NewRelation( *this, &QRelations<Traits>::calcEdgeQTmpMax,       EdgeQTmpMax,         EdgeDensity,       EdgeQPressure  );
		Let::NewRelation( *this, &QRelations<Traits>::calcSpokeDVolDt,       SpokeDVolDt,         EdgeVelocity,      SubFaceAreas   );
        Let::NewRelation( *this, &QRelations<Traits>::calcSpokeQSwitch,      SpokeQSwitch,        SpokeDVolDt,       Volume,            OldDt );
		
		Let::NewRelation( *this, &QRelations<Traits>::calcRightLimiterRatio, RightLimiterRatio,   OldEdgeLength,     OldEdgeVelocity );
		Let::NewRelation( *this, &QRelations<Traits>::calcLeftLimiterRatio,  LeftLimiterRatio,    OldEdgeLength,     OldEdgeVelocity );
		Let::NewRelation( *this, &QRelations<Traits>::calcEdgePsiLimiter,    EdgePsiLimiter,      RightLimiterRatio, LeftLimiterRatio, OldEdgeLength, OldEdgeVelocity, OldDt );

		Let::NewRelation( *this, &QRelations<Traits>::calcCellQ,             CellQ,               EdgeQTmpMax,       SpokeQSwitch      );
		Let::NewRelation( *this, &QRelations<Traits>::calcSubForceQ,         SubForceQ,           EdgeQTmpMax,       EdgeVelocity,     SpokeDVolDt,   SpokeQSwitch );
		Let::NewRelation( *this, &QRelations<Traits>::calcSubPressureQMod,   SubPressureQMod,     EdgeQPressure,     SpokeQSwitch      );
		
	}
	

	//======================================================================
	// Function -- QRelations<Traits>::calcEdgeVelocity
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcEdgeVelocity ( const VectorField&  EdgeVelocity,
	                    	   			        const VectorField&  OldVelocity)
	{
		ENTER("QRelations::calcEdgeVelocity");
		int d = getEdgeDirection(EdgeVelocity);
		EdgeVelocity(CoarseEdges[d]) = OldVelocity(EdgeNgbr[d]) - OldVelocity(CoarseEdges[d]);
	}           // end function calcEdgeVelocity
	

	//======================================================================
	// Function -- QRelations<Traits>::calcEdgeDensity
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcEdgeDensity ( const ScalarField&  EdgeDensity,
	                    	   			       const ScalarField&  VertDensity)
	{
		ENTER("QRelations::calcEdgeDensity");
		
		int d = getEdgeDirection(EdgeDensity);
		EdgeDensity(CoarseEdges[d]) = 2.0 * ( VertDensity(CoarseEdges[d]) * VertDensity(EdgeNgbr[d]) ) /
		                                    ( VertDensity(CoarseEdges[d]) + VertDensity(EdgeNgbr[d]) );
	    ScalarField& VertVolume        = DataDir.get<ScalarField>( "VertVolume",         Mesh.getField<ScalarField>    ( Vert   () ) );
	    ScalarField& CellDensity       = DataDir.strictGet<ScalarField>( "CellDensity" );
	}           // end function calcEdgeDensity
	
	//======================================================================
	// Function -- QRelations<Traits>::calcEdgeGammaConstant
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcEdgeGammaConstant ( const ScalarField&  EdgeGammaConstant,
	                    	   			             const ScalarField&  VertGammaConstant)
	{
		ENTER("QRelations::calcEdgeGammaConstant");
		
		int d = getEdgeDirection(EdgeGammaConstant);
		EdgeGammaConstant(CoarseEdges[d]) = 0.5 * ( VertGammaConstant(CoarseEdges[d]) + VertGammaConstant(EdgeNgbr[d]) );
	}           // end function calcEdgeGammaConstant
	
	
	//======================================================================
	// Function -- QRelations<Traits>::calcEdgeQPressure
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcEdgeQPressure ( const ScalarField&  EdgeQPressure,
	                    	   			         const ScalarField&  EdgeGammaConstant,
	                    	   			         const ScalarField&  EdgeSoundSpeed,
	                    	   			         const VectorField&  EdgeVelocity,
 	                    	   			         const ScalarField&  EdgePsiLimiter )
	{
		ENTER("QRelations::calcEdgeQPressure");
		
		int d = getEdgeDirection(EdgeQPressure);
		EdgeGammaConstant[d].update();
		EdgeSoundSpeed[d].update();
		EdgeVelocity[d].update();
		EdgePsiLimiter[d].update();
		
		ScalarEdgeQPressure<Traits> sEdgeQPressure(linearQ);
        ScalarCode<ScalarEdgeQPressure<Traits> > scEdgeQPressure(sEdgeQPressure);

        scEdgeQPressure(EdgeQPressure,EdgeGammaConstant[d], EdgeSoundSpeed[d],EdgeVelocity[d],EdgePsiLimiter[d]);
	}           // end function EdgeQPressure

	//======================================================================
	// Function -- QRelations<Traits>::calcEdgeSoundSpeed
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcEdgeSoundSpeed ( const ScalarField&  EdgeSoundSpeed,
	                    	   			          const ScalarField&  VertSoundSpeed )
	{
		ENTER("QRelations::calcEdgeSoundSpeed");
		
		int d = getEdgeDirection(EdgeSoundSpeed);
		VertSoundSpeed.update();
		EdgeSoundSpeed(CoarseEdges[d]) = min( VertSoundSpeed(CoarseEdges[d]),VertSoundSpeed(EdgeNgbr[d]) );
	}           // end function calcEdgeSoundSpeed


	//======================================================================
	// Function -- QRelations<Traits>::calcEdgeQTmpMax
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcEdgeQTmpMax ( const ScalarField&  EdgeQTmpMax,
	                    	   			       const ScalarField&  EdgeDensity,
	                    	   			       const ScalarField&  EdgeQPressure )
	{
		ENTER("QRelations::calcEdgeQTmpMax");
		int d = getEdgeDirection(EdgeQTmpMax);
		EdgeQTmpMax = EdgeDensity[d] * EdgeQPressure[d];
	}           // end function calcEdgeQTmpMax
	
	//======================================================================
	// Function -- QRelations<Traits>::calcSpokeDVolDt
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcSpokeDVolDt ( const ScalarField&  SpokeDVolDt,
	                    	   			       const VectorField&  EdgeVelocity,
	                    	   			       const VectorField&  SubFaceAreas)
	{
		ENTER("QRelations::calcSpokeDVolDt");
		int d = getFaceDirection(SpokeDVolDt);
		EdgeVelocity[d].update();
		SubFaceAreas[d].update();
	   	for(int edg=0;edg<nEdgesPerDimension;++edg) {
		    SpokeDVolDt(Spoke[d][edg]) = dot(EdgeVelocity[d](CellEdge[d][edg]),SubFaceAreas[d](Spoke[d][edg]));
		}
	}           // end function calcSpokeDVolDt
	
    //======================================================================
	// Function -- QRelations<Traits>::calcSpokeQSwitch
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcSpokeQSwitch ( const ScalarField&  SpokeQSwitch,
	                    	   			   const ScalarField&  SpokeDVolDt,
	                    	   			   const ScalarField&  Volume,
	                    	   			   const ScalarField&  Dt )
	{
		ENTER("QRelations::calcSpokeQSwitch");
		int d = getFaceDirection(SpokeQSwitch);
	   	for(int edg=0;edg<nEdgesPerDimension;++edg) {
		    SpokeQSwitch(Spoke[d][edg]) = (-Dt(CoarseCell) * SpokeDVolDt[d](Spoke[d][edg]))/Volume(CoarseCell);
		}
		SpokeQSwitch = where(SpokeQSwitch > spokeCutoff, 1.0, 0.0);
	}           // end function calcSpokeQSwitch
	
	//======================================================================
	// Function -- QRelations<Traits>::calcRightLimiterRatio
	//======================================================================

	template <class Traits>
    void QRelations<Traits>::calcRightLimiterRatio ( const ScalarField&  RightLimiterRatio,
                                                     const VectorField&  EdgeLength,
                                                     const VectorField&  EdgeVelocity)
	{
		ENTER("QRelations::calcRightLimiterRatio");
		int d = getEdgeDirection(RightLimiterRatio);
        EdgeLength[d].update();
        EdgeVelocity[d].update();
		RightLimiterRatio = 1.0;

		RightLimiterRatio(RDomain[d]) = dot(EdgeLength[d](RightEdgeNgbr[d]),
		                                    EdgeLength[d](RDomain[d]))       *
                                        dot(EdgeVelocity[d](RDomain[d]),
		                                    EdgeVelocity[d](RDomain[d]));

		RightLimiterRatio(RDomain[d]) = where(RightLimiterRatio(RDomain[d]) > numeric_limits<Real>::epsilon(),
                                                (dot(EdgeVelocity[d](RightEdgeNgbr[d]),
                                                     EdgeVelocity[d](RDomain[d]))       *
                                                 dot(EdgeLength[d](RDomain[d]),
                                                     EdgeLength[d](RDomain[d])) ) /
                                               RightLimiterRatio(RDomain[d]),
                                               1.0 );

        //-------------------------------------------------------------
        //  if ( d == 0 ) {
        //  } else if ( d == 1) {
        //     RightLimiterRatio -= 1.0;
        //     tecout << "RightLimiterRatio[1] = " << endl;
        //     tecout << RightLimiterRatio << endl;
        //     RightLimiterRatio += 1.0;
        //  }
        //-------------------------------------------------------------


	}           // end function calcRightLimiterRatio

	//======================================================================
	// Function -- QRelations<Traits>::calcLeftLimiterRatio
	//======================================================================

	template <class Traits>
    void QRelations<Traits>::calcLeftLimiterRatio ( const ScalarField&  LeftLimiterRatio,
                                                    const VectorField&  EdgeLength,
                                                    const VectorField&  EdgeVelocity)
	{
		ENTER("QRelations::calcLeftLimiterRatio");
		int d = getEdgeDirection(LeftLimiterRatio);
        EdgeLength[d].update();
        EdgeVelocity[d].update();
		LeftLimiterRatio = 1.0;

		LeftLimiterRatio(LDomain[d]) = dot(EdgeLength[d](LeftEdgeNgbr[d]),
		                                    EdgeLength[d](LDomain[d]))       *
                                        dot(EdgeVelocity[d](LDomain[d]),
		                                    EdgeVelocity[d](LDomain[d]));

		LeftLimiterRatio(LDomain[d]) = where(LeftLimiterRatio(LDomain[d]) > numeric_limits<Real>::epsilon(),
                                              (dot(EdgeVelocity[d](LeftEdgeNgbr[d]),
                                                    EdgeVelocity[d](LDomain[d]))       *
                                               dot(EdgeLength[d](LDomain[d]),
                                                    EdgeLength[d](LDomain[d])) ) /
                                               LeftLimiterRatio(LDomain[d]),
                                               1.0 );

        //-------------------------------------------------------------
        // if ( d == 0 ) {
        // } else if ( d == 1) {
        //    LeftLimiterRatio -= 1.0;
        //    tecout << "LeftLimiterRatio[1] = " << endl;
        //    tecout << LeftLimiterRatio << endl;
        //    LeftLimiterRatio += 1.0;
        // }
        //-------------------------------------------------------------

	}           // end function calcLeftLimiterRatio

	//======================================================================
	// Function -- QRelations<Traits>::calcEdgePsiLimiter
	//======================================================================

	template <class Traits>
    void QRelations<Traits>::calcEdgePsiLimiter ( const ScalarField&  EdgePsiLimiter,
                                                  const ScalarField&  RightLimiterRatio,
                                                  const ScalarField&  LeftLimiterRatio,
                                                  const VectorField&  EdgeLength,
                                                  const VectorField&  EdgeVelocity,
                                                  const ScalarField&  Dt)
	{
		ENTER("QRelations::calcEdgePsiLimiter");

		int d = getEdgeDirection(EdgePsiLimiter);

        //------------------------------------------------------------------------
        //  Typically the EdgePsiLimiter is limited between 0 and 1,
        //  For this algorithm, 0 means do not have any artificial viscosity
        //  along the edge.
        //
        //  (In Randy Christensen's paper, EdgePsiLimiter is
        //  PsiLimiter = 1.0 - EdgePsiLimiter, so that when he calculates the
        //  Q, there is a factor of ( 1.0 - PsiLimiter) in the expression.  This
        //  means his PsiLimiter has a different meaning than the one used here.
        //  Don M )
        //------------------------------------------------------------------------
        RightLimiterRatio[d].update();
        LeftLimiterRatio[d].update();
        EdgeLength[d].update();
        EdgeVelocity[d].update();
		EdgePsiLimiter = 1.0 - max( 0.0, min( min( 2.0 * RightLimiterRatio[d],
		                                       2.0 * LeftLimiterRatio[d]),
                                          min( 0.5 * (RightLimiterRatio[d] +
		                                              LeftLimiterRatio[d]),
		                                       1.0 ) ) );
		


        //------------------------------------------------------------------------
        // The where statement turns off the limiter when:
        //    1.  The limiter is non zero because of round off
        //    2.  The edge is degenerate (the vertex points coincide)
        //    3.  The change in the velocity along the edge is too small for
        //           anything to happen during the time step.
        //------------------------------------------------------------------------
        EdgePsiLimiter = where( (EdgePsiLimiter > numeric_limits<Real>::epsilon() &&
		                      dot(EdgeLength[d],EdgeLength[d])    >
		                     numeric_limits<Real>::epsilon()             &&
		                      dot(EdgeVelocity[d],EdgeVelocity[d]) * Dt * Dt  >
		                     numeric_limits<Real>::epsilon() *
		                      dot(EdgeLength[d],EdgeLength[d]) ),
		                   EdgePsiLimiter, 0.0 );

//---------------------------------------------------------------------------------------------------------
       if ( d == 0 ) {
//        //   tecout << "eps = " << eps <<endl;
//        //   tecout << "numeric_limits<Real>::epsilon() = " << numeric_limits<Real>::epsilon() << endl;
//           tecout << " Dt = " << Dt << endl;
//           tecout << "EdgePsiLimiter[0] = " << endl;
//           tecout << EdgePsiLimiter << endl;
//           tecout << "EdgeVelocity[0] = " << endl;
//           tecout << EdgeVelocity[0] << endl;
        } else if ( d == 1) {
//        //   tecout << "RightLimiterRatio[1] = " << endl;
//        //   tecout << RightLimiterRatio[1] << endl;
//        //   tecout << "LeftLimiterRatio[1] = " << endl;
//        //   tecout << LeftLimiterRatio[1] << endl;
//           tecout << "EdgePsiLimiter[1] = " << endl;
//           tecout << EdgePsiLimiter << endl;
//           tecout << "EdgeVelocity[1] = " << endl;   
//           tecout << EdgeVelocity[1] << endl;
        }
//---------------------------------------------------------------------------------------------------------

	}           // end function calcEdgePsiLimiter

	//======================================================================
	// Function -- QRelations<Traits>::calcCellQ
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcCellQ ( const ScalarField&  CellQ,
	                    	   			 const ScalarField&  EdgeQTmpMax,
                                         const ScalarField&  SpokeQSwitch )
	{
		ENTER("QRelations::calcCellQ");
		EdgeQTmpMax.update();
		SpokeQSwitch.update();
		CellQ = 0.0;
		for ( int d = 0; d < Dim; ++d ) {
		    for ( int edg = 0; edg < nEdgesPerDimension; ++edg ) {
		        CellQ(CoarseCell) = max( CellQ(CoarseCell), EdgeQTmpMax[d](CellEdge[d][edg]) * SpokeQSwitch[d](Spoke[d][edg]) );
		    }
		}

//----------------------------------------
//         tecout << " in calcCellQ: CellQ = " << endl;
//         tecout << CellQ << endl;
//----------------------------------------

	}           // end function calcCellQ

	//======================================================================
	// Function -- QRelations<Traits>::calcSubForceQ
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcSubForceQ ( const VectorField&  SubForceQ,
	                    	   			     const ScalarField&  EdgeQTmpMax,
	                    	   			     const VectorField&  EdgeVelocity,
	                    	   			     const ScalarField&  SpokeDVolDt,
                                             const ScalarField&  SpokeQSwitch )
	{
		ENTER("QRelations::calcSubForceQ");
	    SubForceQ = 0.0;
		for ( int d = 0; d < Dim; ++d ) {
		    Loc<Dim> offset(0); offset[d] = 1;
		    for ( int edg = 0; edg < nEdgesPerDimension; ++edg ) {
		        SubForceQ(Spoke[d][edg] - offset) -=(EdgeVelocity[d](CellEdge[d][edg]) *
		                                             SpokeDVolDt[d] (Spoke[d][edg])    *
		                                             EdgeQTmpMax[d] (CellEdge[d][edg]) *
                                                     SpokeQSwitch[d](Spoke[d][edg]) )  /
                                                    (dot(EdgeVelocity[d](CellEdge[d][edg]),EdgeVelocity[d](CellEdge[d][edg]))+eps);

		        SubForceQ(Spoke[d][edg])          +=(EdgeVelocity[d](CellEdge[d][edg]) *
		                                             SpokeDVolDt[d] (Spoke[d][edg])    *
		                                             EdgeQTmpMax[d] (CellEdge[d][edg]) *
                                                     SpokeQSwitch[d](Spoke[d][edg]) )  /
                                                    (dot(EdgeVelocity[d](CellEdge[d][edg]),EdgeVelocity[d](CellEdge[d][edg]))+eps);
		    }
		}

//--------------------------------------------
//         tecout << " in calcSubForceQ: SubForceQ = " << endl;
//         tecout << SubForceQ << endl;
//--------------------------------------------

	}           // end function calcSubForceQ

	//======================================================================
	// Function -- QRelations<Traits>::calcSubPressureQMod
	//======================================================================

	template <class Traits>
	void QRelations<Traits>::calcSubPressureQMod ( const ScalarField&  SubPressureQMod,
	                    	   			           const ScalarField&  EdgeQPressure,
                                                   const ScalarField&  SpokeQSwitch )
	{
		ENTER("QRelations::calcSubPressureQMod");
		
	    SubPressureQMod = 0.0;
		for ( int d = 0; d < Dim; ++d ) {
		    Loc<Dim> offset(0); offset[d] = 1;
		    for ( int edg = 0; edg < nEdgesPerDimension; ++edg ) {
		        SubPressureQMod(Spoke[d][edg] - offset) += EdgeQPressure[d](CellEdge[d][edg]) *
                                                           SpokeQSwitch[d](Spoke[d][edg]);

		        SubPressureQMod(Spoke[d][edg])          += EdgeQPressure[d](CellEdge[d][edg]) *
                                                           SpokeQSwitch[d](Spoke[d][edg]);

		    }
		}
	}           // end function calcSubPressureQMod


}          // end namespace conejo

#endif     // end shroud __conejo_QRelations_t_hh
-------------- next part --------------
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
//  CCSource File: QRelations
//  Author:      jcm 
//  Date:        Sat - Nov 18, 2000 
//  Namespace:   conejo
//  Framework:   Tecolote
//  Copyright:   Los Alamos National Laboratory 
//               Full Copyright=$(TECOLOTE_ROOT)/Doc/Copyright
//  RCS_VERSION_ID: $Id: 
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

#if !defined (__MWERKS__)
#include "Demo_src/include/DemoPCH.hh"
#pragma hdrstop
#endif // !__MWERKS__

#include "Demo_src/Model/CompatibleHydro/QRelations.t.hh"

#include "TecFramework_src/MetaTypes/MetaTypes.hh"
#include "TecFramework_src/Foundation/LoadObject.hh"

namespace conejo
{
   using namespace TecFramework;
   using namespace poomalote;
   using namespace Hydrodynamics;
   using namespace PhysicsBaseClasses;
   using namespace std;

   static MetaClass<ITecoloteTraits<QRelations<OneDF<DefaultTraits> >,  RelationPkg> >
                QRelations1DMeta("QRelations1D", QRelations<OneDF<DefaultTraits> >::MakePersistents());

   LoadObjectGroup QRelations1DBase_cc = { &QRelations1DMeta };

}          // end namespace conejo

namespace TecFramework
{
    using namespace conejo;

    LoadObjectGroup QRelations1D_cc = { &QRelations1DBase_cc };

}    // end namespace TecFramework
-------------- next part --------------
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
//  CCSource File: QRelations
//  Author:      jcm 
//  Date:        Sat - Nov 18, 2000 
//  Namespace:   conejo
//  Framework:   Tecolote
//  Copyright:   Los Alamos National Laboratory 
//               Full Copyright=$(TECOLOTE_ROOT)/Doc/Copyright
//  RCS_VERSION_ID: $Id: 
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

#if !defined (__MWERKS__)
#include "Demo_src/include/DemoPCH.hh"
#pragma hdrstop
#endif // !__MWERKS__

#include "Demo_src/Model/CompatibleHydro/QRelations.t.hh"

#include "TecFramework_src/MetaTypes/MetaTypes.hh"
#include "TecFramework_src/Foundation/LoadObject.hh"

namespace conejo
{
   using namespace TecFramework;
   using namespace poomalote;
   using namespace Hydrodynamics;
   using namespace PhysicsBaseClasses;
   using namespace std;

   static MetaClass<ITecoloteTraits<QRelations<TwoDF<DefaultTraits> >,  RelationPkg> >
                QRelations2DMeta("QRelations2D", QRelations<TwoDF<DefaultTraits> >::MakePersistents());

   LoadObjectGroup QRelations2DBase_cc = { &QRelations2DMeta };

}          // end namespace conejo

namespace TecFramework
{
    using namespace conejo;

    LoadObjectGroup QRelations2D_cc = { &QRelations2DBase_cc };

}    // end namespace TecFramework

-------------- next part --------------
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
//  Header File: QRelations
//  Author:      jcm
//  Date:        Sat - Nov 18, 2000
//  Namespace:   conejo
//  Framework:   Tecolote
//  Copyright:   Los Alamos National Laboratory
//               Full Copyright=$(TECOLOTE_ROOT)/Doc/Copyright
//  RCS_VERSION_ID: $Id:
//:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

#ifndef  __conejo_QRelations_hh
#define  __conejo_QRelations_hh

#define DEBUG_UPDATERS 1

#include "Hydrodynamics_src/CompatibleHydro/CompatibleRelations.hh"
#include "Pooma2Integration_src/TecMesh/TecMesh.hh"
#include "Pooma/NewFields.h"

namespace conejo
{
   using namespace TecFramework;
   using namespace Hydrodynamics;
   using namespace poomalote;
   using namespace std;

   //*******************************************************************
   // Tecolote Class - QRelations
   // ------------------------------------------------------------------
   // Summary:
   //
   // This class holds functions that define Independent/Dependent
   // Field Relationships.  These Relationships cause Dependent
   // Fields to be updated automatically when they are used and
   // are out-of-date with respect to their Independent Fields.
   //
   //
   //  When declaring Relation functions, include in the parameter
   // list the Fields that will participate in the relationships.
   //  The Dependent Field is listed first (the LField - Left
   // of the equals sign) and the Independent Fields are listed
   // next (the RFields - Right of the equals sign), followed
   // by any scalar values.  It is not necessary to include the
   // parameter types if they default to the types declared in
   // your Model class.
   //
   //  An example of a relation-function declaration is:
   //
   //       GammaLaw( Pressure, Density, IntEnergy);
   //
   //  where Pressure is a function of Density and IntEnergy,
   // and the GammaLaw function defines the expressions to update
   // the Pressure.
   //*******************************************************************
   template <class Traits>
   class QRelations : public CompatibleRelations<Traits>
   {

   public:

      PERSISTENT_MEMBERS(QRelations)

      // Typedefs
      FIELD_TYPEDEFS(Traits)
      typedef CompatibleRelations<Traits>  Parent;
      typedef CompatibleRelations<Traits> *pParent;

      // Tecolote Constructor
      QRelations( DataDirectory* pDataDir, const string& inName);

      // Public Member Functions
      void createRelations (void);

	  void calcWeightedVertVol ( const ScalarField&  WeightedVertVol,
	                    	   	 const ScalarField&  SubVertVolume,
	                    	   	 const ScalarField&  VertVolume );

//	  void calcEdgeVolume ( const ScalarField&  EdgeVolume,
//	                    	const ScalarField&  WeightedVertVol );
	                    	   	
      void calcEdgeVelocity   ( const VectorField&  EdgeVelocity,
                                const VectorField&  OldVelocity);

	  void calcSpokeDVolDt( const ScalarField&  SpokeDVolDt,
	                              const VectorField&  EdgeVelocity,
	                    	      const VectorField&  SubFaceAreas);
	                    	   	
      void calcEdgeDensity    ( const ScalarField&  EdgeDensity,
                                const ScalarField&  VertDensity);

	  void calcEdgeGammaConstant( const ScalarField&  EdgeGammaConstant,
	                    	   	  const ScalarField&  VertGammaConstant);

	   void calcEdgeQPressure ( const ScalarField&  EdgeQPressure,
	                    	   	const ScalarField&  EdgeGammaConstant,
	                    	   	const ScalarField&  EdgeSoundSpeed,
	                    	   	const VectorField&  EdgeVelocity,
 	                    	   	const ScalarField&  EdgePsiLimiter );
 	                    	
      void calcEdgeSoundSpeed ( const ScalarField&  EdgeSoundSpeed,
                                const ScalarField&  VertSoundSpeed );

	  void calcEdgeQTmpMax    ( const ScalarField&  EdgeQTmpMax,
	                    	    const ScalarField&  EdgeDensity,
	                    	    const ScalarField&  EdgeQPressure );

      void calcRightLimiterRatio( const ScalarField&  RightLimiterRatio,
                                  const VectorField&  EdgeDeltaLength,
                                  const VectorField&  EdgeVelocity);

      void calcLeftLimiterRatio ( const ScalarField&  LeftLimiterRatio,
                                  const VectorField&  EdgeDeltaLength,
                                  const VectorField&  EdgeVelocity);

      void calcEdgePsiLimiter ( const ScalarField&  EdgePsiLimiter,
                                const ScalarField&  RightLimiterRatio,
                                const ScalarField&  LeftLimiterRatio,
                                const VectorField&  EdgeDeltaLength,
                                const VectorField&  EdgeVelocity,
                                const ScalarField&  Dt);

      void calcSpokeQSwitch   ( const ScalarField&  SpokeQSwitch,
                                const ScalarField&  SpokeDVolDt,
                                const ScalarField&  Volume,
                                const ScalarField&  Dt);


      void calcCellQ          ( const ScalarField&  CellQ,
                                const ScalarField&  EdgeQTmpMax,
                                const ScalarField&  SpokeQSwitch );


	  void calcSubForceQ      ( const VectorField&  SubForceQ,
	                    	    const ScalarField&  EdgeQTmpMax,
	                    	   	const VectorField&  EdgeVelocity,
	                    	   	const ScalarField&  SpokeDVolDt,
                                const ScalarField&  SpokeQSwitch );
	                    	   	
	  void calcSubPressureQMod( const ScalarField&  SubPressureQMod,
	                    	   	const ScalarField&  EdgeQPressure,
                                const ScalarField&  SpokeQSwitch );

   //..............................................................
   // The 6 C++ default methods
   //
   public:
      virtual ~QRelations();
   private:
      QRelations();
   // QRelations(const QRelations& c);
      QRelations& operator=(const QRelations& c);
   // QRelations* operator&();
   // const QRelations* operator&() const;
   //..............................................................

   private:

		// Private Member Functions

		//----------------
		// Member Data
		//----------------
		DataDirectory& Old;
		Real   linearQ;
		Real   quadQ;
		Real   gammaConst;
		vector<Range<Dim> >             RDomain;
		vector<Range<Dim> >             LDomain;
		vector<Range<Dim> >             RightEdgeNgbr;
		vector<Range<Dim> >             LeftEdgeNgbr;
		vector<Range<Dim> >             CoarseEdges;
		vector<Range<Dim> >             FineEdges;
		vector<Range<Dim> >             EdgeNgbr;
		vector<Range<Dim> >             UpperVert;
		vector<Range<Dim> >             LowerVert;
   };      // end class QRelations
}          // end namespace conejo

#ifndef TEC_INCLUDE_T_HH_FILE
#include "Demo_src/Model/CompatibleHydro/QRelations.t.hh"
#endif

#endif     // end shroud __conejo_QRelations_hh

From cummings at linkline.com  Mon Apr 23 18:08:13 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 23 Apr 2001 11:08:13 -0700
Subject: DynamicArray destroy methods
Message-ID: <NEBBLCJDELMDOJLGLNJGGELFCBAA.cummings@linkline.com>

Jim,

I was going to add new destroy() functions
to Particles corresponding to the new
IteratorPairDomain-based functions you 
added to DynamicArray.  I noticed three minor
glitches in DynamicArray.h that I was going
to fix, if you don't object.  One is on
line 486.  We don't need to provide the 
BackFill() argument here because dynamic 
engines already provide a destroy() function
that takes just a Domain argument.  (No harm
done here though, and I think this glitch
was here prior to your recent changes.)  The
next item is on line 501.  You left out the 
Pooma:: qualifier on the IteratorPairDomain
type.  It should be there for consistency,
although there is probably a "using namespace
Pooma;" statement somewhere that is making 
this work as written.  The last problem is on
line 542.  I think you do have to provide the
BackFill() argument here because MPEngine only
provides three versions of destroy(): domain,
domain and patchID, or domain, patchID and method.

I was trying to check out this third item when 
I ran into another problem.  Perhaps others can 
chime in on this.  I modified dynamic_array_test5.cpp
to call destroy() without specifying a method.  So
I made calls with arguments (int*,int*) and with
(vector<int>::iterator,vector<int>::iterator,int).
The first call should invoke destroy() with Iter
equal to int* (DynamicArray.h, line 498), but gcc 
says the overload is ambiguous with the version on
line 477 also being plausible.  I thought matching
one template parameter always beats matching two.
With my second call, I was trying to invoke the
destroy() function on line 538 of DynamicArray.h,
but gcc thinks the version on line 491 is a good
match also.  Again I am surprised because PatchID_t
is defined as int, and that exactly matches the
type of my third argument.  What's the deal?

Julian C.



From cummings at linkline.com  Mon Apr 23 18:18:54 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 23 Apr 2001 11:18:54 -0700
Subject: [pooma-dev] DynamicArray destroy methods
In-Reply-To: <NEBBLCJDELMDOJLGLNJGGELFCBAA.cummings@linkline.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGOELFCBAA.cummings@linkline.com>

One way out of the function overloading 
quandary I noted below would be to call
out versions of destroy() for each of the
two existing destroy methods, BackFill
and ShiftUp, rather than use a template
parameter.  We are unlikely to add more 
of these, and if we do, they have to be 
added to the list in DynamicEvents anyway.
Should we take this approach?

Julian C.


> -----Original Message-----
> From: Julian C. Cummings [mailto:cummings at linkline.com]
> Sent: Monday, April 23, 2001 11:08 AM
> To: James Crotinger
> Cc: Pooma Developers
> Subject: [pooma-dev] DynamicArray destroy methods
> 
> 
> Jim,
> 
> I was going to add new destroy() functions
> to Particles corresponding to the new
> IteratorPairDomain-based functions you 
> added to DynamicArray.  I noticed three minor
> glitches in DynamicArray.h that I was going
> to fix, if you don't object.  One is on
> line 486.  We don't need to provide the 
> BackFill() argument here because dynamic 
> engines already provide a destroy() function
> that takes just a Domain argument.  (No harm
> done here though, and I think this glitch
> was here prior to your recent changes.)  The
> next item is on line 501.  You left out the 
> Pooma:: qualifier on the IteratorPairDomain
> type.  It should be there for consistency,
> although there is probably a "using namespace
> Pooma;" statement somewhere that is making 
> this work as written.  The last problem is on
> line 542.  I think you do have to provide the
> BackFill() argument here because MPEngine only
> provides three versions of destroy(): domain,
> domain and patchID, or domain, patchID and method.
> 
> I was trying to check out this third item when 
> I ran into another problem.  Perhaps others can 
> chime in on this.  I modified dynamic_array_test5.cpp
> to call destroy() without specifying a method.  So
> I made calls with arguments (int*,int*) and with
> (vector<int>::iterator,vector<int>::iterator,int).
> The first call should invoke destroy() with Iter
> equal to int* (DynamicArray.h, line 498), but gcc 
> says the overload is ambiguous with the version on
> line 477 also being plausible.  I thought matching
> one template parameter always beats matching two.
> With my second call, I was trying to invoke the
> destroy() function on line 538 of DynamicArray.h,
> but gcc thinks the version on line 491 is a good
> match also.  Again I am surprised because PatchID_t
> is defined as int, and that exactly matches the
> type of my third argument.  What's the deal?
> 
> Julian C.
> 
> 


From cummings at linkline.com  Mon Apr 23 18:58:46 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 23 Apr 2001 11:58:46 -0700
Subject: [pooma-dev] DynamicArray destroy methods
In-Reply-To: <NEBBLCJDELMDOJLGLNJGOELFCBAA.cummings@linkline.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGKELGCBAA.cummings@linkline.com>

Never mind!  I just figured out the problem
and the solution.  The reason for the overload
ambiguities is that we were defining the 
destroy() functions to take domain and destroy
method arguments by const reference but take 
iterators and patch IDs by value.  So the 
overloads did not match the function calls in
exactly the same way, and I guess const int& is
preferred to int when you pass a literal int 
like "6".  Also, you have to be careful about 
passing with an int array like killList because
it is not treated quite the same as &killList[0]
when it comes to argument matching.

Anyhow, once I changed the iterator and patchID
arguments to be passed by const reference, all 
the function overloads matched as expected.  I'd
like to check in these fixes to DynamicArray.h
along with the minor fixes I mentioned in my 
original e-mail on this, barring any objections.
I am attaching the diff's for DynamicArray.h
Sorry for the volley of e-mails on this.

Julian C.


> -----Original Message-----
> From: Julian C. Cummings [mailto:cummings at linkline.com]
> Sent: Monday, April 23, 2001 11:19 AM
> To: Pooma Developers
> Subject: RE: [pooma-dev] DynamicArray destroy methods
> 
> 
> One way out of the function overloading 
> quandary I noted below would be to call
> out versions of destroy() for each of the
> two existing destroy methods, BackFill
> and ShiftUp, rather than use a template
> parameter.  We are unlikely to add more 
> of these, and if we do, they have to be 
> added to the list in DynamicEvents anyway.
> Should we take this approach?
> 
> Julian C.
> 
> 
> > -----Original Message-----
> > From: Julian C. Cummings [mailto:cummings at linkline.com]
> > Sent: Monday, April 23, 2001 11:08 AM
> > To: James Crotinger
> > Cc: Pooma Developers
> > Subject: [pooma-dev] DynamicArray destroy methods
> > 
> > 
> > Jim,
> > 
> > I was going to add new destroy() functions
> > to Particles corresponding to the new
> > IteratorPairDomain-based functions you 
> > added to DynamicArray.  I noticed three minor
> > glitches in DynamicArray.h that I was going
> > to fix, if you don't object.  One is on
> > line 486.  We don't need to provide the 
> > BackFill() argument here because dynamic 
> > engines already provide a destroy() function
> > that takes just a Domain argument.  (No harm
> > done here though, and I think this glitch
> > was here prior to your recent changes.)  The
> > next item is on line 501.  You left out the 
> > Pooma:: qualifier on the IteratorPairDomain
> > type.  It should be there for consistency,
> > although there is probably a "using namespace
> > Pooma;" statement somewhere that is making 
> > this work as written.  The last problem is on
> > line 542.  I think you do have to provide the
> > BackFill() argument here because MPEngine only
> > provides three versions of destroy(): domain,
> > domain and patchID, or domain, patchID and method.
> > 
> > I was trying to check out this third item when 
> > I ran into another problem.  Perhaps others can 
> > chime in on this.  I modified dynamic_array_test5.cpp
> > to call destroy() without specifying a method.  So
> > I made calls with arguments (int*,int*) and with
> > (vector<int>::iterator,vector<int>::iterator,int).
> > The first call should invoke destroy() with Iter
> > equal to int* (DynamicArray.h, line 498), but gcc 
> > says the overload is ambiguous with the version on
> > line 477 also being plausible.  I thought matching
> > one template parameter always beats matching two.
> > With my second call, I was trying to invoke the
> > destroy() function on line 538 of DynamicArray.h,
> > but gcc thinks the version on line 491 is a good
> > match also.  Again I am surprised because PatchID_t
> > is defined as int, and that exactly matches the
> > type of my third argument.  What's the deal?
> > 
> > Julian C.
> > 
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DArray_042301.patch
Type: application/octet-stream
Size: 4132 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010423/1f4246a2/attachment.obj>

From JimC at proximation.com  Mon Apr 23 19:20:07 2001
From: JimC at proximation.com (James Crotinger)
Date: Mon, 23 Apr 2001 12:20:07 -0700
Subject: [pooma-dev] DynamicArray destroy methods
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BED@proxim-sf001.santafe.proximation.com>

I tend not to like this idea. Won't passing references result in
dereferencing every time you use the object in question? With iterators and
ints I would think this could potentially impact performance. 

What about going the other way and passing the Destroy tag by value? We
might need to write a dummy copy constructor for the tag, but that's not so
hard. 

	Jim


> -----Original Message-----
> From: Julian C. Cummings [mailto:cummings at linkline.com]
> Sent: Monday, April 23, 2001 12:59 PM
> To: Pooma Developers
> Subject: RE: [pooma-dev] DynamicArray destroy methods
> 
> 
> Never mind!  I just figured out the problem
> and the solution.  The reason for the overload
> ambiguities is that we were defining the 
> destroy() functions to take domain and destroy
> method arguments by const reference but take 
> iterators and patch IDs by value.  So the 
> overloads did not match the function calls in
> exactly the same way, and I guess const int& is
> preferred to int when you pass a literal int 
> like "6".  Also, you have to be careful about 
> passing with an int array like killList because
> it is not treated quite the same as &killList[0]
> when it comes to argument matching.
> 
> Anyhow, once I changed the iterator and patchID
> arguments to be passed by const reference, all 
> the function overloads matched as expected.  I'd
> like to check in these fixes to DynamicArray.h
> along with the minor fixes I mentioned in my 
> original e-mail on this, barring any objections.
> I am attaching the diff's for DynamicArray.h
> Sorry for the volley of e-mails on this.
> 
> Julian C.
> 
> 
> > -----Original Message-----
> > From: Julian C. Cummings [mailto:cummings at linkline.com]
> > Sent: Monday, April 23, 2001 11:19 AM
> > To: Pooma Developers
> > Subject: RE: [pooma-dev] DynamicArray destroy methods
> > 
> > 
> > One way out of the function overloading 
> > quandary I noted below would be to call
> > out versions of destroy() for each of the
> > two existing destroy methods, BackFill
> > and ShiftUp, rather than use a template
> > parameter.  We are unlikely to add more 
> > of these, and if we do, they have to be 
> > added to the list in DynamicEvents anyway.
> > Should we take this approach?
> > 
> > Julian C.
> > 
> > 
> > > -----Original Message-----
> > > From: Julian C. Cummings [mailto:cummings at linkline.com]
> > > Sent: Monday, April 23, 2001 11:08 AM
> > > To: James Crotinger
> > > Cc: Pooma Developers
> > > Subject: [pooma-dev] DynamicArray destroy methods
> > > 
> > > 
> > > Jim,
> > > 
> > > I was going to add new destroy() functions
> > > to Particles corresponding to the new
> > > IteratorPairDomain-based functions you 
> > > added to DynamicArray.  I noticed three minor
> > > glitches in DynamicArray.h that I was going
> > > to fix, if you don't object.  One is on
> > > line 486.  We don't need to provide the 
> > > BackFill() argument here because dynamic 
> > > engines already provide a destroy() function
> > > that takes just a Domain argument.  (No harm
> > > done here though, and I think this glitch
> > > was here prior to your recent changes.)  The
> > > next item is on line 501.  You left out the 
> > > Pooma:: qualifier on the IteratorPairDomain
> > > type.  It should be there for consistency,
> > > although there is probably a "using namespace
> > > Pooma;" statement somewhere that is making 
> > > this work as written.  The last problem is on
> > > line 542.  I think you do have to provide the
> > > BackFill() argument here because MPEngine only
> > > provides three versions of destroy(): domain,
> > > domain and patchID, or domain, patchID and method.
> > > 
> > > I was trying to check out this third item when 
> > > I ran into another problem.  Perhaps others can 
> > > chime in on this.  I modified dynamic_array_test5.cpp
> > > to call destroy() without specifying a method.  So
> > > I made calls with arguments (int*,int*) and with
> > > (vector<int>::iterator,vector<int>::iterator,int).
> > > The first call should invoke destroy() with Iter
> > > equal to int* (DynamicArray.h, line 498), but gcc 
> > > says the overload is ambiguous with the version on
> > > line 477 also being plausible.  I thought matching
> > > one template parameter always beats matching two.
> > > With my second call, I was trying to invoke the
> > > destroy() function on line 538 of DynamicArray.h,
> > > but gcc thinks the version on line 491 is a good
> > > match also.  Again I am surprised because PatchID_t
> > > is defined as int, and that exactly matches the
> > > type of my third argument.  What's the deal?
> > > 
> > > Julian C.
> > > 
> > > 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010423/6439b279/attachment.html>

From cummings at linkline.com  Mon Apr 23 20:19:31 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Mon, 23 Apr 2001 13:19:31 -0700
Subject: [pooma-dev] DynamicArray destroy methods
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BED@proxim-sf001.santafe.proximation.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGKELHCBAA.cummings@linkline.com>

RE: [pooma-dev] DynamicArray destroy methodsHi Jim,

I'm pretty sure your performance concerns are unfounded.
Accessing object methods via reference should never incur
a performance penalty, just as using the dot operator and
the arrow operator should be equivalent.  If this were not the
case, almost all C++ code ever written would have problems.
There is a performance penalty when you pass a heavyweight
object by value, of course.

In any case, I did a quick test of your idea.  It can be made
to work, but is slightly more annoying in actual use.  In order
for the pass-by-value to match when passing an iterator pair,
both of the arguments must be local objects that can be copied.
Thus, passing something like (dptr,dptr+3), where dptr is an
int*, once again triggers the ambiguity error.  The compiler thinks
you have passed an int* & and an int*, and these two arguments
are not exactly the same.  So you have to declare a second
int* object and set it equal to dptr+3.  With const references,
this little annoyance is gone.

Julian C.

P.S.  I stumbled over another potential bug, this time in the
IteratorPairDomain class.  The non-const version of operator()
returns an Element_t&.  This is incorrect when Iter is a const T*.
I think we need to add a typedef for ElementRef_t, which would
be set to std::iterator_traits<Iter>::reference, and return that here.

  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Monday, April 23, 2001 12:20 PM
  To: 'cummings at linkline.com'; Pooma Developers
  Subject: RE: [pooma-dev] DynamicArray destroy methods


  I tend not to like this idea. Won't passing references result in
dereferencing every time you use the object in question? With iterators and
ints I would think this could potentially impact performance.

  What about going the other way and passing the Destroy tag by value? We
might need to write a dummy copy constructor for the tag, but that's not so
hard.

          Jim



  > -----Original Message-----
  > From: Julian C. Cummings [mailto:cummings at linkline.com]
  > Sent: Monday, April 23, 2001 12:59 PM
  > To: Pooma Developers
  > Subject: RE: [pooma-dev] DynamicArray destroy methods
  >
  >
  > Never mind!  I just figured out the problem
  > and the solution.  The reason for the overload
  > ambiguities is that we were defining the
  > destroy() functions to take domain and destroy
  > method arguments by const reference but take
  > iterators and patch IDs by value.  So the
  > overloads did not match the function calls in
  > exactly the same way, and I guess const int& is
  > preferred to int when you pass a literal int
  > like "6".  Also, you have to be careful about
  > passing with an int array like killList because
  > it is not treated quite the same as &killList[0]
  > when it comes to argument matching.
  >
  > Anyhow, once I changed the iterator and patchID
  > arguments to be passed by const reference, all
  > the function overloads matched as expected.  I'd
  > like to check in these fixes to DynamicArray.h
  > along with the minor fixes I mentioned in my
  > original e-mail on this, barring any objections.
  > I am attaching the diff's for DynamicArray.h
  > Sorry for the volley of e-mails on this.
  >
  > Julian C.
  >
  >
  > > -----Original Message-----
  > > From: Julian C. Cummings [mailto:cummings at linkline.com]
  > > Sent: Monday, April 23, 2001 11:19 AM
  > > To: Pooma Developers
  > > Subject: RE: [pooma-dev] DynamicArray destroy methods
  > >
  > >
  > > One way out of the function overloading
  > > quandary I noted below would be to call
  > > out versions of destroy() for each of the
  > > two existing destroy methods, BackFill
  > > and ShiftUp, rather than use a template
  > > parameter.  We are unlikely to add more
  > > of these, and if we do, they have to be
  > > added to the list in DynamicEvents anyway.
  > > Should we take this approach?
  > >
  > > Julian C.
  > >
  > >
  > > > -----Original Message-----
  > > > From: Julian C. Cummings [mailto:cummings at linkline.com]
  > > > Sent: Monday, April 23, 2001 11:08 AM
  > > > To: James Crotinger
  > > > Cc: Pooma Developers
  > > > Subject: [pooma-dev] DynamicArray destroy methods
  > > >
  > > >
  > > > Jim,
  > > >
  > > > I was going to add new destroy() functions
  > > > to Particles corresponding to the new
  > > > IteratorPairDomain-based functions you
  > > > added to DynamicArray.  I noticed three minor
  > > > glitches in DynamicArray.h that I was going
  > > > to fix, if you don't object.  One is on
  > > > line 486.  We don't need to provide the
  > > > BackFill() argument here because dynamic
  > > > engines already provide a destroy() function
  > > > that takes just a Domain argument.  (No harm
  > > > done here though, and I think this glitch
  > > > was here prior to your recent changes.)  The
  > > > next item is on line 501.  You left out the
  > > > Pooma:: qualifier on the IteratorPairDomain
  > > > type.  It should be there for consistency,
  > > > although there is probably a "using namespace
  > > > Pooma;" statement somewhere that is making
  > > > this work as written.  The last problem is on
  > > > line 542.  I think you do have to provide the
  > > > BackFill() argument here because MPEngine only
  > > > provides three versions of destroy(): domain,
  > > > domain and patchID, or domain, patchID and method.
  > > >
  > > > I was trying to check out this third item when
  > > > I ran into another problem.  Perhaps others can
  > > > chime in on this.  I modified dynamic_array_test5.cpp
  > > > to call destroy() without specifying a method.  So
  > > > I made calls with arguments (int*,int*) and with
  > > > (vector<int>::iterator,vector<int>::iterator,int).
  > > > The first call should invoke destroy() with Iter
  > > > equal to int* (DynamicArray.h, line 498), but gcc
  > > > says the overload is ambiguous with the version on
  > > > line 477 also being plausible.  I thought matching
  > > > one template parameter always beats matching two.
  > > > With my second call, I was trying to invoke the
  > > > destroy() function on line 538 of DynamicArray.h,
  > > > but gcc thinks the version on line 491 is a good
  > > > match also.  Again I am surprised because PatchID_t
  > > > is defined as int, and that exactly matches the
  > > > type of my third argument.  What's the deal?
  > > >
  > > > Julian C.
  > > >
  > > >
  > >
  >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010423/0c29f5fc/attachment.html>

From JimC at proximation.com  Mon Apr 23 21:20:36 2001
From: JimC at proximation.com (James Crotinger)
Date: Mon, 23 Apr 2001 14:20:36 -0700
Subject: [pooma-dev] DynamicArray destroy methods
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BEE@proxim-sf001.santafe.proximation.com>

Mark or Allan, any comment on these issues? I'm mostly just following
instinct based on what I see in the STL, where iterators, tags, functors,
etc., seem to always be passed by value, and only the container's value's
are passed by reference. Passing by reference has to incur some overhead for
small objects, but perhaps it isn't important (you are, after all, passing a
pointer on the stack and not the value, so there has to be at least one
dereference in the function body - perhaps the compiler can optimize other
derefs away, but only if it doesn't run out of registers for other things).
However, I definitely don't understand the second problem Julian's having.
The fundamental source of the problem is that we have Domain and Method
(tag) template parameters and so we have the following destroy overloads:
 
template <class Dom, class Meth)   destroy(const Dom &, const Meth&);
 
template <class Dom>               destroy(const Dom &);
 
template <class Iter, class Meth)  destroy(Iter begin, Iter end, const Meth
&);
 
template <class Iter>              destroy(Iter begin, Iter end);
 
template <class Dom, class Meth)   destroy(const Dom &, int, const Meth &);
 
template <class Dom>               destroy(const Dom &, int);
 
template <class Iter, class Meth>  destroy(Iter, Iter, int, const Meth &);
 
template <class Iter>              destroy(Iter, Iter, int);
 
(We do want to pass Domains by reference here since they are not necessarily
small objects. I would tend to pass everything else by value, though, so I'd
also change "const Meth &" to just "Meth". But I don't THINK that
significantly simplifies the complexity.)
 
Now that I see all of these, I do feel like this is a recipe for disaster.
Julian "fixed" it by passing everything by reference, but this seems like a
hack. If having both
 
  destroy(const Dom &,const Meth &)
 
and 
 
  destroy(Iter,Iter)
 
is causing an ambiguity with:
 
  int *p = ...;
  a.destroy(p, p+3)
 
I'm guessing this is just telling us that we're in template hell. 8-) This
looks to me like it should work with the above, but perhaps we've just tried
to get too fancy.
 
We could fix the problem by passing an enum instead of a tag, or by
explicitly overloading on Shiftup and BackFill, the only two types that are
valid to pass as the Meth parameter right now.
 
Thoughts? 
 
    Jim
 
 -----Original Message-----
From: Julian C. Cummings [mailto:cummings at linkline.com]
Sent: Monday, April 23, 2001 2:20 PM
To: James Crotinger; Pooma Developers
Subject: RE: [pooma-dev] DynamicArray destroy methods



Hi Jim,
 
I'm pretty sure your performance concerns are unfounded.
Accessing object methods via reference should never incur
a performance penalty, just as using the dot operator and
the arrow operator should be equivalent.  If this were not the
case, almost all C++ code ever written would have problems.
There is a performance penalty when you pass a heavyweight
object by value, of course.
 
In any case, I did a quick test of your idea.  It can be made 
to work, but is slightly more annoying in actual use.  In order
for the pass-by-value to match when passing an iterator pair,
both of the arguments must be local objects that can be copied.
Thus, passing something like (dptr,dptr+3), where dptr is an
int*, once again triggers the ambiguity error.  The compiler thinks 
you have passed an int* & and an int*, and these two arguments
are not exactly the same.  So you have to declare a second 
int* object and set it equal to dptr+3.  With const references,
this little annoyance is gone.
 
Julian C.
 
P.S.  I stumbled over another potential bug, this time in the 
IteratorPairDomain class.  The non-const version of operator()
returns an Element_t&.  This is incorrect when Iter is a const T*.
I think we need to add a typedef for ElementRef_t, which would 
be set to std::iterator_traits<Iter>::reference, and return that here.
 

-----Original Message-----
From: James Crotinger [mailto:JimC at proximation.com]
Sent: Monday, April 23, 2001 12:20 PM
To: 'cummings at linkline.com'; Pooma Developers
Subject: RE: [pooma-dev] DynamicArray destroy methods



I tend not to like this idea. Won't passing references result in
dereferencing every time you use the object in question? With iterators and
ints I would think this could potentially impact performance. 

What about going the other way and passing the Destroy tag by value? We
might need to write a dummy copy constructor for the tag, but that's not so
hard. 

        Jim 


> -----Original Message----- 
> From: Julian C. Cummings [ mailto:cummings at linkline.com
<mailto:cummings at linkline.com> ] 
> Sent: Monday, April 23, 2001 12:59 PM 
> To: Pooma Developers 
> Subject: RE: [pooma-dev] DynamicArray destroy methods 
> 
> 
> Never mind!  I just figured out the problem 
> and the solution.  The reason for the overload 
> ambiguities is that we were defining the 
> destroy() functions to take domain and destroy 
> method arguments by const reference but take 
> iterators and patch IDs by value.  So the 
> overloads did not match the function calls in 
> exactly the same way, and I guess const int& is 
> preferred to int when you pass a literal int 
> like "6".  Also, you have to be careful about 
> passing with an int array like killList because 
> it is not treated quite the same as &killList[0] 
> when it comes to argument matching. 
> 
> Anyhow, once I changed the iterator and patchID 
> arguments to be passed by const reference, all 
> the function overloads matched as expected.  I'd 
> like to check in these fixes to DynamicArray.h 
> along with the minor fixes I mentioned in my 
> original e-mail on this, barring any objections. 
> I am attaching the diff's for DynamicArray.h 
> Sorry for the volley of e-mails on this. 
> 
> Julian C. 
> 
> 
> > -----Original Message----- 
> > From: Julian C. Cummings [ mailto:cummings at linkline.com
<mailto:cummings at linkline.com> ] 
> > Sent: Monday, April 23, 2001 11:19 AM 
> > To: Pooma Developers 
> > Subject: RE: [pooma-dev] DynamicArray destroy methods 
> > 
> > 
> > One way out of the function overloading 
> > quandary I noted below would be to call 
> > out versions of destroy() for each of the 
> > two existing destroy methods, BackFill 
> > and ShiftUp, rather than use a template 
> > parameter.  We are unlikely to add more 
> > of these, and if we do, they have to be 
> > added to the list in DynamicEvents anyway. 
> > Should we take this approach? 
> > 
> > Julian C. 
> > 
> > 
> > > -----Original Message----- 
> > > From: Julian C. Cummings [ mailto:cummings at linkline.com
<mailto:cummings at linkline.com> ] 
> > > Sent: Monday, April 23, 2001 11:08 AM 
> > > To: James Crotinger 
> > > Cc: Pooma Developers 
> > > Subject: [pooma-dev] DynamicArray destroy methods 
> > > 
> > > 
> > > Jim, 
> > > 
> > > I was going to add new destroy() functions 
> > > to Particles corresponding to the new 
> > > IteratorPairDomain-based functions you 
> > > added to DynamicArray.  I noticed three minor 
> > > glitches in DynamicArray.h that I was going 
> > > to fix, if you don't object.  One is on 
> > > line 486.  We don't need to provide the 
> > > BackFill() argument here because dynamic 
> > > engines already provide a destroy() function 
> > > that takes just a Domain argument.  (No harm 
> > > done here though, and I think this glitch 
> > > was here prior to your recent changes.)  The 
> > > next item is on line 501.  You left out the 
> > > Pooma:: qualifier on the IteratorPairDomain 
> > > type.  It should be there for consistency, 
> > > although there is probably a "using namespace 
> > > Pooma;" statement somewhere that is making 
> > > this work as written.  The last problem is on 
> > > line 542.  I think you do have to provide the 
> > > BackFill() argument here because MPEngine only 
> > > provides three versions of destroy(): domain, 
> > > domain and patchID, or domain, patchID and method. 
> > > 
> > > I was trying to check out this third item when 
> > > I ran into another problem.  Perhaps others can 
> > > chime in on this.  I modified dynamic_array_test5.cpp 
> > > to call destroy() without specifying a method.  So 
> > > I made calls with arguments (int*,int*) and with 
> > > (vector<int>::iterator,vector<int>::iterator,int). 
> > > The first call should invoke destroy() with Iter 
> > > equal to int* (DynamicArray.h, line 498), but gcc 
> > > says the overload is ambiguous with the version on 
> > > line 477 also being plausible.  I thought matching 
> > > one template parameter always beats matching two. 
> > > With my second call, I was trying to invoke the 
> > > destroy() function on line 538 of DynamicArray.h, 
> > > but gcc thinks the version on line 491 is a good 
> > > match also.  Again I am surprised because PatchID_t 
> > > is defined as int, and that exactly matches the 
> > > type of my third argument.  What's the deal? 
> > > 
> > > Julian C. 
> > > 
> > > 
> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010423/d1f82923/attachment.html>

From oldham at codesourcery.com  Tue Apr 24 00:24:57 2001
From: oldham at codesourcery.com (Jeffrey Oldham)
Date: Mon, 23 Apr 2001 17:24:57 -0700
Subject: Chevron and Hydrodynamics Kernels and Operator Centerings
Message-ID: <20010423172457.A32767@codesourcery.com>

Attached is a new document explaining the similarities between the
hydrodynamics kernel and the Chevron kernel.  Both algorithms compute
cells' faces' normals and then corner fluxes.  This presents
interesting challenges since face-centered and cell-centered
operations (operators) occur.  Fields with different granularities are
also used, but the previous proposal for interpolation and restriction
operators suffices.  Pseudocode for computing the corner fluxes is
presented.  Also, my attempt to explain to myself all possible
centerings for a d-D polytope is appended.

The second document, the proposal to add interpolation and restriction
operators to Pooma, has been revised to better address operators with
input fields having different centerings than the resulting output
fields.  When the input and output fields have different centerings,
the centerings must be explicitly specified.  Semantics for a few such
operators are provided.

To compute with fields with different centerings, Scott Haney proposed
conversion operators to convert from one centering to another.  I do
not know what the semantics of such a statement means.  For example,
the number of values in a face-centered field is signiicantly
different than in a cell-centered field.  Thus, a one-to-one matching
is not possible.  Instead, I propose extending interpolation and
restriction operators to accommodate different centerings.  For
example, one operator adds all face-centered values incident on a
cell to form a cell-centered value.

Unresolved is a consistent notation for referring to incident
geometric objects, e.g., given a face, refer to incident vertices.

Thanks,
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernels.pdf
Type: application/pdf
Size: 49317 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010423/de22d094/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: field-granularity.pdf
Type: application/pdf
Size: 46572 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010423/de22d094/attachment-0001.pdf>

From cummings at linkline.com  Wed Apr 25 15:56:53 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Wed, 25 Apr 2001 08:56:53 -0700
Subject: [pooma-dev] DynamicArray destroy methods
In-Reply-To: <F871BB04B0EA224A821A5274C31DF3152BEE@proxim-sf001.santafe.proximation.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGIELNCBAA.cummings@linkline.com>

RE: [pooma-dev] DynamicArray destroy methodsCan I get some final comments
and closure on this?
I'd like to check in fixes for the problem with overloading
destroy(), and the incorrect return type of non-const
operator() in IteratorPairDomain.  For the first problem,
there seem to be three solutions: pass tags by const ref,
pass destroy methods as an enum type rather than tag
classes, or specialize destroy() to each of the two destroy
methods that we provide.  The first solution is kind of a
tricky hack, but it does work.  The third one is less elegant
but certainly works as well.  Either of these seems OK to me.

I'd like to make some decisions on these little items, so I
can check in the fixes and move on.

Thanks, Julian C.

  -----Original Message-----
  From: James Crotinger [mailto:JimC at proximation.com]
  Sent: Monday, April 23, 2001 2:21 PM
  To: 'pooma-dev at pooma.codesourcery.com'
  Subject: RE: [pooma-dev] DynamicArray destroy methods


  Mark or Allan, any comment on these issues? I'm mostly just following
instinct based on what I see in the STL, where iterators, tags, functors,
etc., seem to always be passed by value, and only the container's value's
are passed by reference. Passing by reference has to incur some overhead for
small objects, but perhaps it isn't important (you are, after all, passing a
pointer on the stack and not the value, so there has to be at least one
dereference in the function body - perhaps the compiler can optimize other
derefs away, but only if it doesn't run out of registers for other things).
However, I definitely don't understand the second problem Julian's having.
The fundamental source of the problem is that we have Domain and Method
(tag) template parameters and so we have the following destroy overloads:

  template <class Dom, class Meth)   destroy(const Dom &, const Meth&);

  template <class Dom>               destroy(const Dom &);

  template <class Iter, class Meth)  destroy(Iter begin, Iter end, const
Meth &);

  template <class Iter>              destroy(Iter begin, Iter end);

  template <class Dom, class Meth)   destroy(const Dom &, int, const Meth
&);

  template <class Dom>               destroy(const Dom &, int);

  template <class Iter, class Meth>  destroy(Iter, Iter, int, const Meth &);

  template <class Iter>              destroy(Iter, Iter, int);

  (We do want to pass Domains by reference here since they are not
necessarily small objects. I would tend to pass everything else by value,
though, so I'd also change "const Meth &" to just "Meth". But I don't THINK
that significantly simplifies the complexity.)

  Now that I see all of these, I do feel like this is a recipe for disaster.
Julian "fixed" it by passing everything by reference, but this seems like a
hack. If having both

    destroy(const Dom &,const Meth &)

  and

    destroy(Iter,Iter)

  is causing an ambiguity with:

    int *p = ...;
    a.destroy(p, p+3)

  I'm guessing this is just telling us that we're in template hell. 8-) This
looks to me like it should work with the above, but perhaps we've just tried
to get too fancy.

  We could fix the problem by passing an enum instead of a tag, or by
explicitly overloading on Shiftup and BackFill, the only two types that are
valid to pass as the Meth parameter right now.

  Thoughts?

      Jim

   -----Original Message-----
  From: Julian C. Cummings [mailto:cummings at linkline.com]
  Sent: Monday, April 23, 2001 2:20 PM
  To: James Crotinger; Pooma Developers
  Subject: RE: [pooma-dev] DynamicArray destroy methods


    Hi Jim,

    I'm pretty sure your performance concerns are unfounded.
    Accessing object methods via reference should never incur
    a performance penalty, just as using the dot operator and
    the arrow operator should be equivalent.  If this were not the
    case, almost all C++ code ever written would have problems.
    There is a performance penalty when you pass a heavyweight
    object by value, of course.

    In any case, I did a quick test of your idea.  It can be made
    to work, but is slightly more annoying in actual use.  In order
    for the pass-by-value to match when passing an iterator pair,
    both of the arguments must be local objects that can be copied.
    Thus, passing something like (dptr,dptr+3), where dptr is an
    int*, once again triggers the ambiguity error.  The compiler thinks
    you have passed an int* & and an int*, and these two arguments
    are not exactly the same.  So you have to declare a second
    int* object and set it equal to dptr+3.  With const references,
    this little annoyance is gone.

    Julian C.

    P.S.  I stumbled over another potential bug, this time in the
    IteratorPairDomain class.  The non-const version of operator()
    returns an Element_t&.  This is incorrect when Iter is a const T*.
    I think we need to add a typedef for ElementRef_t, which would
    be set to std::iterator_traits<Iter>::reference, and return that here.

      -----Original Message-----
      From: James Crotinger [mailto:JimC at proximation.com]
      Sent: Monday, April 23, 2001 12:20 PM
      To: 'cummings at linkline.com'; Pooma Developers
      Subject: RE: [pooma-dev] DynamicArray destroy methods


      I tend not to like this idea. Won't passing references result in
dereferencing every time you use the object in question? With iterators and
ints I would think this could potentially impact performance.

      What about going the other way and passing the Destroy tag by value?
We might need to write a dummy copy constructor for the tag, but that's not
so hard.

              Jim



      > -----Original Message-----
      > From: Julian C. Cummings [mailto:cummings at linkline.com]
      > Sent: Monday, April 23, 2001 12:59 PM
      > To: Pooma Developers
      > Subject: RE: [pooma-dev] DynamicArray destroy methods
      >
      >
      > Never mind!  I just figured out the problem
      > and the solution.  The reason for the overload
      > ambiguities is that we were defining the
      > destroy() functions to take domain and destroy
      > method arguments by const reference but take
      > iterators and patch IDs by value.  So the
      > overloads did not match the function calls in
      > exactly the same way, and I guess const int& is
      > preferred to int when you pass a literal int
      > like "6".  Also, you have to be careful about
      > passing with an int array like killList because
      > it is not treated quite the same as &killList[0]
      > when it comes to argument matching.
      >
      > Anyhow, once I changed the iterator and patchID
      > arguments to be passed by const reference, all
      > the function overloads matched as expected.  I'd
      > like to check in these fixes to DynamicArray.h
      > along with the minor fixes I mentioned in my
      > original e-mail on this, barring any objections.
      > I am attaching the diff's for DynamicArray.h
      > Sorry for the volley of e-mails on this.
      >
      > Julian C.
      >
      >
      > > -----Original Message-----
      > > From: Julian C. Cummings [mailto:cummings at linkline.com]
      > > Sent: Monday, April 23, 2001 11:19 AM
      > > To: Pooma Developers
      > > Subject: RE: [pooma-dev] DynamicArray destroy methods
      > >
      > >
      > > One way out of the function overloading
      > > quandary I noted below would be to call
      > > out versions of destroy() for each of the
      > > two existing destroy methods, BackFill
      > > and ShiftUp, rather than use a template
      > > parameter.  We are unlikely to add more
      > > of these, and if we do, they have to be
      > > added to the list in DynamicEvents anyway.
      > > Should we take this approach?
      > >
      > > Julian C.
      > >
      > >
      > > > -----Original Message-----
      > > > From: Julian C. Cummings [mailto:cummings at linkline.com]
      > > > Sent: Monday, April 23, 2001 11:08 AM
      > > > To: James Crotinger
      > > > Cc: Pooma Developers
      > > > Subject: [pooma-dev] DynamicArray destroy methods
      > > >
      > > >
      > > > Jim,
      > > >
      > > > I was going to add new destroy() functions
      > > > to Particles corresponding to the new
      > > > IteratorPairDomain-based functions you
      > > > added to DynamicArray.  I noticed three minor
      > > > glitches in DynamicArray.h that I was going
      > > > to fix, if you don't object.  One is on
      > > > line 486.  We don't need to provide the
      > > > BackFill() argument here because dynamic
      > > > engines already provide a destroy() function
      > > > that takes just a Domain argument.  (No harm
      > > > done here though, and I think this glitch
      > > > was here prior to your recent changes.)  The
      > > > next item is on line 501.  You left out the
      > > > Pooma:: qualifier on the IteratorPairDomain
      > > > type.  It should be there for consistency,
      > > > although there is probably a "using namespace
      > > > Pooma;" statement somewhere that is making
      > > > this work as written.  The last problem is on
      > > > line 542.  I think you do have to provide the
      > > > BackFill() argument here because MPEngine only
      > > > provides three versions of destroy(): domain,
      > > > domain and patchID, or domain, patchID and method.
      > > >
      > > > I was trying to check out this third item when
      > > > I ran into another problem.  Perhaps others can
      > > > chime in on this.  I modified dynamic_array_test5.cpp
      > > > to call destroy() without specifying a method.  So
      > > > I made calls with arguments (int*,int*) and with
      > > > (vector<int>::iterator,vector<int>::iterator,int).
      > > > The first call should invoke destroy() with Iter
      > > > equal to int* (DynamicArray.h, line 498), but gcc
      > > > says the overload is ambiguous with the version on
      > > > line 477 also being plausible.  I thought matching
      > > > one template parameter always beats matching two.
      > > > With my second call, I was trying to invoke the
      > > > destroy() function on line 538 of DynamicArray.h,
      > > > but gcc thinks the version on line 491 is a good
      > > > match also.  Again I am surprised because PatchID_t
      > > > is defined as int, and that exactly matches the
      > > > type of my third argument.  What's the deal?
      > > >
      > > > Julian C.
      > > >
      > > >
      > >
      >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010425/e655f8c2/attachment.html>

From scotth at proximation.com  Wed Apr 25 17:19:17 2001
From: scotth at proximation.com (Scott Haney)
Date: Wed, 25 Apr 2001 11:19:17 -0600
Subject: Request for Review
Message-ID: <mailman.16.1331172042.20475.pooma-dev@codesourcery.com>

I was looking at the changes that Julian made to Range, Interval, etc 
and, as reported by John, they indeed don't compile under Metrowerks. 
However, it seems like they shouldn't compile at all unless there is yet 
another corner case of C++. Here's the deal:

We have a class, which is a full specialization of a templated class:

template<class T> class Interval;

template<>
class Interval<1> {
   ...

   template<class T1, class T2>
   Interval(const T1 &m, const T2 &n);

};

The question is what does the definition of the constructor look like 
outside the class body. Julian had:

template<class T1, class T2>
Interval<1>::Interval(const T1, &m, const T2 &n) { ... }

Metrowerks complains of "Illegal function overloading" and I originally 
just thought this was a bug, but on further thought, it looks like the 
function should read:

template<>
template<class T1, class T2>
Interval<1>::Interval(const T1, &m, const T2 &n) { ... }

This compiles with CodeWarrior and it makes sense to me, but is this 
correct? If so, I'll check in the changes, which consist of adding the 
template<> on the top of the 6 out of line ctors at the bottom of 
Interval.h, Grid.h, and Range.h.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1222 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010425/9bba7712/attachment.bin>

From cummings at linkline.com  Thu Apr 26 08:11:39 2001
From: cummings at linkline.com (Julian C. Cummings)
Date: Thu, 26 Apr 2001 01:11:39 -0700
Subject: [pooma-dev] Request for Review
In-Reply-To: <20010425171850.B956D16352A@smtp1.linkline.com>
Message-ID: <NEBBLCJDELMDOJLGLNJGEELPCBAA.cummings@linkline.com>

Hi Scott,

I actually had written those templated constructor definitions
the way you suggest at first.  I think that the "template <>"
should be there, indicating the specialization of the class
template.  However, both the HP aCC compiler and (more
importantly) the Intel VTune compiler get confused by this.

This looks like a case where not all compilers have caught
up with the correct syntax.  I think the best thing to do is what
John suggested: put the constructor definitions back inside
the class definition.  That seems to work for all compilers
except aCC as far as I know, and there are a *lot* of other
problems with that compiler besides this one that are stopping
it from handling Pooma correctly.

Julian C.

  -----Original Message-----
  From: Scott Haney [mailto:scotth at proximation.com]
  Sent: Wednesday, April 25, 2001 10:19 AM
  To: pooma-dev at pooma.codesourcery.com
  Subject: [pooma-dev] Request for Review


  I was looking at the changes that Julian made to Range, Interval, etc and,
as reported by John, they indeed don't compile under Metrowerks. However, it
seems like they shouldn't compile at all unless there is yet another corner
case of C++. Here's the deal:

  We have a class, which is a full specialization of a templated class:

  template<class T> class Interval;

  template<>
  class Interval<1> {
  ...

  template<class T1, class T2>
  Interval(const T1 &m, const T2 &n);

  };

  The question is what does the definition of the constructor look like
outside the class body. Julian had:

  template<class T1, class T2>
  Interval<1>::Interval(const T1, &m, const T2 &n) { ... }

  Metrowerks complains of "Illegal function overloading" and I originally
just thought this was a bug, but on further thought, it looks like the
function should read:

  template<>
  template<class T1, class T2>
  Interval<1>::Interval(const T1, &m, const T2 &n) { ... }

  This compiles with CodeWarrior and it makes sense to me, but is this
correct? If so, I'll check in the changes, which consist of adding the
template<> on the top of the 6 out of line ctors at the bottom of
Interval.h, Grid.h, and Range.h.

  Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010426/64ae630c/attachment.html>

From JimC at proximation.com  Thu Apr 26 20:12:37 2001
From: JimC at proximation.com (James Crotinger)
Date: Thu, 26 Apr 2001 13:12:37 -0700
Subject: [pooma-dev] DynamicArray destroy methods
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BEF@proxim-sf001.santafe.proximation.com>

Perhaps we should use different names for the destroy methods that take
iterators. Ordinarily, my preference would be "destroyRange", but Range has
a special connotation in Pooma, so perhaps that isn't so good here. Also,
for the functions that take a patchID - does the ID have to be local? Is it
a local ID? Or global? If local, the perhaps we should go with destroyLocal
and destroyGlobal. It just seems that we have too many connotations rolled
into one overloade method name. 
 
    Jim
 

-----Original Message-----
From: Julian C. Cummings [mailto:cummings at linkline.com]
Sent: Wednesday, April 25, 2001 9:57 AM
To: pooma-dev at pooma.codesourcery.com
Subject: RE: [pooma-dev] DynamicArray destroy methods


Can I get some final comments and closure on this?
I'd like to check in fixes for the problem with overloading
destroy(), and the incorrect return type of non-const
operator() in IteratorPairDomain.  For the first problem,
there seem to be three solutions: pass tags by const ref,
pass destroy methods as an enum type rather than tag
classes, or specialize destroy() to each of the two destroy
methods that we provide.  The first solution is kind of a
tricky hack, but it does work.  The third one is less elegant
but certainly works as well.  Either of these seems OK to me.
 
I'd like to make some decisions on these little items, so I
can check in the fixes and move on.
 
Thanks, Julian C.
 

-----Original Message-----
From: James Crotinger [mailto:JimC at proximation.com]
Sent: Monday, April 23, 2001 2:21 PM
To: 'pooma-dev at pooma.codesourcery.com'
Subject: RE: [pooma-dev] DynamicArray destroy methods


Mark or Allan, any comment on these issues? I'm mostly just following
instinct based on what I see in the STL, where iterators, tags, functors,
etc., seem to always be passed by value, and only the container's value's
are passed by reference. Passing by reference has to incur some overhead for
small objects, but perhaps it isn't important (you are, after all, passing a
pointer on the stack and not the value, so there has to be at least one
dereference in the function body - perhaps the compiler can optimize other
derefs away, but only if it doesn't run out of registers for other things).
However, I definitely don't understand the second problem Julian's having.
The fundamental source of the problem is that we have Domain and Method
(tag) template parameters and so we have the following destroy overloads:
 
template <class Dom, class Meth)   destroy(const Dom &, const Meth&);
 
template <class Dom>               destroy(const Dom &);
 
template <class Iter, class Meth)  destroy(Iter begin, Iter end, const Meth
&);
 
template <class Iter>              destroy(Iter begin, Iter end);
 
template <class Dom, class Meth)   destroy(const Dom &, int, const Meth &);
 
template <class Dom>               destroy(const Dom &, int);
 
template <class Iter, class Meth>  destroy(Iter, Iter, int, const Meth &);
 
template <class Iter>              destroy(Iter, Iter, int);
 

(We do want to pass Domains by reference here since they are not necessarily
small objects. I would tend to pass everything else by value, though, so I'd
also change "const Meth &" to just "Meth". But I don't THINK that
significantly simplifies the complexity.)
 
Now that I see all of these, I do feel like this is a recipe for disaster.
Julian "fixed" it by passing everything by reference, but this seems like a
hack. If having both
 
  destroy(const Dom &,const Meth &)
 
and 
 
  destroy(Iter,Iter)
 
is causing an ambiguity with:
 
  int *p = ...;
  a.destroy(p, p+3)
 
I'm guessing this is just telling us that we're in template hell. 8-) This
looks to me like it should work with the above, but perhaps we've just tried
to get too fancy.
 
We could fix the problem by passing an enum instead of a tag, or by
explicitly overloading on Shiftup and BackFill, the only two types that are
valid to pass as the Meth parameter right now.
 
Thoughts? 
 
    Jim
 
 -----Original Message-----
From: Julian C. Cummings [mailto:cummings at linkline.com]
Sent: Monday, April 23, 2001 2:20 PM
To: James Crotinger; Pooma Developers
Subject: RE: [pooma-dev] DynamicArray destroy methods



Hi Jim,
 
I'm pretty sure your performance concerns are unfounded.
Accessing object methods via reference should never incur
a performance penalty, just as using the dot operator and
the arrow operator should be equivalent.  If this were not the
case, almost all C++ code ever written would have problems.
There is a performance penalty when you pass a heavyweight
object by value, of course.
 
In any case, I did a quick test of your idea.  It can be made 
to work, but is slightly more annoying in actual use.  In order
for the pass-by-value to match when passing an iterator pair,
both of the arguments must be local objects that can be copied.
Thus, passing something like (dptr,dptr+3), where dptr is an
int*, once again triggers the ambiguity error.  The compiler thinks 
you have passed an int* & and an int*, and these two arguments
are not exactly the same.  So you have to declare a second 
int* object and set it equal to dptr+3.  With const references,
this little annoyance is gone.
 
Julian C.
 
P.S.  I stumbled over another potential bug, this time in the 
IteratorPairDomain class.  The non-const version of operator()
returns an Element_t&.  This is incorrect when Iter is a const T*.
I think we need to add a typedef for ElementRef_t, which would 
be set to std::iterator_traits<Iter>::reference, and return that here.
 

-----Original Message-----
From: James Crotinger [mailto:JimC at proximation.com]
Sent: Monday, April 23, 2001 12:20 PM
To: 'cummings at linkline.com'; Pooma Developers
Subject: RE: [pooma-dev] DynamicArray destroy methods



I tend not to like this idea. Won't passing references result in
dereferencing every time you use the object in question? With iterators and
ints I would think this could potentially impact performance. 

What about going the other way and passing the Destroy tag by value? We
might need to write a dummy copy constructor for the tag, but that's not so
hard. 

        Jim 


> -----Original Message----- 
> From: Julian C. Cummings [ mailto:cummings at linkline.com
<mailto:cummings at linkline.com> ] 
> Sent: Monday, April 23, 2001 12:59 PM 
> To: Pooma Developers 
> Subject: RE: [pooma-dev] DynamicArray destroy methods 
> 
> 
> Never mind!  I just figured out the problem 
> and the solution.  The reason for the overload 
> ambiguities is that we were defining the 
> destroy() functions to take domain and destroy 
> method arguments by const reference but take 
> iterators and patch IDs by value.  So the 
> overloads did not match the function calls in 
> exactly the same way, and I guess const int& is 
> preferred to int when you pass a literal int 
> like "6".  Also, you have to be careful about 
> passing with an int array like killList because 
> it is not treated quite the same as &killList[0] 
> when it comes to argument matching. 
> 
> Anyhow, once I changed the iterator and patchID 
> arguments to be passed by const reference, all 
> the function overloads matched as expected.  I'd 
> like to check in these fixes to DynamicArray.h 
> along with the minor fixes I mentioned in my 
> original e-mail on this, barring any objections. 
> I am attaching the diff's for DynamicArray.h 
> Sorry for the volley of e-mails on this. 
> 
> Julian C. 
> 
> 
> > -----Original Message----- 
> > From: Julian C. Cummings [ mailto:cummings at linkline.com
<mailto:cummings at linkline.com> ] 
> > Sent: Monday, April 23, 2001 11:19 AM 
> > To: Pooma Developers 
> > Subject: RE: [pooma-dev] DynamicArray destroy methods 
> > 
> > 
> > One way out of the function overloading 
> > quandary I noted below would be to call 
> > out versions of destroy() for each of the 
> > two existing destroy methods, BackFill 
> > and ShiftUp, rather than use a template 
> > parameter.  We are unlikely to add more 
> > of these, and if we do, they have to be 
> > added to the list in DynamicEvents anyway. 
> > Should we take this approach? 
> > 
> > Julian C. 
> > 
> > 
> > > -----Original Message----- 
> > > From: Julian C. Cummings [ mailto:cummings at linkline.com
<mailto:cummings at linkline.com> ] 
> > > Sent: Monday, April 23, 2001 11:08 AM 
> > > To: James Crotinger 
> > > Cc: Pooma Developers 
> > > Subject: [pooma-dev] DynamicArray destroy methods 
> > > 
> > > 
> > > Jim, 
> > > 
> > > I was going to add new destroy() functions 
> > > to Particles corresponding to the new 
> > > IteratorPairDomain-based functions you 
> > > added to DynamicArray.  I noticed three minor 
> > > glitches in DynamicArray.h that I was going 
> > > to fix, if you don't object.  One is on 
> > > line 486.  We don't need to provide the 
> > > BackFill() argument here because dynamic 
> > > engines already provide a destroy() function 
> > > that takes just a Domain argument.  (No harm 
> > > done here though, and I think this glitch 
> > > was here prior to your recent changes.)  The 
> > > next item is on line 501.  You left out the 
> > > Pooma:: qualifier on the IteratorPairDomain 
> > > type.  It should be there for consistency, 
> > > although there is probably a "using namespace 
> > > Pooma;" statement somewhere that is making 
> > > this work as written.  The last problem is on 
> > > line 542.  I think you do have to provide the 
> > > BackFill() argument here because MPEngine only 
> > > provides three versions of destroy(): domain, 
> > > domain and patchID, or domain, patchID and method. 
> > > 
> > > I was trying to check out this third item when 
> > > I ran into another problem.  Perhaps others can 
> > > chime in on this.  I modified dynamic_array_test5.cpp 
> > > to call destroy() without specifying a method.  So 
> > > I made calls with arguments (int*,int*) and with 
> > > (vector<int>::iterator,vector<int>::iterator,int). 
> > > The first call should invoke destroy() with Iter 
> > > equal to int* (DynamicArray.h, line 498), but gcc 
> > > says the overload is ambiguous with the version on 
> > > line 477 also being plausible.  I thought matching 
> > > one template parameter always beats matching two. 
> > > With my second call, I was trying to invoke the 
> > > destroy() function on line 538 of DynamicArray.h, 
> > > but gcc thinks the version on line 491 is a good 
> > > match also.  Again I am surprised because PatchID_t 
> > > is defined as int, and that exactly matches the 
> > > type of my third argument.  What's the deal? 
> > > 
> > > Julian C. 
> > > 
> > > 
> > 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010426/2e381273/attachment.html>

From scotth at proximation.com  Fri Apr 27 23:53:07 2001
From: scotth at proximation.com (Scott Haney)
Date: Fri, 27 Apr 2001 17:53:07 -0600
Subject: Status
Message-ID: <mailman.17.1331172042.20475.pooma-dev@codesourcery.com>

I worked on fixing two bugs that were giving the Blanca team trouble:

(1) There was a pretty serious memory leak that occurred when Updaters 
were added to Fields (well, maybe "pretty" is a little bit of an 
understatement - between 30 and 50% of all bytes allocated to Fields 
were being leaked :-). Updaters are used to enforce boundary conditions 
or support Blanca'a relations. They are supposed to be automatically run 
prior to evaluation if a "dirty" flag is set. One of the big advances in 
POOMA 2 is that standard, data-parallel notation can be used to write 
updaters. This presents a minor problem in that an updater targeting a 
Field operates on a mostly shallow copy of that Field. I say "mostly" 
because one needs to make sure that an operation on the Field stored in 
an Updater doesn't end up causing that Updater to be subsequently 
invoked. This causes infinite recursion. The solution is to strip 
Updaters for the Field stored in an updater. We weren't doing this 
correctly and this ultimately caused the memory leak. To make a copy of 
a Field without Updaters is:

Field_t f(...);
f.addUpdaters(...);
Field_t g(f, Pooma::DontCopyUpdaters());

This was a tough one without good memory diagnostic tools. Stephen 
ultimately figured out the problem, which was quite subtle.

(2) We forgot to make sure that Updaters were run before a Field was 
reduced (e.g., in sum, etc).

I checked in changes for both of these problems. They were reviewed by 
John Hall.

I also checked in a CodeWarrior fix for the out-of-line constructors in 
Interval.h, etc. I never heard definitively on what the correct syntax 
was, so I opted for a solution that looks like it will compile 
everywhere.

Scott


From JimC at proximation.com  Sat Apr 28 18:47:53 2001
From: JimC at proximation.com (James Crotinger)
Date: Sat, 28 Apr 2001 11:47:53 -0700
Subject: Status
Message-ID: <F871BB04B0EA224A821A5274C31DF3152BF0@proxim-sf001.santafe.proximation.com>

Aside from some discussions with Scott and keeping up on Pooma email, I
spent the week focused on Proximation stuff. 

  Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010428/d46ce4ad/attachment.html>