- removed comment
CarpetReduce tests nonstaggered and staggered fail with development version of Carpet
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)
-
-
reporter - removed comment
Assuming the diagonal coordinates are the only things wrong, shall I regenerate the test output?
-
reporter - changed status to open
- assigned issue to
- removed comment
-
- removed comment
When you regenerate the output, can you also briefly compare the grid function values?
-
- changed status to open
- assigned issue to
- removed comment
-
- 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.
-
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.
-
- 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?
-
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!
-
- changed status to resolved
- removed comment
-
- edited description
- changed status to closed
- Log in to comment
The nans in the test cases are for the x coordinate (!) in the diagonal output. They are definitely not supposed to be there.