CarpetReduce tests nonstaggered and staggered fail with development version of Carpet

Issue #494 closed
Ian Hinder created an issue

The CarpetReduce tests nonstaggered and staggered fail with the development version of Carpet and pass with the stable version. The failure is reported as:

weight.d.asc: substantial differences did not reproduce 3 NaNs from old weight.d.asc significant differences on 3 (out of 9) lines

Were the NaNs wrong before, and somehow got into the test output incorrectly? Or are the NaNs supposed to be there?

Keyword:

Comments (11)

  1. Erik Schnetter
    • removed comment

    The nans in the test cases are for the x coordinate (!) in the diagonal output. They are definitely not supposed to be there.

  2. Ian Hinder reporter
    • removed comment

    Assuming the diagonal coordinates are the only things wrong, shall I regenerate the test output?

  3. Erik Schnetter
    • removed comment

    When you regenerate the output, can you also briefly compare the grid function values?

  4. Tanja Bode
    • removed comment

    Regenerating the data without nans is simple enough. The test also fails due to inconsistent grids for 2-processor tests. I'm looking into modifying the grid to work as a 2-processor test as well.

  5. Ian Hinder reporter
    • removed comment

    Was every other point apart from the NaN the same as before? Is it possible to run the test with both 1 and 2 processes? I thought that anything that output gridfunctions could only be run on the same number of processes. This is why we run both 1 and 2 process tests.

  6. Tanja Bode
    • removed comment

    Yes, every other point (apart from the NaN) was the same as before. And I realized you can't have both 1 and 2-processor tests on the same data with gridfunctions due to component-wise output -- need more coffee. It would seem logical to add a 2-processor testsuite that just looks at the reduced values, or would that be superfluous since any failure in that function would cause simultaneous failure in many other testsuites?

  7. Ian Hinder reporter
    • removed comment

    Testing reduction is probably something that wants to test inter-process communication, but we don't want a proliferation of too much test data. I wonder why there is gridfunction output in a reduction test anyway? Probably so that you can see when the test fails if it was due to the underlying grid functions or the reduction itself.

    I would convert the test to use two processes and remove the one-process test (after the release).

    By the way, I think that this is the last pair of test failures on Datura - when this is fixed we will have zero failures!

  8. Log in to comment