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

[Richard Guenther]

On Wed, 21 May 2003, John H. Hall wrote:

> 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.

Well, it didnt compile, so I doubt this. But anyway - its getting better
everytime I spend a few hours hunting for another bug...

> 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.

Uh, while I dont use dependend Field feature (yet), I cannot see how
the centering can make a difference here.

> 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).

Yes, but program (or better, expression) flow would be very hard to follow
then. So from a maintainance point of view I doubt this would be useful.
I see it can be useful for sort of CSE, where you set up a dependent field
for the expression.

As you are (were?) a POOMA user, did you have tricks to overcome the
overly simplistic handing of the inner guards and their exchange? I.e.
the fact that only a simple flag is kept for the state of the internal
guards, so you cannot optimize f.i. directional splitted CFD and instead
do tree times the communication you need to?

Btw. - what is/was the application you were using POOMA on? Is it
available somewhere, so people can learn from it?

Thanks,

Richard.