- removed comment
Uninitialised data in tests using PUGH
PUGH has a poisoning parameter which can initialise grid variables to NaN. The default is "none" which leaves grid variables uninitialised. If the default is changed to NaN, several tests fail, indicating that they are failing to initialise their data correctly. The tests which fail are:
tov_slowsector (from GRHydro)
TestComplex (from TestComplex)
gaussian (from WaveMoL)
The tests fail on both 1 and 2 processes.
All report differences related to NaNs apart from tov_slowsector. Possibly there is some NaN-filtering going on there. The test passes without PUGH poisoning. Tests were performed on Datura.
Keyword:
Comments (10)
-
-
- removed comment
The gaussian test from wavetoy with PUGH poisoning turned on fails due to the application of the radiative boundary condition to the initial data. The radiative boundary condition uses data from the previous timelevel (if available, which it is in this case) to set the boundary. As IDWaveMoL only initializes the current timelevel, the outer boundary gets filled with NaN's when PUGH poisoning is turned on.
The simple fix is to initialize the data on the previous timelevel to zero. This makes the test pass for me and seem to indicate that the compiler used to originally generate the test automatically initialized arrays to zero.
However, as the initial data is setup analytically at the boundary, I think the more correct way to fix this is to not apply the boundary conditions initially. This can be achieved by setting the MoL parameter set_ID_boundaries to no. In this case the test has to be regenerated as the starting point now is the correct initial data everywhere. Which of these options do people prefer?
-
- removed comment
I'd vote to regenerate the data so that the have a sensible test setup rather than keeping the inconsistent setup for backwards compatibility's sake.
-
- removed comment
Applying radiative boundary conditions to the initial conditions does not make sense, since they solve a time evolution equation (outside MoL, but nevertheless). Typically, one would apply e.g. a Robin boundary condition at t=0, and then evolve the boundaries in time via a radiative condition.
-
- removed comment
In this case it is not necessary to apply any boundary conditions at all, since the initial data is analytical and can be calculated everywhere.
Was that a vote for changing the parameter file and regenerate the data, Erik?
-
- removed comment
TestComplex was not setting data in the boundaries when evolving a complex grid function. A simple fix is to copy the past level forward before evolving the interior forward in time.
-
- changed milestone to ET_2014_11
- removed comment
Deferring this to a later time, as this is not critical enough to stall the release (this being the last open ticket). This does not mean that this should not be fixed of course (leaving 'major').
-
- removed comment
Peter identified the failure cause for gaussian to be incorrectly applied boundary conditions, Roland fixed TestComplex in rev 82 of TestComplex, Roland fixed slowsector in rev 222 of TOVSolver.
-
- removed comment
I have just committed the fix for gaussian.par in WaveMoL (revision 24).
-
- changed status to resolved
- removed comment
All three thorns are fixed now.
- Log in to comment
Fixing this for tov_slowsector opens a can of worms, in particular it reveal a bug in MoL's slow sector (
#1606) and makes the test fail everywhere (https://build.barrywardell.net/job/EinsteinToolkit/1217) (sorry Ian).