I tested further, using Carpet instead of PUGH. I believe that the problem is in the single processor case of PUGHInterp, i.e. that the 2 process results are actually correct. Carpet gives identical answers for 1 and 2 processes.<div>
<br></div><div>-erik<br><br><div class="gmail_quote">On Mon, Nov 8, 2010 at 8:03 AM, Peter Diener <span dir="ltr"><<a href="mailto:diener@cct.lsu.edu">diener@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;">
Hi,<br>
<div class="im"><br>
> 1) Testsuites<br>
> A lot has been done over the course of last week, and I would like to<br>
> thank all involved people. A few issues remain however:<br>
> 1a) Most AHFinderDirect testsuites fail on 2 processes. This is not<br>
> new. This has been the same for last release. However, in contrast<br>
> to some other thorns, AHFinderDirect is used by almost every<br>
> group, in production simulations. We should really figure out what<br>
> goes wrong here. Even more severe: preliminary tests suggest that<br>
> this could be connected to the interpolator, which would make<br>
> matters only worse if it turns out to be true.<br>
<br>
</div>I took a bit closer look at this trying to figure out if the problem is<br>
with the interpolator or not. Defining in gr/expansion.cc:<br>
<br>
#define GEOMETRY_INTERP_DEBUG2<br>
<br>
and changing the output formatting from using %g to %15.11g to get more<br>
digits in the debug output it was clear that there was differences in the<br>
interpolation results (of the order 1e-5) when running the test parameter<br>
file Kerr-definition-expansion.par on 1 or 2 processors, even though the<br>
interpolation points were identical.<br>
<br>
That parameter file uses the interpolation parameters:<br>
<br>
AHFinderDirect::geometry_interpolator_name = "Lagrange polynomial interpolation"<br>
AHFinderDirect::geometry_interpolator_pars = "order=4"<br>
<br>
I see the same when using:<br>
<br>
AHFinderDirect::geometry_interpolator_name = "Lagrange polynomial interpolation"<br>
AHFinderDirect::geometry_interpolator_pars = "order=2"<br>
<br>
while the following combinations all give identical bh masses on 1 or 2<br>
processors:<br>
<br>
AHFinderDirect::geometry_interpolator_name = "Lagrange polynomial interpolation"<br>
AHFinderDirect::geometry_interpolator_pars = "order=3"<br>
<br>
AHFinderDirect::geometry_interpolator_name = "Hermite polynomial interpolation"<br>
AHFinderDirect::geometry_interpolator_pars = "order=2"<br>
<br>
AHFinderDirect::geometry_interpolator_name = "Hermite polynomial interpolation"<br>
AHFinderDirect::geometry_interpolator_pars = "order=3"<br>
<br>
In those cases the largest differences between 1 and 2 processor runs seem<br>
to be of order 1e-13.<br>
<br>
So it seems there is a bug in AEILocalInterp in the 4th and 2nd order<br>
Lagrange interpolation schemes, while the 3rd order Lagrange interpolation<br>
and 2nd and 3rd order Hermite interpolation schemes are okay.<br>
<br>
Does anybody feel up to looking into this?<br>
<br>
Cheers,<br>
<br>
Peter<br>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>> <a href="http://www.cct.lsu.edu/~eschnett/">http://www.cct.lsu.edu/~eschnett/</a><br>
<br>
</div>