[Users] Problem with CarpetRegrid2/AMR

[Erik Schnetter]

Hal

You should be able to apply boundary conditions (i.e. synchronised, apply
symmetry conditions) in your code. You will also need to use sufficiently
many processes to ensure that periodicity is applied correctly; this
circumvents the bug/missing feature in the Periodic boundary conditions.

-erik

On Thu, Dec 15, 2011 at 3:14 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> On Thu, 2011-12-15 at 11:17 -0500, Erik Schnetter wrote:
> > Eloisa
> >
> >
> > Thanks for digging into this.
> >
> >
> > I didn't think of syncing, but yes, syncing would be necessary, and so
> > would be setting all boundaries. In your case, this would be applying
> > periodic boundary conditions only (and not setting anything to zero
> > since you don't have an outer boundary). Of course, you need to use
> > sufficiently many processes for this because of the bug in thorn
> > Periodic.
>
> Erik, Eloisa, et al.,
>
> Thank you very much for looking at this. Just so that I'm clear, is
> there a way that I can get this to work now, or am I waiting on another
> bug fix?
>
>  -Hal
>
> >
> >
> > -erik
> >
> > On Thu, Dec 15, 2011 at 9:39 AM, Eloisa Bentivegna
> > <bentivegna at cct.lsu.edu> wrote:
> >         On Dec 15, 2011, at 5:58 AM, Hal Finkel wrote:
> >
> >         > On Wed, 2011-12-14 at 19:48 -0500, Erik Schnetter wrote:
> >         >> On Wed, Dec 14, 2011 at 6:53 PM, Hal Finkel
> >         <hfinkel at anl.gov> wrote:
> >         >>        On Wed, 2011-12-14 at 18:27 -0500, Erik Schnetter
> >         wrote:
> >         >>> You are not setting any values on the boundary. Is that
> >         >>        intentional?
> >         >>
> >         >>
> >         >>        Currently, this is because I am using neighboring
> >         values in
> >         >>        the
> >         >>        calculation, so I can't do that on the boundary.
> >         Should I do
> >         >>        that some
> >         >>        other way?
> >         >>
> >         >>
> >         >> Setting the boundary to zero should be good enough. (The
> >         boundary
> >         >> values should not be used -- but I don't recall whether
> >         this is the
> >         >> case.)
> >         >
> >         > Maybe this is another problem with the periodic boundary
> >         conditions?
> >         > The problem seems to appear in other fields too. I've
> >         attached some
> >         > images from my test problem. One shows the field
> >         configuration (this one
> >         > looks like a ring -- it is a slice through  a bubble). The
> >         second one
> >         > shows the T_00 computed from that. As you can see, the
> >         values near the
> >         > extremal indicies are wrong. At the next (half) time step,
> >         looking at
> >         > the field data from level 1, the same phenomonon can be seen
> >         in the
> >         > level 1 boxes.
> >         >
> >         > These were all done in Kranc, so I did not do any real
> >         coding myself ;)
> >         >
> >         > What do you think?
> >
> >
> >         Hi all!
> >
> >         I believe that what Hal is doing with the allocation of
> >         level_mask is correct; what seems to be problematic is setting
> >         its value.
> >
> >         The problem is that this function cannot be calculated
> >         pointwise, and the way it's currently set leaves some parts of
> >         the grid uninitialized, which then leads to poison and
> >         ultimately to all sorts of weird behavior including nans at
> >         the boundaries, lack of regridding when expected, and so on. I
> >         wouldn't pay too much attention to all these symptoms
> >         (although it would be nice of course for the AMR logic to
> >         detect that the mask is nan and issue an error message). The
> >         origin is in the incomplete initialization of the mask.
> >
> >         To convince myself of this, I switched poisoning off, and
> >         observed no odd behavior. I then switched it back on and ran a
> >         number of grid configurations where the mask was set pointwise
> >         (say, to coincide with one of the evolution variables), and
> >         again I had no trouble. As for the actual mask (based on the
> >         derivative of a grid function), I played a long time with
> >         scheduling the filling of interior points and boundaries, but
> >         always observed the issue that Hal is reporting. Ideally, I'd
> >         think that filling the interior, syncing, and finally applying
> >         outer/symmetry boundary conditions would work, but that
> >         doesn't seem to be the case.
> >
> >         Erik: when you suggest to set the boundary explicitly, do you
> >         mean the outer boundary? Since in this case we only have a
> >         symmetry boundary (periodic), do you mean we should populate
> >         that part of the grid independently of the symmetry thorn?
> >
> >         Thanks,
> >         Eloisa
> >
> >
> >
> >
> > --
> > Erik Schnetter <schnetter at cct.lsu.edu>
> > http://www.cct.lsu.edu/~eschnett/
> >
> >
>
> --
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
>
>


-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20111215/6be85efe/attachment.html