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

Don't pass -stat=1 option to CBC to avoid slowdown #3191

Open
AlexeyNikonorov opened this issue Mar 12, 2024 · 1 comment
Open

Don't pass -stat=1 option to CBC to avoid slowdown #3191

AlexeyNikonorov opened this issue Mar 12, 2024 · 1 comment

Comments

@AlexeyNikonorov
Copy link

Summary

When constructing a command line for CBC executable, CBCSHELL plugin adds -stat=1 option to it. This option tells CBC to gather additional stats about the MIP problem and write these stats to logs.

Rationale

I faced a situation when gathering information requested by -stat=1 option takes significantly more time then the actual solve. The MIP problem I'm working with is quite large but easy. I suppose this is when the slowdown due to -stat=1 is most noticeable.
I'm not interested in these stats but in current CBCSHELL interface I can't prevent it from passing -stat=1 option to CBC.

Description

CBCSHELL lets user to pass options to CBC via .options attribute. The -stat option is no different. Then why not let user decide whether to gather more stats or no. I suggest to not pass -stat=1 option during command line construction. The user can do it themselves via .options attribute just like any other option.

The alternative would be for the user to subclass CBCSHELL and override the create_command_line method to exclude this option. To me this looks more like a hack. But I don't see other options without editing Pyomo code.

@AlexeyNikonorov AlexeyNikonorov changed the title Pyomo passes -stat=1 option to CBC which causes slowdown Don't pass -stat=1 option to CBC to avoid slowdown Mar 12, 2024
@mrmundt
Copy link
Contributor

mrmundt commented Mar 12, 2024

@AlexeyNikonorov - This is a good suggestion. We have just taken a first pass at redesigning the solver interfaces, and I'm going to track this as part of that redesign effort.

Tagging in #1030

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

No branches or pull requests

2 participants