From rguenth at tat.physik.uni-tuebingen.de  Mon Nov  3 12:36:19 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Mon, 3 Nov 2003 13:36:19 +0100 (CET)
Subject: [PATCH] Clean up Tensor.h
Message-ID: <Pine.LNX.4.44.0311031312240.1646-100000@bellatrix.tat.physik.uni-tuebingen.de>

Hi!

I'm staring a lot on Tensor.h and TensorElement.h from time to time.
And I think its very complicated and undocumented. Does anyone remember
what exactly the TensorAssign<> template is doing? And why it was done
this way instead of simple loops? Are the T1 and T2 argument templates
really independend, or are they supposed to have the same tensor structure
(Antisymmentric, Symmetric, etc.) and the same base type?

Anyway, here's some first cleanup to reduce the code one has to look at ;)

Tested on x86 using gcc3.3 and Intel icpc.

Ok?

Richard.


2003Nov03  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Tiny/Tensor.h: remove default implementations of
	(Antisymmentric|Symmetric|Diagonal)TensorAssign<>.
	Use template template parameter specialization
	to get rid of Tensor<> and TensorEngine<> specialization
	duplicates.

===== Tensor.h 1.8 vs edited =====
--- 1.8/r2/src/Tiny/Tensor.h	Mon Nov  3 11:03:34 2003
+++ edited/Tensor.h	Mon Nov  3 13:02:25 2003
@@ -871,64 +871,36 @@
 struct AntisymmetricTensorAssign;

 // 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<1,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<1,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  { }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<1,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct AntisymmetricTensorAssign<T1<1,T,Antisymmetric>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(Tensor<1,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<1,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   { }
 };
+
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<2,T,Antisymmetric>,
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct AntisymmetricTensorAssign<T1<2,T,Antisymmetric>,
   T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<2,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<2,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   {
-    TensorAssign<TensorEngine<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<2,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
   }
 };
+
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<3,T,Antisymmetric>,
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct AntisymmetricTensorAssign<T1<3,T,Antisymmetric>,
   T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<3,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<3,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   {
-    TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<3,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<3,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
   }
 };

@@ -1148,71 +1120,37 @@
 struct SymmetricTensorAssign;

 // 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<1,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<1,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<TensorEngine<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<1,T,Symmetric>,
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct SymmetricTensorAssign<T1<1,T,Symmetric>,
   T2,Op,B1,L1,B2,L2>
 {
-  static void apply(Tensor<1,T,Symmetric> &x, const T2 &y,
+  static void apply(T1<1,T,Symmetric> &x, const T2 &y,
                     Op op=Op())
   {
-    TensorAssign<Tensor<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
   }
 };
+
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<2,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct SymmetricTensorAssign<T1<2,T,Symmetric>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<2,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
+  static void apply(T1<2,T,Symmetric> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<TensorEngine<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<2,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
   }
 };
+
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<3,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct SymmetricTensorAssign<T1<3,T,Symmetric>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<3,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<3,T,Symmetric>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<3,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
+  static void apply(T1<3,T,Symmetric> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
   }
 };

@@ -1531,62 +1469,37 @@
 struct DiagonalTensorAssign;

 // 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct DiagonalTensorAssign<T1<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<1,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<1,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<TensorEngine<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<1,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-    TensorAssign<Tensor<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
   }
 };
+
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct DiagonalTensorAssign<T1<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<2,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<2,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,0,1,0,1>::
+    TensorAssign<T1<2,T,Diagonal>,T2,Op,0,1,0,1>::
       apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,1,1,1,1>::
+    TensorAssign<T1<2,T,Diagonal>,T2,Op,1,1,1,1>::
       apply(x,y,op);
   }
 };
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<2,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-  }
-};
+
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<3,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op, int B1, int L1, int B2, int L2>
+struct DiagonalTensorAssign<T1<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(Tensor<3,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<3,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
   }
 };




From jcrotinger at proximation.com  Mon Nov  3 14:32:21 2003
From: jcrotinger at proximation.com (James Crotinger)
Date: Mon, 3 Nov 2003 07:32:21 -0700 
Subject: [pooma-dev] [PATCH] Clean up Tensor.h
Message-ID: <F871BB04B0EA224A821A5274C31DF315129738@proxim-sf001.santafe.proximation.com>

Hi Richard,

It's been too long for me to comment on the details here. There were places
in the code where template meta-programs were used over loops in order to
get performance, and some developers (myself included - it's a fun thing to
play with but easy to overuse) used these in places where loops would have
sufficed (assuming the upper limits were small and were compile-time
constants, so that they could be completely unrolled). There was a wave of
simplifications (between 2.2 and 2.3 I think) that cleaned most of these out
as the meta-programs were adding a lot to compile time. If this is the
nature of your changes, and if the changed code still generates good
assembly-code, then the Tensor stuff was probably missed during this
cleanup.

It does look like your changes make use of template template parameters.
This will hurt portability. I don't think those were supported by anyone
when this code was written, and I'm not sure how widely they are supported
now. Probably the high-performance compilers can handle them, but at least
in the past a number of people would do development with Metrowerks and VC++
since they were/are very productive environments, and they've tended to lag
on details such as these. I'd probably avoid them for this reason. 

	Jim


-----Original Message-----
From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] 
Sent: Monday, November 03, 2003 5:36 AM
To: pooma-dev at pooma.codesourcery.com
Cc: Jeffrey D. Oldham
Subject: [pooma-dev] [PATCH] Clean up Tensor.h

Hi!

I'm staring a lot on Tensor.h and TensorElement.h from time to time.
And I think its very complicated and undocumented. Does anyone remember
what exactly the TensorAssign<> template is doing? And why it was done
this way instead of simple loops? Are the T1 and T2 argument templates
really independend, or are they supposed to have the same tensor structure
(Antisymmentric, Symmetric, etc.) and the same base type?

Anyway, here's some first cleanup to reduce the code one has to look at ;)

Tested on x86 using gcc3.3 and Intel icpc.

Ok?

Richard.


2003Nov03  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Tiny/Tensor.h: remove default implementations of
	(Antisymmentric|Symmetric|Diagonal)TensorAssign<>.
	Use template template parameter specialization
	to get rid of Tensor<> and TensorEngine<> specialization
	duplicates.

===== Tensor.h 1.8 vs edited =====
--- 1.8/r2/src/Tiny/Tensor.h	Mon Nov  3 11:03:34 2003
+++ edited/Tensor.h	Mon Nov  3 13:02:25 2003
@@ -871,64 +871,36 @@
 struct AntisymmetricTensorAssign;

 // 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<1,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<1,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  { }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<1,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct AntisymmetricTensorAssign<T1<1,T,Antisymmetric>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(Tensor<1,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<1,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   { }
 };
+
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<2,T,Antisymmetric>,
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct AntisymmetricTensorAssign<T1<2,T,Antisymmetric>,
   T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<2,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<2,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   {
-
TensorAssign<TensorEngine<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<2,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
   }
 };
+
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<3,T,Antisymmetric>,
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct AntisymmetricTensorAssign<T1<3,T,Antisymmetric>,
   T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<3,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<3,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   {
-
TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-
TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<3,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<3,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
   }
 };

@@ -1148,71 +1120,37 @@
 struct SymmetricTensorAssign;

 // 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<1,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<1,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<TensorEngine<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<1,T,Symmetric>,
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct SymmetricTensorAssign<T1<1,T,Symmetric>,
   T2,Op,B1,L1,B2,L2>
 {
-  static void apply(Tensor<1,T,Symmetric> &x, const T2 &y,
+  static void apply(T1<1,T,Symmetric> &x, const T2 &y,
                     Op op=Op())
   {
-    TensorAssign<Tensor<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
   }
 };
+
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<2,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct SymmetricTensorAssign<T1<2,T,Symmetric>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<2,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
+  static void apply(T1<2,T,Symmetric> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<TensorEngine<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<2,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
   }
 };
+
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<3,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct SymmetricTensorAssign<T1<3,T,Symmetric>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<3,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<3,T,Symmetric>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<3,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
+  static void apply(T1<3,T,Symmetric> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
   }
 };

@@ -1531,62 +1469,37 @@
 struct DiagonalTensorAssign;

 // 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct DiagonalTensorAssign<T1<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<1,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<1,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<TensorEngine<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<1,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-    TensorAssign<Tensor<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
   }
 };
+
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct DiagonalTensorAssign<T1<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(TensorEngine<2,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<2,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,0,1,0,1>::
+    TensorAssign<T1<2,T,Diagonal>,T2,Op,0,1,0,1>::
       apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,1,1,1,1>::
+    TensorAssign<T1<2,T,Diagonal>,T2,Op,1,1,1,1>::
       apply(x,y,op);
   }
 };
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<2,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-  }
-};
+
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<3,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class
Op, int B1, int L1, int B2, int L2>
+struct DiagonalTensorAssign<T1<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
 {
-  static void apply(Tensor<3,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<3,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
   }
 };

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

From rguenth at tat.physik.uni-tuebingen.de  Mon Nov  3 14:43:19 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Mon, 3 Nov 2003 15:43:19 +0100 (CET)
Subject: [pooma-dev] [PATCH] Clean up Tensor.h
In-Reply-To: <F871BB04B0EA224A821A5274C31DF315129738@proxim-sf001.santafe.proximation.com>
Message-ID: <Pine.LNX.4.44.0311031535080.1646-100000@bellatrix.tat.physik.uni-tuebingen.de>

On Mon, 3 Nov 2003, James Crotinger wrote:

> Hi Richard,
>
> It's been too long for me to comment on the details here. There were places
> in the code where template meta-programs were used over loops in order to
> get performance, and some developers (myself included - it's a fun thing to
> play with but easy to overuse) used these in places where loops would have
> sufficed (assuming the upper limits were small and were compile-time
> constants, so that they could be completely unrolled). There was a wave of
> simplifications (between 2.2 and 2.3 I think) that cleaned most of these out
> as the meta-programs were adding a lot to compile time. If this is the
> nature of your changes, and if the changed code still generates good
> assembly-code, then the Tensor stuff was probably missed during this
> cleanup.

Ok, I'll have another look into Tensor.h then and figure out if the
template metaprogams can do any magic a simple loop implementation cannot
do. If not, I'm going to scrap the metaprograms in favor of simple loops.
Like

 TensorAssign<TensorEngine<Dim, T, Tag>, TensorEngine<Dim, T2, Tag>, Op >
  ::apply(T1& t1, T2& t2, Op& op) {
    for (int i=0; i<TensorStorageSize<Dim, Tag>::size; ++i)
      op(t1(i), t2(i));
 }

for matching dimensions and engine tags.

> It does look like your changes make use of template template parameters.
> This will hurt portability. I don't think those were supported by anyone
> when this code was written, and I'm not sure how widely they are supported
> now. Probably the high-performance compilers can handle them, but at least
> in the past a number of people would do development with Metrowerks and VC++
> since they were/are very productive environments, and they've tended to lag
> on details such as these. I'd probably avoid them for this reason.

I think they are widely supported now.  This also raises the question, if
we're going to require an ISO C++ conformant compiler for future releases,
which I would encourage.  Even MS is shipping one with .NET now.

Richard.

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



From jcrotinger at proximation.com  Mon Nov  3 15:27:49 2003
From: jcrotinger at proximation.com (James Crotinger)
Date: Mon, 3 Nov 2003 08:27:49 -0700 
Subject: [pooma-dev] [PATCH] Clean up Tensor.h
Message-ID: <F871BB04B0EA224A821A5274C31DF315129739@proxim-sf001.santafe.proximation.com>


> I think they are widely supported now.  This also raises the question, if
> we're going to require an ISO C++ conformant compiler for future releases,
> which I would encourage.  Even MS is shipping one with .NET now.

Wow - everyone's figured out how to implement export? 8^) 

	Jim

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

From rguenth at tat.physik.uni-tuebingen.de  Mon Nov  3 15:30:40 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Mon, 3 Nov 2003 16:30:40 +0100 (CET)
Subject: [pooma-dev] [PATCH] Clean up Tensor.h
In-Reply-To: <F871BB04B0EA224A821A5274C31DF315129739@proxim-sf001.santafe.proximation.com>
Message-ID: <Pine.LNX.4.44.0311031629190.1646-100000@bellatrix.tat.physik.uni-tuebingen.de>

On Mon, 3 Nov 2003, James Crotinger wrote:

>
> > I think they are widely supported now.  This also raises the question, if
> > we're going to require an ISO C++ conformant compiler for future releases,
> > which I would encourage.  Even MS is shipping one with .NET now.
>
> Wow - everyone's figured out how to implement export? 8^)

At least they know how to ignore it ;)

Oh - the TensorBinaryCombine<> template seems to be unused. Can we kill
it?

Richard.

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



From rguenth at tat.physik.uni-tuebingen.de  Thu Nov  6 21:01:45 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 6 Nov 2003 22:01:45 +0100 (CET)
Subject: [RFA/PATCH] FieldEngine FIXMEs anyone?
Message-ID: <Pine.LNX.4.58.0311062151530.599@goofy>

Hi!

While looking for the cause of centering views of FieldEngines being to
costly, I noticed several points in the FieldEngine implementation:
 - lots of FIXMEs!
 - a mix of weird centeringSize()/numMaterials() checks and
   implementations differing for specific cases
 - interesting way of keeping track of the domains in case of multiple
   centering points
 - everything is with respect to cell domains, not vertex domains (as
   arrays and also Meshes expect)

In the way of understanding whats going on, I added some documentation
and two new subfield view constructors (see patch below).

Can anyone elaborate on the successful usages of the centering/materials
concept from real applications?  Would it be acceptable to remove all the
special-cases for centeringSize()==1 and/or numMaterials()==1?

Does it really make sense to take views of multiple-centering fields? If
yes, can we change the expected domains to be vertex domains instead? So
an application can transparently switch Array/Field for vertex centerings.

Is there some documentation on why/how the INode and FieldEnginePatch
views are supposed to work and what is the advantage of using them
compared to usual domain views?


Thanks for any hints,

Richard.


