problem with Loops in AMPL

[Hossein Haghighat]

Hi
I am solving a problem for a number of scenarios. each scenario differs from the others just in data. when I solve each scenario separately (not in a loop), AMPL finds the solution, but when I implement a loop, AMPL finds the solution just to the first scenario and does not converge to a solution for the rest of the scenarios.
in the beginning of the loop, I change data items and at the end of the loop, I retract all data items to their initial values by command "update data". The codes look something like this:
 
reset;
loop statement {
  - change data
  - solve
...
  - reset data
  - update data  
 }
 
 
Does anyone have any idea what is happening in my model?   
 
hossein
 
 
 
 
 
 
 
 
 

---

Express yourself instantly with MSN Messenger! MSN Messenger

[Paul]

On Mar 7, 4:11 pm, Hossein Haghighat <hj_haghig...@hotmail.com> wrote:
> Hi
> I am solving a problem for a number of scenarios. each scenario differs from the others just in data. when I solve each scenario separately (not in a loop), AMPL finds the solution, but when I implement a loop, AMPL finds the solution just to the first scenario and does not converge to a solution for the rest of the scenarios.
> in the beginning of the loop, I change data items and at the end of the loop, I retract all data items to their initial values by command "update data". The codes look something like this:
>
> reset;
> loop statement {
> - change data
> - solve
> ...
> - reset data
> - update data
> }
>
> Does anyone have any idea what is happening in my model?
>

I can't think of any reason to use both 'reset data' and 'update
data'. At the top of the loop, where you say "change data", are you
supplying new values for *all* parameters? The 'reset data' command
will wipe all parameter settings; parameters with a default clause in
their declarations will revert to those values, but I believe those
without defaults will go to missing values.

There are three ways to modify the data within the loop:

1. If you are reading in new values for all the parameters at the top
of the loop, use 'reset data'. If you are reading in new values for
just some of them, use 'reset data <list>' and list the parameters
being reset (the others will then retain their current values). In
this approach, do not use 'update data'.

2. Use 'update data' (or 'update data <list>') to allow new values to
be read in for some or all parameters, retaining existing values of
any parameters for which you are not reading in new values. In this
approach, do not use 'reset data'.

3. If only changing a few parameters, and particularly if you are
using computed values as updates, use 'let' statements ('let p := v;'
where p is a parameter and v is a new value) at the top of the loop
and skip both the reset and update statements.

/Paul

[Alan H]

Hi,

I think I am still facing a similar, if not the same, problem as the first
poster. I am using the MINOS solver. My parameters (data) are X0, X1, X2 and
Y. My variables are LProb, Beta, B, Theta.

If I run the following commands, everything works:
reset;
model mymodel.mod;
data mydata.dat; #reads in X0, X1 and X2
read {k in K, i in N} Y[k,i] < ydata.txt; #reads in Y
solve;

If I change the value of X2 first before solve, as below, everything works:
reset;
model mymodel.mod;
data mydata.dat; #reads in X0, X1 and X2
read {k in K, i in N} Y[k,i] < ydata.txt; #reads in Y
let {k in K} X2[k] := X1[k]*X1[k]; #re-define X2 as the square of X1
solve;

However, if I solve the first problem, reset all my variables, change my X2
parameter and try to solve the second problem, I get an "infeasible problem
(bad starting guess)" error:
reset;
model mymodel.mod;
data mydata.dat; #reads in X0, X1 and X2
read {k in K, i in N} Y[k,i] < ydata.txt; #read in Y values
solve;
reset data LProb, Beta, B, Theta;
let {k in K} X2[k] := X1[k]*X1[k];
solve;

The same commands worked with a previous problem, so I am lost to why it is
not working here. Any suggestions would be much appreciated.

Alan

Paul A. Rubin wrote:
>
>
> On Mar 7, 4:11 pm, Hossein Haghighat <hj_haghig...@hotmail.com> wrote:
>> Hi
>> I am solving a problem for a number of scenarios. each scenario differs
>> from the others just in data. when I solve each scenario separately (not
>> in a loop), AMPL finds the solution, but when I implement a loop, AMPL
>> finds the solution just to the first scenario and does not converge to a
>> solution for the rest of the scenarios.
>> in the beginning of the loop, I change data items and at the end of the
>> loop, I retract all data items to their initial values by command "update
>> data". The codes look something like this:
>>
>> reset;
>> loop statement {
>> - change data
>> - solve
>> ...
>> - reset data
>> - update data
>> }
>>
>> Does anyone have any idea what is happening in my model?
>>
>

> There are three ways to modify the data within the loop:
>
> 1. If you are reading in new values for all the parameters at the top
> of the loop, use 'reset data'. If you are reading in new values for
> just some of them, use 'reset data <list>' and list the parameters
> being reset (the others will then retain their current values). In
> this approach, do not use 'update data'.
>
> 2. Use 'update data' (or 'update data <list>') to allow new values to
> be read in for some or all parameters, retaining existing values of
> any parameters for which you are not reading in new values. In this
> approach, do not use 'reset data'.
>
> 3. If only changing a few parameters, and particularly if you are
> using computed values as updates, use 'let' statements ('let p := v;'
> where p is a parameter and v is a new value) at the top of the loop
> and skip both the reset and update statements.
>
> /Paul
>

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "AMPL Modeling Language" group.
> To post to this group, send email to am...@googlegroups.com
> To unsubscribe from this group, send email to
> ampl-uns...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/ampl?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
>

