Sage stalls during computation
I was using SageMath 8.8's feedback_edge_set function on a large dataset. The calculation would take a couple of days to finish.
Unfortunately, Sage would keep stalling every few hours. The CPU usage of the process would simply drop to zero, and it would stop doing anything. I had to kill the process (a simple kill worked, no kill -9 necessary).
Has anyone else experienced this? Is it a known problem? Is there a workaround? It is very frustrating to have to keep manually killing and restarting the process. This problem also prevents me from running a calculation overnight: in the morning I might find that it stopped merely an hour after I started it (if I'm unlucky).
More information:
- I was using Sage on Linux
- This function uses MixedIntegerLinearProgram. I used the default GLPK (didn't change settings)
- I used
alarm()to set a time limit on each computation. - I always believed GLPK not to be interruptible, so I am not even sure which interruption (either manual or alarm) work on Sage with this function. This may be relevant.
- The memory usage of the process stayed low. It did not stall because the memory got filled and the machine started swapping.
Minimal example:
Put this in a source file:
import datetime
i=1
while True:
alarm(60)
try:
dg=digraphs.RandomDirectedGNM(300,750);
fes = dg.feedback_edge_set()
print(len(fes))
except AlarmInterrupt:
print("timeout")
cancel_alarm()
print(i)
print(str(datetime.datetime.now()))
print("\n")
i = i+1
Run it as sage sourcefile.sage.
In my last test, it took 291 iterations and ~4-5 hours before it stalled.
It appears to stall only when GLPK is used as the MIP solver (i.e. feedback_edge_set(solver='GLPK'), which is also the default). If I use solver='Coin' (which needs to be installed first using sage -i cbc) then it does not stall. However, the calculation is several times slower with Coin than with GLPK.
Could you please isolate the graph that causes the issue and see if it is reproducible when the method is applied on that graph ?
You can provide a short string representation of your graph with:
@tmonteil It's not because of a specific graph. The stalling appears to be random. I know this because I normally run this on a set of pre-computed graphs, so I could easily re-try on the graph where it stalled. Also, running it twice on the same data won't stall at the same step.
aha, i was trying to idendify the culprit graphs.