===== FieldEngine.h 1.7 vs edited =====
--- 1.7/r2/src/Field/FieldEngine/FieldEngine.h	Mon Oct 27 11:25:16 2003
+++ edited/FieldEngine.h	Thu Nov  6 21:25:18 2003
@@ -37,7 +37,7 @@
 /** @file
  * @ingroup Field
  * @brief
- * FieldEngineBase and related classes.
+ * FieldEngine and FieldEngineBaseData classes.
  *
  * POOMA supports a flexible form
  * of "centering" that allows a hierarchy of multiple centering points per
@@ -69,6 +69,11 @@
 template<int Dim, class T, class EngineTag> class Engine;
 template<class Components> class ComponentWrapper;

+namespace Pooma {
+  struct MaterialViewTag {};
+  struct CenteringViewTag {};
+}
+

 /**
  * FieldEngineBaseData holds an engine and the relations.
@@ -83,6 +88,9 @@
     : engine_m()
   { }

+  /// Initializer to be used with an engine compatible layout or
+  /// similar initializer.
+
   template<class Initializer>
   FieldEngineBaseData(const Initializer &init)
     : engine_m(init)
@@ -192,41 +200,57 @@
   {
   }

-  /// Sub-field view constructor. This is when we want to construct a view of
-  /// one of the subFields in our top-level list.
-
-  FieldEngine(const This_t &model, int subField)
+  ///@name Sub-field view constructors
+  //@{
+
+  /// Takes a view of the specified centering point of the specified material.
+
+  FieldEngine(const This_t &model, int m, int c)
     : num_materials_m(1),
       stride_m(model.stride_m),
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
-    if (model.numMaterials() > 1)
-    {
-      centering_m = model.centering();
-      data_m = model.data_m + model.stride_m * subField;
-    }
-    else
-    {
-      centering_m = model.centering()[subField];
-      data_m = model.data_m + subField;
-    }
+    PAssert((m >= 0) && (m < model.numMaterials()));
+    PAssert((c >= 0) && (c < model.centeringSize()));
+    centering_m = model.centering()[c];
+    data_m = model.data_m + model.stride_m * m + c;
   }

-  FieldEngine(const This_t &model, int m, int c)
-    : num_materials_m(1),
+  /// Takes a view of the specified centering point from all
+  /// materials.
+
+  FieldEngine(const This_t &model, int c, const Pooma::CenteringViewTag&)
+    : num_materials_m(model.num_materials_m),
       stride_m(model.stride_m),
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
-    PAssert((m >= 0) && (m < model.numMaterials()));
     PAssert((c >= 0) && (c < model.centeringSize()));
     centering_m = model.centering()[c];
-    data_m = model.data_m + model.stride_m * m + c;
+    data_m = model.data_m + c;
   }

+  /// Takes a view of the specified material retaining all centering points.
+
+  FieldEngine(const This_t &model, int m, const Pooma::MaterialViewTag&)
+    : num_materials_m(1),
+      centering_m(model.centering_m),
+      stride_m(model.stride_m),
+      physicalCellDomain_m(model.physicalCellDomain_m),
+      guards_m(model.guards_m),
+      mesh_m(model.mesh_m)
+  {
+    PAssert((m >= 0) && (m < model.numMaterials()));
+    data_m = model.data_m + m * model.stride_m;
+  }
+
+  /// Takes a view of the specified centering point of the first material.
+  /// This is useless for fields with multiple materials and thus this
+  /// method is deprecated. Use FieldEngine(field, 0, c).
+
   FieldEngine(int c, const This_t &model)
     : num_materials_m(1),
       stride_m(model.stride_m),
@@ -239,7 +263,42 @@
     data_m = model.data_m + c;
   }

-  /// View constructors.
+  /// Takes a view of
+  ///  - the specified material including all centering points,
+  ///    if there is more than one material
+  ///  - the specified centering, if there is only one material
+  /// These are weird semantics and thus this method is deprecated.
+
+  FieldEngine(const This_t &model, int subField)
+    : num_materials_m(1),
+      stride_m(model.stride_m),
+      physicalCellDomain_m(model.physicalCellDomain_m),
+      guards_m(model.guards_m),
+      mesh_m(model.mesh_m)
+  {
+    PAssert((subField >= 0) && (subField < model.numSubFields()));
+    if (model.numMaterials() > 1)
+    {
+      centering_m = model.centering();
+      data_m = model.data_m + model.stride_m * subField;
+    }
+    else
+    {
+      centering_m = model.centering()[subField];
+      data_m = model.data_m + subField;
+    }
+  }
+
+  //@}
+
+  ///@name View constructors
+  //@{
+
+  /// Taking a domain view of the specified field-engine. For a field-engine
+  /// with one centering point and possibly multiple materials this is well
+  /// defined and expects the domain with respect to the centering of the
+  /// materials.  For multiple centerings this expects a cell domain as
+  /// viewing domain that is possibly extended to the respective vertex domain.

   template<class T2, class EngineTag2>
   FieldEngine(const FieldEngine<Mesh, T2, EngineTag2> &model,
@@ -277,29 +336,7 @@
     }
   }

-  /// This constructor handle weird things like range views.
-
-  template<class Mesh2, class T2, class EngineTag2, class Domain>
-  FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
-              const Domain &d)
-    : num_materials_m(model.numMaterials()),
-      centering_m(model.centering()),
-      stride_m(model.centeringSize()),
-      guards_m(0)
-  {
-    addSubFields();
-    // FIXME: Does this ever happen to fields with multiple centering points?
-    // (or event to fields with multiple materials???)
-    PAssert(model.centeringSize() == 1);
-    for (int m = 0; m < num_materials_m; ++m)
-    {
-      data(m, 0) = Data_t(model.data(m, 0).engine(), d,
-                          model.data(m, 0).relations());
-    }
-    // FIXME: how do we construct the mesh?????
-    mesh_m = Mesh(DomainLayout<Dim>(inputDomainToVertexDomain(data(0,0).engine().domain())));
-    physicalCellDomain_m = mesh_m.physicalCellDomain();
-  }
+  /// INode view.

   template<class T2, class EngineTag2>
   FieldEngine(const FieldEngine<Mesh, T2, EngineTag2> &model,
@@ -308,6 +345,11 @@
       centering_m(model.centering()),
       stride_m(model.centeringSize()),
       guards_m(0),
+      // FIXME: should hand INode to mesh?
+      // Probably, but Mesh(Mesh&, INode&) expects the INode domain
+      // being a vertex domain.
+      // This constructor expects a cell domain instead? I can't see how
+      // this can be correct for centering sizes > 1.
       mesh_m(model.mesh(),
              inputDomainToVertexDomain(i.domain())) // FIXME: should hand INode to mesh?
   {
@@ -363,6 +405,8 @@
     }
   }

+  /// FieldEnginePatch view.
+
   template<class EngineTag2>
   FieldEngine(const FieldEngine<Mesh, T, EngineTag2> &model,
               const FieldEnginePatch<Dim> &p)
@@ -370,7 +414,9 @@
       centering_m(model.centering()),
       stride_m(model.centeringSize()),
       guards_m(model.guardLayers()),
-      mesh_m(model.mesh()) // FIXME: should take a view of the mesh???
+      // FIXME: should take a view of the mesh???
+      // Yes. But again the mesh expects vertex domains.
+      mesh_m(model.mesh(), p)
   {
     // FIXME: should we copy the relations for patch?  Do we want
     // to take patch views of composite fields?
@@ -381,6 +427,8 @@
       centeringDomainToCellDomain(p.domain_m, centering_m, 0);
   }

+  /// Component view.
+
   template<class Mesh2, class T2, class EngineTag2, class Components>
   FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
               const ComponentWrapper<Components> &cw)
@@ -403,6 +451,33 @@
     }
   }

+  /// This constructor handle weird things like range views.
+  /// Its probably far from doing anything sane.
+
+  template<class Mesh2, class T2, class EngineTag2, class Domain>
+  FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
+              const Domain &d)
+    : num_materials_m(model.numMaterials()),
+      centering_m(model.centering()),
+      stride_m(model.centeringSize()),
+      guards_m(0)
+  {
+    addSubFields();
+    // FIXME: Does this ever happen to fields with multiple centering points?
+    // (or event to fields with multiple materials???)
+    PAssert(model.centeringSize() == 1);
+    for (int m = 0; m < num_materials_m; ++m)
+    {
+      data(m, 0) = Data_t(model.data(m, 0).engine(), d,
+                          model.data(m, 0).relations());
+    }
+    // FIXME: how do we construct the mesh?????
+    mesh_m = Mesh(DomainLayout<Dim>(inputDomainToVertexDomain(data(0,0).engine().domain())));
+    physicalCellDomain_m = mesh_m.physicalCellDomain();
+  }
+
+  //@}
+
   FieldEngine(const This_t &model,
               const Pooma::DontCopyRelations &d)
     : num_materials_m(model.numMaterials()),
@@ -673,6 +748,10 @@
   unsigned int num_materials_m;
   Centering<Dim> centering_m;
   int stride_m;
+  /// A one-dimensional organization of the FieldEngineBaseData
+  /// objects, for each of the numMaterials materials there are
+  /// centeringSize data objects. We use stride_m for taking
+  /// views, thus data(m,c) == data_m[material * stride_m + centering].
   RefCountedBlockPtr<Data_t> data_m;

   Domain_t physicalCellDomain_m;


From jxyh at lanl.gov  Thu Nov  6 21:19:45 2003
From: jxyh at lanl.gov (John H. Hall)
Date: Thu, 6 Nov 2003 14:19:45 -0700
Subject: [pooma-dev] [RFA/PATCH] FieldEngine FIXMEs anyone?
In-Reply-To: <Pine.LNX.4.58.0311062151530.599@goofy>
Message-ID: <F1DF2A7C-109E-11D8-B44C-000A958E5012@lanl.gov>

Richard:
I think we kinda got mixed up in the latest version of field and I am  
right in the middle of a proposal about how to correct our design. The  
concept of multi-material fields really should probably have been  
multi-material engines with different views for a multi- and  
single-material engine both pointing to the same data. We are getting  
pretty far along in our sparse mixed cell engine treatment and with  
some small modifications we would be able to interchange between the  
2.4 multi-material model and our new sparse multi-material model simply  
by choosing new engines.

The confusion you are pointing out is a strong indicator that we didn't  
quite get it right. I will follow up on this after I study it some more  
and discuss it with more of the old pooma team.
John Hall


On Thursday, November 6, 2003, at 02:01  PM, Richard Guenther wrote:

> Hi!
>
> While looking for the cause of centering views of FieldEngines being to
> costly, I noticed several points in the FieldEngine implementation:
>  - lots of FIXMEs!
>  - a mix of weird centeringSize()/numMaterials() checks and
>    implementations differing for specific cases
>  - interesting way of keeping track of the domains in case of multiple
>    centering points
>  - everything is with respect to cell domains, not vertex domains (as
>    arrays and also Meshes expect)
>
> In the way of understanding whats going on, I added some documentation
> and two new subfield view constructors (see patch below).
>
> Can anyone elaborate on the successful usages of the  
> centering/materials
> concept from real applications?  Would it be acceptable to remove all  
> the
> special-cases for centeringSize()==1 and/or numMaterials()==1?
>
> Does it really make sense to take views of multiple-centering fields?  
> If
> yes, can we change the expected domains to be vertex domains instead?  
> So
> an application can transparently switch Array/Field for vertex  
> centerings.
>
> Is there some documentation on why/how the INode and FieldEnginePatch
> views are supposed to work and what is the advantage of using them
> compared to usual domain views?
>
>
> Thanks for any hints,
>
> Richard.
>
>
> ===== FieldEngine.h 1.7 vs edited =====
> --- 1.7/r2/src/Field/FieldEngine/FieldEngine.h	Mon Oct 27 11:25:16 2003
> +++ edited/FieldEngine.h	Thu Nov  6 21:25:18 2003
> @@ -37,7 +37,7 @@
>  /** @file
>   * @ingroup Field
>   * @brief
> - * FieldEngineBase and related classes.
> + * FieldEngine and FieldEngineBaseData classes.
>   *
>   * POOMA supports a flexible form
>   * of "centering" that allows a hierarchy of multiple centering  
> points per
> @@ -69,6 +69,11 @@
>  template<int Dim, class T, class EngineTag> class Engine;
>  template<class Components> class ComponentWrapper;
>
> +namespace Pooma {
> +  struct MaterialViewTag {};
> +  struct CenteringViewTag {};
> +}
> +
>
>  /**
>   * FieldEngineBaseData holds an engine and the relations.
> @@ -83,6 +88,9 @@
>      : engine_m()
>    { }
>
> +  /// Initializer to be used with an engine compatible layout or
> +  /// similar initializer.
> +
>    template<class Initializer>
>    FieldEngineBaseData(const Initializer &init)
>      : engine_m(init)
> @@ -192,41 +200,57 @@
>    {
>    }
>
> -  /// Sub-field view constructor. This is when we want to construct a  
> view of
> -  /// one of the subFields in our top-level list.
> -
> -  FieldEngine(const This_t &model, int subField)
> +  ///@name Sub-field view constructors
> +  //@{
> +
> +  /// Takes a view of the specified centering point of the specified  
> material.
> +
> +  FieldEngine(const This_t &model, int m, int c)
>      : num_materials_m(1),
>        stride_m(model.stride_m),
>        physicalCellDomain_m(model.physicalCellDomain_m),
>        guards_m(model.guards_m),
>        mesh_m(model.mesh_m)
>    {
> -    if (model.numMaterials() > 1)
> -    {
> -      centering_m = model.centering();
> -      data_m = model.data_m + model.stride_m * subField;
> -    }
> -    else
> -    {
> -      centering_m = model.centering()[subField];
> -      data_m = model.data_m + subField;
> -    }
> +    PAssert((m >= 0) && (m < model.numMaterials()));
> +    PAssert((c >= 0) && (c < model.centeringSize()));
> +    centering_m = model.centering()[c];
> +    data_m = model.data_m + model.stride_m * m + c;
>    }
>
> -  FieldEngine(const This_t &model, int m, int c)
> -    : num_materials_m(1),
> +  /// Takes a view of the specified centering point from all
> +  /// materials.
> +
> +  FieldEngine(const This_t &model, int c, const  
> Pooma::CenteringViewTag&)
> +    : num_materials_m(model.num_materials_m),
>        stride_m(model.stride_m),
>        physicalCellDomain_m(model.physicalCellDomain_m),
>        guards_m(model.guards_m),
>        mesh_m(model.mesh_m)
>    {
> -    PAssert((m >= 0) && (m < model.numMaterials()));
>      PAssert((c >= 0) && (c < model.centeringSize()));
>      centering_m = model.centering()[c];
> -    data_m = model.data_m + model.stride_m * m + c;
> +    data_m = model.data_m + c;
>    }
>
> +  /// Takes a view of the specified material retaining all centering  
> points.
> +
> +  FieldEngine(const This_t &model, int m, const  
> Pooma::MaterialViewTag&)
> +    : num_materials_m(1),
> +      centering_m(model.centering_m),
> +      stride_m(model.stride_m),
> +      physicalCellDomain_m(model.physicalCellDomain_m),
> +      guards_m(model.guards_m),
> +      mesh_m(model.mesh_m)
> +  {
> +    PAssert((m >= 0) && (m < model.numMaterials()));
> +    data_m = model.data_m + m * model.stride_m;
> +  }
> +
> +  /// Takes a view of the specified centering point of the first  
> material.
> +  /// This is useless for fields with multiple materials and thus this
> +  /// method is deprecated. Use FieldEngine(field, 0, c).
> +
>    FieldEngine(int c, const This_t &model)
>      : num_materials_m(1),
>        stride_m(model.stride_m),
> @@ -239,7 +263,42 @@
>      data_m = model.data_m + c;
>    }
>
> -  /// View constructors.
> +  /// Takes a view of
> +  ///  - the specified material including all centering points,
> +  ///    if there is more than one material
> +  ///  - the specified centering, if there is only one material
> +  /// These are weird semantics and thus this method is deprecated.
> +
> +  FieldEngine(const This_t &model, int subField)
> +    : num_materials_m(1),
> +      stride_m(model.stride_m),
> +      physicalCellDomain_m(model.physicalCellDomain_m),
> +      guards_m(model.guards_m),
> +      mesh_m(model.mesh_m)
> +  {
> +    PAssert((subField >= 0) && (subField < model.numSubFields()));
> +    if (model.numMaterials() > 1)
> +    {
> +      centering_m = model.centering();
> +      data_m = model.data_m + model.stride_m * subField;
> +    }
> +    else
> +    {
> +      centering_m = model.centering()[subField];
> +      data_m = model.data_m + subField;
> +    }
> +  }
> +
> +  //@}
> +
> +  ///@name View constructors
> +  //@{
> +
> +  /// Taking a domain view of the specified field-engine. For a  
> field-engine
> +  /// with one centering point and possibly multiple materials this  
> is well
> +  /// defined and expects the domain with respect to the centering of  
> the
> +  /// materials.  For multiple centerings this expects a cell domain  
> as
> +  /// viewing domain that is possibly extended to the respective  
> vertex domain.
>
>    template<class T2, class EngineTag2>
>    FieldEngine(const FieldEngine<Mesh, T2, EngineTag2> &model,
> @@ -277,29 +336,7 @@
>      }
>    }
>
> -  /// This constructor handle weird things like range views.
> -
> -  template<class Mesh2, class T2, class EngineTag2, class Domain>
> -  FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
> -              const Domain &d)
> -    : num_materials_m(model.numMaterials()),
> -      centering_m(model.centering()),
> -      stride_m(model.centeringSize()),
> -      guards_m(0)
> -  {
> -    addSubFields();
> -    // FIXME: Does this ever happen to fields with multiple centering  
> points?
> -    // (or event to fields with multiple materials???)
> -    PAssert(model.centeringSize() == 1);
> -    for (int m = 0; m < num_materials_m; ++m)
> -    {
> -      data(m, 0) = Data_t(model.data(m, 0).engine(), d,
> -                          model.data(m, 0).relations());
> -    }
> -    // FIXME: how do we construct the mesh?????
> -    mesh_m =  
> Mesh(DomainLayout<Dim>(inputDomainToVertexDomain(data(0,0).engine().dom 
> ain())));
> -    physicalCellDomain_m = mesh_m.physicalCellDomain();
> -  }
> +  /// INode view.
>
>    template<class T2, class EngineTag2>
>    FieldEngine(const FieldEngine<Mesh, T2, EngineTag2> &model,
> @@ -308,6 +345,11 @@
>        centering_m(model.centering()),
>        stride_m(model.centeringSize()),
>        guards_m(0),
> +      // FIXME: should hand INode to mesh?
> +      // Probably, but Mesh(Mesh&, INode&) expects the INode domain
> +      // being a vertex domain.
> +      // This constructor expects a cell domain instead? I can't see  
> how
> +      // this can be correct for centering sizes > 1.
>        mesh_m(model.mesh(),
>               inputDomainToVertexDomain(i.domain())) // FIXME: should  
> hand INode to mesh?
>    {
> @@ -363,6 +405,8 @@
>      }
>    }
>
> +  /// FieldEnginePatch view.
> +
>    template<class EngineTag2>
>    FieldEngine(const FieldEngine<Mesh, T, EngineTag2> &model,
>                const FieldEnginePatch<Dim> &p)
> @@ -370,7 +414,9 @@
>        centering_m(model.centering()),
>        stride_m(model.centeringSize()),
>        guards_m(model.guardLayers()),
> -      mesh_m(model.mesh()) // FIXME: should take a view of the mesh???
> +      // FIXME: should take a view of the mesh???
> +      // Yes. But again the mesh expects vertex domains.
> +      mesh_m(model.mesh(), p)
>    {
>      // FIXME: should we copy the relations for patch?  Do we want
>      // to take patch views of composite fields?
> @@ -381,6 +427,8 @@
>        centeringDomainToCellDomain(p.domain_m, centering_m, 0);
>    }
>
> +  /// Component view.
> +
>    template<class Mesh2, class T2, class EngineTag2, class Components>
>    FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
>                const ComponentWrapper<Components> &cw)
> @@ -403,6 +451,33 @@
>      }
>    }
>
> +  /// This constructor handle weird things like range views.
> +  /// Its probably far from doing anything sane.
> +
> +  template<class Mesh2, class T2, class EngineTag2, class Domain>
> +  FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
> +              const Domain &d)
> +    : num_materials_m(model.numMaterials()),
> +      centering_m(model.centering()),
> +      stride_m(model.centeringSize()),
> +      guards_m(0)
> +  {
> +    addSubFields();
> +    // FIXME: Does this ever happen to fields with multiple centering  
> points?
> +    // (or event to fields with multiple materials???)
> +    PAssert(model.centeringSize() == 1);
> +    for (int m = 0; m < num_materials_m; ++m)
> +    {
> +      data(m, 0) = Data_t(model.data(m, 0).engine(), d,
> +                          model.data(m, 0).relations());
> +    }
> +    // FIXME: how do we construct the mesh?????
> +    mesh_m =  
> Mesh(DomainLayout<Dim>(inputDomainToVertexDomain(data(0,0).engine().dom 
> ain())));
> +    physicalCellDomain_m = mesh_m.physicalCellDomain();
> +  }
> +
> +  //@}
> +
>    FieldEngine(const This_t &model,
>                const Pooma::DontCopyRelations &d)
>      : num_materials_m(model.numMaterials()),
> @@ -673,6 +748,10 @@
>    unsigned int num_materials_m;
>    Centering<Dim> centering_m;
>    int stride_m;
> +  /// A one-dimensional organization of the FieldEngineBaseData
> +  /// objects, for each of the numMaterials materials there are
> +  /// centeringSize data objects. We use stride_m for taking
> +  /// views, thus data(m,c) == data_m[material * stride_m +  
> centering].
>    RefCountedBlockPtr<Data_t> data_m;
>
>    Domain_t physicalCellDomain_m;



From rguenth at tat.physik.uni-tuebingen.de  Thu Nov  6 21:44:19 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 6 Nov 2003 22:44:19 +0100 (CET)
Subject: [pooma-dev] [RFA/PATCH] FieldEngine FIXMEs anyone?
In-Reply-To: <F1DF2A7C-109E-11D8-B44C-000A958E5012@lanl.gov>
References: <F1DF2A7C-109E-11D8-B44C-000A958E5012@lanl.gov>
Message-ID: <Pine.LNX.4.58.0311062234490.599@goofy>

On Thu, 6 Nov 2003, John H.Hall wrote:

> Richard:
> I think we kinda got mixed up in the latest version of field and I am
> right in the middle of a proposal about how to correct our design. The
> concept of multi-material fields really should probably have been
> multi-material engines with different views for a multi- and
> single-material engine both pointing to the same data. We are getting
> pretty far along in our sparse mixed cell engine treatment and with
> some small modifications we would be able to interchange between the
> 2.4 multi-material model and our new sparse multi-material model simply
> by choosing new engines.
>
> The confusion you are pointing out is a strong indicator that we didn't
> quite get it right. I will follow up on this after I study it some more
> and discuss it with more of the old pooma team.

Yes, I also think the current design of Fields has some flaws. In the end
all that should distinguish Fields from Arrays is that the former has
meta-data such as
 - a centering
 - multiplicity (aka materials)
 - a mesh
 - relations

So in the end we need sort of a MultiBrick engine that provides a
collection of identical Brick engines and the Field maintaining the
mapping from (material, centering) -> MultiBrick[i].  So basically
FieldEngine should be a _real_ engine and the metadata part of FieldEngine
fold into Field.  This would also allow for multi-component Arrays, if we
want to allow this.

Also of course the Field interface should be a superset of the Array
interface, so we may just inherit from Array and save some code
duplication in evaluators?  Or we can at least allow Array views of Fields
and vice-versa.

Ah and while we're at it - mesh and coordinate system support should be
changed a lot, too.

Maybe we can discuss the needs of different groups some further here. My
main use of Fields is representing a staggered grid, so I use (canonical)
centerings a lot, and also (in future) handling of multi-component fluids
which require multiple materials.

Thanks for your input,

Richard.


From rguenth at tat.physik.uni-tuebingen.de  Thu Nov  6 21:56:20 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 6 Nov 2003 22:56:20 +0100 (CET)
Subject: [PATCH] Guard PInsist with POOMA_BOUNDS_CHECK
Message-ID: <Pine.LNX.4.58.0311062255030.599@goofy>

Hi!

The following patch removes PInsist calls from taking centering views of
Fields.  This allows for better optimized code here.

Ok?

Richard.

===== FieldCentering.h 1.6 vs edited =====
--- 1.6/r2/src/Field/FieldCentering.h	Mon Oct 27 11:25:15 2003
+++ edited/FieldCentering.h	Thu Nov  6 22:54:48 2003
@@ -244,8 +244,10 @@
   /// Return a centering with one specified value.
   const Centering<Dim> operator[](int iSubField) const
   {
+#if POOMA_BOUNDS_CHECK
     PInsist(iSubField >= 0 && iSubField < size(),
 	    "Illegal attempt to extract a non-existent centering.");
+#endif
     return Centering<Dim>(centering_type_m, discontinuous_m,
 			  Orientations(1, orientations_m[iSubField]),
 			  Positions(1, positions_m[iSubField]));
@@ -303,8 +305,10 @@

   inline int size() const
   {
+#if POOMA_BOUNDS_CHECK
     PInsist(orientations_m.size() == positions_m.size(),
 	    "In a centering, the number of orientations must match the number of positions.");
+#endif
     return orientations_m.size();
   }



From jcrotinger at proximation.com  Thu Nov  6 22:34:43 2003
From: jcrotinger at proximation.com (James Crotinger)
Date: Thu, 6 Nov 2003 15:34:43 -0700 
Subject: [pooma-dev] [RFA/PATCH] FieldEngine FIXMEs anyone?
Message-ID: <F871BB04B0EA224A821A5274C31DF315129743@proxim-sf001.santafe.proximation.com>

That's what happens when a contract gets cancelled mid-development. :(

Field "domains" were made cell-centric because that provided a nice way of
dealing with complex cell-oriented algorithms. This was an experimental
departure form Pooma 1, which handled centerings as a template parameter, a
fact that gave rise to a variety of complaints. The new design made things
like edge/face-centered fields, which don't have simple Cartesian-product
domains, much cleaner. 

Jeffrey might be able to better elucidate some of the Field design decisions
as he worked pretty closely with Scott Haney and Stephen Smith on the new
design. I don't think Scott Haney follows this list anymore, and I'm not
sure about Stephen. 

The INode and FieldEnginePatch views are for getting "Brick-like" views, if
I remember correctly. If the field has an underlying Multi-patch engine,
then a view with a regular Domain will give you a field with a Multi-patch
view. Even if local, indexing will be slow. By getting a brick-like view,
you're guaranteed fast serial access.

	Jim


-----Original Message-----
From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] 
Sent: Thursday, November 06, 2003 2:02 PM
To: pooma-dev at pooma.codesourcery.com
Subject: [pooma-dev] [RFA/PATCH] FieldEngine FIXMEs anyone?

Hi!

While looking for the cause of centering views of FieldEngines being to
costly, I noticed several points in the FieldEngine implementation:
 - lots of FIXMEs!
 - a mix of weird centeringSize()/numMaterials() checks and
   implementations differing for specific cases
 - interesting way of keeping track of the domains in case of multiple
   centering points
 - everything is with respect to cell domains, not vertex domains (as
   arrays and also Meshes expect)

In the way of understanding whats going on, I added some documentation
and two new subfield view constructors (see patch below).

Can anyone elaborate on the successful usages of the centering/materials
concept from real applications?  Would it be acceptable to remove all the
special-cases for centeringSize()==1 and/or numMaterials()==1?

Does it really make sense to take views of multiple-centering fields? If
yes, can we change the expected domains to be vertex domains instead? So
an application can transparently switch Array/Field for vertex centerings.

Is there some documentation on why/how the INode and FieldEnginePatch
views are supposed to work and what is the advantage of using them
compared to usual domain views?


Thanks for any hints,

Richard.


===== FieldEngine.h 1.7 vs edited =====
--- 1.7/r2/src/Field/FieldEngine/FieldEngine.h	Mon Oct 27 11:25:16 2003
+++ edited/FieldEngine.h	Thu Nov  6 21:25:18 2003
@@ -37,7 +37,7 @@
 /** @file
  * @ingroup Field
  * @brief
- * FieldEngineBase and related classes.
+ * FieldEngine and FieldEngineBaseData classes.
  *
  * POOMA supports a flexible form
  * of "centering" that allows a hierarchy of multiple centering points per
@@ -69,6 +69,11 @@
 template<int Dim, class T, class EngineTag> class Engine;
 template<class Components> class ComponentWrapper;

+namespace Pooma {
+  struct MaterialViewTag {};
+  struct CenteringViewTag {};
+}
+

 /**
  * FieldEngineBaseData holds an engine and the relations.
@@ -83,6 +88,9 @@
     : engine_m()
   { }

+  /// Initializer to be used with an engine compatible layout or
+  /// similar initializer.
+
   template<class Initializer>
   FieldEngineBaseData(const Initializer &init)
     : engine_m(init)
@@ -192,41 +200,57 @@
   {
   }

-  /// Sub-field view constructor. This is when we want to construct a view
of
-  /// one of the subFields in our top-level list.
-
-  FieldEngine(const This_t &model, int subField)
+  ///@name Sub-field view constructors
+  //@{
+
+  /// Takes a view of the specified centering point of the specified
material.
+
+  FieldEngine(const This_t &model, int m, int c)
     : num_materials_m(1),
       stride_m(model.stride_m),
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
-    if (model.numMaterials() > 1)
-    {
-      centering_m = model.centering();
-      data_m = model.data_m + model.stride_m * subField;
-    }
-    else
-    {
-      centering_m = model.centering()[subField];
-      data_m = model.data_m + subField;
-    }
+    PAssert((m >= 0) && (m < model.numMaterials()));
+    PAssert((c >= 0) && (c < model.centeringSize()));
+    centering_m = model.centering()[c];
+    data_m = model.data_m + model.stride_m * m + c;
   }

-  FieldEngine(const This_t &model, int m, int c)
-    : num_materials_m(1),
+  /// Takes a view of the specified centering point from all
+  /// materials.
+
+  FieldEngine(const This_t &model, int c, const Pooma::CenteringViewTag&)
+    : num_materials_m(model.num_materials_m),
       stride_m(model.stride_m),
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
-    PAssert((m >= 0) && (m < model.numMaterials()));
     PAssert((c >= 0) && (c < model.centeringSize()));
     centering_m = model.centering()[c];
-    data_m = model.data_m + model.stride_m * m + c;
+    data_m = model.data_m + c;
   }

+  /// Takes a view of the specified material retaining all centering
points.
+
+  FieldEngine(const This_t &model, int m, const Pooma::MaterialViewTag&)
+    : num_materials_m(1),
+      centering_m(model.centering_m),
+      stride_m(model.stride_m),
+      physicalCellDomain_m(model.physicalCellDomain_m),
+      guards_m(model.guards_m),
+      mesh_m(model.mesh_m)
+  {
+    PAssert((m >= 0) && (m < model.numMaterials()));
+    data_m = model.data_m + m * model.stride_m;
+  }
+
+  /// Takes a view of the specified centering point of the first material.
+  /// This is useless for fields with multiple materials and thus this
+  /// method is deprecated. Use FieldEngine(field, 0, c).
+
   FieldEngine(int c, const This_t &model)
     : num_materials_m(1),
       stride_m(model.stride_m),
@@ -239,7 +263,42 @@
     data_m = model.data_m + c;
   }

-  /// View constructors.
+  /// Takes a view of
+  ///  - the specified material including all centering points,
+  ///    if there is more than one material
+  ///  - the specified centering, if there is only one material
+  /// These are weird semantics and thus this method is deprecated.
+
+  FieldEngine(const This_t &model, int subField)
+    : num_materials_m(1),
+      stride_m(model.stride_m),
+      physicalCellDomain_m(model.physicalCellDomain_m),
+      guards_m(model.guards_m),
+      mesh_m(model.mesh_m)
+  {
+    PAssert((subField >= 0) && (subField < model.numSubFields()));
+    if (model.numMaterials() > 1)
+    {
+      centering_m = model.centering();
+      data_m = model.data_m + model.stride_m * subField;
+    }
+    else
+    {
+      centering_m = model.centering()[subField];
+      data_m = model.data_m + subField;
+    }
+  }
+
+  //@}
+
+  ///@name View constructors
+  //@{
+
+  /// Taking a domain view of the specified field-engine. For a
field-engine
+  /// with one centering point and possibly multiple materials this is well
+  /// defined and expects the domain with respect to the centering of the
+  /// materials.  For multiple centerings this expects a cell domain as
+  /// viewing domain that is possibly extended to the respective vertex
domain.

   template<class T2, class EngineTag2>
   FieldEngine(const FieldEngine<Mesh, T2, EngineTag2> &model,
@@ -277,29 +336,7 @@
     }
   }

-  /// This constructor handle weird things like range views.
-
-  template<class Mesh2, class T2, class EngineTag2, class Domain>
-  FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
-              const Domain &d)
-    : num_materials_m(model.numMaterials()),
-      centering_m(model.centering()),
-      stride_m(model.centeringSize()),
-      guards_m(0)
-  {
-    addSubFields();
-    // FIXME: Does this ever happen to fields with multiple centering
points?
-    // (or event to fields with multiple materials???)
-    PAssert(model.centeringSize() == 1);
-    for (int m = 0; m < num_materials_m; ++m)
-    {
-      data(m, 0) = Data_t(model.data(m, 0).engine(), d,
-                          model.data(m, 0).relations());
-    }
-    // FIXME: how do we construct the mesh?????
-    mesh_m =
Mesh(DomainLayout<Dim>(inputDomainToVertexDomain(data(0,0).engine().domain()
)));
-    physicalCellDomain_m = mesh_m.physicalCellDomain();
-  }
+  /// INode view.

   template<class T2, class EngineTag2>
   FieldEngine(const FieldEngine<Mesh, T2, EngineTag2> &model,
@@ -308,6 +345,11 @@
       centering_m(model.centering()),
       stride_m(model.centeringSize()),
       guards_m(0),
+      // FIXME: should hand INode to mesh?
+      // Probably, but Mesh(Mesh&, INode&) expects the INode domain
+      // being a vertex domain.
+      // This constructor expects a cell domain instead? I can't see how
+      // this can be correct for centering sizes > 1.
       mesh_m(model.mesh(),
              inputDomainToVertexDomain(i.domain())) // FIXME: should hand
INode to mesh?
   {
@@ -363,6 +405,8 @@
     }
   }

+  /// FieldEnginePatch view.
+
   template<class EngineTag2>
   FieldEngine(const FieldEngine<Mesh, T, EngineTag2> &model,
               const FieldEnginePatch<Dim> &p)
@@ -370,7 +414,9 @@
       centering_m(model.centering()),
       stride_m(model.centeringSize()),
       guards_m(model.guardLayers()),
-      mesh_m(model.mesh()) // FIXME: should take a view of the mesh???
+      // FIXME: should take a view of the mesh???
+      // Yes. But again the mesh expects vertex domains.
+      mesh_m(model.mesh(), p)
   {
     // FIXME: should we copy the relations for patch?  Do we want
     // to take patch views of composite fields?
@@ -381,6 +427,8 @@
       centeringDomainToCellDomain(p.domain_m, centering_m, 0);
   }

+  /// Component view.
+
   template<class Mesh2, class T2, class EngineTag2, class Components>
   FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
               const ComponentWrapper<Components> &cw)
@@ -403,6 +451,33 @@
     }
   }

+  /// This constructor handle weird things like range views.
+  /// Its probably far from doing anything sane.
+
+  template<class Mesh2, class T2, class EngineTag2, class Domain>
+  FieldEngine(const FieldEngine<Mesh2, T2, EngineTag2> &model,
+              const Domain &d)
+    : num_materials_m(model.numMaterials()),
+      centering_m(model.centering()),
+      stride_m(model.centeringSize()),
+      guards_m(0)
+  {
+    addSubFields();
+    // FIXME: Does this ever happen to fields with multiple centering
points?
+    // (or event to fields with multiple materials???)
+    PAssert(model.centeringSize() == 1);
+    for (int m = 0; m < num_materials_m; ++m)
+    {
+      data(m, 0) = Data_t(model.data(m, 0).engine(), d,
+                          model.data(m, 0).relations());
+    }
+    // FIXME: how do we construct the mesh?????
+    mesh_m =
Mesh(DomainLayout<Dim>(inputDomainToVertexDomain(data(0,0).engine().domain()
)));
+    physicalCellDomain_m = mesh_m.physicalCellDomain();
+  }
+
+  //@}
+
   FieldEngine(const This_t &model,
               const Pooma::DontCopyRelations &d)
     : num_materials_m(model.numMaterials()),
@@ -673,6 +748,10 @@
   unsigned int num_materials_m;
   Centering<Dim> centering_m;
   int stride_m;
+  /// A one-dimensional organization of the FieldEngineBaseData
+  /// objects, for each of the numMaterials materials there are
+  /// centeringSize data objects. We use stride_m for taking
+  /// views, thus data(m,c) == data_m[material * stride_m + centering].
   RefCountedBlockPtr<Data_t> data_m;

   Domain_t physicalCellDomain_m;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20031106/47348658/attachment.html>

From rguenth at tat.physik.uni-tuebingen.de  Sat Nov  8 14:41:52 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sat, 8 Nov 2003 15:41:52 +0100 (CET)
Subject: [PATCH] Clean up Tensor (2nd try)
Message-ID: <Pine.LNX.4.58.0311081526570.446@goofy>

Hi!

The following patch cleans up Tensor wrt TensorAssign and friends. It does
so by using partial specialization of TensorAssign for the engine types.
It also uses template template parameters to get rid of code duplication
for identical specializations for Tensor<> and TensorEngine<>.

Tested on ia32 for Tiny, Particles, DataBrowser and Array with no
regressions.

Ok?

Richard.

# This is a BitKeeper generated patch for the following project:
# Project Name: pooma/cheetah repository tracking CVS/tarball
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.69    -> 1.70
#	r2/src/Tiny/TensorOperators.h	1.1     -> 1.2
#	r2/src/Tiny/Tensor.h	1.7     -> 1.11
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/11/08	richard at goofy.(none)	1.70
# Clean up Tensor wrt TensorAssign and friends.
# --------------------------------------------
#
diff -Nru a/r2/src/Tiny/Tensor.h b/r2/src/Tiny/Tensor.h
--- a/r2/src/Tiny/Tensor.h	Sat Nov  8 15:26:41 2003
+++ b/r2/src/Tiny/Tensor.h	Sat Nov  8 15:26:41 2003
@@ -72,12 +72,6 @@
 //-----------------------------------------------------------------------------

 template<int D, class T, class EngineTag> class Tensor;
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign;
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign;
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign;

 template <class T>
 void reverseBytes(T&);
@@ -399,7 +393,6 @@
 { };


-
 /**
  * TensorEngine definitions for a Full Tensor.
  */
