> 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 > >
