Eloisa<div><br></div><div>Thanks for digging into this.</div><div><br></div><div>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.</div>
<div><br></div><div>-erik<br><br><div class="gmail_quote">On Thu, Dec 15, 2011 at 9:39 AM, Eloisa Bentivegna <span dir="ltr"><<a href="mailto:bentivegna@cct.lsu.edu">bentivegna@cct.lsu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Dec 15, 2011, at 5:58 AM, Hal Finkel wrote:<br>
<br>
> On Wed, 2011-12-14 at 19:48 -0500, Erik Schnetter wrote:<br>
>> On Wed, Dec 14, 2011 at 6:53 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
>> On Wed, 2011-12-14 at 18:27 -0500, Erik Schnetter wrote:<br>
>>> You are not setting any values on the boundary. Is that<br>
>> intentional?<br>
>><br>
>><br>
>> Currently, this is because I am using neighboring values in<br>
>> the<br>
>> calculation, so I can't do that on the boundary. Should I do<br>
>> that some<br>
>> other way?<br>
>><br>
>><br>
>> Setting the boundary to zero should be good enough. (The boundary<br>
>> values should not be used -- but I don't recall whether this is the<br>
>> case.)<br>
><br>
> Maybe this is another problem with the periodic boundary conditions?<br>
> The problem seems to appear in other fields too. I've attached some<br>
> images from my test problem. One shows the field configuration (this one<br>
> looks like a ring -- it is a slice through a bubble). The second one<br>
> shows the T_00 computed from that. As you can see, the values near the<br>
> extremal indicies are wrong. At the next (half) time step, looking at<br>
> the field data from level 1, the same phenomonon can be seen in the<br>
> level 1 boxes.<br>
><br>
> These were all done in Kranc, so I did not do any real coding myself ;)<br>
><br>
> What do you think?<br>
<br>
</div>Hi all!<br>
<br>
I believe that what Hal is doing with the allocation of level_mask is correct; what seems to be problematic is setting its value.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thanks,<br>
Eloisa</blockquote></div><br><br clear="all"><div><br></div>-- <br>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>> <a href="http://www.cct.lsu.edu/~eschnett/" target="_blank">http://www.cct.lsu.edu/~eschnett/</a><br>
<br>
</div>