@@ -671,7 +664,7 @@
   // Copy ctor is deep.
   TensorEngine(const TensorEngine<d,T,Antisymmetric> &x)
   {
-    AntisymmetricTensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
+    TensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
       apply(*this,x,OpAssign());
   }

@@ -680,7 +673,7 @@
   template<class X>
   TensorEngine(const X& x)
   {
-    AntisymmetricTensorAssign<This_t,X,OpAssign,0,d,0,d>::
+    TensorAssign<This_t,X,OpAssign,0,d,0,d>::
       apply(*this,x,OpAssign());
   }

@@ -728,7 +721,7 @@
   operator=(const This_t& x)
   {
     if (this != &x) {
-      AntisymmetricTensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
+      TensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
         apply(*this,x,OpAssign());
     }
     return *this;
@@ -739,7 +732,7 @@
   This_t&
   operator=(const V& x)
   {
-    AntisymmetricTensorAssign<This_t,V,OpAssign,0,d,0,d>::
+    TensorAssign<This_t,V,OpAssign,0,d,0,d>::
       apply(*this,x,OpAssign());
     return *this;
   }
@@ -857,88 +850,43 @@
 T TensorEngine<D,T,Antisymmetric>::Zero = 0.0;


-// ----------------------------------------------------------------------------
-// Special antisymmetric assignment class: Has specializations for different
-// dimensionalities (for 1, 2, and 3, so far). This may ultimately be
-// replaceable with a dimensionality-independent equivalent that uses template
-// metaprogramming. It may, in fact, be replaceable with partial
-// specializations of TensorAssign itself, with
-// TensorEngine<D,T,Antisymmetric> partial specializations for the general
-// class parameter T1 and/or T2 of TensorAssign. --TJW 9/10/1999
-// ----------------------------------------------------------------------------
+/**
+ * Special antisymmetric assignment class: Has specializations for different
+ * dimensionalities (for 1, 2, and 3, so far). This may ultimately be
+ * replaceable with a dimensionality-independent equivalent that uses template
+ * metaprogramming. It may, in fact, be replaceable with partial
+ * specializations of TensorAssign itself, with
+ * TensorEngine<D,T,Antisymmetric> partial specializations for the general
+ * class parameter T1 and/or T2 of TensorAssign. --TJW 9/10/1999
+ */

-// General template: does nothing:
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign
-{
-  static void apply(T1& x, const T2& y, Op op=Op())
-  { }
-};
 // 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<1,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op>
+struct TensorAssign<T1<1,T,Antisymmetric>,T2,Op,0,1,0,1>
 {
-  static void apply(TensorEngine<1,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  { }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<1,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<1,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<1,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   { }
 };
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<2,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op>
+struct TensorAssign<T1<2,T,Antisymmetric>,T2,Op,0,2,0,2>
 {
-  static void apply(TensorEngine<2,T,Antisymmetric> &x, const T2 &y,
+  static void apply(T1<2,T,Antisymmetric> &x, const T2 &y,
                     Op op=Op())
   {
-//     TensorAssign<TensorEngine<2,T,Antisymmetric>,T2,OpAssign,1,1,0,1>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<2,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
   }
 };
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<TensorEngine<3,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op>
+struct TensorAssign<T1<3,T,Antisymmetric>,T2,Op,0,3,0,3>
 {
-  static void apply(TensorEngine<3,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
+  static void apply(T1<3,T,Antisymmetric> &x, const T2 &y,
+		    Op op=Op())
   {
-//     TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,OpAssign,1,1,0,1>::
-//       apply(x,y,op);
-//     TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,OpAssign,2,1,0,2>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign<Tensor<3,T,Antisymmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<3,T,Antisymmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<3,T,Antisymmetric>,T2,Op,1,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Antisymmetric>,T2,Op,2,1,0,2>::apply(x,y,op);
   }
 };

@@ -986,7 +934,7 @@
   // Copy ctor is deep.
   TensorEngine(const TensorEngine<D,T,Symmetric> &x)
   {
-    SymmetricTensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
+    TensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
       apply(*this,x,OpAssign());
   }

@@ -1042,7 +990,7 @@
   operator=(const This_t &x)
   {
     if (this != &x) {
-      SymmetricTensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
+      TensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
         apply(*this,x,OpAssign());
     }
     return *this;
@@ -1053,7 +1001,7 @@
   This_t&
   operator=(const V &x)
   {
-    SymmetricTensorAssign<This_t,V,OpAssign,0,d,0,d>::
+    TensorAssign<This_t,V,OpAssign,0,d,0,d>::
       apply(*this,x,OpAssign());
     return *this;
   }
@@ -1144,101 +1092,37 @@
 };


-// ----------------------------------------------------------------------------
-// Special symmetric assignment class: Has specializations for different
-// dimensionalities (for 1, 2, and 3, so far). This may ultimately be
-// replaceable with a dimensionality-independent equivalent that uses template
-// metaprogramming. It may, in fact, be replaceable with partial
-// specializations of TensorAssign itself, with
-// TensorEngine<D,T,Symmetric> partial specializations for the general
-// class parameter T1 and/or T2 of TensorAssign. --TJW 9/10/1999
-// ----------------------------------------------------------------------------
+/**
+ * Special symmetric assignment class: Has specializations for different
+ * dimensionalities (for 2, and 3, so far). This may ultimately be
+ * replaceable with a dimensionality-independent equivalent that uses template
+ * metaprogramming. It may, in fact, be replaceable with partial
+ * specializations of TensorAssign itself, with
+ * TensorEngine<D,T,Symmetric> partial specializations for the general
+ * class parameter T1 and/or T2 of TensorAssign. --TJW 9/10/1999
+ */

-// General template: does nothing:
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign
-{
-  // We're not supposed to come along here.
-  static void apply(T1& x, const T2& y, Op op=Op());
-};
-// 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<1,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<1,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-//     TensorAssign<TensorEngine<1,T,Symmetric>,T2,OpAssign,0,1,0,1>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<1,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<1,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<1,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<2,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op>
+struct TensorAssign<T1<2,T,Symmetric>,T2,Op,0,2,0,2>
 {
-  static void apply(TensorEngine<2,T,Symmetric> &x, const T2 &y,
+  static void apply(T1<2,T,Symmetric> &x, const T2 &y,
                     Op op=Op())
   {
-//     TensorAssign<TensorEngine<2,T,Symmetric>,T2,OpAssign,0,1,0,1>::
-//       apply(x,y,op);
-//     TensorAssign<TensorEngine<2,T,Symmetric>,T2,OpAssign,1,1,0,2>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<2,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<2,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-    TensorAssign<Tensor<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<2,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
   }
 };
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<TensorEngine<3,T,Symmetric>,
-  T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<3,T,Symmetric> &x, const T2 &y,
-                    Op op=Op())
-  {
-//     TensorAssign<TensorEngine<3,T,Symmetric>,T2,OpAssign,0,1,0,1>::
-//       apply(x,y,op);
-//     TensorAssign<TensorEngine<3,T,Symmetric>,T2,OpAssign,1,1,0,2>::
-//       apply(x,y,op);
-//     TensorAssign<TensorEngine<3,T,Symmetric>,T2,OpAssign,2,1,0,3>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign<Tensor<3,T,Symmetric>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op>
+struct TensorAssign<T1<3,T,Symmetric>,T2,Op,0,3,0,3>
 {
-  static void apply(Tensor<3,T,Symmetric> &x, const T2 &y,
+  static void apply(T1<3,T,Symmetric> &x, const T2 &y,
                     Op op=Op())
   {
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,1,1,0,2>::apply(x,y,op);
+    TensorAssign<T1<3,T,Symmetric>,T2,Op,2,1,0,3>::apply(x,y,op);
   }
 };

@@ -1319,7 +1203,7 @@
   // Copy ctor is deep.
   TensorEngine(const TensorEngine<D,T,Diagonal> &x)
   {
-    DiagonalTensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
+    TensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
       apply(*this,x,OpAssign());
   }

@@ -1424,7 +1308,7 @@
   operator=(const This_t &x)
   {
     if (this != &x) {
-      DiagonalTensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
+      TensorAssign<This_t,This_t,OpAssign,0,d,0,d>::
         apply(*this,x,OpAssign());
     }
     return *this;
@@ -1435,8 +1319,7 @@
   This_t&
   operator=(const V &x)
   {
-//     TensorAssign<This_t,V,OpAssign,0,D,0,D>::apply(*this,x,OpAssign());
-    DiagonalTensorAssign<This_t,V,OpAssign,0,d,0,d>::
+    TensorAssign<This_t,V,OpAssign,0,d,0,d>::
       apply(*this,x,OpAssign());
     return *this;
   }
@@ -1543,91 +1426,35 @@
 T TensorEngine<D,T,Diagonal>::Zero = 0.0;


-// ----------------------------------------------------------------------------
-// Special diagonal assignment class: Has specializations for different
-// dimensionalities (for 1, 2, and 3, so far). This may ultimately be
-// replaceable with a dimensionality-independent equivalent that uses template
-// metaprogramming. It may, in fact, be replaceable with partial
-// specializations of TensorAssign itself, with
-// TensorEngine<D,T,Diagonal> partial specializations for the general
-// class parameter T1 and/or T2 of TensorAssign. --TJW 9/10/1999
-// ----------------------------------------------------------------------------
+/**
+ * Special diagonal assignment class: Has specializations for different
+ * dimensionalities (for 2, and 3, so far). This may ultimately be
+ * replaceable with a dimensionality-independent equivalent that uses template
+ * metaprogramming. It may, in fact, be replaceable with partial
+ * specializations of TensorAssign itself, with
+ * TensorEngine<D,T,Diagonal> partial specializations for the general
+ * class parameter T1 and/or T2 of TensorAssign. --TJW 9/10/1999
+ */

-// General template: does nothing:
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign
-{
-  static void apply(T1& x, const T2& y, Op op=Op()) { }
-};
-// 1D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<1,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-//     TensorAssign<TensorEngine<1,T,Diagonal>,T2,OpAssign,0,1,0,1>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<1,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(Tensor<1,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-    TensorAssign<Tensor<1,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-  }
-};
 // 2D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<2,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-//     TensorAssign<TensorEngine<2,T,Diagonal>,T2,OpAssign,0,1,0,1>::
-//       apply(x,y,op);
-//     TensorAssign<TensorEngine<2,T,Diagonal>,T2,OpAssign,1,1,1,1>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,0,1,0,1>::
-      apply(x,y,op);
-    TensorAssign<TensorEngine<2,T,Diagonal>,T2,Op,1,1,1,1>::
-      apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<2,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op>
+struct TensorAssign<T1<2,T,Diagonal>,T2,Op,0,2,0,2>
 {
-  static void apply(Tensor<2,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<2,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<Tensor<2,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<2,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<2,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
   }
 };
 // 3D partial specialization:
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
-{
-  static void apply(TensorEngine<3,T,Diagonal> &x, const T2 &y, Op op=Op())
-  {
-//     TensorAssign<TensorEngine<3,T,Diagonal>,T2,OpAssign,0,1,0,1>::
-//       apply(x,y,op);
-//     TensorAssign<TensorEngine<3,T,Diagonal>,T2,OpAssign,1,1,1,1>::
-//       apply(x,y,op);
-//     TensorAssign<TensorEngine<3,T,Diagonal>,T2,OpAssign,2,1,2,1>::
-//       apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-    TensorAssign<TensorEngine<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
-  }
-};
-template<class T, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign<Tensor<3,T,Diagonal>,T2,Op,B1,L1,B2,L2>
+template<template <int, class, class> class T1, class T, class T2, class Op>
+struct TensorAssign<T1<3,T,Diagonal>,T2,Op,0,3,0,3>
 {
-  static void apply(Tensor<3,T,Diagonal> &x, const T2 &y, Op op=Op())
+  static void apply(T1<3,T,Diagonal> &x, const T2 &y, Op op=Op())
   {
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
-    TensorAssign<Tensor<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,0,1,0,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,1,1,1,1>::apply(x,y,op);
+    TensorAssign<T1<3,T,Diagonal>,T2,Op,2,1,2,1>::apply(x,y,op);
   }
 };

diff -Nru a/r2/src/Tiny/TensorOperators.h b/r2/src/Tiny/TensorOperators.h
--- a/r2/src/Tiny/TensorOperators.h	Sat Nov  8 15:26:41 2003
+++ b/r2/src/Tiny/TensorOperators.h	Sat Nov  8 15:26:41 2003
@@ -53,12 +53,6 @@

 template<int D, class T, class E> class Tensor;
 class Full;
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct SymmetricTensorAssign;
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct AntisymmetricTensorAssign;
-template<class T1, class T2, class Op, int B1, int L1, int B2, int L2>
-struct DiagonalTensorAssign;

 //-----------------------------------------------------------------------------
 //
@@ -744,7 +738,7 @@
 {                                                                             \
   typedef Tensor<D,T1,Symmetric> Left_t;                                      \
   typedef Tensor<D,T2,Symmetric> Right_t;                                     \
-  SymmetricTensorAssign<Left_t,Right_t,TAG,0,D,0,D>::apply(v1,v2,TAG());      \
+  TensorAssign<Left_t,Right_t,TAG,0,D,0,D>::apply(v1,v2,TAG());      \
   return v1;                                                                  \
 }                                                                             \
                                                                               \
@@ -754,7 +748,7 @@
 {                                                                             \
   typedef Tensor<D,T1,Antisymmetric> Left_t;                                  \
   typedef Tensor<D,T2,Antisymmetric> Right_t;                                 \
-  AntisymmetricTensorAssign<Left_t,Right_t,TAG,0,D,0,D>::apply(v1,v2,TAG());  \
+  TensorAssign<Left_t,Right_t,TAG,0,D,0,D>::apply(v1,v2,TAG());  \
   return v1;                                                                  \
 }                                                                             \
                                                                               \
@@ -764,7 +758,7 @@
 {                                                                             \
   typedef Tensor<D,T1,Diagonal> Left_t;                                       \
   typedef Tensor<D,T2,Diagonal> Right_t;                                      \
-  DiagonalTensorAssign<Left_t,Right_t,TAG,0,D,0,D>::apply(v1,v2,TAG());       \
+  TensorAssign<Left_t,Right_t,TAG,0,D,0,D>::apply(v1,v2,TAG());       \
   return v1;                                                                  \
 }                                                                             \
                                                                               \
@@ -780,7 +774,7 @@
 inline Tensor<D,T1,Symmetric>&                                                \
 FUNC( Tensor<D,T1,Symmetric>& v1, const T2& v2 )                              \
 {                                                                             \
-  SymmetricTensorAssign<Tensor<D,T1,Symmetric>,T2,TAG,0,D,0,D>::              \
+  TensorAssign<Tensor<D,T1,Symmetric>,T2,TAG,0,D,0,D>::              \
     apply(v1,v2,TAG());                                                       \
   return v1;                                                                  \
 }                                                                             \
@@ -789,7 +783,7 @@
 inline Tensor<D,T1,Antisymmetric>&                                            \
 FUNC( Tensor<D,T1,Antisymmetric>& v1, const T2& v2 )                          \
 {                                                                             \
-  AntisymmetricTensorAssign<Tensor<D,T1,Antisymmetric>,T2,TAG,0,D,0,D>::      \
+  TensorAssign<Tensor<D,T1,Antisymmetric>,T2,TAG,0,D,0,D>::      \
     apply(v1,v2,TAG());                                                       \
   return v1;                                                                  \
 }                                                                             \
@@ -798,7 +792,7 @@
 inline Tensor<D,T1,Diagonal>&                                                 \
 FUNC( Tensor<D,T1,Diagonal>& v1, const T2& v2 )                               \
 {                                                                             \
-  DiagonalTensorAssign<Tensor<D,T1,Diagonal>,T2,TAG,0,D,0,D>::                \
+  TensorAssign<Tensor<D,T1,Diagonal>,T2,TAG,0,D,0,D>::                \
     apply(v1,v2,TAG());                                                       \
   return v1;                                                                  \
 }


From rguenth at tat.physik.uni-tuebingen.de  Sat Nov  8 17:44:11 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sat, 8 Nov 2003 18:44:11 +0100 (CET)
Subject: [PATCH] Add centering and material viewing constructor to FieldEngine
Message-ID: <Pine.LNX.4.58.0311081839560.446@goofy>

Hi!

The following patch adds sub-field view constructors to FieldEngine that
allow to view a centering point or a material while not affecting the
material or centering structure of the Field. It also deprecates the old
viewing constructors that tried to do the same, but failed.

Patch to use these from Field on the way.

Ok?

Richard.


2003Nov08  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Field/FieldEngine/FieldEngine.h: deprecate
	FieldEngine(model, subfield) and FieldEngine(centering, model).
	New centering and material sub-field viewing constructors.

===== FieldEngine.h 1.7 vs 1.8 =====
--- 1.7/r2/src/Field/FieldEngine/FieldEngine.h	Mon Oct 27 11:25:16 2003
+++ 1.8/r2/src/Field/FieldEngine/FieldEngine.h	Sat Nov  8 18:36:52 2003
@@ -37,7 +37,7 @@
 /** @file
  * @ingroup Field
  * @brief
- * FieldEngineBase and related classes.
+ * FieldEngine and FieldEngineBaseData classes.
  *
  * POOMA supports a flexible form
  * of "centering" that allows a hierarchy of multiple centering points per
@@ -69,6 +69,12 @@
 template<int Dim, class T, class EngineTag> class Engine;
 template<class Components> class ComponentWrapper;

+namespace Pooma {
+  // Tag classes for taking sub-field views.
+  struct MaterialViewTag {};
+  struct CenteringViewTag {};
+}
+

 /**
  * FieldEngineBaseData holds an engine and the relations.
@@ -83,6 +89,9 @@
     : engine_m()
   { }

+  /// Initializer to be used with an engine compatible layout or
+  /// similar initializer.
+
   template<class Initializer>
   FieldEngineBaseData(const Initializer &init)
     : engine_m(init)
@@ -192,9 +201,15 @@
   {
   }

-  /// Sub-field view constructor. This is when we want to construct a view of
-  /// one of the subFields in our top-level list.
-
+  ///@name Sub-field view constructors
+  //@{
+
+  /// Takes a view of
+  ///  - the specified material including all centering points,
+  ///    if there is more than one material
+  ///  - the specified centering, if there is only one material
+  /// These are weird semantics and thus this method is deprecated.
+
   FieldEngine(const This_t &model, int subField)
     : num_materials_m(1),
       stride_m(model.stride_m),
@@ -214,6 +229,8 @@
     }
   }

+  /// Takes a view of the specified centering point of the specified material.
+
   FieldEngine(const This_t &model, int m, int c)
     : num_materials_m(1),
       stride_m(model.stride_m),
@@ -227,6 +244,39 @@
     data_m = model.data_m + model.stride_m * m + c;
   }

+  /// Takes a view of the specified centering point from all
+  /// materials.
+
+  FieldEngine(const This_t &model, int c, const Pooma::CenteringViewTag&)
+    : num_materials_m(model.num_materials_m),
+      stride_m(model.stride_m),
+      physicalCellDomain_m(model.physicalCellDomain_m),
+      guards_m(model.guards_m),
+      mesh_m(model.mesh_m)
+  {
+    PAssert((c >= 0) && (c < model.centeringSize()));
+    centering_m = model.centering()[c];
+    data_m = model.data_m + c;
+  }
+
+  /// Takes a view of the specified material retaining all centering points.
+
+  FieldEngine(const This_t &model, int m, const Pooma::MaterialViewTag&)
+    : num_materials_m(1),
+      centering_m(model.centering_m),
+      stride_m(model.stride_m),
+      physicalCellDomain_m(model.physicalCellDomain_m),
+      guards_m(model.guards_m),
+      mesh_m(model.mesh_m)
+  {
+    PAssert((m >= 0) && (m < model.numMaterials()));
+    data_m = model.data_m + m * model.stride_m;
+  }
+
+  /// Takes a view of the specified centering point of the first material.
+  /// This is useless for fields with multiple materials and thus this
+  /// method is deprecated. Use FieldEngine(field, 0, c).
+
   FieldEngine(int c, const This_t &model)
     : num_materials_m(1),
       stride_m(model.stride_m),
@@ -238,6 +288,8 @@
     centering_m = model.centering()[c];
     data_m = model.data_m + c;
   }
+
+  //@}

   /// View constructors.



From rguenth at tat.physik.uni-tuebingen.de  Sat Nov  8 17:51:28 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sat, 8 Nov 2003 18:51:28 +0100 (CET)
Subject: [PATCH] Fix accessors of FieldEngine and FieldEngineBaseData
Message-ID: <Pine.LNX.4.58.0311081848130.446@goofy>

Hi!

The following patch fixes one bug in the FieldEngine::engine(m,c) accessor
and cleans up the remaining by introducing the missed const/non-const
versions.

Ok?

Richard.

2003Nov08  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Field/FieldEngine/FieldEngine.h: fix
	FieldEngine::engine(m,c), add const version. Add
        FieldEngine::relations(m, c). No need for const RelationList&
	accessors as the relation list doesnt participate in constness.

===== FieldEngine.h 1.8 vs edited =====
--- 1.8/r2/src/Field/FieldEngine/FieldEngine.h	Sat Nov  8 18:36:52 2003
+++ edited/FieldEngine.h	Sat Nov  8 18:47:08 2003
@@ -119,8 +119,7 @@
   const Engine<Dim, T, EngineTag> &engine() const { return engine_m; }
   Engine<Dim, T, EngineTag> &engine() { return engine_m; }

-  const RelationList &relations() const { return relations_m; }
-  RelationList &relations() { return relations_m; }
+  RelationList &relations() const { return relations_m; }

 private:

@@ -539,13 +538,25 @@
   Engine_t &engine(int m, int c)
   {
     PAssert(data_m.isValid());
-    return data(m,c)->engine();
+    return data(m,c).engine();
+  }
+
+  const Engine_t &engine(int m, int c) const
+  {
+    PAssert(data_m.isValid());
+    return data(m,c).engine();
   }

   RelationList &relations() const
   {
     PAssert(data_m.isValid());
     return data_m->relations();
+  }
+
+  RelationList &relations(int m, int c) const
+  {
+    PAssert(data_m.isValid());
+    return data(m, c).relations();
   }

   const GuardLayers_t &guardLayers() const


From rguenth at tat.physik.uni-tuebingen.de  Sat Nov  8 17:57:30 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sat, 8 Nov 2003 18:57:30 +0100 (CET)
Subject: [PATCH] Add viewing constructor to FieldCentering
Message-ID: <Pine.LNX.4.58.0311081855180.446@goofy>

Hi!

This patch adds a viewing constructor to FieldCentering and cleans up
some accessors. It mainly allows using this from initializers in
FieldEngine sub-field views (patch to come).

Ok?

Richard.


2003Nov08  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Field/FieldCentering.h: add Centering(model, c) constructor.
	Clean up accessors.

===== FieldCentering.h 1.7 vs edited =====
--- 1.7/r2/src/Field/FieldCentering.h	Sat Nov  8 18:53:47 2003
+++ edited/FieldCentering.h	Sat Nov  8 18:54:17 2003
@@ -236,13 +236,22 @@
       return;
   }

+  /// Sub-centering constructor.
+
+  Centering(const Centering<Dim>& model, int c)
+    : centering_type_m(model.centering_type_m),
+      discontinuous_m(model.discontinuous_m),
+      orientations_m(1, model.orientations_m[c]),
+      positions_m(1, model.positions_m[c])
+    { }
+
   //@}

   //---------------------------------------------------------------------------
   /// Sub-centering creation function.  This is not really meant to be
   /// called by users.
   /// Return a centering with one specified value.
-  const Centering<Dim> operator[](int iSubField) const
+  Centering<Dim> operator[](int iSubField) const
   {
 #if POOMA_BOUNDS_CHECK
     PInsist(iSubField >= 0 && iSubField < size(),
@@ -263,12 +272,12 @@
   //@name Accessors.
   //@{

-  inline const CenteringType &centeringType() const
+  inline CenteringType centeringType() const
     {
       return centering_type_m;
     }

-  inline const ContinuityType &continuityType() const
+  inline ContinuityType continuityType() const
     {
       return discontinuous_m;
     }


From rguenth at tat.physik.uni-tuebingen.de  Sat Nov  8 18:33:09 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sat, 8 Nov 2003 19:33:09 +0100 (CET)
Subject: [PATCH] Use Centering view constructor in FieldEngine
Message-ID: <Pine.LNX.4.58.0311081906280.446@goofy>

Hi!

The following patch makes use of the new centering view constructor in
doing sub-field views of the FieldEngine. This saves 12% assembler text
size in a small example involving centering views aka Field::center(int).
The #ifdefs look ugly, but for correctness, they are needed.

Tested on ia32, with Field and Evaluator (together with changes posted in
previous patches).

Ok?

Richard.


2003Nov08  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Field/FieldEngine/FieldEngine.h: Use sub-centering view
	constructor for centering.

===== FieldEngine.h 1.9 vs edited =====
--- 1.9/r2/src/Field/FieldEngine/FieldEngine.h	Sat Nov  8 18:47:57 2003
+++ edited/FieldEngine.h	Sat Nov  8 19:03:00 2003
@@ -232,15 +232,23 @@

   FieldEngine(const This_t &model, int m, int c)
     : num_materials_m(1),
+#ifdef NOPAssert
+      centering_m(model.centering_m, c),
+#endif
       stride_m(model.stride_m),
+#ifdef NOPAssert
+      data_m(model.data_m + model.stride_m * m + c),
+#endif
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
     PAssert((m >= 0) && (m < model.numMaterials()));
     PAssert((c >= 0) && (c < model.centeringSize()));
+#ifndef NOPAssert
     centering_m = model.centering()[c];
     data_m = model.data_m + model.stride_m * m + c;
+#endif
   }

   /// Takes a view of the specified centering point from all
@@ -248,14 +256,22 @@

   FieldEngine(const This_t &model, int c, const Pooma::CenteringViewTag&)
     : num_materials_m(model.num_materials_m),
+#ifdef NOPAssert
+      centering_m(model.centering_m, c),
+#endif
       stride_m(model.stride_m),
+#ifdef NOPAssert
+      data_m(model.data_m + c),
+#endif
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
     PAssert((c >= 0) && (c < model.centeringSize()));
+#ifndef NOPAssert
     centering_m = model.centering()[c];
     data_m = model.data_m + c;
+#endif
   }

   /// Takes a view of the specified material retaining all centering points.
@@ -264,12 +280,17 @@
     : num_materials_m(1),
       centering_m(model.centering_m),
       stride_m(model.stride_m),
+#ifdef NOPAssert
+      data_m(model.data_m + m * model.stride_m),
+#endif
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
     PAssert((m >= 0) && (m < model.numMaterials()));
+#ifndef NOPAssert
     data_m = model.data_m + m * model.stride_m;
+#endif
   }

   /// Takes a view of the specified centering point of the first material.
@@ -278,14 +299,22 @@

   FieldEngine(int c, const This_t &model)
     : num_materials_m(1),
+#ifdef NOPAssert
+      centering_m(model.centering_m, c),
+#endif
       stride_m(model.stride_m),
+#ifdef NOPAssert
+      data_m(model.data_m + c),
+#endif
       physicalCellDomain_m(model.physicalCellDomain_m),
       guards_m(model.guards_m),
       mesh_m(model.mesh_m)
   {
     PAssert((c >= 0) && (c < model.centeringSize()));
+#ifndef NOPAssert
     centering_m = model.centering()[c];
     data_m = model.data_m + c;
+#endif
   }

   //@}


From rguenth at tat.physik.uni-tuebingen.de  Sun Nov  9 12:48:01 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sun, 9 Nov 2003 13:48:01 +0100 (CET)
Subject: How is FieldEngine.ExprEngine.h supposed to work?
Message-ID: <Pine.LNX.4.58.0311091338480.827@goofy>

Hi!

I just stumbeled over FieldEngine.ExprEngine and wonder how sub-field
views are supposed to work here. In fact, I get errors about missing
Engine<>(int c, Engine& model) constructors from

  (a + b).center(0)

as expected -- normal engines dont have sub-field constructors. But it
seems for material and subField views some constructors Engine<>(Engine&,
int) and Engine<>(Engine&, int, int) match - and somehow "work"!?

Only from reductions I get assertion failures, because the number of
subfields is not updated:

  all(a.center(0)+b.center(0) == (a+b).center(0))

does not work.

So my idea of the code is, that the Fields in the expression are hidden
behind _one_ normal expression engine. And the Field information is taken
from the "FarLeft" Field in the expression. But where do the sub-fields
kick in? In fact,

  a = b + c;

should evaluate for each subfield of a,b,c - no? How is this reflected
inside the normal expression engine? Wouldnt we have to "rewrite" the
expression tree for taking sub-field views as we do for taking normal
views of normal expression trees?

I'm a little bit confused... - are there some design documents available
about these issues?

Thanks for any hints,

Richard.


From rguenth at tat.physik.uni-tuebingen.de  Sun Nov  9 21:27:00 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Sun, 9 Nov 2003 22:27:00 +0100 (CET)
Subject: [PATCH] Use new sub-field constructors, fix centering view of
 expression
Message-ID: <Pine.LNX.4.58.0311092219000.827@goofy>

Hi!

This patch uses the new sub-field constructors from Field::centering() and
Field::material() fixing taking centering views of expressions like
(a+b).center(c). It disambiguates possibly other viewing constructors also
by constructing the expression rather than the expression engine in the
FieldEngine<,,ExpressionTag> viewing constructors.

I'd like to remove all unused sub-field viewing constructors as a follow
up patch now.  Also the Field::subField() viewing method should be now
either removed or made honouring centerings and materials, which needs
adjusting of f.i. FieldEngine::numSubFields() to return
materials*centerings and similar changes elsewhere.  These changes will
kill backward compatibility for some apps - is this feasible? I think yes,
as the current code doesnt seem to have gotten wide testing/appliance.

Tested on ppc, for Field and Evaluator, including previous changes.

Ok?

Richard.


2003Nov09  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Field/FieldEngine/FieldEngine.ExprEngine.h: add sub-field
	viewing constructors for centerings and materials. Construct
	expression rather than engine.
	src/Field/Field.h: use new sub-field viewing constructors for
	centerings and materials. Adjust Field constructors accordingly.

===== Field.h 1.13 vs edited =====
--- 1.13/r2/src/Field/Field.h	Mon Oct 27 11:43:23 2003
+++ edited/Field.h	Sun Nov  9 21:35:00 2003
@@ -184,21 +184,29 @@
   inline static Type_t make(const Type_t &s, int m, int c)
   {
 #if POOMA_BOUNDS_CHECK
-    PInsist(m >= 0 && m < s.numMaterials(),
-            "Field::subField(m, c) indexing error.");
-    PInsist(c >= 0 && c < s.centeringSize(),
+    PInsist(m >= 0 && m < s.numMaterials()
+	    && c >= 0 && c < s.centeringSize(),
             "Field::subField(m, c) indexing error.");
 #endif
     return Type_t(s, m, c);
   }

-  inline static Type_t make(int c, const Type_t &s)
+  inline static Type_t make(const Type_t &s, int c, const Pooma::CenteringViewTag &tag)
   {
 #if POOMA_BOUNDS_CHECK
     PInsist(c >= 0 && c < s.centeringSize(),
-            "Field::subField(m, c) indexing error.");
+            "Field::center(c) indexing error.");
 #endif
-    return Type_t(c, s);
+    return Type_t(s, c, tag);
+  }
+
+  inline static Type_t make(const Type_t &s, int m, const Pooma::MaterialViewTag &tag)
+  {
+#if POOMA_BOUNDS_CHECK
+    PInsist(m >= 0 && m < s.numMaterials(),
+            "Field::material(m) indexing error.");
+#endif
+    return Type_t(s, m, tag);
   }
 };

@@ -229,21 +237,29 @@
   inline static Type_t make(const Subject_t &s, int m, int c)
   {
 #if POOMA_BOUNDS_CHECK
-    PInsist(m >= 0 && m < s.numMaterials(),
-            "Field::subField(m, c) indexing error.");
-    PInsist(c >= 0 && c < s.centeringSize(),
+    PInsist(m >= 0 && m < s.numMaterials()
+	    && c >= 0 && c < s.centeringSize(),
             "Field::subField(m, c) indexing error.");
 #endif
     return Type_t(s, m, c);
   }

-  inline static Type_t make(int c, const Subject_t &s)
+  inline static Type_t make(const Subject_t &s, int c, const Pooma::CenteringViewTag &tag)
   {
 #if POOMA_BOUNDS_CHECK
     PInsist(c >= 0 && c < s.centeringSize(),
-            "Field::subField(m, c) indexing error.");
+            "Field::center(c) indexing error.");
+#endif
+    return Type_t(s, c, tag);
+  }
+
+  inline static Type_t make(const Subject_t &s, int m, const Pooma::MaterialViewTag &tag)
+  {
+#if POOMA_BOUNDS_CHECK
+    PInsist(m >= 0 && m < s.numMaterials(),
+            "Field::material(m) indexing error.");
 #endif
-    return Type_t(c, s);
+    return Type_t(s, m, tag);
   }
 };

@@ -1248,6 +1264,16 @@
     : fieldEngine_m(c, model.fieldEngine())
   { }

+  template<class ET2>
+  Field(const Field<Mesh, T, ET2> &model, int c, const Pooma::CenteringViewTag &tag)
+    : fieldEngine_m(model.fieldEngine(), c, tag)
+  { }
+
+  template<class ET2>
+  Field(const Field<Mesh, T, ET2> &model, int m, const Pooma::MaterialViewTag &tag)
+    : fieldEngine_m(model.fieldEngine(), m, tag)
+  { }
+
   //---------------------------------------------------------------------------
   /// Empty destructor is fine for us.

@@ -1408,7 +1434,7 @@
   center(int c) const
   {
     typedef SubFieldView<This_t> Ret_t;
-    return Ret_t::make(c, *this);
+    return Ret_t::make(*this, c, Pooma::CenteringViewTag());
   }

   inline typename SubFieldView<This_t>::Type_t
@@ -1416,7 +1442,7 @@
   {
     PAssert(numMaterials() > 1);
     typedef SubFieldView<This_t> Ret_t;
-    return Ret_t::make(*this, m);
+    return Ret_t::make(*this, m, Pooma::MaterialViewTag());
   }
   //@}

===== FieldEngine/FieldEngine.ExprEngine.h 1.2 vs edited =====
--- 1.2/r2/src/Field/FieldEngine/FieldEngine.ExprEngine.h	Sun Oct 26 14:35:21 2003
+++ edited/FieldEngine/FieldEngine.ExprEngine.h	Sun Nov  9 21:23:12 2003
@@ -53,6 +53,7 @@
 #include "Engine/ExpressionEngine.h"
 #include "Layout/GuardLayers.h"
 #include "Utilities/PAssert.h"
+#include "Field/FieldEngine/FieldEngine.h"


 //-----------------------------------------------------------------------------
@@ -215,38 +216,59 @@
     referenceField_m(
       forEachRef(engine_m.expression(), FarLeftTag(), FarLeftTag()))
     { }
-
-  // Sub-field view constructor. This is when we want to construct a view of
-  // one of the subFields in our top-level list.
-  // All these constructors take ints.  We distinguish the sub-material view
-  // from the sub-center view by the order of the arguments.

-  // Version that takes a material and centering.
+  ///@name Sub-field view constructors
+  //@{
+
+  /// This is when we want to construct a view of
+  /// one of the subFields in our top-level list from material and centering.

   template<class Expr2>
   FieldEngine(const FieldEngine<Mesh, T, ExpressionTag<Expr2> > &model, int m, int c)
-    : engine_m(model.engine(), m, c),
+    : engine_m(Expr(model.engine().expression(), m, c)),
       referenceField_m(forEachRef(engine_m.expression(),
                                   FarLeftTag(), FarLeftTag()))
   { }

-  // sub-material view.
+  /// Sub-field view for a material.
+
+  template<class Expr2>
+  FieldEngine(const FieldEngine<Mesh, T, ExpressionTag<Expr2> > &model, int m,
+	      const Pooma::MaterialViewTag& tag)
+    : engine_m(Expr(model.engine().expression(), m, tag)),
+      referenceField_m(forEachRef(engine_m.expression(),
+                                  FarLeftTag(), FarLeftTag()))
+  { }
+
+  /// Sub-field view for a centering.

   template<class Expr2>
-  FieldEngine(const FieldEngine<Mesh, T, ExpressionTag<Expr2> > &model, const int &m)
-    : engine_m(model.engine(), m),
+  FieldEngine(const FieldEngine<Mesh, T, ExpressionTag<Expr2> > &model, int c,
+	      const Pooma::CenteringViewTag& tag)
+    : engine_m(Expr(model.engine().expression(), c, tag)),
       referenceField_m(forEachRef(engine_m.expression(),
                                   FarLeftTag(), FarLeftTag()))
   { }

-  // sub-center view.
+  /// sub-material view. Deprecated.
+
+  template<class Expr2>
+  FieldEngine(const FieldEngine<Mesh, T, ExpressionTag<Expr2> > &model, int m)
+    : engine_m(Expr(model.engine().expression, m)),
+      referenceField_m(forEachRef(engine_m.expression(),
+                                  FarLeftTag(), FarLeftTag()))
+  { }
+
+  /// sub-center view. Deprecated.

   template<class Expr2>
   FieldEngine(int c, const FieldEngine<Mesh, T, ExpressionTag<Expr2> > &model)
-    : engine_m(c, model.engine()),
+    : engine_m(Expr(c, model.engine().expression())),
       referenceField_m(forEachRef(engine_m.expression(),
                                   FarLeftTag(), FarLeftTag()))
   { }
+
+  //@}

   // Very important! Copy constructor is needed so that referenceField_m
   // doesn't refer to someone else's expression.


From rguenth at tat.physik.uni-tuebingen.de  Tue Nov 11 13:10:36 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Tue, 11 Nov 2003 14:10:36 +0100 (CET)
Subject: [PATCH] fix CanonicalCentering missing pre-instantiation
Message-ID: <Pine.LNX.4.44.0311111408300.1646-100000@bellatrix.tat.physik.uni-tuebingen.de>

Hi!

Intel icpc 8.0 moans about missing canonical centering constructor during
linking. In fact it is correct, that it is not instantiated explicitly.
So I think the following patch is correct.

Tested with Intel icpc 8.0 on ia32 for the Field/Centerings test.

Ok?

Richard.


===== FieldCentering.cmpl.cpp 1.5 vs edited =====
--- 1.5/r2/src/Field/FieldCentering.cmpl.cpp	Fri Jan 24 10:35:52 2003
+++ edited/FieldCentering.cmpl.cpp	Tue Nov 11 14:05:40 2003
@@ -347,6 +347,13 @@
 }


+// Pre-instantiate canonical centerings
+
+template class CanonicalCentering<1>;
+template class CanonicalCentering<2>;
+template class CanonicalCentering<3>;
+
+
 // ACL:rcsinfo
 // ----------------------------------------------------------------------
 // $RCSfile: FieldCentering.cmpl.cpp,v $   $Author: pooma $



From rguenth at tat.physik.uni-tuebingen.de  Thu Nov 20 19:46:15 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 20 Nov 2003 20:46:15 +0100 (CET)
Subject: [PATCH] Remaining FieldCentering cleanup
Message-ID: <Pine.LNX.4.58.0311202045200.6406@goofy>

Hi!

The following is the remaining cleanup of the FieldCentering class.

Tested together with all other changes.

Ok?

Richard.


Index: FieldCentering.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Field/FieldCentering.h,v
retrieving revision 1.8
diff -u -u -r1.8 FieldCentering.h
--- FieldCentering.h	20 Nov 2003 19:19:28 -0000	1.8
+++ FieldCentering.h	20 Nov 2003 19:41:17 -0000
@@ -250,15 +250,13 @@
   /// Sub-centering creation function.  This is not really meant to be
   /// called by users.
   /// Return a centering with one specified value.
-  const Centering<Dim> operator[](int iSubField) const
+  Centering<Dim> operator[](int iSubField) const
   {
 #if POOMA_BOUNDS_CHECK
     PInsist(iSubField >= 0 && iSubField < size(),
 	    "Illegal attempt to extract a non-existent centering.");
 #endif
-    return Centering<Dim>(centering_type_m, discontinuous_m,
-			  Orientations(1, orientations_m[iSubField]),
-			  Positions(1, positions_m[iSubField]));
+    return Centering<Dim>(*this, iSubField);
   }


@@ -271,9 +269,14 @@
   //@name Accessors.
   //@{

-  inline const CenteringType &centeringType() const
+  inline CenteringType centeringType() const
     {
       return centering_type_m;
+    }
+
+  inline ContinuityType continuityType() const
+    {
+      return discontinuous_m;
     }

   inline bool discontinuous() const


From rguenth at tat.physik.uni-tuebingen.de  Thu Nov 20 21:14:03 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 20 Nov 2003 22:14:03 +0100 (CET)
Subject: [PATCH] Merge Array/Reductions.h and Field/FieldReductions.h
Message-ID: <Pine.LNX.4.58.0311202204130.6406@goofy>

Hi!

This patch merges the aforementioned files by providing a generic one
in Functions/Reductions.h.  Also generic PerformUpdate is split out of
Field.h and put into Utilities/PerformUpdate.h.  These changes will allow
for reductions over three- and two-arg where(), which is the next patch to
send.

Tested on (hopefully) all relevant tests on serial ppc-linux.

Ok?

Richard.


2003Nov20  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Field/Field.h: split generic
	LeafFunctor<Node, PerformUpdateTag> out ...
	src/Utilities/PerformUpdate.h: ... here (new file).
	src/Array/Reductions.h: remove.
	src/Field/FieldReductions.h: remove.
	src/Functions/Reductions.h: new, merged from Array and
	Field versions.
	src/Array/Array.h: use new include.
	src/Array/tests/array_test1.cpp: likewise.
	src/Array/tests/array_test20.cpp: likewise.
	src/Array/tests/array_test21.cpp: likewise.
	src/Array/tests/array_test26.cpp: likewise.
	src/Array/tests/array_test27.cpp: likewise.
	src/Array/tests/array_test28.cpp: likewise.
	src/Array/tests/array_test6.cpp: likewise.
	src/Array/tests/array_test7.cpp: likewise.
	src/IO/DiskLayout.cmpl.cpp: likewise.
	src/Pooma/Fields.h: likewise.
	src/Evaluator/Reduction.h: perform update on Fields, check
	for single subfield (checks moved from old *Reductions.h).


# This is a BitKeeper generated patch for the following project:
# Project Name: pooma/cheetah repository tracking CVS/tarball
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.74    -> 1.75
#	r2/src/Pooma/Fields.h	1.2     -> 1.3
#	r2/src/Evaluator/MultiArgEvaluator.h	1.10    -> 1.11
#	r2/src/Array/tests/array_test6.cpp	1.1     -> 1.2
#	r2/src/Field/FieldReductions.h	1.4     -> 1.6     r2/src/Functions/Reductions.h (moved)
#	r2/src/Array/tests/array_test21.cpp	1.1     -> 1.2
#	r2/src/Array/tests/array_test7.cpp	1.1     -> 1.2
#	r2/src/Array/Reductions.h	1.4     ->         (deleted)
#	r2/src/Array/tests/array_test28.cpp	1.1     -> 1.2
#	r2/src/Array/Array.h	1.9     -> 1.10
#	r2/src/Array/tests/array_test27.cpp	1.1     -> 1.2
#	r2/src/Evaluator/Reduction.h	1.4     -> 1.5
#	r2/src/Field/Field.h	1.16    -> 1.17
#	r2/src/Array/tests/array_test1.cpp	1.1     -> 1.2
#	r2/src/IO/DiskLayout.cmpl.cpp	1.2     -> 1.3
#	r2/src/Array/tests/array_test26.cpp	1.1     -> 1.2
#	r2/src/Array/tests/array_test20.cpp	1.1     -> 1.2
#	               (new)	        -> 1.1     r2/src/Utilities/PerformUpdate.h
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/11/20	richard at goofy.(none)	1.75
# Clean up reduction functions and connection to Reduction<>.
# Split out PerformUpdateTag() from Field.h.
# --------------------------------------------
#
diff -Nru a/r2/src/Array/Array.h b/r2/src/Array/Array.h
--- a/r2/src/Array/Array.h	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/Array.h	Thu Nov 20 22:02:48 2003
@@ -83,6 +83,7 @@
 #include "Pooma/PETE/ExpressionTraits.h"
 #include "Pooma/View.h"
 #include "Utilities/Conform.h"
+#include "Utilities/PerformUpdate.h"
 #include "Utilities/ElementProperties.h"
 #include "Utilities/ModelElement.h"
 #include "Utilities/NotifyPreRead.h"
@@ -93,7 +94,7 @@
 #include "Array/ArrayOperatorSpecializations.h"
 #include "Array/VectorArrayOperators.h"
 #include "Array/CreateLeaf.h"
-#include "Array/Reductions.h"
+#include "Functions/Reductions.h"

 #include <iosfwd>

diff -Nru a/r2/src/Array/Reductions.h b/r2/src/Array/Reductions.h
--- a/r2/src/Array/Reductions.h	Thu Nov 20 22:02:48 2003
+++ /dev/null	Wed Dec 31 16:00:00 1969
@@ -1,156 +0,0 @@
-// -*- 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
-//-----------------------------------------------------------------------------
-// Functions:
-//   sum             - sum all the elements in an array.
-//   prod            - multiply all of the elements in an array.
-//   max             - find the maximum value in an array.
-//   min             - find the minimum value in an array.
-//   all             - returns true if all of the array's elements are != 0.
-//   any             - returns true if any of the array's elements are != 0.
-//   bitOr           - does a bitwise or of all of the elements.
-//   bitAnd          - does a bitwise and of all of the elements.
-//-----------------------------------------------------------------------------
-
-/** @file
- * @ingroup Array
- * @brief
- * Array reduction functions.
- * These include sum, prod, max, min, all, any, bitOr and bitAnd.
- */
-
-#ifndef POOMA_ARRAY_REDUCTIONS_H
-#define POOMA_ARRAY_REDUCTIONS_H
-
-//-----------------------------------------------------------------------------
-// Includes
-//-----------------------------------------------------------------------------
-
-#include "Evaluator/Reduction.h"
-
-
-//-----------------------------------------------------------------------------
-// Forward definitions
-//-----------------------------------------------------------------------------
-
-template<int Dim, class T, class EngineTag>
-class Array;
-
-
-//-----------------------------------------------------------------------------
-// Specific global reduction functions.
-//-----------------------------------------------------------------------------
-
-/// Sum up the elements of an array.
-
-template<int Dim, class T, class EngineTag>
-T sum(const Array<Dim, T, EngineTag> &a)
-{
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpAddAssign(), a);
-  return ret;
-}
-
-/// Compute the product of the elements of an array.
-
-template<int Dim, class T, class EngineTag>
-T prod(const Array<Dim, T, EngineTag> &a)
-{
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpMultiplyAssign(), a);
-  return ret;
-}
-
-/// Find the smallest element of an array.
-
-template<int Dim, class T, class EngineTag>
-T min(const Array<Dim, T, EngineTag> &a)
-{
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnMinAssign(), a);
-  return ret;
-}
-
-/// Find the largest element of an array.
-
-template<int Dim, class T, class EngineTag>
-T max(const Array<Dim, T, EngineTag> &a)
-{
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnMaxAssign(), a);
-  return ret;
-}
-
-/// Report if all of the elments of the array are true.
-
-template<int Dim, class T, class EngineTag>
-bool all(const Array<Dim, T, EngineTag> &a)
-{
-  bool ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnAndAssign(), a);
-  return ret;
-}
-
-/// Report if some of the elments of the array are true.
-
-template<int Dim, class T, class EngineTag>
-bool any(const Array<Dim, T, EngineTag> &a)
-{
-  bool ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnOrAssign(), a);
-  return ret;
-}
-
-/// Bitwise-or all of the elements together.
-
-template<int Dim, class T, class EngineTag>
-T bitOr(const Array<Dim, T, EngineTag> &a)
-{
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpBitwiseOrAssign(), a);
-  return ret;
-}
-
-/// Bitwise-and all of the elements together.
-
-template<int Dim, class T, class EngineTag>
-T bitAnd(const Array<Dim, T, EngineTag> &a)
-{
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpBitwiseAndAssign(), a);
-  return ret;
-}
-
-#endif
-
-// ACL:rcsinfo
-// ----------------------------------------------------------------------
-// $RCSfile: Reductions.h,v $   $Author: pooma $
-// $Revision: 1.14 $   $Date: 2003/10/19 12:54:50 $
-// ----------------------------------------------------------------------
-// ACL:rcsinfo
diff -Nru a/r2/src/Array/tests/array_test1.cpp b/r2/src/Array/tests/array_test1.cpp
--- a/r2/src/Array/tests/array_test1.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test1.cpp	Thu Nov 20 22:02:48 2003
@@ -43,7 +43,6 @@
 #include "Engine/CompressibleBrick.h"
 #include "Engine/MultiPatchEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"

 static bool OK = true;

