Specify Wall-Time instead of number of iterations about ls1-mardyn HOT 4 CLOSED

maybe it would be cleanest and easiest to implement, if the wall time refers precisely and only to the time spent inside the primary for-loop in Simulation::simulate. I.e. mardyn initialization and mardyn finalization (with checkpoint writing) are not included.
Otherwise it gets a bit messy that the mardyn initialization is included, but the "easy" way to write the final checkpoint -- the code after the primary for-loop in Simulation::simulate -- is not included.

from ls1-mardyn.

I think that when your job runs out of wall-time, the scheduler sends some system signal to the process of the program, before sending the signal to kill it.

If this were true for LoadLeveler or SLURM I would not count on it to be defined everywhere. So a timer in mardyn will be way safer.

maybe it would be cleanest and easiest to implement, if the wall time refers precisely and only to the time spent inside the primary for-loop

Would it? Depends on what you actually want to achive. If it s to simplify wall clock time for the job scripts then I would disagree, because then you roughly know the time spent in the main loop but still have to estimate the time before and after the loop which can be significant.

So in my opinion the cleanest solution would be to track wall-time from the start of the process. After each iteration the remaining time can be calculated. If this time t_remain is smaller than a given threshold a checkpoint file can be written if specified. However, there must be enough time left for this. Optimally we find a good way to estimate this.

from ls1-mardyn.

I think that if we say that the mardyn time is the time spent inside the main loop, it is an easy and relatively clean solution. Maybe "wall-time" is no longer accurate, but it is a "clean" substitution of the number of iterations - the number of iterations also says something only about the time spent in the main for loop and not the entire runtime, so currently you also have to estimate time outside the for-loop anyway.

Also, it will be straightforward to program - only the main for-loop turns into a while-loop with either a condition on the number of iterations or a condition on whether the time has been reached.

Estimating thresholds etc. requires more effort and may require more corner cases to be considered.

from ls1-mardyn.

Added via PR #53

from ls1-mardyn.