Recently, someone asked me about time limits for AIMMS PRO Jobs.
You can control the timeout via the timeout argument in pro::delegateToServer. Note that this timeout is in milliseconds.
When thinking about time limits, I usually think about time limit for the solver.
To provide the solver with the opportunity to share the best solution thus far,
I usually add some minutes to cater for case load, project start, case save etc of the job to the time limit for the AIMMS PRO Job.
Therefore, my delegate sometimes looks as follows:
timeout: p_timeLimit * 1.2 * 1000 + 5 * 60 * 1000, ! timelimit for job is in milli seconds.
Where p_timeLimit is the time limit in seconds for the solve itself.
@Chris Kuip ,
I currently consider a model where the solver time limit is set to 10 minutes. Usually, if I solve this model locally within the AIMMS IDE, I get a solution after a few seconds and the relative gap after 10 minutes is still greater than the defined stopping criterion. Nevertheless, after the interruption due to the reached time limit, I am still able to obtain the best solution found so far. Therefore, this is the behavior I expect when solving the same model with the same data on AIMMS Pro. However, in this case, the session is terminated after 10 minutes and the code following the solve statement is not executed at all. The respective entry in the log file reads:
The parameter pro::DelegateToServer::timeOut you are referring to is not changed and still takes its default value of 3600000 milliseconds.
What is the reason for this beavior and how can I obtain the solution?
Can you share a reproducible example, perhaps by sharing via firstname.lastname@example.org?
I found the cause of this problem. The AIMMS Pro session was triggered by an API call with another value of pro::DelegateToServer::timeOut (so it had nothing to do with the model itself). Thank you anyway!