diff -Nru a/r2/src/Array/tests/array_test20.cpp b/r2/src/Array/tests/array_test20.cpp
--- a/r2/src/Array/tests/array_test20.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test20.cpp	Thu Nov 20 22:02:48 2003
@@ -38,7 +38,6 @@
 #include "Engine/ConstantFunctionEngine.h"
 #include "Engine/IndexFunctionEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"
 #include "Tiny/Vector.h"

 #include <iostream>
diff -Nru a/r2/src/Array/tests/array_test21.cpp b/r2/src/Array/tests/array_test21.cpp
--- a/r2/src/Array/tests/array_test21.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test21.cpp	Thu Nov 20 22:02:48 2003
@@ -43,7 +43,6 @@
 #include "Engine/CompressibleBrick.h"
 #include "Engine/MultiPatchEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"


 static bool OK = true;
diff -Nru a/r2/src/Array/tests/array_test26.cpp b/r2/src/Array/tests/array_test26.cpp
--- a/r2/src/Array/tests/array_test26.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test26.cpp	Thu Nov 20 22:02:48 2003
@@ -36,7 +36,6 @@
 #include "Utilities/Tester.h"
 #include "Engine/BrickEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"


 int main(int argc, char *argv[])
diff -Nru a/r2/src/Array/tests/array_test27.cpp b/r2/src/Array/tests/array_test27.cpp
--- a/r2/src/Array/tests/array_test27.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test27.cpp	Thu Nov 20 22:02:48 2003
@@ -43,7 +43,6 @@
 #include "Engine/MultiPatchEngine.h"
 #include "Engine/RemoteEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"


 int main(int argc, char *argv[])
