I want to run multiple instances of a problem by changing a single parameter w… But each time, I want to run it fresh (from scratch)… For example, when I run the model with ~ (w = 6), ~ I want a fresh run — that is, not use the optimal solution from the previous ~ (w = 5) ~ run as a starting solution… (This is due to the nature of my problem – I have to start from scratch every time.)

I can do this with a script written in C or Python or a UNIX shell script — but it appears impossible with AMPL commands… For example, if I write a for loop such as

for (T in 22..44) {
model myModel.mod;
let w := T;
solve;
display X;
display Y;
reset;
}

The reset command ~ “destroys” ~ the loop variable T — and so in the second run of the for loop, the statement ~ “let w := T” ~ is flagged as invalid (error).

Tried replacing “let w:= T” with “let w := w + 1” and replacing the “for” loop with
“for {22..44}” — but this doesn’t work either.

I have tried the ~ “reset data w” ~ and ~ “update” ~ commands described in Chapter 11 of the AMPL book (the “Command Scripts” chapter) — but they all seem to use the optimal solutions from the previous ~w~ run (often resulting in zero iterations of the solver in the subsequent run).

Is there any way to do fresh “from scratch” runs with AMPL commands?

Set the AMPL option reset_initial_guesses to 1 to tell AMPL to ignore the previous optimal solution each time that the problem is solved. Also move your model statement outside of the loop, so that it is only executed once, and do not reset inside the loop:

model myModel.mod;
option reset_initial_guesses 1;
for {T in 22..44} {
let w := T;
solve;
display X;
display Y;
}

Here’s the description from the AMPL Options listing:

reset_initial_guesses b (default 0)

Whether to send to the solver the current values of the variables. Values are sent when b is at its default value of 0, and are reset to the initial values specified in the model if b is set to 1.

Thank you, but sorry, it doesn’t work… I am using MINOS as my solver… And in the model file (which contains a data section at the bottom), my options are:

Maybe for some values of w, MINOS doesn’t need any iterations. You can easily check: Pick a value of w for which MINOS reports zero iterations, and just solve for that one value of w. For example, if you are seeing zero iterations when you run in the loop and w is 53, do this test:

model myModel.mod;
option solver minos, reset_initial_guesses 1;
option minos_options 'superbasics_limit=10000 scale_option=2 solution=yes Major_iterations=200 timing=1';
let w := 53;
solve;

If MINOS still reports zero iterations, there is nothing wrong. But if instead in this test, MINOS reports a positive number of iterations, then upload your file(s) and I’ll take a closer look.

I have uploaded the files… As you can see, besides the “number of iterations”, the solutions (the X values) and the values of “integerCount” are also different.

I had to change the names of file extensions (from “.txt” to “.dat”, then “.cmd” to “.run”, etc…) so that I could upload them.

After running some tests on your example, I realized that MINOS is a special case. Unlike most local nonlinear solvers, it can use 3 kinds of information from the previous solve:

The optimal values of the variables.

The optimal values of the dual variables.

The statuses of the variables (basic, nonbasic, or superbasic) in the optimal solution.

You can tell MINOS to ignore all of this information, by setting the following options:

The reason that I like this approach (rather than the C program approach) is that I can sometimes use NEOS… I can upload the model file and command file into NEOS and use their AMPL-MINOS platform… Thank you, I will try your suggestions and report back.

Did some more testing… The number of iterations is now non-zero in each case… However, I still notice some interference from previous runs.

In one experiment, for [w = 0.0169], if I run the model in the range (0.0163 \le w \le 0.0172), the number of iterations for [w = 0.0169] is 13035… whereas if my range is (0.0164 \le w \le 0.0172), MINOS performs 20038 iterations for [w = 0.0169]… and the solutions returned are also different.

Anyway, I guess I will stop experimenting with this… Could be an issue with MINOS… Thanks for your help — let me continue my research using the C program method.