HighsCallbackDataIn with user_interrupt = 1 (nonzero) not working i.e., not returning HiGHS back to the user

[jeffreydeankelly2]

The Control-C interrupt in HiGHS 1.10.0 is now fixed (thank you) and enables the HiGHS user to invoke a Control-C event from which the HighsCallbackDataIn's user_interrupt is set to one (non-zero) in a MIP callback routine and for us this is when the callback type = kHighsCallbackMipInterrupt.

This works as we are able to properly change the user_interrupt from zero (observed HiGHS default) to one when Control-C is typed.

Unfortunately, when HighsCallbackDataIn->user_interrupt is passed as non-zero, HiGHS does not terminate, exit or return HiGHS back to the user as stated.

[jajhall]

Since HighsCallbackDataIn->user_interrupt is a bool (default false) in the native C++, and you're talking about its observed default being zero, and setting it to one (successfully) and two (unsuccessfully), I guess you're using the C API.

I've experimented with the unit test in check/TestCAPI.c, changing line 197 from

data_in->user_interrupt = 1

to

data_in->user_interrupt = 2

but don't reproduce what you observe.

If the interrupt were failing completely (regardless of the setting of data_in->user_interrupt) then I have an idea of what might be happening, but that seems not to be the case.

In the light of #2214, #2217 and #2226, I'm looking to improve the handling of bailout events in the MIP solver (which include user interrupt) but I thought that the MIP user interrupt (when identified) was being handled correctly.

I'll add a parameter to data_out so that the source of the MIP user interrupt call can be traced, which might help

Otherwise, I'm stuck for an explanation for your observation.

[jeffreydeankelly2]

Thanks, I guess the best approach would be to have a separate C API function like GUROBI and COPT with GRBterminate() and COPT_interrupt() which we use to about gracefully these two MIP solvers.

…

On Sat, Mar 22, 2025 at 2:15 PM Julian Hall ***@***.***> wrote: Since HighsCallbackDataIn->user_interrupt is a bool (default false) in the native C++, and you're talking about its observed default being zero, and setting it to one (successfully) and two (unsuccessfully), I guess you're using the C API. I've experimented with the unit test in check/TestCAPI.c, changing line 197 from data_in->user_interrupt = 1 to data_in->user_interrupt = 2 but don't reproduce what you observe. If the interrupt were failing completely (regardless of the setting of data_in->user_interrupt) then I have an idea of what might be happening, but that seems not to be the case. In the light of #2214 <#2214>, #2217 <#2217> and #2226 <#2226>, I'm looking to improve the handling of bailout events in the MIP solver (which include user interrupt) but I thought that the MIP user interrupt (when identified) was being handled correctly. I'll add a parameter to data_out so that the source of the MIP user interrupt call can be traced, which might help Otherwise, I'm stuck for an explanation for your observation. — Reply to this email directly, view it on GitHub <#2248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEDIZCE3FA7K3TIE46T2VWSFZAVCNFSM6AAAAABZR4ZTOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBVGM4TMNZZGI> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: jajhall]*jajhall* left a comment (ERGO-Code/HiGHS#2248) <#2248 (comment)> Since HighsCallbackDataIn->user_interrupt is a bool (default false) in the native C++, and you're talking about its observed default being zero, and setting it to one (successfully) and two (unsuccessfully), I guess you're using the C API. I've experimented with the unit test in check/TestCAPI.c, changing line 197 from data_in->user_interrupt = 1 to data_in->user_interrupt = 2 but don't reproduce what you observe. If the interrupt were failing completely (regardless of the setting of data_in->user_interrupt) then I have an idea of what might be happening, but that seems not to be the case. In the light of #2214 <#2214>, #2217 <#2217> and #2226 <#2226>, I'm looking to improve the handling of bailout events in the MIP solver (which include user interrupt) but I thought that the MIP user interrupt (when identified) was being handled correctly. I'll add a parameter to data_out so that the source of the MIP user interrupt call can be traced, which might help Otherwise, I'm stuck for an explanation for your observation. — Reply to this email directly, view it on GitHub <#2248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEDIZCE3FA7K3TIE46T2VWSFZAVCNFSM6AAAAABZR4ZTOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBVGM4TMNZZGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ********************************************************** *I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m i z a t i o n S m a r t e r"* Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: ***@***.*** Phone: (647) 917-4675 (IMPL) *Making Industrial AI (Algorithms & Integration) Real!* ********************************************************** This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

[jajhall]

Thanks, I guess the best approach would be to have a separate C API function like GUROBI and COPT with GRBterminate() and COPT_interrupt() which we use to about gracefully these two MIP solvers.

I can't see us having the resources to implement this any time soon.

Are you running Windows?

[jeffreydeankelly2]

Yes, Windows 11 calling HiGHS from Intel Fortran (IFX). Is there any other way to terminate HiGHS?

…

On Sat, Mar 22, 2025 at 3:53 PM Julian Hall ***@***.***> wrote: Thanks, I guess the best approach would be to have a separate C API function like GUROBI and COPT with GRBterminate() and COPT_interrupt() which we use to about gracefully these two MIP solvers. I can't see us having the resources to implement this any time soon. Are you running Windows? — Reply to this email directly, view it on GitHub <#2248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEEJP4M4R4W5KDXJ4P32VW5UJAVCNFSM6AAAAABZR4ZTOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBVGQ4DKNZZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: jajhall]*jajhall* left a comment (ERGO-Code/HiGHS#2248) <#2248 (comment)> Thanks, I guess the best approach would be to have a separate C API function like GUROBI and COPT with GRBterminate() and COPT_interrupt() which we use to about gracefully these two MIP solvers. I can't see us having the resources to implement this any time soon. Are you running Windows? — Reply to this email directly, view it on GitHub <#2248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEEJP4M4R4W5KDXJ4P32VW5UJAVCNFSM6AAAAABZR4ZTOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBVGQ4DKNZZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ********************************************************** *I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m i z a t i o n S m a r t e r"* Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: ***@***.*** Phone: (647) 917-4675 (IMPL) *Making Industrial AI (Algorithms & Integration) Real!* ********************************************************** This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

[jajhall]

Yes, Windows 11 calling HiGHS from Intel Fortran (IFX). Is there any other way to terminate HiGHS?

Thanks. I'll see whether I can reproduce your experience on Windows.

There is no other way to interrupt HiGHS