diff -Nru a/r2/src/Array/tests/array_test28.cpp b/r2/src/Array/tests/array_test28.cpp
--- a/r2/src/Array/tests/array_test28.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test28.cpp	Thu Nov 20 22:02:48 2003
@@ -42,7 +42,6 @@
 #include "Engine/MultiPatchEngine.h"
 #include "Engine/RemoteEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"
 #include "Tiny/Vector.h"

 int main(int argc, char *argv[])
diff -Nru a/r2/src/Array/tests/array_test6.cpp b/r2/src/Array/tests/array_test6.cpp
--- a/r2/src/Array/tests/array_test6.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test6.cpp	Thu Nov 20 22:02:48 2003
@@ -36,7 +36,6 @@
 #include "Domain/AllDomain.h"
 #include "Engine/BrickEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"


 int main(int argc, char *argv[])
diff -Nru a/r2/src/Array/tests/array_test7.cpp b/r2/src/Array/tests/array_test7.cpp
--- a/r2/src/Array/tests/array_test7.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Array/tests/array_test7.cpp	Thu Nov 20 22:02:48 2003
@@ -41,7 +41,6 @@
 #include "Engine/CompressibleBrick.h"
 #include "Engine/MultiPatchEngine.h"
 #include "Array/Array.h"
-#include "Array/Reductions.h"


 int main(int argc, char *argv[])
diff -Nru a/r2/src/Evaluator/MultiArgEvaluator.h b/r2/src/Evaluator/MultiArgEvaluator.h
--- a/r2/src/Evaluator/MultiArgEvaluator.h	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Evaluator/MultiArgEvaluator.h	Thu Nov 20 22:02:48 2003
@@ -67,7 +67,7 @@
 #include "Evaluator/MultiArgKernel.h"
 #include "Evaluator/SimpleIntersector.h"
 #include "Evaluator/ScalarCodeInfo.h"
-#include "Field/Field.h" // for PerformUpdateTag only
+#include "Utilities/PerformUpdate.h"

 //-----------------------------------------------------------------------------
 // Forward Declarations:
diff -Nru a/r2/src/Evaluator/Reduction.h b/r2/src/Evaluator/Reduction.h
--- a/r2/src/Evaluator/Reduction.h	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Evaluator/Reduction.h	Thu Nov 20 22:02:48 2003
@@ -93,16 +93,35 @@

   ~Reduction() { }

-  //---------------------------------------------------------------------------
-  // Input an expression and cause it to be reduced.
-  // We just pass the buck to a special reduction.
+  /// Helper to check validity of the expression, general version.
+
+  template <class Expr>
+  static inline bool checkValidity(const Expr &e, WrappedInt<false>)
+  {
+    return true;
+  }
+
+  /// Helper to check validity of the expression, version for fields.
+
+  template <class Expr>
+  static inline bool checkValidity(const Expr &e, WrappedInt<true>)
+  {
+    return e.centeringSize() == 1 && e.numMaterials() == 1;
+  }
+
+  /// Input an expression and cause it to be reduced.
+  /// We just pass the buck to a special reduction after updating
+  /// the expression leafs and checking its validity (we can handle
+  /// one subfield only).

   template<class T, class Op, class Expr>
   void evaluate(T &ret, const Op &op, const Expr &e) const
   {
     typedef typename EvaluatorTag1<Expr>::Evaluator_t Evaluator_t;
+    PAssert(checkValidity(e, WrappedInt<Expr::hasRelations>()));
+    forEach(e, PerformUpdateTag(), NullCombine());
     Reduction<Evaluator_t>().evaluate(ret, op, e());
-
+
     POOMA_INCREMENT_STATISTIC(NumReductions)
   }
 };
diff -Nru a/r2/src/Field/Field.h b/r2/src/Field/Field.h
--- a/r2/src/Field/Field.h	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Field/Field.h	Thu Nov 20 22:02:48 2003
@@ -56,6 +56,7 @@
 #include "Pooma/View.h"
 #include "Utilities/PAssert.h"
 #include "Utilities/RefCountedBlockPtr.h"
+#include "Utilities/PerformUpdate.h"

 // NOTE:  The current order of includes puts FieldCreateLeaf after the
 // operators files to work around a bug with template instantiation in KCC.
@@ -1972,7 +1973,6 @@
 // These leaf functor specializations are used to notify a field or expression
 // that it is going to be read and, therefore, needs to update itself.
 //
-// The first LeafFunctor represents default behavior, which is to do nothing.
 // The second handles fields other than those with expression-engines by simply
 // calling applyRelations(). The third passes the tag to the leaves.
 //
@@ -1984,24 +1984,6 @@
 // operate on the engines.
 //
 //-----------------------------------------------------------------------------
-
-struct PerformUpdateTag
-{
-  POOMA_PURIFY_CONSTRUCTORS(PerformUpdateTag)
-};
-
-template<class Node>
-struct LeafFunctor<Node, PerformUpdateTag>
-{
-  typedef int Type_t;
-
-  inline static
-  Type_t apply(const Node &, const PerformUpdateTag &)
-    {
-      return 0;
-    }
-};
-

 template<class Mesh, class T, class EngineTag>
 struct LeafFunctor<Field<Mesh, T, EngineTag>,
diff -Nru a/r2/src/Field/FieldReductions.h b/r2/src/Field/FieldReductions.h
--- a/r2/src/Field/FieldReductions.h	Thu Nov 20 22:02:48 2003
+++ /dev/null	Wed Dec 31 16:00:00 1969
@@ -1,227 +0,0 @@
-// -*- 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
-//-----------------------------------------------------------------------------
-// Functions:
-//   sum             - sum all the elements in a subfield.
-//   prod            - multiply all of the elements in a subfield.
-//   max             - find the maximum value in a subfield.
-//   min             - find the minimum value in a subfield.
-//   all             - returns true if all of the subfield's elements are != 0.
-//   any             - returns true if any of the subfield's elements are != 0.
-//   bitOr           - does a bitwise or of all of the elements.
-//   bitAnd          - does a bitwise and of all of the elements.
-//-----------------------------------------------------------------------------
-
-/** @file
- * @ingroup Field
- * @brief
- * Field reduction functions.
- */
-
-#ifndef POOMA_FIELD_FIELDREDUCTIONS_H
-#define POOMA_FIELD_FIELDREDUCTIONS_H
-
-//-----------------------------------------------------------------------------
-// Includes
-//-----------------------------------------------------------------------------
-
-#include "Evaluator/Reduction.h"
-
-
-//-----------------------------------------------------------------------------
-// Forward definitions
-//-----------------------------------------------------------------------------
-
-template<class GeometryTag, class T, class EngineTag>
-class Field;
-
-
-//-----------------------------------------------------------------------------
-// Specific global reduction functions for Fields.
-//-----------------------------------------------------------------------------
-
-/// Sum up the elements of a Field.
-
-template<class GeometryTag, class T, class EngineTag>
-T sum(const Field<GeometryTag, T, EngineTag> &f)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpAddAssign(), f);
-  return ret;
-}
-
-/// Compute the product of the elements of a Field.
-
-template<class GeometryTag, class T, class EngineTag>
-T prod(const Field<GeometryTag, T, EngineTag> &f)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpMultiplyAssign(), f);
-  return ret;
-}
-
-/// Find the smallest element of a Field.
-
-template<class GeometryTag, class T, class EngineTag>
-T min(const Field<GeometryTag, T, EngineTag> &f)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnMinAssign(), f);
-  return ret;
-}
-
-/// Find the largest element of a Field.
-
-template<class GeometryTag, class T, class EngineTag>
-T max(const Field<GeometryTag, T, EngineTag> &f)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnMaxAssign(), f);
-  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)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  bool ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnAndAssign(), f);
-  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)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  bool ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, FnOrAssign(), f);
-  return ret;
-}
-
-/// Bitwise-or all of the elements together.
-
-template<class GeometryTag, class T, class EngineTag>
-T bitOr(const Field<GeometryTag, T, EngineTag> &f)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpBitwiseOrAssign(), f);
-  return ret;
-}
-
-// Bitwise-and all of the elements together.
-
-template<class GeometryTag, class T, class EngineTag>
-T bitAnd(const Field<GeometryTag, T, EngineTag> &f)
-{
-  // These versions only work with fields with one value per cell.
-
-  PAssert(f.numMaterials() <= 1 && f.centering().size() <= 1);
-
-  // We need to notify the field that we are reducing that we are getting
-  // ready to read.
-
-  forEach(f, PerformUpdateTag(), NullCombine());
-
-  T ret;
-  Reduction<MainEvaluatorTag>().evaluate(ret, OpBitwiseAndAssign(), f);
-  return ret;
-}
-
-#endif // POOMA_FIELD_FIELDREDUCTIONS_H
-
-// ACL:rcsinfo
-// ----------------------------------------------------------------------
-// $RCSfile: FieldReductions.h,v $   $Author: pooma $
-// $Revision: 1.2 $   $Date: 2003/10/25 13:31:34 $
-// ----------------------------------------------------------------------
-// ACL:rcsinfo
diff -Nru a/r2/src/Functions/Reductions.h b/r2/src/Functions/Reductions.h
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/r2/src/Functions/Reductions.h	Thu Nov 20 22:02:48 2003
@@ -0,0 +1,148 @@
+// -*- 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
+//-----------------------------------------------------------------------------
+// Functions:
+//   sum             - sum all the elements.
+//   prod            - multiply all of the elements.
+//   max             - find the maximum value.
+//   min             - find the minimum value.
+//   all             - returns true if all of the elements are != 0.
+//   any             - returns true if any of the elements are != 0.
+//   bitOr           - does a bitwise or of all of the elements.
+//   bitAnd          - does a bitwise and of all of the elements.
+//-----------------------------------------------------------------------------
+
+/** @file
+ * @ingroup Functions
+ * @brief
+ * Reduction functions for Fields and Arrays.
+ */
+
+#ifndef POOMA_FUNCTIONS_REDUCTIONS_H
+#define POOMA_FUNCTIONS_REDUCTIONS_H
+
+//-----------------------------------------------------------------------------
+// Includes
+//-----------------------------------------------------------------------------
+
+#include "Evaluator/Reduction.h"
+#include "Utilities/WrappedInt.h"
+
+
+//-----------------------------------------------------------------------------
+// Specific global reduction functions for Fields.
+//-----------------------------------------------------------------------------
+
+/// Sum up the elements.
+
+template<class Subject>
+typename Subject::Element_t sum(const Subject &s)
+{
+  typename Subject::Element_t ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, OpAddAssign(), s);
+  return ret;
+}
+
+/// Compute the product of the elements.
+
+template<class Subject>
+typename Subject::Element_t prod(const Subject &s)
+{
+  typename Subject::Element_t ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, OpMultiplyAssign(), s);
+  return ret;
+}
+
+/// Find the smallest element.
+
+template<class Subject>
+typename Subject::Element_t min(const Subject &s)
+{
+  typename Subject::Element_t ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, FnMinAssign(), s);
+  return ret;
+}
+
+/// Find the largest element.
+
+template<class Subject>
+typename Subject::Element_t max(const Subject &s)
+{
+  typename Subject::Element_t ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, FnMaxAssign(), s);
+  return ret;
+}
+
+/// Report if all of the elements are true.
+
+template<class Subject>
+bool all(const Subject &s)
+{
+  bool ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, FnAndAssign(), s);
+  return ret;
+}
+
+/// Report if some of the elements are true.
+
+template<class Subject>
+bool any(const Subject &s)
+{
+  bool ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, FnOrAssign(), s);
+  return ret;
+}
+
+/// Bitwise-or all of the elements together.
+
+template<class Subject>
+typename Subject::Element_t bitOr(const Subject &s)
+{
+  typename Subject::Element_t ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, OpBitwiseOrAssign(), s);
+  return ret;
+}
+
+/// Bitwise-and all of the elements together.
+
+template<class Subject>
+typename Subject::Element_t bitAnd(const Subject &s)
+{
+  typename Subject::Element_t ret;
+  Reduction<MainEvaluatorTag>().evaluate(ret, OpBitwiseAndAssign(), s);
+  return ret;
+}
+
+#endif // POOMA_FUNCTIONS_REDUCTIONS_H
+
+// ACL:rcsinfo
+// ----------------------------------------------------------------------
+// $RCSfile: FieldReductions.h,v $   $Author: pooma $
+// $Revision: 1.2 $   $Date: 2003/10/25 13:31:34 $
+// ----------------------------------------------------------------------
+// ACL:rcsinfo
diff -Nru a/r2/src/IO/DiskLayout.cmpl.cpp b/r2/src/IO/DiskLayout.cmpl.cpp
--- a/r2/src/IO/DiskLayout.cmpl.cpp	Thu Nov 20 22:02:48 2003
+++ b/r2/src/IO/DiskLayout.cmpl.cpp	Thu Nov 20 22:02:48 2003
@@ -46,7 +46,6 @@
 // For checkLayout:

 #include "Array/Array.h"
