Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when solving case89_pegase__api and case240_pserc__api #25

Open
cbingane opened this issue Jul 25, 2019 · 7 comments
Open

Error when solving case89_pegase__api and case240_pserc__api #25

cbingane opened this issue Jul 25, 2019 · 7 comments

Comments

@cbingane
Copy link

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

@ccoffrin
Copy link
Member

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

@cbingane
Copy link
Author

Yes, I did.

@ccoffrin
Copy link
Member

ccoffrin commented Jul 26, 2019

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.

@cbingane
Copy link
Author

cbingane commented Jul 26, 2019

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.

@ccoffrin
Copy link
Member

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

@rdzman
Copy link
Contributor

rdzman commented Jul 29, 2019

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.

@ccoffrin
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants