Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CBC solution status "Stopped on Time Limit" when it didn't actually reach the time limit #605

Open
ebongo1 opened this issue Jun 14, 2023 · 7 comments

Comments

@ebongo1
Copy link

ebongo1 commented Jun 14, 2023

I set the solver time limit to 1200 seconds, but the solver is producing a "Stopped at Time Limit" status, but the solve time is only 739.64 seconds. See attached log for additional context.
feasible_solution.log

solver - Copy.txt

Some of my other teammates are seeing the solver time out at about 600 seconds with no solution found (even though the time limit is 1200).

So it seems like the time limit isn't actually being reached but the solver is still saying it's stopping on time limit...

@ebongo1
Copy link
Author

ebongo1 commented Jun 14, 2023

Is CBC still using CPU time instead of wall clock time? I know Pulp updated the time limit to default to wall clock time, but the code snippet below makes me think that it's not updated in CBC.
image

@tkralphs
Copy link
Member

There is a parameter timeMode that can be set and you are correct that this has default of cpu. One could argue whether this is the most natural default, but you can over-ride it.

Welcome to the CBC MILP Solver
Version: 2.10
Build Date: Jun  1 2023

CoinSolver takes input from arguments ( - switches to stdin)
Enter ? for list of commands or help
Coin:timeMode
timeMode has value cpu

With regard to the code snippet above. if I'm not mistaken, this is about a time limit for a subprocess, not the overall solution process. Whenever the code decides whether to halt the solution process altogether, it should check whether to use elapsed or cpu time.

@ebongo1
Copy link
Author

ebongo1 commented Jun 14, 2023

I double checked, and the log I attached above says that "Option for timeMode changed from cpu to elapsed", so it should be using elapsed wall clock time. So it should still be running to the full 1200 seconds and not stopping at 739.64.

Thank you for clarifying the code snippet I sent above.

@tkralphs
Copy link
Member

Ah, OK, I didn't check the log, since I assumed the issue must be that you didn't set the parameter (otherwise, the default is irrelevant). This could be a bug then. It looks like you are using the master branch. Could you try the latest release and see if you observe the same behavior?

@ebongo1
Copy link
Author

ebongo1 commented Jun 14, 2023

I am using PuLP 2.7.0, and when I tried updating it, it said I had the latest version. Is there something else I should update instead?

@tkralphs
Copy link
Member

Oops, sorry, I assumed you were using Cbc directly. I now see from the output that you are actually using 2.10.3, though the source code you were pointing to is that of master. You could try updating to the latest release of Cbc. It's possible a bug has been fixed since 2.10.3, which is pretty old now. There are many ways of getting the latest release, depending on your platform. You can check the README for details. PuLP allows you to point to a different installed version.

But in any case, this is not a case of elapsed versus wallclock, since I now see also that the reported elapsed and wallclock are the same (which means you are using the sequential version). It's possible that the reported wallclock is incorrect. I remember that at some point, the wallclock being used for termination was not quite the same as the wallclock that was reported. It looks like you have a very large instance for which the preprocessing time maybe substantial (the time reported after processing the root is already ~500 s). It's possible that some significant part of the running time isn't being included in what's reported. Did you try measuring the running time externally to see what it really is?

@ebongo1
Copy link
Author

ebongo1 commented Nov 7, 2023

Ok that is good to know that PuLP can point to a different version of Cbc - we can try doing that to see if that helps.

I believe we are wrapping the program in our own timer and are still seeing the total time be less than the time limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants