1. Einstein Toolkit Avatar Einstein Toolkit
  2. Einstein Toolkit
  3. tickets
  4. Issues

Uninitialised data in tests using PUGH

Issue #1604 closed
Ian Hinder created an issue

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 (11)

  2. Peter Diener
    • 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?

  3. Roland Haas
    • 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.

  4. Erik Schnetter
    • 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.

  5. Peter Diener
    • 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?

  6. Roland Haas
    • 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.

  7. Frank Löffler

    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').

  8. Roland Haas
    • 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.

  12. Log in to comment
Assignee
–
Type
bug
Priority
minor
Status
closed
Component
EinsteinToolkit thorn
Milestone
ET_2014_11
Version
development version
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!