[Einstein Toolkit] #494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- 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?
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by eschnett):
The nans in the test cases are for the x coordinate (!) in the diagonal output. They are definitely not supposed to be there.
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by hinder):
Assuming the diagonal coordinates are the only things wrong, shall I regenerate the test output?
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: hinder Type: defect | Status: accepted Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by hinder):
* owner: eschnett => hinder * status: new => accepted
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: hinder Type: defect | Status: accepted Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by eschnett):
When you regenerate the output, can you also briefly compare the grid function values?
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: tbode Type: defect | Status: assigned Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by tbode):
* owner: hinder => tbode * status: accepted => assigned
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: tbode Type: defect | Status: assigned Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by tbode):
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.
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: tbode Type: defect | Status: assigned Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by hinder):
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.
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: tbode Type: defect | Status: assigned Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by tbode):
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?
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: tbode Type: defect | Status: assigned Priority: major | Milestone: Component: Carpet | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by hinder):
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!
#494: CarpetReduce tests nonstaggered and staggered fail with development version of Carpet ---------------------+------------------------------------------------------ Reporter: hinder | Owner: tbode Type: defect | Status: closed Priority: major | Milestone: Component: Carpet | Version: Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by tbode):
* status: assigned => closed * resolution: => fixed
trac@lists.einsteintoolkit.org
-
Einstein Toolkit