-#include "Array/Reductions.h" // all
 #include "Engine/CompressibleBrick.h"
 #include "Engine/MultiPatchEngine.h"
 #include "Partition/UniformGridPartition.h"
diff -Nru a/r2/src/Pooma/Fields.h b/r2/src/Pooma/Fields.h
--- a/r2/src/Pooma/Fields.h	Thu Nov 20 22:02:48 2003
+++ b/r2/src/Pooma/Fields.h	Thu Nov 20 22:02:48 2003
@@ -71,7 +71,7 @@

 // Other stuff:

-#include "Field/FieldReductions.h"
+#include "Functions/Reductions.h"
 #include "Field/PrintField.h"
 #include "Field/FieldOperatorSpecializations.h"

diff -Nru a/r2/src/Utilities/PerformUpdate.h b/r2/src/Utilities/PerformUpdate.h
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/r2/src/Utilities/PerformUpdate.h	Thu Nov 20 22:02:48 2003
@@ -0,0 +1,88 @@
+// -*- 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
+
+/** @file
+ * @ingroup Utilities
+ * @brief
+ * A tag for updating leafs in an expression.
+ */
+
+#ifndef POOMA_UTILITIES_PERFORMUPDATE_H
+#define POOMA_UTILITIES_PERFORMUPDATE_H
+
+//-----------------------------------------------------------------------------
+// Typedefs:
+//-----------------------------------------------------------------------------
+
+//-----------------------------------------------------------------------------
+// Includes:
+//-----------------------------------------------------------------------------
+
+//-----------------------------------------------------------------------------
+// Forward Declarations:
+//-----------------------------------------------------------------------------
+
+template<class T, class A> struct LeafFunctor;
+
+/**
+ * These leaf functor specializations are used to notify a field or expression
+ * that it is going to be read and, therefore, needs to update itself.
+ *
+ * The first LeafFunctor represents default behavior, which is to do nothing.
+ *
+ * Fields with engines that store internal fields AND don't copy those
+ * fields' relations to its list must provide a specialization to get the
+ * internal fields to update.
+ *
+ * NOTE: we don't use the ExpressionApply machinery here because this really
+ * operate on the engines.
+ */
+
+struct PerformUpdateTag {};
+
+template<class Node>
+struct LeafFunctor<Node, PerformUpdateTag>
+{
+  typedef int Type_t;
+
+  inline static
+  Type_t apply(const Node &, const PerformUpdateTag &)
+    {
+      return 0;
+    }
+};
+
+
+#endif // POOMA_UTILITIES_PERFORMUPDATE_H
+
+// ACL:rcsinfo
+// ----------------------------------------------------------------------
+// $RCSfile: Conform.h,v $   $Author: pooma $
+// $Revision: 1.4 $   $Date: 2003/10/19 21:35:55 $
+// ----------------------------------------------------------------------
+// ACL:rcsinfo


From rguenth at tat.physik.uni-tuebingen.de  Thu Nov 20 21:22:38 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 20 Nov 2003 22:22:38 +0100 (CET)
Subject: [PATCH] Support reductions over where()
Message-ID: <Pine.LNX.4.58.0311202214070.6406@goofy>

Hi!

This patch adds support for reductions over two- and three-arg where()
functions like in

  double star_mass = sum(where(norm(positions(rh).read(I)) <= star_radius,
                               (rh * Pooma::cellVolumes(rh))(I)));

which integrates mass over a sphere with radius star_radius inside the
computational domain.

More interesting cases like

  int cnt = sum(where(rh.read(I) != 0.0, 1));

still need to be fixed - but they are less interesting for me at the
moment.

Tested by checking old reduction and where functionality. New testcase
passes.

Ok?

Richard.


2003Nov20  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Evaluator/WhereProxy.h: add Element_t typedef and
	hasRelations enum.
	src/Evaluator/OpMask.h: add Unwrap<> and ReductionTraits<>
	specialization for OpMask<> operators.
	src/Evaluator/Reduction.h: handle WhereProxy<> in main
	reduction evaluator by unwrapping the expression. Unwrap op
	for final reduction over patch results.
	src/Engine/RemoteEngine.h: unwrap op for final reduction over
	patch results.
	src/Field/tests/WhereTest.cpp: add tests for reduction over
	two- and three-arg where.

diff -Nru a/r2/src/Engine/RemoteEngine.h b/r2/src/Engine/RemoteEngine.h
--- a/r2/src/Engine/RemoteEngine.h	Thu Nov 20 22:03:32 2003
+++ b/r2/src/Engine/RemoteEngine.h	Thu Nov 20 22:03:32 2003
@@ -2069,7 +2069,7 @@
       {
 	ret = vals[0];
 	for (j = 1; j < n; j++)
-	  op(ret, vals[j]);
+	  Unwrap<Op>::unwrap(op)(ret, vals[j]);
       }

     delete [] vals;
diff -Nru a/r2/src/Evaluator/OpMask.h b/r2/src/Evaluator/OpMask.h
--- a/r2/src/Evaluator/OpMask.h	Thu Nov 20 22:03:32 2003
+++ b/r2/src/Evaluator/OpMask.h	Thu Nov 20 22:03:32 2003
@@ -169,6 +169,28 @@
   typedef T1 &Type_t;
 };

+template <class Op>
+struct Unwrap {
+  typedef Op Op_t;
+  static inline const Op_t& unwrap(const Op &op) { return op; }
+};
+
+template <class Op>
+struct Unwrap<OpMask<Op> > {
+  typedef typename Unwrap<Op>::Op_t Op_t;
+  static inline const Op_t& unwrap(const OpMask<Op> &op) { return Unwrap<Op>::unwrap(op.op_m); }
+};
+
+template <class Op, class T>
+struct ReductionTraits;
+
+template <class Op, class T>
+struct ReductionTraits<OpMask<Op>, T>
+{
+  static T identity() { return ReductionTraits<Op, T>::identity(); }
+};
+
+
 //-----------------------------------------------------------------------------
 //
 //-----------------------------------------------------------------------------
diff -Nru a/r2/src/Evaluator/Reduction.h b/r2/src/Evaluator/Reduction.h
--- a/r2/src/Evaluator/Reduction.h	Thu Nov 20 22:03:32 2003
+++ b/r2/src/Evaluator/Reduction.h	Thu Nov 20 22:03:32 2003
@@ -53,6 +53,7 @@
 #include "Engine/IntersectEngine.h"
 #include "Evaluator/ReductionKernel.h"
 #include "Evaluator/EvaluatorTags.h"
+#include "Evaluator/WhereProxy.h"
 #include "Threads/PoomaCSem.h"

 #include <vector>
@@ -109,6 +110,14 @@
     return e.centeringSize() == 1 && e.numMaterials() == 1;
   }

+  /// Un-wrap where() expression operation and pass on to generic evaluator.
+
+  template<class T, class Op, class Cond, class Expr>
+  void evaluate(T &ret, const Op &op, const WhereProxy<Cond, Expr> &w) const
+  {
+    evaluate(ret, w.opMask(op), w.whereMask());
+  }
+
   /// Input an expression and cause it to be reduced.
   /// We just pass the buck to a special reduction after updating
   /// the expression leafs and checking its validity (we can handle
@@ -249,7 +258,7 @@

     ret = vals[0];
     for (j = 1; j < n; j++)
-      op(ret, vals[j]);
+      Unwrap<Op>::unwrap(op)(ret, vals[j]);
     delete [] vals;
   }
 };
diff -Nru a/r2/src/Evaluator/WhereProxy.h b/r2/src/Evaluator/WhereProxy.h
--- a/r2/src/Evaluator/WhereProxy.h	Thu Nov 20 22:03:32 2003
+++ b/r2/src/Evaluator/WhereProxy.h	Thu Nov 20 22:03:32 2003
@@ -85,6 +85,10 @@
   typedef typename ConvertWhereProxy<ETrait_t,Tree_t>::Make_t MakeFromTree_t;
   typedef typename MakeFromTree_t::Expression_t               WhereMask_t;

+  typedef typename B::Element_t Element_t;
+
+  enum { hasRelations = B::hasRelations };
+
   inline WhereMask_t
   whereMask() const
   {
diff -Nru a/r2/src/Field/tests/WhereTest.cpp b/r2/src/Field/tests/WhereTest.cpp
--- a/r2/src/Field/tests/WhereTest.cpp	Thu Nov 20 22:03:32 2003
+++ b/r2/src/Field/tests/WhereTest.cpp	Thu Nov 20 22:03:32 2003
@@ -86,6 +86,7 @@
   // Now, we can declare a field.

   Centering<2> allFace = canonicalCentering<2>(FaceType, Continuous);
+  Centering<2> allCell = canonicalCentering<2>(CellType, Continuous);

   typedef UniformRectilinearMesh<2> Geometry_t;

@@ -103,6 +104,9 @@
   Field_t a(allFace, layout, origin, spacings);
   Field_t b(allFace, layout, origin, spacings);
   Field_t c(allFace, layout, origin, spacings);
+  Field_t d(allCell, layout, origin, spacings);
+  Field_t e(allCell, layout, origin, spacings);
+  Field_t f(allCell, layout, origin, spacings);

   PositionsTraits<Geometry_t>::Type_t x = positions(a);

@@ -154,6 +158,21 @@
   tester.check("twoarg where result dirtied part, centering one",
                all(where(dot(x.subField(0, 1), line) > 8.0,
                    b.subField(0, 1), c.subField(0, 1)) == a.subField(0, 1)));
+
+  // 2-arg where reduction
+
+  d = 1.0;
+  e = positions(e).read(e.physicalDomain()).comp(0);
+  tester.check("reduction over twoarg where",
+	       sum(where(e(e.physicalDomain()) < 4.0, d)) == 4.0*9.0);
+
+  // 3-arg where reduction
+
+  d = 1.0;
+  f = 0.0;
+  e = positions(e).read(e.physicalDomain()).comp(0);
+  tester.check("reduction over twoarg where",
+	       sum(where(e(e.physicalDomain()) < 4.0, d, f)) == 4.0*9.0);

   int ret = tester.results("WhereTest");
   Pooma::finalize();


From rguenth at tat.physik.uni-tuebingen.de  Fri Nov 21 21:08:27 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Fri, 21 Nov 2003 22:08:27 +0100 (CET)
Subject: [PATCH] Support reductions over where(), 2nd try
Message-ID: <Pine.LNX.4.58.0311212054100.560@goofy>

Hi!

This version doesnt break any use of where as the first version did.
Double-checked with a full build and regression test using Intel
icpc 8.0 in -ansi mode.

This also adds the where cases I broke with the first patch to the
array and field tests.

Ok?

Richard.


2003Nov21  Richard Guenther <richard.guenther at uni-tuebingen.de>

	* src/Evaluator/WhereProxy.h: support reduction over
	WhereProxy<> objects by adding Element_t.
	src/Evaluator/OpMask.h: Add ReductionTraits<> specialization
	for OpMask<T>, add Unwrap<> to unwrap OpMask<>.
	src/Engine/RemoteEngine.h: use unwrapped Op for final
	reduction over patch results.
	src/Evaluator/Reduction.h: likewise. Add evaluate() method
	handling WhereProxy to main evaluator.
	src/Array/tests/array_test12.cpp: Add where reduction testcases.
	src/Field/tests/WhereTest.cpp: likewise.

===================================================================
RCS file: /home/pooma/Repository/r2/src/Array/tests/array_test12.cpp,v
retrieving revision 1.13
diff -u -u -r1.13 array_test12.cpp
--- Array/tests/array_test12.cpp	10 Mar 2000 18:10:45 -0000	1.13
+++ Array/tests/array_test12.cpp	21 Nov 2003 20:30:07 -0000
@@ -109,6 +109,11 @@
   tester.out() << std::endl;
   tester.check("d2 < 0.000001", d2 < 0.000001);

+  int cnt = sum(where(d == 0.0, 1));
+  tester.check("couting zeros with where reduction", cnt == 6);
+
+  tester.check("where reduction", prod(where(d == 0.0, d)) == 0.0);
+
   int ret = tester.results("array_test12");
   Pooma::finalize();
   return ret;
Index: Engine/RemoteEngine.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Engine/RemoteEngine.h,v
retrieving revision 1.37
diff -u -u -r1.37 RemoteEngine.h
--- Engine/RemoteEngine.h	22 Oct 2003 19:38:07 -0000	1.37
+++ Engine/RemoteEngine.h	21 Nov 2003 20:30:08 -0000
@@ -2069,7 +2069,7 @@
       {
 	ret = vals[0];
 	for (j = 1; j < n; j++)
-	  op(ret, vals[j]);
+	  Unwrap<Op>::unwrap(op)(ret, vals[j]);
       }

     delete [] vals;
Index: Evaluator/OpMask.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/OpMask.h,v
retrieving revision 1.20
diff -u -u -r1.20 OpMask.h
--- Evaluator/OpMask.h	22 Oct 2003 20:43:26 -0000	1.20
+++ Evaluator/OpMask.h	21 Nov 2003 20:30:08 -0000
@@ -169,6 +169,28 @@
   typedef T1 &Type_t;
 };

+template <class Op>
+struct Unwrap {
+  typedef Op Op_t;
+  static inline const Op_t& unwrap(const Op &op) { return op; }
+};
+
+template <class Op>
+struct Unwrap<OpMask<Op> > {
+  typedef typename Unwrap<Op>::Op_t Op_t;
+  static inline const Op_t& unwrap(const OpMask<Op> &op) { return Unwrap<Op>::unwrap(op.op_m); }
+};
+
+template <class Op, class T>
+struct ReductionTraits;
+
+template <class Op, class T>
+struct ReductionTraits<OpMask<Op>, T>
+{
+  static T identity() { return ReductionTraits<Op, T>::identity(); }
+};
+
+
 //-----------------------------------------------------------------------------
 //
 //-----------------------------------------------------------------------------
Index: Evaluator/Reduction.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/Reduction.h,v
retrieving revision 1.12
diff -u -u -r1.12 Reduction.h
--- Evaluator/Reduction.h	21 Nov 2003 17:36:10 -0000	1.12
+++ Evaluator/Reduction.h	21 Nov 2003 20:30:08 -0000
@@ -53,7 +53,9 @@
 #include "Engine/IntersectEngine.h"
 #include "Evaluator/ReductionKernel.h"
 #include "Evaluator/EvaluatorTags.h"
+#include "Evaluator/WhereProxy.h"
 #include "Threads/PoomaCSem.h"
+#include "Utilities/PerformUpdate.h"

 #include <vector>
 #include <iterator>
@@ -109,6 +111,14 @@
     return e.centeringSize() == 1 && e.numMaterials() == 1;
   }

+  /// Un-wrap where() expression operation and pass on to generic evaluator.
+
+  template<class T, class Op, class Cond, class Expr>
+  void evaluate(T &ret, const Op &op, const WhereProxy<Cond, Expr> &w) const
+  {
+    evaluate(ret, w.opMask(op), w.whereMask());
+  }
+
   /// Input an expression and cause it to be reduced.
   /// We just pass the buck to a special reduction after updating
   /// the expression leafs and checking its validity (we can handle
@@ -249,7 +259,7 @@

     ret = vals[0];
     for (j = 1; j < n; j++)
-      op(ret, vals[j]);
+      Unwrap<Op>::unwrap(op)(ret, vals[j]);
     delete [] vals;
   }
 };
Index: Evaluator/WhereProxy.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/WhereProxy.h,v
retrieving revision 1.5
diff -u -u -r1.5 WhereProxy.h
--- Evaluator/WhereProxy.h	22 Oct 2003 20:43:26 -0000	1.5
+++ Evaluator/WhereProxy.h	21 Nov 2003 20:30:08 -0000
@@ -48,6 +48,7 @@

 #include "Evaluator/OpMask.h"
 #include "Pooma/PETE/ExpressionTraits.h"
+#include "Engine/ExpressionEngine.h"

 //-----------------------------------------------------------------------------
 /// We need the tools to convert a WhereProxy into an Array or Field or
@@ -84,6 +85,8 @@
   typedef typename ExpressionTraits<Tree_t>::Type_t           ETrait_t;
   typedef typename ConvertWhereProxy<ETrait_t,Tree_t>::Make_t MakeFromTree_t;
   typedef typename MakeFromTree_t::Expression_t               WhereMask_t;
+  typedef typename ForEach<typename CreateLeaf<B>::Leaf_t,
+			   EvalLeaf<1>, OpCombine>::Type_t    Element_t;

   inline WhereMask_t
   whereMask() const
Index: Field/tests/WhereTest.cpp
===================================================================
RCS file: /home/pooma/Repository/r2/src/Field/tests/WhereTest.cpp,v
retrieving revision 1.2
diff -u -u -r1.2 WhereTest.cpp
--- Field/tests/WhereTest.cpp	23 Jan 2003 19:21:49 -0000	1.2
+++ Field/tests/WhereTest.cpp	21 Nov 2003 20:30:09 -0000
@@ -86,6 +86,7 @@
   // Now, we can declare a field.

   Centering<2> allFace = canonicalCentering<2>(FaceType, Continuous);
+  Centering<2> allCell = canonicalCentering<2>(CellType, Continuous);

   typedef UniformRectilinearMesh<2> Geometry_t;

@@ -103,6 +104,9 @@
   Field_t a(allFace, layout, origin, spacings);
   Field_t b(allFace, layout, origin, spacings);
   Field_t c(allFace, layout, origin, spacings);
+  Field_t d(allCell, layout, origin, spacings);
+  Field_t e(allCell, layout, origin, spacings);
+  Field_t f(allCell, layout, origin, spacings);

   PositionsTraits<Geometry_t>::Type_t x = positions(a);

@@ -154,6 +158,43 @@
   tester.check("twoarg where result dirtied part, centering one",
                all(where(dot(x.subField(0, 1), line) > 8.0,
                    b.subField(0, 1), c.subField(0, 1)) == a.subField(0, 1)));
+
+  // 2-arg where reduction
+
+  d = 1.0;
+  e = positions(e).read(e.physicalDomain()).comp(0);
+  tester.check("reduction over twoarg where",
+	       sum(where(e(e.physicalDomain()) < 4.0, d)) == 4.0*9.0);
+
+  // 3-arg where reduction
+
+  d = 1.0;
+  f = 0.0;
+  e = positions(e).read(e.physicalDomain()).comp(0);
+  tester.check("reduction over twoarg where",
+	       sum(where(e(e.physicalDomain()) < 4.0, d, f)) == 4.0*9.0);
+
+  // 2-arg where with scalar expression and reduction variant thereof
+
+  d = where(e(e.physicalDomain()) >= 4.0, 0.0);
+  tester.check("counting reduction",
+	       sum(where(d(d.physicalDomain()) != 0.0, 1)) == 4*9);
+
+  // 2-arg where with scalar test and reduction variant thereof
+
+  d = where(true, f);
+  tester.check("stupid where", all(d(d.physicalDomain()) == 0.0));
+  tester.check("stupid where reduction", prod(where(true, d)) == 0.0);
+
+  // note that where with both expression and test being scalar does not
+  // work because of
+  // src/Pooma/PETE/ExpressionTraits.h:121:
+  // error: no type named `Type_t' in
+  //        `struct CombineExpressionTraits<ExpressionIsScalar, ExpressionIsScalar>'
+  // and that is probably not the only reason.
+  //
+  // d = where(true, 1.0);
+  // tester.check("even more stupid where", all(d(d.physicalDomain()) == 1.0));

   int ret = tester.results("WhereTest");
   Pooma::finalize();


