- removed comment
Hydro_InitExcision test cases take a long time
Issue #465
closed
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)
-
-
- 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?
-
- 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.)?
-
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.
-
- 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.
-
- marked as enhancement
- marked as
- removed comment
-
- 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?
-
reporter
- changed status to open
- removed comment
Okay to apply.
I recommend using a switch statement instead of an if-cascade.
-
- 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.
-
- changed status to resolved
- removed comment
-
- edited description
- changed status to closed
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- closed
- Component
- EinsteinToolkit thorn
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 0
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.