[Users] SphericalHarmonicRecon and SphericalHarmonicReconGen

[Erik Schnetter]

If this double problem occurs only on a particular machine, then this is
likely an MPI problem. If things are misconfigured, you are running two
identical serial computations instead of one parallel simulation. The
output will be correct, but it will be doubled, and the run will take twice
as long.

-erik

On Thu, Jul 13, 2017 at 10:27 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:

>
> On 13 Jul 2017, at 10:48, Miguel Zilhão <mzilhao at ffn.ub.es> wrote:
>
> hi Ian,
>
> NewsB_scri.L02Mm01.asc: substantial differences
>       significant differences on 1 (out of 2) lines
>       maximum absolute difference in column 1 is 963
>       maximum absolute difference in column 2 is 0.000185770963653907
>       maximum absolute difference in column 3 is 0.000142466608463344
>       maximum relative difference in column 1 is 1
>       maximum relative difference in column 2 is 1
>       maximum relative difference in column 3 is 1
>       ...
> The third, SphericalHarmonicReconGen.SpEC-h5-test, fails like this:
> NewsB_scri.L02Mm01.asc: substantial differences
>       significant differences on 1 (out of 2) lines
>       maximum absolute difference in column 1 is 963
>       maximum absolute difference in column 2 is 0.000185770963653907
>       maximum absolute difference in column 3 is 0.000142466608463344
>       maximum relative difference in column 1 is 1
>       maximum relative difference in column 2 is 1
>       maximum relative difference in column 3 is 1
>       ...
> I suspect the second and third failures have the same cause.  Do we have
> any idea why these tests fail?  They don't seem to fail on any other
> machines (http://einsteintoolkit.org/testsuite_results/index.php).
>
>
> i'm not sure whether it's related, but i've had a similar issue with a
> testsuite of a local thorn i have, which was passing just fine with 1 proc
> but not with 2 procs (and similar errors). the root of the problem turned
> out to be that on this particular machine, for whatever reason, when
> running the parfile with 2 procs the output was "doubled". as if each
> processor was writing the same thing on the same file. the output itself
> was the same, but the files that were written were obviously not. so diff
> was signalling differences in the files where in fact the numbers
> themselves were (nearly) the same. could you be seeing something like this
> as well?
>
>
> Hi,
>
> This is in general a problem; Cactus output is not guaranteed to be the
> same when you change the number of processes.  There are ways to work
> around this in specific cases, which are used for the tests.  Specifically,
> you can use the options
>
> CarpetIOASCII::compact_format = yes
> CarpetIOASCII::output_ghost_points = no
>
> and look at output only in the z direction.  If Carpet splits the grid in
> the z direction, then I think that for small numbers of processes at least,
> you are guaranteed that the output will be independent of the number of
> processes, as the processes will write in component order to the file, and
> the component ordering is the same as the z-ordering in this case.
>
> In your case, you are probably seeing duplicate points because some points
> (the ghost points) exist on more than one process, and each process outputs
> all the points it has.  Using output_ghost_points = no might help in that
> case.
>
> For SphericalHarmonicRecon, the tests use PUGH, not Carpet, and
> compact_format is not available.  I will have to check if this is a diffing
> issue, but I would be surprised, since it works on other machines on 2
> processes.
>
> --
> Ian Hinder
> http://members.aei.mpg.de/ianhin
>
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>


-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20170713/9673987d/attachment-0001.html