Hydro_InitExcision test cases take a long time

Create issue
Issue #465 closed
Erik Schnetter created an issue

I am just running all test cases with an executable without optimisation, and I find that Hydro_InitExcision takes a long time. While most other test cases finish in a few minutes, Hydro_InitExcision takes two hours to run. The test cases should be reduced in number, size, or duration.

Keyword:

Comments (11)

  1. Roland Haas
    • removed comment

    Are there any objections to me reducing their it_last parameter to 1/10 of what it currently is (after testing that the currently pass)? It should still test for regression (though maybe not for correctness) even when doing only 6 instead of 60 timesteps.

    I find myself spending a large fraction of the time for the testsuites in these tests.

  2. Frank Löffler
    • removed comment

    Yes, because that would render the testsuite useless. These tests evolve a shock passing into an excision boundary. Reducing the number of iterations so much would mean not to evolve until that point in time, essentially not testing the excision boundaries as a result.

    A more effective way of reducing the runtime would be to reduce the number of evolved points. Can you try that instead?

  3. Roland Haas
    • removed comment

    Sure. The reason we need the shock to pass into the excised region is to trigger some if statements inside of GRHydro so that we actually cover the code we want to test? The lines of code to check for are in the modified PPM scheme (trying to make sure not to remove the interesting code pieces from the test)? I'll throw in a couple of write(*,*) to check that we cover the same branches (or more) of the if statements before and after the change. Would that be sufficient? Would it be possible to star the shock so that it already overlaps the excised region (also: most of the slowness was due to user error on my part, mainly running with 2-processes 4-threads-each on a quad core machine. Not sure about unoptimized builds.)?

  4. Erik Schnetter reporter
    • removed comment

    Each test case should finish in well under two minutes. We probably also want longer-running correctness tests, but the regression tests need to be quick so they are painless. The regression tests do not need to be physically meaningful, so that inconsistent initial conditions or very coarse resolutions are fine.

  5. Roland Haas
    • removed comment

    They currently seem to do so (at least on my machine) when called in the typical way (ie. optimized and with no more total threads than ones has cores). In that case the difference between Cactus' "Run date" output and the timestamp of the logfile is below 2min for each of them (the whole set finished in 6min). As said, most of the slowness was due to user error.

  6. Roland Haas
    • changed status to open
    • removed comment

    the attached patch replaces a number of CCTK_Equal calls in the innermost loop by comparison to integers. Passes all tests, though it is not much faster than before. Note that HydroBase_InitExcision has a paremeter to run it in poststep in which case the strcmp will become important (same as the strcmp inside of Tmunu were for the include mechanism).

    Ok to apply?

  7. Erik Schnetter reporter
    • changed status to open
    • removed comment

    Okay to apply.

    I recommend using a switch statement instead of an if-cascade.

  8. Roland Haas
    • removed comment

    Applied as rev 125 of Hydro_InitExcision. I left the if-cascade in, since replacing it would have involved a nested switch statement which I found even harder to read. Indentation is not quite correct to simply add a switch either and I would rather not have a very large commit that has a real change an pure whitespace changes mixed together.

  9. Log in to comment