pglib-opf icon indicating copy to clipboard operation
pglib-opf copied to clipboard

Error when solving case89_pegase__api and case240_pserc__api

Open cbingane opened this issue 4 years ago • 7 comments

Hello,

I got the following error when solving OPF for 2 test cases: case89_pegase__api and case240_pserc__api with the MATPOWER function runopf. It seems that there is a problem when generator bound Pmax is 0.

Error using makeAvl (line 52) makeAvl: either Qmin or Qmax must be equal to zero for each dispatchable load.

Error in opf_setup (line 171) [Avl, lvl, uvl] = makeAvl(baseMVA, gen);

Error in opf (line 198) om = opf_setup(mpc, mpopt);

Error in runopf (line 75) [r, success] = opf(casedata, mpopt);

Best regards,

Christian

cbingane avatar Jul 25 '19 19:07 cbingane

Thanks for the heads up! Did you test with v19.05? We recently fixed some generator bounds in that release.

ccoffrin avatar Jul 25 '19 20:07 ccoffrin

Yes, I did.

cbingane avatar Jul 25 '19 21:07 cbingane

Ok I think I see the source of the issue.

For example a generator from case89_pegase__api,

	4586	 -363.8	 0.0	 254.4	 -254.4	 1.0	 100.0	 1	 0	 -727.6; % SYNC

This is a consumption-only generator, which also provides reactive support.

This is a valid input for the AC-OPF problem as stated by the specification of this repository and I can also imagine practical cases where this type of input would be generated. My inclination is to say this is an inconsistency between the AC-OPF formulation in this repository and the one defined in Matpower, and that Matpower's formulation should be extended to support this case. However, I am open to debate on this point.

ccoffrin avatar Jul 26 '19 14:07 ccoffrin

I also think there is an inconsistency with the ACOPF defined in MATPOWER. Maybe, there is a reason why they do not take into account this kind of generator in their formulation. Thanks for the clarification.

cbingane avatar Jul 26 '19 20:07 cbingane

@rdzman, what are your thoughts on modifying Matpower to support non-zero q-bounds on consumption-only generators?

ccoffrin avatar Jul 29 '19 14:07 ccoffrin

I don't think the issue is the Q bounds themselves. MATPOWER includes a constant power factor constraint for dispatchable loads. Currently a dispatchable load is represented as a consumption-only generator. That is, it is defined as a generator with negative Pmin and Pmax exactly equal to zero.

If I understand correctly, what you want is to be able to define such a generator without MATPOWER automatically assuming it is a dispatchable load and adding the constant power factor constraint. The easiest workaround would be to define Pmax to be some non-zero value very close to, but not equal to, zero (e.g. -1e-10).

Eventually, I plan to explicitly model dispatchable loads as separate elements, rather than using the "negative generator" hack. At that point, this should be a non-issue.

rdzman avatar Jul 29 '19 15:07 rdzman

That sounds good, thanks for your insights! We will use the -1e-10 work around until dispatchable loads become separate elements.

ccoffrin avatar Jul 29 '19 17:07 ccoffrin