Thorns providing interpolator routines should provide testcases for them

Create issue
Issue #395 new
Frank Löffler created an issue

Errors in the interpolator often show up in the output of other thorns, depending on those interpolating routines. Figuring out that this is caused by problem while interpolating can take quite a bit of time, which could be saved if the interpolating thorns would include testsuites themselves.

Keyword:

Comments (7)

  1. Frank Löffler reporter
    • removed comment

    Right, InterpToArray contains one testsuite. The "problem" with the testsuites in CarpetInterp is that they use thorns outside of the ET (wavetoy). It would be nice to have testsuites working within the ET, which would require to either include those wavetoy thorns, or to add testsuites using e.g. analytically setup data (carefully not suggesting Exact).

  2. Roland Haas
    • removed comment

    As long as we interpolate only the metric Exact would be fine, wouldn't it? The metric itself does not require interpolation (we do not want an evolution for the interpolator tests, do we?) We could also use say the gauge wave initial data thorns. Anything that uses some analytic expression to fill in a grid function with non-constant data would seem fine to me.

  3. Erik Schnetter
    • removed comment

    We have many other initial data thorns in addition to Exact.

    I think WaveToy is small, we could just add it.

  4. Ian Hinder
    • removed comment

    Interpolation within Carpet (i.e. for prolongation, which is separate from that provided by AEILocalInterp) is tested using a polynomial for which interpolation of the correct order (at least for some interpolators) is exact. This means that the correct solution is trivial and it's obvious if the test is correct or not. I propose some sort of initial data thorn for setting polynomial initial data which could be used by the testsuites for the interpolator. This would be part of Cactus, as it is sufficiently generic and useful for testing interpolator thorns. I don't think we should use an Einstein-based initial data thorn for testing the interpolators. This belongs in Cactus, not the ET.

  5. Erik Schnetter
    • removed comment

    Such a generic routine is part of thorn CarpetExtra/CarpetProlongateTest in the Mercurial version of Carpet.

  6. Ian Hinder
    • removed milestone
    • removed comment

    There is no time to implement additional test cases for interpolators before the release - removing milestone.

  7. Log in to comment