#465: Hydro_InitExcision test cases take a long time ------------------------------------+--------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------

Comment (by rhaas):

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.

#465: Hydro_InitExcision test cases take a long time ------------------------------------+--------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------

Comment (by rhaas):

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

#465: Hydro_InitExcision test cases take a long time ------------------------------------+--------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------

Comment (by rhaas):

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.

#465: Hydro_InitExcision test cases take a long time ------------------------------------+--------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: review Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by rhaas):

* status: new => review

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?

#465: Hydro_InitExcision test cases take a long time ------------------------------------+--------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: reviewed_ok Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+---------------------------------------

Comment (by rhaas):

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.