[pooma-dev] Problem with Field::makeOwnCopy() and Relations tests=USER_AGENT_PINE,X_AUTH_WARNING version=2.54

[John H. Hall]

Richard:
I think I ran into this one. There is an inconsistency between the 
general field interface and the subField interface regarding relations. 
The relations only exist at the lowest subField layer. This becomes 
complex when you begin talking about "multi-material fields" with 
complex centerings. I would like to have it so that if you have a 
relation that involves all the subFields, it would exist at the level 
above the lowest layer of subFields that it depends upon. Right now we 
build some complex relations that have to be called for each centering 
or material, but, they could be called only once as a driver and walk 
through all the subFields themselves. Part of this is my fault, during 
the rewrite to add multi-material fields and the relations concepts we 
were in a hurry and I agreed to have the relations and expressions only 
make sense at the lowest subField level as a practical concession.

The reason you are having so many problems in this one area is that we 
decided to stop using makeOwnCopy and instead came up with some other 
workarounds at the application level (I was on a team of users, not 
developers of POOMA). So we never relied on makeOwnCopy and therefore 
it never got debugged in parallel, it seemed to work fine in serial.

Has anyone explained why we changed the name from Boundary Conditions 
to relations. POOMA has within it a rudimentary implementation of the 
concept of Independent and Dependent fields. Unfortunately, the 
built-in set of relation routines has a defect that doesn't allow a 
Dependent field to be dependent on another field with a different 
centering. We fixed this dilemma in our integration layer with POOMA, 
so the fix never became a part of POOMA itself. Anyhow, when relations 
are working properly, you can extend the concept of automatic updating 
of the Boundary Conditions to include automatic updating of fields that 
are dependent upon other fields. So when an Independent Field (no 
dependencies on other fields) gets changed, it not only marks its own 
Boundaries as dirty, but, it also calls a tree which marks all of its 
dependent fields as dirty also. Therefore, when a dependent field is on 
the RHS of an equation, it triggers a set of relations that result in 
its being current. This is done using deferred evaluation, so it only 
happens if the dependent field is used. Another name for these 
dependent fields would be a cached evaluation. Once the evaluation has 
been triggered, the field is marked as clean and in all further uses it 
acts as a normal field. If you know the calculation will only be done 
once, or that it is extremely cheap to perform, you should probably use 
a calculational engine that doesn't cache the result.

Another feature which we didn't have time to play with, is that when a 
dependent field is marked as dirty, you may as well set it to zero and 
free its data. Since establishing the relation tree is much more 
onerous than managing data, we got to the point where we almost never 
got rid of a field, we just set it to zero (manually instead of 
automatically) and poof its memory was essentially gone.

If you tried hard enough, you should be able to write a code in which 
no field calculations (besides setting up the independent fields) occur 
until a final print statement. At that point all of the relations would 
trigger and all of the work would be done (deferred evaluation).

John Hall


On Wednesday, May 21, 2003, at 09:12  AM, Richard Guenther wrote:

> On Wed, 21 May 2003, Richard Guenther wrote:
>
>> Hi!
>>
>> We have a problem with Field::makeOwnCopy() and Relations in case of
>> a Field with multiple subfields. Consider
>>
>>   Field_t f(canonicalCentering(FaceType, Continuous), ...);
>>   Pooma::addAllConstantFaceBC(f, 0.0);
>>   Field_t g(f);
>>   g.makeOwnCopy();
>>
>> now in FieldEngine::makeOwnCopy() we get passed g as target s and do
>>
>>    ...
>>       data(m, c).relations().makeOwnCopy(s);
>>    ...
>>
>> i.e. we retarget all the subfields relation to the base field g which
>> the relation later chokes on with an assert.
>>
>> I'll try to pass s.subField(m, c) here, but I dont think this will 
>> work
>> - will it?
>
> It seems it does. Tested with Fields, Ok?
>
> Richard.
>
> ===== FieldEngine.h 1.4 vs edited =====
> --- 1.4/r2/src/Field/FieldEngine/FieldEngine.h	Thu Jan 30 12:11:07 2003
> +++ edited/FieldEngine.h	Wed May 21 17:04:26 2003
> @@ -606,7 +606,7 @@
>        {
>          data(m, c) = model[m*stride_m + c];
>          data(m, c).engine().makeOwnCopy();
> -        data(m, c).relations().makeOwnCopy(s);
> +        data(m, c).relations().makeOwnCopy(s.subField(m, c));
>        }
>      }
>    }