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

Overrunning SQP Time Cap #16

Closed
Foggalong opened this issue Jul 18, 2024 · 3 comments
Closed

Overrunning SQP Time Cap #16

Foggalong opened this issue Jul 18, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@Foggalong
Copy link
Owner

At the moment the SQP time cap is applied to each sub problem, rather than the problem as a whole. It's documented as if intended, but it's only like this because I was lazy when first writing it 😅

This is an easy fix, just needs some extra structure set up to keep a running total of how long has been spent in Gurobi/HiGHS.

time_left = T  # limit

for i = 1, ... n
   time_start = Time()
   SQP.solve()
   time_left -= Time()-time_start

   if time_limit < 0:
      break  # timeout
@Foggalong Foggalong added the bug Something isn't working label Jul 18, 2024
Foggalong added a commit that referenced this issue Jul 26, 2024
@Foggalong Foggalong mentioned this issue Jul 26, 2024
@Foggalong Foggalong changed the title SQP Time Cap Overrunning SQP Time Cap Aug 1, 2024
@Foggalong
Copy link
Owner Author

As of #26 being merged both Gurobi and HiGHS have time_limit implemented for the full problem not just one iteration. However the HiGHS functions in particular may still overrun the time cap (though nowhere near as dramatically).

See this comment for more information, but essentially there's no way at present through highspy to tell HiGHS it only has $T$ time for a particular h.run(). This means at a given iteration we can't tell HiGHS it only has time_remaining left, only check afterwards whether or not it exceeded that before starting the next iteration.

This does mean that HiGHS will overrun the time cap when reached mid-iteration. Functionality to fix this will be added in HiGHS 2.0, so nought to do on this end until that release.

@Foggalong Foggalong added the hold Will not / cannot be worked on yet label Aug 1, 2024
@jajhall
Copy link
Collaborator

jajhall commented Aug 1, 2024

You can tell HiGHS that it has only time T for a particular call to 'run()' by setting its time limit before that run to t0+T, where t0 is the HiGHS run time - obtained with the call h.getRunTime() - before the call.

@Foggalong
Copy link
Owner Author

Nice, good to know about h.getRunTime(). Will incorporate that now

@Foggalong Foggalong removed the hold Will not / cannot be worked on yet label Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants