[AMPL 24474] Why is a variable being considered/modified solving a specified problem

Google Group Mirror
1

Hi,

There are two defined problems in a project which are quite the same exept that the second problem does not consider an (independent) variable. The program looks like following:

…
var v_bra_tap_pos {MPC_BRA_ID} integer >= -5, <= 5 default 0; # variable declaration
…
minimize obj1: sum{ … # objective functions
minimize obj2: sum{ …
…
problem pr1: obj1, v_bra_tap_pos, … # additional variables and constraints
problem pr2: obj2, … # variables and constraints - without variable “v_bra_tap_pos”

problem pr1;
let …
fix …
solve pr1;

at this point, there are optimized values for variable “v_bra_tap_pos”

problem pr2;
let …
fix … # approach 1) don’t fixing variable “v_bra_tap_pos”; approach 2) fixing variable “v_bra_tap_pos”;
solve pr2;

After solving problem “pr2”, the values for variable “v_bra_tap_pos” have been changed using approach 1). They are not changed fixing the independent variable “v_bra_tap_pos” (approach 2)).

Why this is this way, since variable “v_bra_tap_pos” is not a variable of the problem and - from my point of view - it has to be fixed automatically by AMPL?

Best regards,
Lothar

2

If problem pr2 is defined as you describe, then the command “problem pr2;” will make pr2 the current problem and will fix the v_bra_tap_pos variables at their current values. To investigate the behavior that you are seeing, add these commands,

problem;
show pr1;
show pr2;
display v_bra_tap_pos.astatus;

in the following three places:

  • immediately after “problem pr2;”
  • immediately before “solve pr2;”
  • immediately after “solve pr2;”
    The added commands display the current problem, the current definitions of problems pr1 and pr2, and the AMPL status of the v_bra_tap_pos variables – which should be “in” if those variables are in the current problem, and should be “fix” if those variables are not in the current problem. To get more help, copy the output from all three times that these commands are executed, and paste it into your email.
3

Hi Robert,
Thank’s for facing the problem.
Unfortunately, it is depicted that the variable is in both problems considered (“in”). Here is the output (pr1 is IEEOptTool_pandapower_problem and pr2 is IEEOptTool_pandapower_problem_hard).

v_bra_tap_pos :=
1 96 5
1 97 9
1 98 6
;

problem IEEOptTool_pandapower_problem_hard;

problem IEEOptTool_pandapower_problem: f_obj_sl, v_bra_tap_pos, v_bus_vm,
v_bus_va, v_gen_p, v_gen_q, c_add_acpf_p, c_add_acpf_q, c_bus_vmMin,
c_bus_vmMax, c_bra_util_12, c_bra_util_21, c_gen_pMin, c_gen_pMax,

c_gen_qMin, c_gen_qMax, c_gen_q_bus_distr;

problem IEEOptTool_pandapower_problem_hard: f_P_LOSS, v_bus_vm, v_bus_va,
v_gen_p, v_gen_q, c_add_acpf_p, c_add_acpf_q, c_bus_vmMin, c_bus_vmMax,
c_bra_util_12, c_bra_util_21, c_gen_pMin, c_gen_pMax, c_gen_qMin,
c_gen_qMax, c_gen_q_bus_distr, c_TSO_DSO_QNVP_sum_setp,
c_TSO_DSO_vm_setps;

v_bra_tap_pos.astatus :=
1 96 in
1 97 in
1 98 in
;

v_bra_tap_pos :=
1 96 5
1 97 9
1 98 6
;

v_bra_tap_pos[s,i].relax :=
1 96 0
1 97 0
1 98 0
;

problem IEEOptTool_pandapower_problem_hard;
problem IEEOptTool_pandapower_problem: f_obj_sl, v_bra_tap_pos, v_bus_vm,
v_bus_va, v_gen_p, v_gen_q, c_add_acpf_p, c_add_acpf_q, c_bus_vmMin,
c_bus_vmMax, c_bra_util_12, c_bra_util_21, c_gen_pMin, c_gen_pMax,
c_gen_qMin, c_gen_qMax, c_gen_q_bus_distr;
problem IEEOptTool_pandapower_problem_hard: f_P_LOSS, v_bus_vm, v_bus_va,
v_gen_p, v_gen_q, c_add_acpf_p, c_add_acpf_q, c_bus_vmMin, c_bus_vmMax,
c_bra_util_12, c_bra_util_21, c_gen_pMin, c_gen_pMax, c_gen_qMin,
c_gen_qMax, c_gen_q_bus_distr, c_TSO_DSO_QNVP_sum_setp,
c_TSO_DSO_vm_setps;

v_bra_tap_pos.astatus :=
1 96 in
1 97 in
1 98 in
;

Ipopt 3.12.13: outlev=2

==> Warning: Treating 0 binary and 3 integer variables as continous.

Ipopt 3.12.13: Optimal Solution Found

problem IEEOptTool_pandapower_problem_hard;
problem IEEOptTool_pandapower_problem: f_obj_sl, v_bra_tap_pos, v_bus_vm,
v_bus_va, v_gen_p, v_gen_q, c_add_acpf_p, c_add_acpf_q, c_bus_vmMin,
c_bus_vmMax, c_bra_util_12, c_bra_util_21, c_gen_pMin, c_gen_pMax,
c_gen_qMin, c_gen_qMax, c_gen_q_bus_distr;
problem IEEOptTool_pandapower_problem_hard: f_P_LOSS, v_bus_vm, v_bus_va,
v_gen_p, v_gen_q, c_add_acpf_p, c_add_acpf_q, c_bus_vmMin, c_bus_vmMax,
c_bra_util_12, c_bra_util_21, c_gen_pMin, c_gen_pMax, c_gen_qMin,
c_gen_qMax, c_gen_q_bus_distr, c_TSO_DSO_QNVP_sum_setp,
c_TSO_DSO_vm_setps;

v_bra_tap_pos.astatus :=
1 96 in
1 97 in
1 98 in
;

v_bra_tap_pos :=
1 96 -2.36994
1 97 -0.0189152
1 98 -2.407

;

As depicted, variable" v_bra_tap_pos" is only defined in problem " IEEOptTool_pandapower_problem" and not in " IEEOptTool_pandapower_problem_hard". However, it has the status “in” activating and solving this problem resulting in modified values.
There is the warning of solver “ipopt” that integer variables are treated as continous, but the variable already has this status activating the problem.

Best regards,
Lothar

4

I analyzed the problem in the meantime - to be honest it is mainly the problem (and program) of a colleague:

After solving problem “pr1”, he unfixes the variable " v_bra_tap_pos" before activating and solving problem “pr2”. I don’t know why he entered this line. Nevertheless, so far, I thought that this unfix belongs to the last active problem (“pr1”). Nevertheless, deleting this line, the variable is being fixed solving problem “pr2” and - of course - the values remains untouched.

Why is is this way? Is the last defined problem automatically activated after solving any problem?

Best regards,
Lothar

5

Even after the current problem is changed, the .astatus of variables only changes after the next “solve” (or “write”). That may be the cause of some of the confusion in this case. Still, if the fix and problem statements are in this order,

unfix v_bra_tap_pos;
problem pr2;

and v_bra_tap_pos is not in problem pr2, then v_bra_tap_pos will normally be fixed when pr2 is solved. (I even ran a simple example to confirm this.) I am not not sure why it’s not working that way in your application, but the explanation must involve some details of the script that I have not seen.

Because the purpose of AMPL problem definitions is to avoid a lot of fix/unfix and drop/restore statements, there is seldom a need to have any fix or unfix statements when problem statements are being used. Having both fix/unfix and problem in the same run file tends to create complicated situations (and unexpected results).

Concerning Ipopt: When you see “Warning: Treating 0 binary and 3 integer variables as continous” it’s because Ipopt cannot handle integrality requirements on variables. If your model requires variables to have integer values, then you’ll need to switch to a different solver; if you want to stick with COIN-OR solvers, check out Bonmin and/or Couenne.