From oldham at codesourcery.com  Fri Nov 21 21:23:37 2003
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Fri, 21 Nov 2003 13:23:37 -0800
Subject: [PATCH] Support reductions over where(), 2nd try
In-Reply-To: <Pine.LNX.4.58.0311212054100.560@goofy>
References: <Pine.LNX.4.58.0311212054100.560@goofy>
Message-ID: <3FBE8259.6020904@codesourcery.com>

Richard Guenther wrote:
> Hi!
> 
> This version doesnt break any use of where as the first version did.
> Double-checked with a full build and regression test using Intel
> icpc 8.0 in -ansi mode.
> 
> This also adds the where cases I broke with the first patch to the
> array and field tests.
> 
> Ok?

Yes, but see the correction and three suggestions below.

> Richard.
> 
> 
> 2003Nov21  Richard Guenther <richard.guenther at uni-tuebingen.de>
> 
> 	* src/Evaluator/WhereProxy.h: support reduction over
> 	WhereProxy<> objects by adding Element_t.
> 	src/Evaluator/OpMask.h: Add ReductionTraits<> specialization
> 	for OpMask<T>, add Unwrap<> to unwrap OpMask<>.
> 	src/Engine/RemoteEngine.h: use unwrapped Op for final
> 	reduction over patch results.
> 	src/Evaluator/Reduction.h: likewise. Add evaluate() method
> 	handling WhereProxy to main evaluator.
> 	src/Array/tests/array_test12.cpp: Add where reduction testcases.
> 	src/Field/tests/WhereTest.cpp: likewise.
> 
> ===================================================================
> RCS file: /home/pooma/Repository/r2/src/Array/tests/array_test12.cpp,v
> retrieving revision 1.13
> diff -u -u -r1.13 array_test12.cpp
> --- Array/tests/array_test12.cpp	10 Mar 2000 18:10:45 -0000	1.13
> +++ Array/tests/array_test12.cpp	21 Nov 2003 20:30:07 -0000
> @@ -109,6 +109,11 @@
>    tester.out() << std::endl;
>    tester.check("d2 < 0.000001", d2 < 0.000001);
> 
> +  int cnt = sum(where(d == 0.0, 1));
> +  tester.check("couting zeros with where reduction", cnt == 6);

s/couting/counting/

> +
> +  tester.check("where reduction", prod(where(d == 0.0, d)) == 0.0);
> +
>    int ret = tester.results("array_test12");
>    Pooma::finalize();
>    return ret;
> Index: Engine/RemoteEngine.h
> ===================================================================
> RCS file: /home/pooma/Repository/r2/src/Engine/RemoteEngine.h,v
> retrieving revision 1.37
> diff -u -u -r1.37 RemoteEngine.h
> --- Engine/RemoteEngine.h	22 Oct 2003 19:38:07 -0000	1.37
> +++ Engine/RemoteEngine.h	21 Nov 2003 20:30:08 -0000
> @@ -2069,7 +2069,7 @@
>        {
>  	ret = vals[0];
>  	for (j = 1; j < n; j++)
> -	  op(ret, vals[j]);
> +	  Unwrap<Op>::unwrap(op)(ret, vals[j]);
>        }
> 
>      delete [] vals;
> Index: Evaluator/OpMask.h
> ===================================================================
> RCS file: /home/pooma/Repository/r2/src/Evaluator/OpMask.h,v
> retrieving revision 1.20
> diff -u -u -r1.20 OpMask.h
> --- Evaluator/OpMask.h	22 Oct 2003 20:43:26 -0000	1.20
> +++ Evaluator/OpMask.h	21 Nov 2003 20:30:08 -0000
> @@ -169,6 +169,28 @@
>    typedef T1 &Type_t;
>  };
> 
> +template <class Op>
> +struct Unwrap {
> +  typedef Op Op_t;
> +  static inline const Op_t& unwrap(const Op &op) { return op; }
> +};
> +
> +template <class Op>
> +struct Unwrap<OpMask<Op> > {
> +  typedef typename Unwrap<Op>::Op_t Op_t;
> +  static inline const Op_t& unwrap(const OpMask<Op> &op) { return Unwrap<Op>::unwrap(op.op_m); }
> +};
> +
> +template <class Op, class T>
> +struct ReductionTraits;
> +
> +template <class Op, class T>
> +struct ReductionTraits<OpMask<Op>, T>
> +{
> +  static T identity() { return ReductionTraits<Op, T>::identity(); }
> +};
> +
> +
>  //-----------------------------------------------------------------------------
>  //
>  //-----------------------------------------------------------------------------
> Index: Evaluator/Reduction.h
> ===================================================================
> RCS file: /home/pooma/Repository/r2/src/Evaluator/Reduction.h,v
> retrieving revision 1.12
> diff -u -u -r1.12 Reduction.h
> --- Evaluator/Reduction.h	21 Nov 2003 17:36:10 -0000	1.12
> +++ Evaluator/Reduction.h	21 Nov 2003 20:30:08 -0000
> @@ -53,7 +53,9 @@
>  #include "Engine/IntersectEngine.h"
>  #include "Evaluator/ReductionKernel.h"
>  #include "Evaluator/EvaluatorTags.h"
> +#include "Evaluator/WhereProxy.h"
>  #include "Threads/PoomaCSem.h"
> +#include "Utilities/PerformUpdate.h"
> 
>  #include <vector>
>  #include <iterator>
> @@ -109,6 +111,14 @@
>      return e.centeringSize() == 1 && e.numMaterials() == 1;
>    }
> 
> +  /// Un-wrap where() expression operation and pass on to generic evaluator.
> +
> +  template<class T, class Op, class Cond, class Expr>
> +  void evaluate(T &ret, const Op &op, const WhereProxy<Cond, Expr> &w) const
> +  {
> +    evaluate(ret, w.opMask(op), w.whereMask());
> +  }
> +
>    /// Input an expression and cause it to be reduced.
>    /// We just pass the buck to a special reduction after updating
>    /// the expression leafs and checking its validity (we can handle
> @@ -249,7 +259,7 @@
> 
>      ret = vals[0];
>      for (j = 1; j < n; j++)
> -      op(ret, vals[j]);
> +      Unwrap<Op>::unwrap(op)(ret, vals[j]);
>      delete [] vals;
>    }
>  };
> Index: Evaluator/WhereProxy.h
> ===================================================================
> RCS file: /home/pooma/Repository/r2/src/Evaluator/WhereProxy.h,v
> retrieving revision 1.5
> diff -u -u -r1.5 WhereProxy.h
> --- Evaluator/WhereProxy.h	22 Oct 2003 20:43:26 -0000	1.5
> +++ Evaluator/WhereProxy.h	21 Nov 2003 20:30:08 -0000
> @@ -48,6 +48,7 @@
> 
>  #include "Evaluator/OpMask.h"
>  #include "Pooma/PETE/ExpressionTraits.h"
> +#include "Engine/ExpressionEngine.h"
> 
>  //-----------------------------------------------------------------------------
>  /// We need the tools to convert a WhereProxy into an Array or Field or
> @@ -84,6 +85,8 @@
>    typedef typename ExpressionTraits<Tree_t>::Type_t           ETrait_t;
>    typedef typename ConvertWhereProxy<ETrait_t,Tree_t>::Make_t MakeFromTree_t;
>    typedef typename MakeFromTree_t::Expression_t               WhereMask_t;
> +  typedef typename ForEach<typename CreateLeaf<B>::Leaf_t,
> +			   EvalLeaf<1>, OpCombine>::Type_t    Element_t;
> 
>    inline WhereMask_t
>    whereMask() const
> Index: Field/tests/WhereTest.cpp
> ===================================================================
> RCS file: /home/pooma/Repository/r2/src/Field/tests/WhereTest.cpp,v
> retrieving revision 1.2
> diff -u -u -r1.2 WhereTest.cpp
> --- Field/tests/WhereTest.cpp	23 Jan 2003 19:21:49 -0000	1.2
> +++ Field/tests/WhereTest.cpp	21 Nov 2003 20:30:09 -0000
> @@ -86,6 +86,7 @@
>    // Now, we can declare a field.
> 
>    Centering<2> allFace = canonicalCentering<2>(FaceType, Continuous);
> +  Centering<2> allCell = canonicalCentering<2>(CellType, Continuous);
> 
>    typedef UniformRectilinearMesh<2> Geometry_t;
> 
> @@ -103,6 +104,9 @@
>    Field_t a(allFace, layout, origin, spacings);
>    Field_t b(allFace, layout, origin, spacings);
>    Field_t c(allFace, layout, origin, spacings);
> +  Field_t d(allCell, layout, origin, spacings);
> +  Field_t e(allCell, layout, origin, spacings);
> +  Field_t f(allCell, layout, origin, spacings);
> 
>    PositionsTraits<Geometry_t>::Type_t x = positions(a);
> 
> @@ -154,6 +158,43 @@
>    tester.check("twoarg where result dirtied part, centering one",
>                 all(where(dot(x.subField(0, 1), line) > 8.0,
>                     b.subField(0, 1), c.subField(0, 1)) == a.subField(0, 1)));
> +
> +  // 2-arg where reduction
> +
> +  d = 1.0;
> +  e = positions(e).read(e.physicalDomain()).comp(0);
> +  tester.check("reduction over twoarg where",
> +	       sum(where(e(e.physicalDomain()) < 4.0, d)) == 4.0*9.0);
> +
> +  // 3-arg where reduction
> +
> +  d = 1.0;
> +  f = 0.0;
> +  e = positions(e).read(e.physicalDomain()).comp(0);
> +  tester.check("reduction over twoarg where",
> +	       sum(where(e(e.physicalDomain()) < 4.0, d, f)) == 4.0*9.0);
> +
> +  // 2-arg where with scalar expression and reduction variant thereof
> +
> +  d = where(e(e.physicalDomain()) >= 4.0, 0.0);
> +  tester.check("counting reduction",
> +	       sum(where(d(d.physicalDomain()) != 0.0, 1)) == 4*9);
> +
> +  // 2-arg where with scalar test and reduction variant thereof
> +
> +  d = where(true, f);
> +  tester.check("stupid where", all(d(d.physicalDomain()) == 0.0));
> +  tester.check("stupid where reduction", prod(where(true, d)) == 0.0);

I would prefer to use the word "simple", not "stupid".

> +
> +  // note that where with both expression and test being scalar does not
> +  // work because of
> +  // src/Pooma/PETE/ExpressionTraits.h:121:
> +  // error: no type named `Type_t' in
> +  //        `struct CombineExpressionTraits<ExpressionIsScalar, ExpressionIsScalar>'
> +  // and that is probably not the only reason.
> +  //
> +  // d = where(true, 1.0);
> +  // tester.check("even more stupid where", all(d(d.physicalDomain()) == 1.0));

Likewise.

> 
>    int ret = tester.results("WhereTest");
>    Pooma::finalize();


-- 
Jeffrey D. Oldham
oldham at codesourcery.com



From rguenth at tat.physik.uni-tuebingen.de  Fri Nov 21 22:21:59 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Fri, 21 Nov 2003 23:21:59 +0100 (CET)
Subject: Extracting a list of Loc<>s out of a distributed engine?
Message-ID: <Pine.LNX.4.58.0311212316580.560@goofy>

Hi!

Is there a convenient (fast) way to extract say a std::vector<Loc<3> > out
of an existing distributed Array into another (local) 1d Array? So,
something like

   std::vector<Loc<3> > v = ...;
   Array<1, double, Remote<Brick> > A;  // local on node #0
   Array<3, double, MultiPatch<GridTag, Remote<Brick> > > B;  // distributed
   A = B(v);

?

I'm currently iterating over the vector copying one Loc at a time, but
this obviously doesnt scale - optimal would be communication in chunks
local to one host.

Any suggestions?

Richard.


From rguenth at tat.physik.uni-tuebingen.de  Fri Nov 21 22:52:09 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Fri, 21 Nov 2003 23:52:09 +0100 (CET)
Subject: OpenMP question
Message-ID: <Pine.LNX.4.58.0311212345490.560@goofy>

Hi!

Any OpenMP experts on the table? How would one do manual reduction
parallelized with OpenMP like from Evaluator/ReductionEvaluator.h:

  template<class T, class Op, class Expr, class Domain>
  inline static void evaluate(T &ret, const Op &op, const Expr &e,
    const Domain &domain, WrappedInt<1>)
  {
    Expr localExpr(e);
    int e0 = domain[0].length();

    T answer = ReductionTraits<Op, T>::identity();
    for (int i0 = 0; i0 < e0; ++i0)
      op(answer, localExpr.read(i0));

    ret = answer;
  }

So the first part may be easy, just(?)

    T answer = ReductionTraits<Op, T>::identity();
#pragma omp parallel for private (answer)
    for (int i0 = 0; i0 < e0; ++i0)
      op(answer, localExpr.read(i0));

but how do the final reduction on the multiple private answer's? One cant
use the reduction functionality from OpenMP with these C++ constructs
here, sadly. The stranges version I could come up with is (I'm sure it
still won't work):

#pragma omp parallel shared (answer)
    {
      T answer[omp_get_num_threads()]; // is probably private now... :/
      int n = omp_get_thread_num();
      answer[n] = ReductionTraits<Op, T>::identity();
#pragma omp for
      for (int i0 = 0; i0 < e0; ++i0)
        op(answer[n], localExpr.read(i0));
#pragma omp master
      {
        for (int i = 1; i<omp_get_num_threads(); ++i)
          op(answer[0], answer[i]);

        ret = answer[0];
      }
    }


Any hints on doing OpenMP reductions with C++ operators here from anyone?

Thanks in advance!

Richard.


From h.belitz at fz-juelich.de  Wed Nov 26 14:01:25 2003
From: h.belitz at fz-juelich.de (Hendrik Belitz)
Date: Wed, 26 Nov 2003 15:01:25 +0100
Subject: POOMA Namespace Pollution
Message-ID: <200311261501.25037.h.belitz@fz-juelich.de>

Hi there!

I want to use POOMA inside my project. But POOMA defines some structs with 
names that collide with other libraries I use. Is there an simple way to 
create a seperate namespace for the POOMA lib?

----------------------------------------------------------------
Dipl.-Inform. Hendrik Belitz
Zentrallabor f?r Elektronik
Forschungszentrum J?lich GmbH
D-52428 J?lich, Germany
Tel.: (++49)2461 61 2425
Fax: (++49)2461 61 3990
email: h.belitz at fz-juelich.de



From rguenth at tat.physik.uni-tuebingen.de  Wed Nov 26 14:07:15 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Wed, 26 Nov 2003 15:07:15 +0100 (CET)
Subject: [pooma-dev] POOMA Namespace Pollution
In-Reply-To: <200311261501.25037.h.belitz@fz-juelich.de> tests=DOUBLE_CAPSWORD,USER_IN_WHITELIST version=2.31
References: <200311261501.25037.h.belitz@fz-juelich.de>
 tests=DOUBLE_CAPSWORD,USER_IN_WHITELIST version=2.31
Message-ID: <Pine.LNX.4.53.0311261505160.23001@bellatrix.tat.physik.uni-tuebingen.de>

On Wed, 26 Nov 2003, Hendrik Belitz wrote:

> Hi there!
>
> I want to use POOMA inside my project. But POOMA defines some structs with
> names that collide with other libraries I use. Is there an simple way to
> create a seperate namespace for the POOMA lib?

namespace Pooma {
  #include "Pooma/Pooma.h"
  ...
}

but maybe you need to change the namespace name to something else than
Pooma, as I dont know, if Pooma::Pooma::XXX works.

You can also mark the colliding names inside the sources with namespace
Pooma. But I really suspect internal Pooma is not namespace clean.

Richard.

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


From h.belitz at fz-juelich.de  Wed Nov 26 14:35:09 2003
From: h.belitz at fz-juelich.de (Hendrik Belitz)
Date: Wed, 26 Nov 2003 15:35:09 +0100
Subject: [pooma-dev] POOMA Namespace Pollution
In-Reply-To: <Pine.LNX.4.53.0311261505160.23001@bellatrix.tat.physik.uni-tuebingen.de>
References: <200311261501.25037.h.belitz@fz-juelich.de> <tests=DOUBLE_CAPSWORD@fz-juelich.de>  <Pine.LNX.4.53.0311261505160.23001@bellatrix.tat.physik.uni-tuebingen.de>
Message-ID: <200311261535.09778.h.belitz@fz-juelich.de>

Am Mittwoch, 26. November 2003 15:07 schrieben Sie:
> You can also mark the colliding names inside the sources with namespace
> Pooma. But I really suspect internal Pooma is not namespace clean.

It doesn't seem to be. Putting the POOMA headers into a namespace won't solve 
the problem (this seem to lead to a double inclusion of some STL headers, 
resulting in a pretty large bunch of errors). Not putting POOMA into an 
namespace shows that most of the internal POOMA structures are not in the 
POOMA namespace at all (Resulting in namespace pollution).
 
----------------------------------------------------------------
Dipl.-Inform. Hendrik Belitz
Zentrallabor f?r Elektronik
Forschungszentrum J?lich GmbH
D-52428 J?lich, Germany
Tel.: (++49)2461 61 2425
Fax: (++49)2461 61 3990
email: h.belitz at fz-juelich.de



From rguenth at tat.physik.uni-tuebingen.de  Wed Nov 26 15:29:47 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Wed, 26 Nov 2003 16:29:47 +0100 (CET)
Subject: [pooma-dev] POOMA Namespace Pollution
In-Reply-To: <200311261535.09778.h.belitz@fz-juelich.de> tests=IN_REP_TO,DOUBLE_CAPSWORD,USER_IN_WHITELIST version=2.31
References: <200311261501.25037.h.belitz@fz-juelich.de> <tests=DOUBLE_CAPSWORD@fz-juelich.de>
  <Pine.LNX.4.53.0311261505160.23001@bellatrix.tat.physik.uni-tuebingen.de>
 <200311261535.09778.h.belitz@fz-juelich.de> tests=IN_REP_TO,DOUBLE_CAPSWORD,USER_IN_WHITELIST
 version=2.31
Message-ID: <Pine.LNX.4.53.0311261627520.23001@bellatrix.tat.physik.uni-tuebingen.de>

On Wed, 26 Nov 2003, Hendrik Belitz wrote:

> Am Mittwoch, 26. November 2003 15:07 schrieben Sie:
> > You can also mark the colliding names inside the sources with namespace
> > Pooma. But I really suspect internal Pooma is not namespace clean.
>
> It doesn't seem to be. Putting the POOMA headers into a namespace won't solve
> the problem (this seem to lead to a double inclusion of some STL headers,
> resulting in a pretty large bunch of errors). Not putting POOMA into an
> namespace shows that most of the internal POOMA structures are not in the
> POOMA namespace at all (Resulting in namespace pollution).

Yes, in fact, all over the POOMA source there are commented out namespace
Pooma guards, so I think there were compiler problems some time ago. I
already put some global functions back into Pooma namespace locally, so
maybe there needs to be a point in the future we re-enable all the Pooma
namespace.

Maybe Jeffrey has some suggestions on this, as it breaks backward
compatibility.

Richard.

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


From oldham at codesourcery.com  Wed Nov 26 18:42:24 2003
From: oldham at codesourcery.com (Jeffrey D. Oldham)
Date: Wed, 26 Nov 2003 10:42:24 -0800
Subject: [pooma-dev] POOMA Namespace Pollution
In-Reply-To: <Pine.LNX.4.53.0311261627520.23001@bellatrix.tat.physik.uni-tuebingen.de>
References: <200311261501.25037.h.belitz@fz-juelich.de> <tests=DOUBLE_CAPSWORD@fz-juelich.de>  <Pine.LNX.4.53.0311261505160.23001@bellatrix.tat.physik.uni-tuebingen.de> <200311261535.09778.h.belitz@fz-juelich.de> tests=IN_REP_TO,DOUBLE_CAPSWORD,USER_IN_WHITELIST version=2.31 <Pine.LNX.4.53.0311261627520.23001@bellatrix.tat.physik.uni-tuebingen.de>
Message-ID: <3FC4F410.6060405@codesourcery.com>

Richard Guenther wrote:
> On Wed, 26 Nov 2003, Hendrik Belitz wrote:
> 
>>Am Mittwoch, 26. November 2003 15:07 schrieben Sie:
>>
>>>You can also mark the colliding names inside the sources with namespace
>>>Pooma. But I really suspect internal Pooma is not namespace clean.
>>
>>It doesn't seem to be. Putting the POOMA headers into a namespace won't solve
>>the problem (this seem to lead to a double inclusion of some STL headers,
>>resulting in a pretty large bunch of errors). Not putting POOMA into an
>>namespace shows that most of the internal POOMA structures are not in the
>>POOMA namespace at all (Resulting in namespace pollution).
> 
> 
> Yes, in fact, all over the POOMA source there are commented out namespace
> Pooma guards, so I think there were compiler problems some time ago. I
> already put some global functions back into Pooma namespace locally, so
> maybe there needs to be a point in the future we re-enable all the Pooma
> namespace.
> 
> Maybe Jeffrey has some suggestions on this, as it breaks backward
> compatibility.

This might be a good time to add namespace support for POOMA.  I know of 
two issues:

1) Backwards compatibility: We might be able to maintain backwards 
compatibility by supporting optional namespaces where the default option 
is no namespaces.  I attach a file with a possible approach.

2) Adding namespaces to PETE, the loop fusion mechanism, may be non-trivial.

-- 
Jeffrey D. Oldham
oldham at codesourcery.com
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: foo.cpp
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20031126/bbbcd070/attachment.ksh>

From rguenth at tat.physik.uni-tuebingen.de  Thu Nov 27 08:49:31 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 27 Nov 2003 09:49:31 +0100 (CET)
Subject: [pooma-dev] POOMA Namespace Pollution
In-Reply-To: <3FC4F410.6060405@codesourcery.com>
References: <200311261501.25037.h.belitz@fz-juelich.de> <tests=DOUBLE_CAPSWORD@fz-juelich.de>
  <Pine.LNX.4.53.0311261505160.23001@bellatrix.tat.physik.uni-tuebingen.de>
 <200311261535.09778.h.belitz@fz-juelich.de> tests=IN_REP_TO,DOUBLE_CAPSWORD,USER_IN_WHITELIST
 version=2.31 <Pine.LNX.4.53.0311261627520.23001@bellatrix.tat.physik.uni-tuebingen.de>
 <3FC4F410.6060405@codesourcery.com>
Message-ID: <Pine.LNX.4.53.0311270946320.23001@bellatrix.tat.physik.uni-tuebingen.de>

