[pooma-dev] Problem with Field::makeOwnCopy() and Relations

[John H. Hall]

On Wednesday, May 21, 2003, at 01:41  PM, Richard Guenther wrote:

> Not only because you cannot take views of fields with >1
> subfields and calling field.physicalDomain() is "undefined" for fields
> with >1 subfield.
>

I remember the reason for the field.physicalDomain() being defined only 
at the innermost subFields (what would it mean at higher levels since 
it is different for each direction and centering?) But, I don't 
remember a restriction on taking views of edge-centered fields for 
example. We took views of these things all over the place. In fact our 
field object factory was in the unoptimized case up to the second view 
(third object) by the time we returned from its create function call. I 
think you will have to be more specific in what you mean here.

We even had multi-material fields with edge centering, so that they 
would have a layer of subFields for each material and another layer of 
subFields for each direction in the centering and we took views of 
those all the time.

Here is a routine from our object factory:

// =====================================================================
// This method now handles AllFace, AllEdge, and ReplicatedSubFields 
(MMFields)
// TecMesh::newField(const centering& Center, const int numFields)
// =====================================================================

template<class field>
field TecMesh::newField( const CenteringType& center, const int 
numFields, bool forceIt )
{
	typedef field::T_t T;
	typedef field::Layout_t Layout_t;
	enum { Dim = field::dimensions };

	Vector<Dim,Real> origin;
	LoadPoomaVector(origin,stdOrigin); //Copy STL vector (stdOrigin) into 
POOMA vector (origin)
	Vector<Dim,Real> spacings;
	LoadPoomaVector(spacings,stdSpacing);
	Ptr<Layout_t> pLayout = unwrap<Ptr<Layout_t> >(*getLayout());

          Centering<Dim> Center = canonicalCentering<Dim>(center, 
Continuous, AllDim);

	if(( numFields > 1 ) || (forceIt==true)) { // forceIt : e.g. A 
1-material MM_Field needs a subField
                                                                         
      //for compatibility with general multimaterial case
		field tField( numFields, Center,
			*pLayout, origin, spacings ); // Actually create field
                   ... // Initialize Boundary conditions, etc.
		return tField; // return view of field
	}
	else {
		field tField( Center, *pLayout, origin, spacings ); // Actually 
create field
                   ... // Initialize Boundary conditions, etc.
		return tField; // return view of field
	}
}

Notice, we are returning fields as views, not references to fields 
(which would be referring back to deleted views). And for a 
multi-material field with edge centering in 3-D with 10 materials there 
would be 30 subFields at the leaf object level.

We even violated the sanctity of the public interface for POOMA and set 
it up where a Multi-Material field was pointing to the engine for a 
single subField so that we could use the same data some times in a 
single material expression and other times in a multi-material 
expression (actually, a loop over materials to form expressions since 
the POOMA team didn't have time to write the MMField loop expressions)

So something like:
       for(int n=0;n<MM_IntEnergy.numMaterials();++n) {
           MM_IntEnergy.material(n)  = where( MM_Mass.material(n) > eps,
                                     Old.MM_IntEnergy.material(n) - 
(TmpWorkTerm * Dt)/MM_Mass.material(n),
                                     0.0 );
       }
should become:
           MM_IntEnergy  = where( MM_Mass > eps,
                                     Old.MM_IntEnergy - (TmpWorkTerm * 
Dt)/MM_Mass,
                                     0.0 );
This would mean that POOMA could move all of the RHS updating outside 
the loop so that no blocking would occur from material to material 
during the loop.

We could also refer to MM_IntEnergy.material(n) as simply IntEnergy for 
the nth material (we have a bag-type generic object collection known as 
the DataDirectory and the Material objects were derived from this 
hierarchical container and therefore each material could have a field 
known as "IntEnergy"). So that allowed expressions like IntEnergy*=0.5. 
If the single material model got called for each material, then the 
effect would be the same as MM_IntEnergy *= 0.5 which of course right 
now requires a loop over materials.

I am really curious what you mean here. Has something really 
significant changed?
John Hall