freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Freepooma-devel] [PATCH] Canonicalize handling ofexternal/internal


From: Richard Guenther
Subject: RE: [Freepooma-devel] [PATCH] Canonicalize handling ofexternal/internal guards
Date: Tue, 12 Apr 2005 11:20:48 +0200 (CEST)

On Mon, 11 Apr 2005, Julian C. Cummings wrote:

> Hi,
>
> Sorry for coming late to this discussion.  I don't really participate in the
> POOMA developments anymore, but thought I should pipe up regarding this
> issue of particle gather/scatter methods and guard layers.  I just wanted to
> point out that the behavior of eliminating internal guard layers when there
> is only one Field patch is correct.  The internal guard layers are meant
> only to provide consistency across processor (or virtual node) boundaries.
> If there will be no such boundaries (i.e., only one Field patch), then there
> is no need for any internal guard layers.  The code there was probably added
> to prevent any "naïve user" behavior. ;-)  However, there are also external
> guard layers intended to enforce physical domain boundary conditions.  The
> user remains free to add these and select their BCs.  The coding error, IMO,
> was with the InterpolatorCIC requiring that the number of *internal* guard
> layers be greater than zero.  This logic should have been modified to allow
> for the case where the number of internal guard layers is zero, but there is
> only one Field patch and it has an external guard layer.  This is sort of a
> corner case for POOMA, which is normally dealing with parallel computations
> on decomposed Fields; nevertheless, it should be allowed by the
> Interpolators that require a guard layer.

Ok, this was my final conclusion, too.  I changed the Particle
interpolators to look at internal (if available) _and_ external guards
to verify that the stencil will fit.  I also modified some of
UniformGridLayout and GridLayout to enforce the above optimization, as
it was not applied consistently.

The initial question was, if the user specifies one internal guard layer,
but only one patch ends up being used, is it "correct" for the layouts
internalGuards() method to return that there are _no_ internal guard
layers (apart from the issue, that, of course, there will never be
internal guard layers in a one-patch setup).  It sort of violates the
principle of least surprise - likewise, if the grid domain is empty, we
do not honour requests for external guards (though that may be to avoid
corner cases).  I choose to not change this behavior in the end.

Richard.

>  I hope these comments make sense
> to you.  I did not examine the patch you proposed, but from your description
> it sounded like you were removing the optimization of deleting unneeded
> internal guard layers.  That's not a good idea, IMO.  Maybe I have
> misunderstood your comments in this e-mail exchange.  I don't have the time
> to follow the POOMA developments very closely these days, so take my
> comments in that context.
>
> Regards, Julian C.
>
> Dr. Julian C. Cummings
> Staff Scientist, CACR/Caltech
> (626) 395-2543
> address@hidden

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]