On Wed, 26 Nov 2003, Jeffrey D. Oldham wrote:

> This might be a good time to add namespace support for POOMA.  I know of
> two issues:
>
> 1) Backwards compatibility: We might be able to maintain backwards
> compatibility by supporting optional namespaces where the default option
> is no namespaces.  I attach a file with a possible approach.

Hmm, I think this is way too ugly ;)  Backwards compatibility should be
made possible by adding

using Pooma;

to affected user programs.

> 2) Adding namespaces to PETE, the loop fusion mechanism, may be non-trivial.

I dont know what will be hard here, apart from having autogenerated files.
But I suspect leaving PETE alone would be a good start.

Richard.

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


From jcrotinger at proximation.com  Thu Nov 27 19:28:13 2003
From: jcrotinger at proximation.com (James Crotinger)
Date: Thu, 27 Nov 2003 12:28:13 -0700
Subject: [pooma-dev] POOMA Namespace Pollution
Message-ID: <F871BB04B0EA224A821A5274C31DF31512977A@proxim-sf001.santafe.proximation.com>

Hi All,

I thought that the various global (non-Pooma::) functions all had Pooma::
objects as arguments, which should usually be enough to avoid collisions
with other people's stuff. What are the problem functions? 

I added namespace support to PETE a long time ago, but I believe it is an
option on the generator program that is used to generate the operator files.
Does CodeSourcery maintain the separate PETE repository? I don't think this
stuff was ever part of the Pooma distribution - we just generated the
operator includes and checked those in. At any rate, we didn't put the Pooma
operators in a namespace because, at the time, some of our compilers
(probably most, in fact) didn't do Koenig lookup correctly. 

Happy Thanksgiving!

	Jim


-----Original Message-----
From: Jeffrey D. Oldham [mailto:oldham at codesourcery.com] 
Sent: Wednesday, November 26, 2003 11:42 AM
To: Richard Guenther
Cc: Hendrik Belitz; pooma-dev at pooma.codesourcery.com
Subject: Re: [pooma-dev] POOMA Namespace Pollution

Richard Guenther wrote:
> On Wed, 26 Nov 2003, Hendrik Belitz wrote:
> 
>>Am Mittwoch, 26. November 2003 15:07 schrieben Sie:
>>
>>>You can also mark the colliding names inside the sources with namespace
>>>Pooma. But I really suspect internal Pooma is not namespace clean.
>>
>>It doesn't seem to be. Putting the POOMA headers into a namespace won't
solve
>>the problem (this seem to lead to a double inclusion of some STL headers,
>>resulting in a pretty large bunch of errors). Not putting POOMA into an
>>namespace shows that most of the internal POOMA structures are not in the
>>POOMA namespace at all (Resulting in namespace pollution).
> 
> 
> Yes, in fact, all over the POOMA source there are commented out namespace
> Pooma guards, so I think there were compiler problems some time ago. I
> already put some global functions back into Pooma namespace locally, so
> maybe there needs to be a point in the future we re-enable all the Pooma
> namespace.
> 
> Maybe Jeffrey has some suggestions on this, as it breaks backward
> compatibility.

This might be a good time to add namespace support for POOMA.  I know of 
two issues:

1) Backwards compatibility: We might be able to maintain backwards 
compatibility by supporting optional namespaces where the default option 
is no namespaces.  I attach a file with a possible approach.

2) Adding namespaces to PETE, the loop fusion mechanism, may be non-trivial.

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

From rguenth at tat.physik.uni-tuebingen.de  Thu Nov 27 19:38:58 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Thu, 27 Nov 2003 20:38:58 +0100 (CET)
Subject: [pooma-dev] POOMA Namespace Pollution
In-Reply-To: <F871BB04B0EA224A821A5274C31DF31512977A@proxim-sf001.santafe.proximation.com>
References: <F871BB04B0EA224A821A5274C31DF31512977A@proxim-sf001.santafe.proximation.com>
Message-ID: <Pine.LNX.4.58.0311272037420.722@goofy>

On Thu, 27 Nov 2003, James Crotinger wrote:

> Hi All,
>
> I thought that the various global (non-Pooma::) functions all had Pooma::
> objects as arguments, which should usually be enough to avoid collisions
> with other people's stuff. What are the problem functions?

The only problem I experienced is conflicting functions (f.i. positions())
with variables of the same name in my program. But the original request
was about classes anyway.

Richard.


From h.belitz at fz-juelich.de  Fri Nov 28 07:46:49 2003
From: h.belitz at fz-juelich.de (Hendrik Belitz)
Date: Fri, 28 Nov 2003 08:46:49 +0100
Subject: [pooma-dev] POOMA Namespace Pollution
In-Reply-To: <Pine.LNX.4.58.0311272037420.722@goofy>
References: <F871BB04B0EA224A821A5274C31DF31512977A@proxim-sf001.santafe.proximation.com> <Pine.LNX.4.58.0311272037420.722@goofy>
Message-ID: <200311280846.49359.h.belitz@fz-juelich.de>

Am Donnerstag, 27. November 2003 20:38 schrieben Sie:
> On Thu, 27 Nov 2003, James Crotinger wrote:
> > Hi All,
> >
> > I thought that the various global (non-Pooma::) functions all had Pooma::
> > objects as arguments, which should usually be enough to avoid collisions
> > with other people's stuff. What are the problem functions?

Problems arise on including Arrays.h with the Pooma class (or struct?) Region, 
which is not in Pooma namespace. Classes or Functions of this name are 
declared in many other libraries as well (which are also not namespace safe 
and cannot be, e.g. legacy C libs)

----------------------------------------------------------------
Dipl.-Inform. Hendrik Belitz
Zentrallabor f?r Elektronik
Forschungszentrum J?lich GmbH
D-52428 J?lich, Germany
Tel.: (++49)2461 61 2425
Fax: (++49)2461 61 3990
email: h.belitz at fz-juelich.de



From rguenth at tat.physik.uni-tuebingen.de  Fri Nov 28 17:17:13 2003
From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther)
Date: Fri, 28 Nov 2003 18:17:13 +0100 (CET)
Subject: [RFC] OpenMP loop level parallelism
Message-ID: <Pine.LNX.4.58.0311272203210.722@goofy>

Hi!

The attached patch adds loop-level parallelism via OpenMP directives. It
is tested with a full regtest using 2 threads and the Intel compiler 8.0
on an ia32 machine with no regressions compared to non-OpenMP compilation.
Performance and scaling was _not_ evaluated yet (I will have a 4 processor
Itanium available within the next few weeks).

So this is a request for comments and comparisons with parallelization
using threads from SMARTS. Anyone interested should report
success/failure.

Suggested operation is compiling the library in serial mode (with openmp
enabled, edit the config/arch/ file) and best use single patch engines or
at least only a single patch with multi-patch engines.

Anyone with access to an SGI Origin or SGI Altix machine with lots of
processors?

Thanks for any comments,

Richard.
-------------- next part --------------
Index: Evaluator/InlineEvaluator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/InlineEvaluator.h,v
retrieving revision 1.28
diff -u -u -r1.28 InlineEvaluator.h
--- Evaluator/InlineEvaluator.h	22 Oct 2003 20:43:26 -0000	1.28
+++ Evaluator/InlineEvaluator.h	27 Nov 2003 20:57:35 -0000
@@ -149,6 +149,7 @@
     LHS localLHS(lhs);
     RHS localRHS(rhs);
     int e0 = domain[0].length();
+#pragma omp parallel for if (e0 > 512)
     for (int i0=0; i0<e0; ++i0)
       op(localLHS(i0),localRHS.read(i0));
   }
@@ -164,6 +165,7 @@
     RHS localRHS(rhs);
     int e0 = domain[0].length();
     int e1 = domain[1].length();
+#pragma omp parallel for
     for (int i1=0; i1<e1; ++i1)
       for (int i0=0; i0<e0; ++i0)
 	op(localLHS(i0,i1),localRHS.read(i0,i1));
@@ -182,6 +184,7 @@
     int e0 = domain[0].length();
     int e1 = domain[1].length();
     int e2 = domain[2].length();
+#pragma omp parallel for
     for (int i2=0; i2<e2; ++i2)
       for (int i1=0; i1<e1; ++i1)
 	for (int i0=0; i0<e0; ++i0)
@@ -203,6 +206,7 @@
     int e1 = domain[1].length();
     int e2 = domain[2].length();
     int e3 = domain[3].length();
+#pragma omp parallel for
     for (int i3=0; i3<e3; ++i3)
       for (int i2=0; i2<e2; ++i2)
 	for (int i1=0; i1<e1; ++i1)
@@ -227,6 +231,7 @@
     int e2 = domain[2].length();
     int e3 = domain[3].length();
     int e4 = domain[4].length();
+#pragma omp parallel for
     for (int i4=0; i4<e4; ++i4)
       for (int i3=0; i3<e3; ++i3)
 	for (int i2=0; i2<e2; ++i2)
@@ -254,6 +259,7 @@
     int e3 = domain[3].length();
     int e4 = domain[4].length();
     int e5 = domain[5].length();
+#pragma omp parallel for
     for (int i5=0; i5<e5; ++i5)
       for (int i4=0; i4<e4; ++i4)
 	for (int i3=0; i3<e3; ++i3)
@@ -285,6 +291,7 @@
     int e4 = domain[4].length();
     int e5 = domain[5].length();
     int e6 = domain[6].length();
+#pragma omp parallel for
     for (int i6=0; i6<e6; ++i6)
       for (int i5=0; i5<e5; ++i5)
 	for (int i4=0; i4<e4; ++i4)
Index: Evaluator/LoopApply.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/LoopApply.h,v
retrieving revision 1.7
diff -u -u -r1.7 LoopApply.h
--- Evaluator/LoopApply.h	22 Oct 2003 20:43:26 -0000	1.7
+++ Evaluator/LoopApply.h	27 Nov 2003 20:57:35 -0000
@@ -104,6 +104,7 @@
     CTAssert(Domain::unitStride);
     int f0 = domain[0].first();
     int e0 = domain[0].last();
+#pragma omp parallel for if (e0 > 512)
     for (int i0 = f0; i0 <= e0; ++i0)
       op(i0);
   }
@@ -116,6 +117,7 @@
     int f1 = domain[1].first();
     int e0 = domain[0].last();
     int e1 = domain[1].last();
+#pragma omp parallel for
     for (int i1 = f1; i1 <= e1; ++i1)
       for (int i0 = f0; i0 <= e0; ++i0)
 	op(i0, i1);
@@ -131,6 +133,7 @@
     int e0 = domain[0].last();
     int e1 = domain[1].last();
     int e2 = domain[2].last();
+#pragma omp parallel for
     for (int i2 = f2; i2 <= e2; ++i2)
       for (int i1 = f1; i1 <= e1; ++i1)
 	for (int i0 = f0; i0 <= e0; ++i0)
@@ -149,6 +152,7 @@
     int e1 = domain[1].last();
     int e2 = domain[2].last();
     int e3 = domain[3].last();
+#pragma omp parallel for
     for (int i3 = f3; i3 <= e3; ++i3)
       for (int i2 = f2; i2 <= e2; ++i2)
 	for (int i1 = f1; i1 <= e1; ++i1)
@@ -170,6 +174,7 @@
     int e2 = domain[2].last();
     int e3 = domain[3].last();
     int e4 = domain[4].last();
+#pragma omp parallel for
     for (int i4 = f4; i4 <= e4; ++i4)
       for (int i3 = f3; i3 <= e3; ++i3)
 	for (int i2 = f2; i2 <= e2; ++i2)
@@ -194,6 +199,7 @@
     int e3 = domain[3].last();
     int e4 = domain[4].last();
     int e5 = domain[5].last();
+#pragma omp parallel for
     for (int i5 = f5; i5 <= e5; ++i5)
       for (int i4 = f4; i4 <= e4; ++i4)
 	for (int i3 = f3; i3 <= e3; ++i3)
@@ -221,6 +227,7 @@
     int e4 = domain[4].last();
     int e5 = domain[5].last();
     int e6 = domain[6].last();
+#pragma omp parallel for
     for (int i6 = f6; i6 <= e6; ++i6)
       for (int i5 = f5; i5 <= e5; ++i5)
 	for (int i4 = f4; i4 <= e4; ++i4)
Index: Evaluator/ReductionEvaluator.h
===================================================================
RCS file: /home/pooma/Repository/r2/src/Evaluator/ReductionEvaluator.h,v
retrieving revision 1.9
diff -u -u -r1.9 ReductionEvaluator.h
--- Evaluator/ReductionEvaluator.h	29 Oct 2003 20:13:27 -0000	1.9
+++ Evaluator/ReductionEvaluator.h	27 Nov 2003 20:57:36 -0000
@@ -108,6 +108,56 @@
 };
 
 
+/**
+ * Class to hold static array for partial reduction results
+ * and routine for final reduction. Two versions, one dummy
+ * for non-OpenMP, one for OpenMP operation.
+ */
+
+#ifndef _OPENMP
+template<class T>
+struct PartialReduction {
+  static inline void init() {}
+  inline void storePartialResult(const T& result)
+  {
+    answer = result;
+  }
+  template <class Op>
+  inline void reduce(T& ret, const Op&)
+  {
+    ret = answer;
+  }
+  T answer;
+};
+#else
+template<class T>
+struct PartialReduction {
+  static inline void init()
+  {
+    if (!answer)
+      answer = new T[omp_get_max_threads()];
+  }
+  inline void storePartialResult(const T& result)
+  {
+    int n = omp_get_thread_num();
+    answer[n] = result;
+    if (n == 0)
+      num_threads = omp_get_num_threads();
+  }
+  template <class Op>
+  inline void reduce(T& ret, const Op& op)
+  {
+    T res = answer[0];
+    for (int i = 1; i<num_threads; ++i)
+      op(res, answer[i]);
+    ret = res;
+  }
+  int num_threads;
+  static T *answer;
+};
+template <class T>
+T *PartialReduction<T>::answer = NULL;
+#endif
 
 
 //-----------------------------------------------------------------------------
@@ -130,6 +180,7 @@
 template<>
 struct ReductionEvaluator<InlineKernelTag>
 {
+
   //---------------------------------------------------------------------------
   // Input an expression and cause it to be evaluated.
   // All this template function does is extract the domain
@@ -139,6 +190,7 @@
   inline static void evaluate(T &ret, const Op &op, const Expr &e)
   {
     typedef typename Expr::Domain_t Domain_t;
+    PartialReduction<T>::init();
     evaluate(ret, op, e, e.domain(),
       WrappedInt<Domain_t::dimensions>());
   }
@@ -171,7 +223,7 @@
   //
   // NOTE: These loops assume that the domain passed in is a unit-stride
   // domain starting at 0.  Assertions are made to make sure this is true.
-  
+
   template<class T, class Op, class Expr, class Domain>
   inline static void evaluate(T &ret, const Op &op, const Expr &e,
     const Domain &domain, WrappedInt<1>)
@@ -181,9 +233,16 @@
     Expr localExpr(e);
     int e0 = domain[0].length();
 
-    T answer = ReductionTraits<Op, T>::identity();
-    for (int i0 = 0; i0 < e0; ++i0)
-      op(answer, localExpr.read(i0));
+    PartialReduction<T> reduction;
+#pragma omp parallel if (e0 > 512)
+    {
+      T answer = ReductionTraits<Op, T>::identity();
+#pragma omp for nowait
+      for (int i0 = 0; i0 < e0; ++i0)
+        op(answer, localExpr.read(i0));
+        reduction.storePartialResult(answer);
+    }
+    reduction.reduce(ret, op);
 
     ret = answer;
   }
@@ -199,12 +258,17 @@
     int e0 = domain[0].length();
     int e1 = domain[1].length();
 
-    T answer = ReductionTraits<Op, T>::identity();
-    for (int i1 = 0; i1 < e1; ++i1)
-      for (int i0 = 0; i0 < e0; ++i0)
-	op(answer, localExpr.read(i0, i1));
-
-    ret = answer;
+    PartialReduction<T> reduction;
+#pragma omp parallel
+    {
+      T answer = ReductionTraits<Op, T>::identity();
+#pragma omp for nowait
+      for (int i1 = 0; i1 < e1; ++i1)
+	for (int i0 = 0; i0 < e0; ++i0)
+	  op(answer, localExpr.read(i0, i1));
+      reduction.storePartialResult(answer);
+    }
+    reduction.reduce(ret, op);
   }
   
   template<class T, class Op, class Expr, class Domain>
@@ -220,13 +284,18 @@
     int e1 = domain[1].length();
     int e2 = domain[2].length();
     
-    T answer = ReductionTraits<Op, T>::identity();
-    for (int i2 = 0; i2 < e2; ++i2)
-      for (int i1 = 0; i1 < e1; ++i1)
-	for (int i0 = 0; i0 < e0; ++i0)
-	  op(answer, localExpr.read(i0, i1, i2));
-    
-    ret = answer;
+    PartialReduction<T> reduction;
+#pragma omp parallel
+    {
+      T answer = ReductionTraits<Op, T>::identity();
+#pragma omp for nowait
+      for (int i2 = 0; i2 < e2; ++i2)
+	for (int i1 = 0; i1 < e1; ++i1)
+	  for (int i0 = 0; i0 < e0; ++i0)
+	    op(answer, localExpr.read(i0, i1, i2));
+      reduction.storePartialResult(answer);
+    }
+    reduction.reduce(ret, op);
   }
 
   template<class T, class Op, class Expr, class Domain>
@@ -244,14 +313,19 @@
     int e2 = domain[2].length();
     int e3 = domain[3].length();
     
-    T answer = ReductionTraits<Op, T>::identity();
-    for (int i3 = 0; i3 < e3; ++i3)
-      for (int i2 = 0; i2 < e2; ++i2)
-        for (int i1 = 0; i1 < e1; ++i1)
-	  for (int i0 = 0; i0 < e0; ++i0)
-	    op(answer, localExpr.read(i0, i1, i2, i3));
-
-    ret = answer;
+    PartialReduction<T> reduction;
+#pragma omp parallel
+    {
+      T answer = ReductionTraits<Op, T>::identity();
+#pragma omp for nowait
+      for (int i3 = 0; i3 < e3; ++i3)
+	for (int i2 = 0; i2 < e2; ++i2)
+	  for (int i1 = 0; i1 < e1; ++i1)
+	    for (int i0 = 0; i0 < e0; ++i0)
+	      op(answer, localExpr.read(i0, i1, i2, i3));
+      reduction.storePartialResult(answer);
+    }
+    reduction.reduce(ret, op);
   }
 
   template<class T, class Op, class Expr, class Domain>
@@ -271,15 +345,20 @@
     int e3 = domain[3].length();
     int e4 = domain[4].length();
     
-    T answer = ReductionTraits<Op, T>::identity();
-    for (int i4 = 0; i4 < e4; ++i4)
-      for (int i3 = 0; i3 < e3; ++i3)
-        for (int i2 = 0; i2 < e2; ++i2)
-          for (int i1 = 0; i1 < e1; ++i1)
-	    for (int i0 = 0; i0 < e0; ++i0)
-	      op(answer, localExpr.read(i0, i1, i2, i3, i4));
-
-    ret = answer;
+    PartialReduction<T> reduction;
+#pragma omp parallel
+    {
+      T answer = ReductionTraits<Op, T>::identity();
+#pragma omp for nowait
+      for (int i4 = 0; i4 < e4; ++i4)
+	for (int i3 = 0; i3 < e3; ++i3)
+	  for (int i2 = 0; i2 < e2; ++i2)
+	    for (int i1 = 0; i1 < e1; ++i1)
+	      for (int i0 = 0; i0 < e0; ++i0)
+		op(answer, localExpr.read(i0, i1, i2, i3, i4));
+      reduction.storePartialResult(answer);
+    }
+    reduction.reduce(ret, op);
   }
 
   template<class T, class Op, class Expr, class Domain>
@@ -301,16 +380,21 @@
     int e4 = domain[4].length();
     int e5 = domain[5].length();
     
-    T answer = ReductionTraits<Op, T>::identity();
-    for (int i5 = 0; i5 < e5; ++i5)
-      for (int i4 = 0; i4 < e4; ++i4)
-        for (int i3 = 0; i3 < e3; ++i3)
-          for (int i2 = 0; i2 < e2; ++i2)
-            for (int i1 = 0; i1 < e1; ++i1)
-	      for (int i0 = 0; i0 < e0; ++i0)
-		op(answer, localExpr.read(i0, i1, i2, i3, i4, i5));
-
-    ret = answer;
+    PartialReduction<T> reduction;
+#pragma omp parallel
+    {
+      T answer = ReductionTraits<Op, T>::identity();
+#pragma omp for nowait
+      for (int i5 = 0; i5 < e5; ++i5)
+	for (int i4 = 0; i4 < e4; ++i4)
+	  for (int i3 = 0; i3 < e3; ++i3)
+	    for (int i2 = 0; i2 < e2; ++i2)
+	      for (int i1 = 0; i1 < e1; ++i1)
+		for (int i0 = 0; i0 < e0; ++i0)
+		  op(answer, localExpr.read(i0, i1, i2, i3, i4, i5));
+      reduction.storePartialResult(answer);
+    }
+    reduction.reduce(ret, op);
   }
 
   template<class T, class Op, class Expr, class Domain>
@@ -334,17 +418,22 @@
     int e5 = domain[5].length();
     int e6 = domain[6].length();
     
-    T answer = ReductionTraits<Op, T>::identity();
-    for (int i6 = 0; i6 < e6; ++i6)
-      for (int i5 = 0; i5 < e5; ++i5)
-        for (int i4 = 0; i4 < e4; ++i4)
-          for (int i3 = 0; i3 < e3; ++i3)
-            for (int i2 = 0; i2 < e2; ++i2)
-              for (int i1 = 0; i1 < e1; ++i1)
-		for (int i0 = 0; i0 < e0; ++i0)
-		  op(answer, localExpr.read(i0, i1, i2, i3, i4, i5, i6));
-
-    ret = answer;
+    PartialReduction<T> reduction;
+#pragma omp parallel
+    {
+      T answer = ReductionTraits<Op, T>::identity();
+#pragma omp for nowait
+      for (int i6 = 0; i6 < e6; ++i6)
+	for (int i5 = 0; i5 < e5; ++i5)
+	  for (int i4 = 0; i4 < e4; ++i4)
+	    for (int i3 = 0; i3 < e3; ++i3)
+	      for (int i2 = 0; i2 < e2; ++i2)
+		for (int i1 = 0; i1 < e1; ++i1)
+		  for (int i0 = 0; i0 < e0; ++i0)
+		    op(answer, localExpr.read(i0, i1, i2, i3, i4, i5, i6));
+      reduction.storePartialResult(answer);
+    }
+    reduction.reduce(ret, op);
   }
 };