--
View this message in context: http://old.nabble.com/-AMPL-1647--problem-with-Loops-in-AMPL-tp15906329p30137613.html
Sent from the AMPL mailing list archive at Nabble.com.

[Paul]

On Nov 4, 9:08 pm, Alan H <al...@uchicago.edu> wrote:

> However, if I solve the first problem, reset all my variables, change my X2
> parameter and try to solve the second problem, I get an "infeasible problem
> (bad starting guess)" error:
>  reset;
>  model mymodel.mod;
>  data mydata.dat; #reads in X0, X1 and X2
>  read {k in K, i in N} Y[k,i] < ydata.txt; #read in Y values
>  solve;
>  reset data LProb, Beta, B, Theta;
>  let {k in K} X2[k] := X1[k]*X1[k];
>  solve;

You eliminated the values of LProb, Beta, B and Theta with the reset
data command. I assume the model uses them for something (starting
value estimates maybe?). Unless they are truly superfluous, you need
to supply new values for them.

/Paul

[Alan H]

I still occasionally experience the same problem, even though I provide valid
default values for all my variables that always work outside the loop. It's
just that there is an error once I reset these variables within the loop. Is
it possible to "start completely from scratch"/"cold start" each problem
within a loop? I have tried both the following options:

option reset_initial_guesses 1;
option dual_initial_guess 0;

but there still is an error sometimes.

Alan

> --

> You received this message because you are subscribed to the Google Groups
> "AMPL Modeling Language" group.

> To post to this group, send email to am...@googlegroups.com.

> To unsubscribe from this group, send email to

> ampl+uns...@googlegroups.com.

> For more options, visit this group at

> http://groups.google.com/group/ampl?hl=en.
>
>
>

--
View this message in context: http://old.nabble.com/-AMPL-1647--problem-with-Loops-in-AMPL-tp15906329p30347777.html

[Robert Fourer]

Setting reset_initial_guesses to 1 should send to the solver the initial
values of the variables as specified in the var declarations -- or 0 by
default where no values are specified. If you set this parameter at the
beginning of your script then you should get a cold start in every pass
through your loop.

The "infeasible problem (or bad starting guess)" message looks to me like
one that comes from MINOS, however. It does not mean that AMPL made an
error in sending the starting guess to MINOS, but rather that MINOS was
unable to find a feasible solution to the problem starting from whatever
initial values were sent. This could mean that there is simply no feasible
solution for that particular problem. But it could also be that there is a
feasible solution, which MINOS is unable to reach from the given initial
values; in that sense those initial values would be a "bad starting guess"
although all of the values are valid for the variables. So when receiving
this message it is necessary to do some experimentation with other initial
values (or if that's not conclusive, maybe even other solvers) to determine
the true situation.

Bob Fourer
4...@ampl.com

[Alan H]

I am using these two reset options:

option reset_initial_guesses 1;
option dual_initial_guess 0;

which I understand should give a "cold start" to each solve. I can see how
looping over different data may cause a problem with bad starting values.
However, I am completely lost for an explanation as to why I still have an
error when I run solve again immediately after a successful first solve, on
the exact same data and model:

solve;
MINOS 5.5: the current point cannot be improved.
169 iterations, objective -177.0636795
Nonlin evals: constrs = 385, Jac = 384.

solve;
MINOS 5.5: unbounded (or badly scaled) problem.
58 iterations
Nonlin evals: constrs = 179, Jac = 178.

How can AMPL/MINOS give some sort of solution for the first problem, yet
cannot replicate the same solution when I try to solve it immediately
afterwards, using a "cold start"? Shouldn't it give me the same solution or
same error message for both solves?

Thanks!

Alan Huang

> --
> You received this message because you are subscribed to the Google Groups
> "AMPL Modeling Language" group.
> To post to this group, send email to am...@googlegroups.com.
> To unsubscribe from this group, send email to
> ampl+uns...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ampl?hl=en.
>
>
>

--
View this message in context: http://old.nabble.com/-AMPL-1647--problem-with-Loops-in-AMPL-tp15906329p30412992.html

[Robert Fourer]

Because MINOS is based on the simplex method, the second solve would also
receive from AMPL the basis status values determined by the first solve. So
in addition to the two reset options that you mention, you should set option
send_statuses to 0 produce a cold start.

Also the message that "the current point cannot be improved" should not be
interpreted as indicating a successful solve. As I understand it, this
means that MINOS reached a point from which it could not find a way to step
to a better point, but at which the optimality conditions were still not
satisfied to reasonable tolerances. A successful solve should give an
"optimal solution" message.