Baron exitcode 18446744072635809797
203 views
Skip to first unread message
Alba Victoria
Mar 26, 2019, 10:04:39 AM3/26/19
to AMPL Modeling Language
Hi!
I'm running a loop solving various problems with Baron, and I've got the following message:
BARON 18.11.12 (2018.11.12):
optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
exit value 18446744072635809797
optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
exit value 18446744072635809797
Through optfile I'm asking Baron to return the fifth feasible point it finds. I've used these options previously in the loop, without any problem. However, it seems this particular instance is reporting an error. Interestingly, if I change the starting point I do not get this message and Baron runs until the end:
BARON 18.11.12 (2018.11.12):
optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 18.11.12 (2018.11.12): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 18.11.12 (2018.11.12): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
Can anyone help me figuring out what's going on? I attach some files so anyone can reproduce these results.
Thanks!!
Alba
AMPL Google Group
Mar 27, 2019, 11:15:51 AM3/27/19
to Ampl Modeling Language
Last week we made available a new version of BARON (19.3.22) which runs on your example without any error -- see the listing below. Please try downloading and running this new version. Then if you again see messages like "exit value 18446744072635809797", send us a new example that gives the error.
///////////
ampl: include baron_exitcode.run;
'SOLVING SUBPROBLEM t=48' = 'SOLVING SUBPROBLEM t=48'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
'SOLVING SUBPROBLEM t=48, new starting point' =
'SOLVING SUBPROBLEM t=48, new starting point'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
'SOLVING SUBPROBLEM t=48, another starting point' =
'SOLVING SUBPROBLEM t=48, another starting point'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
ampl:
--
Robert Fourer
am...@googlegroups.com
{#HS:811630398-39346#}
///////////
ampl: include baron_exitcode.run;
'SOLVING SUBPROBLEM t=48' = 'SOLVING SUBPROBLEM t=48'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
'SOLVING SUBPROBLEM t=48, new starting point' =
'SOLVING SUBPROBLEM t=48, new starting point'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
'SOLVING SUBPROBLEM t=48, another starting point' =
'SOLVING SUBPROBLEM t=48, another starting point'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
ampl:
--
Robert Fourer
am...@googlegroups.com
Alba Victoria
Mar 28, 2019, 11:48:04 AM3/28/19
to AMPL Modeling Language
Thanks Robert,
I have now downloaded the latest release. Although it now avoids the reported error, the Gilmore-Gomory procedure implemented on file cut.run (referred in Chapter 14 of AMPL book) does not work any longer when using Baron as solver. It keeps on looping as follows:
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 52.1
Objective 52.1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
...and so on. Although my code seems to work fine, I though it would be good to report this in case something is not working properly in the new release.
Best,
Alba
AMPL Google Group
Mar 29, 2019, 12:06:32 PM3/29/19
to Ampl Modeling Language
Please attach the exact files that you used, so that we can try to reproduce this problem.
The example of the Gilmore-Gomory procedure in Chapter 14 of the AMPL book is linear, so we would advise trying a linear solver such as CPLEX, Gurobi, Xpress, or CBC on this example.
--
Robert Fourer
am...@googlegroups.com
{#HS:811630398-39346#}
The example of the Gilmore-Gomory procedure in Chapter 14 of the AMPL book is linear, so we would advise trying a linear solver such as CPLEX, Gurobi, Xpress, or CBC on this example.
--
Robert Fourer
am...@googlegroups.com
AMPL Google Group
Apr 1, 2019, 10:40:47 PM4/1/19
to Ampl Modeling Language
BARON is a global optimization solver designed for nonconvex nonlinear problems. Unlike linear programming solvers, it does not return proper dual values for the constraints Thus the statement "let {i in WIDTHS} price[i] := Fill[i].dual;" in cut.run does not work correctly with BARON. You should use a mixed-integer linear solver with cut.run instead.
--
Robert Fourer
am...@googlegroups.com
{#HS:811630398-39346#}
--
Robert Fourer
am...@googlegroups.com
On Mon, Apr 1, 2019 at 11:25 AM UTC, Ampl Modeling Language <am...@googlegroups.com> wrote:
Here you have!
Best,
Alba
On Fri, Mar 29, 2019 at 4:06 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
Please attach the exact files that you used, so that we can try to reproduce this problem.
The example of the Gilmore-Gomory procedure in Chapter 14 of the AMPL book is linear, so we would advise trying a linear solver such as CPLEX, Gurobi, Xpress, or CBC on this example.
--
Robert Fourer
am...@googlegroups.com
On Thu, Mar 28, 2019 at 3:48 PM UTC, Ampl Modeling Language <am...@googlegroups.com> wrote:
Thanks Robert,
I have now downloaded the latest release. Although it now avoids the reported error, the Gilmore-Gomory procedure implemented on file cut.run (referred in Chapter 14 of AMPL book) does not work any longer when using Baron as solver. It keeps on looping as follows:
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 52.1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
BARON 19.3.22 (2019.03.22): 0 iterations, optimal within tolerances.
Objective 48.6
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -0.2
...and so on. Although my code seems to work fine, I though it would be good to report this in case something is not working properly in the new release.
Best,
Alba
El miércoles, 27 de marzo de 2019, 16:15:51 (UTC+1), AMPL Google Group escribió:
On Wed, Mar 27, 2019 at 3:15 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
Last week we made available a new version of BARON (19.3.22) which runs on your example without any error -- see the listing below. Please try downloading and running this new version. Then if you again see messages like "exit value 18446744072635809797", send us a new example that gives the error.
///////////
ampl: include baron_exitcode.run;
'SOLVING SUBPROBLEM t=48' = 'SOLVING SUBPROBLEM t=48'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
'SOLVING SUBPROBLEM t=48, new starting point' =
'SOLVING SUBPROBLEM t=48, new starting point'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
'SOLVING SUBPROBLEM t=48, another starting point' =
'SOLVING SUBPROBLEM t=48, another starting point'
BARON 19.3.22 (2019.03.22): optfile=baron_option_file5.txt
numsol=5
firstfeas=1
maxtime=-1
BARON 19.3.22 (2019.03.22): 1 iterations, optimal within tolerances.
Objective -8.099999999e-05
On Tue, Mar 26, 2019 at 2:05 PM UTC, Ampl Modeling Language <am...@googlegroups.com> wrote:
Alba Victoria
Apr 2, 2019, 7:46:36 AM4/2/19
to AMPL Modeling Language
Thanks for pointing this out. However, I've got Baron exitcode 18446744072635809797 twice more with the new version. Unfortunately, I haven't been able to reproduce this outcome because when using solve command straight after, Baron solves the problem without any issue:
#Case 1:
BARON 19.3.22 (2019.03.22): maxtime=-1
exit value 18446744072635809797
<BREAK>
ampl: solve;
BARON 19.3.22 (2019.03.22): maxtime=-1
BARON 19.3.22 (2019.03.22): 15241 iterations, optimal within tolerances.
Objective 0.0001735506796
exit value 18446744072635809797
<BREAK>
ampl: solve;
BARON 19.3.22 (2019.03.22): maxtime=-1
BARON 19.3.22 (2019.03.22): 15241 iterations, optimal within tolerances.
Objective 0.0001735506796
#Case 2:
BARON 19.3.22 (2019.03.22): maxtime=-1
exit value 18446744072635809797
<BREAK>
ampl: solve;
BARON 19.3.22 (2019.03.22): maxtime=-1
BARON 19.3.22 (2019.03.22): 921 iterations, optimal within tolerances.
Objective 0.2147777381
exit value 18446744072635809797
<BREAK>
ampl: solve;
BARON 19.3.22 (2019.03.22): maxtime=-1
BARON 19.3.22 (2019.03.22): 921 iterations, optimal within tolerances.
Objective 0.2147777381
Any idea of what's going on? I guess it must be related to using Baron repeatedly on a loop, since the very same problem works just after breaking. Is there any temporal variable or parameter I should be deleting in the loop?
Thanks once again,
Alba
AMPL Google Group
Apr 3, 2019, 11:53:11 AM4/3/19
to Ampl Modeling Language
Since the BARON solver is spawned as a separate process each time you request a solve, BARON does not have any direct information as to whether it was called from at loop. However since in a loop BARON is called many times, there is more chance for a failure. It's still unclear why BARON then succeeds when called immediately after the loop is terminated by the failure.
The first thing you should check is whether the failure is exactly repeatable. That is, if you start another AMPL session and run exactly the same script with the same files, does the failure occur at the same place, and then does BARON succeed with the same iteration counts when run after the failure? This information will narrow down the possible causes of the problem.
Next, try adding "option show_stats 1;" at the beginning of your script, and also adding outlev=1 to your baron_options string. This will produce a lot of log output. Post the output from the last two BARON solves -- the one that failed and the one that subsequently succeeded. (In the output there will be a show_stats listing before each BARON run listing, with information about the size of the problem, numbers of different constraints of different kinds, etc.)
--
Robert Fourer
am...@googlegroups.com
{#HS:811630398-39346#}
The first thing you should check is whether the failure is exactly repeatable. That is, if you start another AMPL session and run exactly the same script with the same files, does the failure occur at the same place, and then does BARON succeed with the same iteration counts when run after the failure? This information will narrow down the possible causes of the problem.
Next, try adding "option show_stats 1;" at the beginning of your script, and also adding outlev=1 to your baron_options string. This will produce a lot of log output. Post the output from the last two BARON solves -- the one that failed and the one that subsequently succeeded. (In the output there will be a show_stats listing before each BARON run listing, with information about the size of the problem, numbers of different constraints of different kinds, etc.)
--
Robert Fourer
am...@googlegroups.com
AMPL Google Group
Apr 10, 2019, 4:53:00 PM4/10/19
to Ampl Modeling Language
We have been able to reproduce the "Baron exitcode 18446744072635809797" message, as least under some conditions. The cause is being investigated, but we may need to ask the developers of BARON to have a look at the problem. Hopefully we can post a fix or workaround before very long.
--
Robert Fourer
am...@googlegroups.com
{#HS:811630398-39346#}
--
Robert Fourer
am...@googlegroups.com
On Mon, Apr 8, 2019 at 10:50 AM UTC, Ampl Modeling Language <am...@googlegroups.com> wrote:
Hi!
I managed to reproduce the exitcode in the attached "baron_exitcode4.run" file. Please, let me know if it also breaks for you.
Thanks,
Alba
El miércoles, 3 de abril de 2019, 17:53:11 (UTC+2), AMPL Google Group escribió:
On Wed, Apr 3, 2019 at 3:52 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
Since the BARON solver is spawned as a separate process each time you request a solve, BARON does not have any direct information as to whether it was called from at loop. However since in a loop BARON is called many times, there is more chance for a failure. It's still unclear why BARON then succeeds when called immediately after the loop is terminated by the failure.
The first thing you should check is whether the failure is exactly repeatable. That is, if you start another AMPL session and run exactly the same script with the same files, does the failure occur at the same place, and then does BARON succeed with the same iteration counts when run after the failure? This information will narrow down the possible causes of the problem.
Next, try adding "option show_stats 1;" at the beginning of your script, and also adding outlev=1 to your baron_options string. This will produce a lot of log output. Post the output from the last two BARON solves -- the one that failed and the one that subsequently succeeded. (In the output there will be a show_stats listing before each BARON run listing, with information about the size of the problem, numbers of different constraints of different kinds, etc.)
--
Robert Fourer
am...@googlegroups.com
Alba Victoria
Apr 11, 2019, 10:02:21 AM4/11/19
to AMPL Modeling Language
Thanks Robert. I've obtained the same exitcode for other instances, so I could try to reproduce more of these examples if you think that having more cases help your team or Baron developers to figure out the issue.
Best,
Alba
AMPL Google Group
Apr 19, 2019, 6:20:27 PM4/19/19
to Ampl Modeling Language
{#HS:811630398-39346#}
On Thu, Apr 11, 2019 at 2:02 PM UTC, Ampl Modeling Language <am...@googlegroups.com> wrote:
Thanks Robert. I've obtained the same exitcode for other instances, so I could try to reproduce more of these examples if you think that having more cases help your team or Baron developers to figure out the issue.
Best,
Alba
El miércoles, 10 de abril de 2019, 22:53:00 (UTC+2), AMPL Google Group escribió:
On Wed, Apr 10, 2019 at 8:52 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
We have been able to reproduce the "Baron exitcode 18446744072635809797" message, as least under some conditions. The cause is being investigated, but we may need to ask the developers of BARON to have a look at the problem. Hopefully we can post a fix or workaround before very long.
--
Robert Fourer
am...@googlegroups.com
Alba Victoria
May 13, 2019, 10:34:06 AM5/13/19
to AMPL Modeling Language
Dear Robert,
Are there any news from Baron developers about this issue?
Thanks!
Alba
AMPL Google Group
May 14, 2019, 7:55:38 PM5/14/19
to Ampl Modeling Language
{#HS:811630398-39346#}
On Mon, May 13, 2019 at 2:34 PM UTC, Ampl Modeling Language <am...@googlegroups.com> wrote:
Dear Robert,
Are there any news from Baron developers about this issue?
Thanks!
Alba
El sábado, 20 de abril de 2019, 0:20:27 (UTC+2), AMPL Google Group escribió:
On Fri, Apr 19, 2019 at 10:20 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
AMPL Google Group
May 16, 2019, 5:52:03 AM5/16/19
to Ampl Modeling Language
We received the following response from our BARON contact:
Apologies that this issue has taken me more than usual to resolve. It
turns out that it is deep in CBC. I am looking for ways to resolve it.
In the meanwhile, I thought that you could let the user know that
using the BARON option
mipcall=0
will get around this issue by simply not calling CBC. Of course, this
will degrade performance for most problems--that's why this option is
not public.
Note that CBC is the mixed-integer programming solver that BARON uses by default. To set the indicated option, you will need to create a BARON options file. For example, if your file is baron_options.txt, put the line mipcall=0 in it, and then specify
option baron_options 'optfile=baron_options.txt';
(or, if you already are specifying a baron_options string, add optfile=baron_options.txt to it).
Alternatively, if you have the CPLEX or Xpress solver for AMPL, then there is the possibility to use one of them instead of CBC by specifying one of the following,
option baron_options 'lpsolver=cplex';
option baron_options 'lpsolver=xpress';
(or by adding one of these to an existing baron_options string).
--
Robert Fourer
am...@googlegroups.com
{#HS:811630398-39346#}
Apologies that this issue has taken me more than usual to resolve. It
turns out that it is deep in CBC. I am looking for ways to resolve it.
In the meanwhile, I thought that you could let the user know that
using the BARON option
mipcall=0
will get around this issue by simply not calling CBC. Of course, this
will degrade performance for most problems--that's why this option is
not public.
Note that CBC is the mixed-integer programming solver that BARON uses by default. To set the indicated option, you will need to create a BARON options file. For example, if your file is baron_options.txt, put the line mipcall=0 in it, and then specify
option baron_options 'optfile=baron_options.txt';
(or, if you already are specifying a baron_options string, add optfile=baron_options.txt to it).
Alternatively, if you have the CPLEX or Xpress solver for AMPL, then there is the possibility to use one of them instead of CBC by specifying one of the following,
option baron_options 'lpsolver=cplex';
option baron_options 'lpsolver=xpress';
(or by adding one of these to an existing baron_options string).
--
Robert Fourer
am...@googlegroups.com
On Tue, May 14, 2019 at 11:55 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
We are following up with the BARON developers about this.
On Mon, May 13, 2019 at 2:34 PM UTC, Ampl Modeling Language <am...@googlegroups.com> wrote:
Dear Robert,
Are there any news from Baron developers about this issue?
Thanks!
Alba
El sábado, 20 de abril de 2019, 0:20:27 (UTC+2), AMPL Google Group escribió:
On Fri, Apr 19, 2019 at 10:20 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:
Alba Victoria
May 29, 2019, 4:25:43 AM5/29/19
to am...@googlegroups.com
Thanks Robert, I'm using cplex instead od CBC and it's working now. However, I would be grateful if you could let me know when the bug is fixed so I can go back to use CBC again.
Best,
Alba
--
You received this message because you are subscribed to a topic in the Google Groups "AMPL Modeling Language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ampl/2SkWvwxF-cA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ampl+uns...@googlegroups.com.
To post to this group, send email to am...@googlegroups.com.
Visit this group at https://groups.google.com/group/ampl.
To view this discussion on the web visit https://groups.google.com/d/msgid/ampl/reply-77152-811630398-2388407977-1558000319-689601517%40helpscout.net.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages