Problem with piecewise linear formulation

Support
1

I want to define the following curve, dealing with a shunt element including a tap changer. Using the tap changer position, which finally shall be optimized, the power consumption behaves like depicted.

image
image752Ă—452 18.5 KB

The sampling points are defined using mainly a polinominal approach.

reset;

problem ACPF; # to define a problem

var tap integer default 3;

let tap:=1;

param x {j in 1..24} = j; # create x-axis data

param y {k in 1..25}; #

let {k in 1..25} y[k] := 0.32*(k^2-(k-1)^2) + 1.36;

let y[1] := -250;

display x;

display y;

var v_q_mvar = << {j in 1..24} x[j]; {k in 1..25} y[k] >> tap;

display tap;

display v_q_mvar;

fix tap;

display v_q_mvar;

Why am I getting two times the assumed value in case the variable is fixed (-500 instead of -250)?

Best regards,
Lothar

1 Like
2

Here is an add-on:
Trying a new test using simply the abs() function:
reset;

var value;

let value:=1;

var result = << 0; -1, 1 >> value;

display value;

display result;

reset;

var value;

let value:=1;

var result = << 0; -1, 1 >> value;

display result;

problem ACPF;

display value;

display result;

I got the same buggy result (“2” instead of “1”) simply after defining a problem. After running the test, a few seconds later - I don’t know why - the AMPL process was terminated using the AMPL-IDE. As a result, the test script showed the correct result. Unfortunately, that’s not the case running the script dealing about the main problem.
I will restart the computer next to test if this will have an effect.
Regards,
Lothar

3

I guess, I found the problem:
Using “option presolve 0;” leads to the wrong result. Due to other problems I had using the presolve, I deactivated the presolve. In general, this option seems not to be set to a generic default value using the reset-command.
So, is there a way to use my approach of the piecewise linear function without using the presolve?

Best regards,
Lothar

4

Maybe it is also in combination with the declaration of a problem.

At least this script leads to the error:

reset;

option presolve 0;

var value;

let value:=1;

var value2;

var result = << 0; -1, 1 >> value;

display result;

problem ACPF: value2;

display value;

display result;

5

Hi Lothar,

Thanks for your report, we are working on it. It’s seems to be an obscure issue when presolve is turned off with problem declarations, and piecewise linear functions…

Since you are fixing tap and giving it a default value, is tap a variable or a parameter? As a workaround, you can get the right display result when declaring tap (or value in the second example) as a parameter:

param tap integer default 3;

A similar option is to just not fixing tap before displaying.

Another option is to not turn off presolve and just do 1 pass with:

option presolve 1;

A third possible workaround is using Amplpy to define different AMPL objects from an API instead of using the problem construct to define different problems. Also fixing/dropping variables and constraints accordingly would be similar to declaring a problem.

It seems that you’re trying to do with AMPL more complex things than solving a simple problem, have you considered using Amplpy to preprocess data and parameters in Python and then send it to AMPL?

6

Hi marcos,
Thank’s for the reply.
In a first calculation, the tap position will be a parameter. But this will change in another calculation. Thus, it is defined as a variable.
I switched to “option presolve 1;” in the meantime. Nevertheless, I detected in former optimizations that this partly leads into a non-convergence of the calculation. That’s the reason why I deactivate the presolve in general.
Of course I can use different AMPL objects using Amplpy. In general the program uses Python as the calling instance. I will check if the problem still exists if tap is a variable which is included in the problem to be modified by the solver. Due to a vacation next week, I will tell the results in about 10 days. :wink:
Best regards,
Lothar

1 Like