This SLEPc example uses PetscTime() to exit EPSSolve() after a given elapsed time. http://slepc.upv.es/documentation/current/src/eps/examples/tutorials/ex29.c.html Jose
> El 10 nov 2017, a las 5:09, Smith, Barry F. <[email protected]> escribió: > > > >> On Nov 7, 2017, at 6:47 AM, Gard Spreemann <[email protected]> wrote: >> >> On Tuesday 7 November 2017 07:35:36 CET Mark Adams wrote: >>> PETSc's signal handler is for segvs, etc. I don't know the details but I >>> don't think we care about external signals. >> >> I see. I'll sketch what I'm trying to achieve in case someone can >> think of another approach. >> >> I have some long-running SLEPc eigenvalue computations, and I'd like >> to have SLURM signal my program that its time limit is drawing >> near. In that case, my problem would set a flag and before the next >> iteration of the SLEPc eigenvalue solver it would give up and save the >> eigenvalues it has so far managed to obtain. >> >> The only workaround I can think of would be to let my program keep >> track of its time limit on its own and check it at each iteration. > > Hmm, I would be more inclined to go with a model that avoided signals. > Signals are best avoided, unless absolutely necessary, plus you need to have > some external script/program to send in the signal requiring added complexity > to your work flow. > > Why not have an input option of the time limit for the run and each > "iteration" or whatever (maybe in a post step function) check if you getting > close to the time-limit and then do what you need. If each "iteration" takes > a long time and you are afraid the program will end before it checks the next > time at the end of an iteration you could track record the time of each > iteration so your monitor routine knows how long a timestep takes and can > estimate if another timestep is possible within the current amount of time > you have available and if there is not enough time triggers the saving. > > Barry > > > >> >> There is no intention for PETSc to have handling of user-defined >> signals? >> >> >> Thanks. >> >> -- Gard >> >> >
