CPF: Change the continuation direction when the operating point moves… #25
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Aah yes, Thank you. I’ve updated the comment.
Shri
From: Jose Luis Marin <notifications@github.com>
Reply-To: MATPOWER/matpower <reply@reply.github.com>
Date: Thursday, September 21, 2017 at 2:32 AM
To: MATPOWER/matpower <matpower@noreply.github.com>
Cc: "Abhyankar, Shrirang G." <abhyshr@anl.gov>, Author <author@noreply.github.com>
Subject: Re: [MATPOWER/matpower] CPF: Change the continuation direction when the operating point moves… (#25)
Hello Shri,
You're referencing issue #21<#21>, but I think your patch actually addresses issue #23<#23>, doesn't it?
JL
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#25 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABHuMH12wo7klSVEnWkgDGcSGuZmI5u1ks5skhEPgaJpZM4PeA1b>.
|
|
Thanks @abhyshr. A few comments ...
|
|
I’m getting errors for test_matpower after rebasing off the master branch
t_mplinsolve............Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 411)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU3' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 415)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 419)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU3a' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 423)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 427)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU4' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 431)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 435)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU5' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 439)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 443)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU3m' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 447)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 451)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU3am' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 455)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 459)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU4m' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 463)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 467)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU5m' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 471)
In t_run_tests (line 61)
In test_matpower (line 144)
Warning: mplinsolve: 'LU' is not a valid value for SOLVER, using default.
In mplinsolve (line 94)
In t_mplinsolve (line 475)
In t_run_tests (line 61)
In test_matpower (line 144)
ok (2 of 21 skipped)
t_mips..................ok
t_qps_matpower..........ok (252 of 360 skipped)
t_miqps_matpower........ok (226 of 240 skipped)
t_pf....................not ok
##### Ran 54 of 54 tests: 53 passed, 1 failed
t_pf_radial.............Error using mpoption (line 659)
Error using mpoption (line 122)
mpoption: 'pf.radial' is not a valid option name
Error in t_pf_radial (line 37)
mpopt = mpoption(mpopt, 'pf.alg', 'NR', 'pf.radial.max_it', 100);
Error in t_run_tests (line 61)
feval( test_names{k}, ~verbose );
Error in test_matpower (line 144)
all_ok = t_run_tests( tests, verbose );
From: Ray Zimmerman <notifications@github.com>
Reply-To: MATPOWER/matpower <reply@reply.github.com>
Date: Monday, September 25, 2017 at 2:14 PM
To: MATPOWER/matpower <matpower@noreply.github.com>
Cc: "Abhyankar, Shrirang G." <abhyshr@anl.gov>, Mention <mention@noreply.github.com>
Subject: Re: [MATPOWER/matpower] CPF: Change the continuation direction when the operating point moves… (#25)
Thanks @abhyshr<https://github.com/abhyshr>. A few comments ...
· Looks like this PR was based on an old version of the master branch. Would you mind rebasing it on the current master?
· The test for "case300 w/Q lims" currently results in a fatal error on my machine.
· I noticed some of the tests are not currently passing. I haven't looked at the details, but it appears to me at first glance that the logic for setting the direction may not be quite correct. In particular, the first of the failing tests ("CPF (full trace) (pseudo arc length) w/Q lims") appears to be a case where it now switches directions (unexpected behavior), when it did not previously. Same for the case that immediately follows that one ("bug #12<#12> : early termination").
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#25 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABHuMC990h-XdeA6VVuUeUe6fSTB6JLlks5sl_ubgaJpZM4PeA1b>.
|
|
Very strange. All of those failing tests are working fine for me. Did you try with a fresh Matlab session? |
|
Looks like the Travis CI build is consistent with my local results as well. It would appear the errors you are seeing are triggered by something in your local setup. If a fresh clone in a fresh Matlab session gives the same results, then we'll have to start digging further. |
|
Works fine for me with the fresh clone, sorry for the noise. Modifying the direction calculation code to if(nx.lam > px.lam)
opts.tol = 1e-3;
direction = sign(min(real(eigs(J,1,'SR',opts))));
endresolves the failing tests for 9-bus case. For the 300-bus case, the eigs solver was diverging so I relaxed its tolerance to 1e-3 as suggested online. The eigs solver converges but shows that the Jacobian has negative eigen values when the first limit is encountered. This indicates the operating point has transitioned from the stable to unstable manifold. However, if I comment out the direction check code, \lambda keeps increasing with decreasing voltages suggesting the operating point is on the stable manifold! This is confusing making me unsure if the eigen values are being computed correctly or not. |
|
Please take into account that case300 is already on the unstable manifold, in the base case scenario. Bus 191 is the culprit; it is on the unstable side of its V-Q curve. |
added 2 commits
November 29, 2017 12:42
… from stable to unstable manifold. Elis Nycander, https://www.mail-archive.com/matpower-l@cornell.edu/msg06048.html, brought up a case where the operating point moves from stable to unstable manifold. Once on the unstable manifold, the continuation curve moves in the direction of lambda increase, which seems intuitively opposite to expected behavior (progress along the decreasing lambda direction). The reason for the lambda increase direction when on unstable manifold is because the tangent direction was always set towards lambda increase. This fix checks whether the operating point is on stable or unstable manifold (by checking the sign of minimum eigen value) and changes the direction accordingly. When on stable manifold, an increasing lambda direction is set, while a decreasing lambda direction on unstable manifold. Relevant discussion can be found here MATPOWER#21
|
What's the current status of this PR? I'd like to get it back in sync with the master branch and merged in as soon as we have something we're comfortable with that is passing all tests. |
abhyshr
pushed a commit
to abhyshr/matpower
that referenced
this pull request
Dec 5, 2017
…s for issues pointed out in PR MATPOWER#25. i) Change the tangent direction after switching based on the sign of the product of current tangent direction and the sign of the smallest real eigen value for Jacobian. This resolves issues where the PV curve seems to turn unnaturally (go in the opposite direction) after PV->PQ switching. 9-bus test case. ii) Use tolerance 1e-3 for eigen value calculation. This resolves the crashing of the failing test for 300-bus case w/Qlims. iii) Check for buses having negative V-Q sensitivity. This is done by checking for positive dQ_dV elements in the tangent vector z. If found, previous tangent direction is retained. Otherwise, a new direction is calculated as per (i). This resolves the failing 300-bus w/Q lims. (Thanks J. Marin!) All test cases pass with the above fixes.
abhyshr
pushed a commit
to abhyshr/matpower
that referenced
this pull request
Dec 5, 2017
…s for issues pointed out in PR MATPOWER#25. i) Change the tangent direction after switching based on the sign of the product of current tangent direction and the sign of the smallest real eigen value for Jacobian. This resolves issues where the PV curve seems to turn unnaturally (go in the opposite direction) after PV->PQ switching. 9-bus test case. ii) Use tolerance 1e-3 for eigen value calculation. This resolves the crashing of the failing test for 300-bus case w/Qlims. iii) Check for buses having negative V-Q sensitivity. This is done by checking for positive dQ_dV elements in the tangent vector z. If found, previous tangent direction is retained. Otherwise, a new direction is calculated as per (i). This resolves the failing 300-bus w/Q lims. (Thanks J. Marin!) All test cases pass with the above fixes.
|
Sorry for the delay. Can you please take a look at this PR. I've updated the logic for the tangent direction and have rebased off the current master. All test cases are passing. |
…s for issues pointed out in PR MATPOWER#25. i) Change the tangent direction after switching based on the sign of the product of current tangent direction and the sign of the smallest real eigen value for Jacobian. This resolves issues where the PV curve seems to turn unnaturally (go in the opposite direction) after PV->PQ switching. 9-bus test case. ii) Use tolerance 1e-3 for eigen value calculation. This resolves the crashing of the failing test for 300-bus case w/Qlims. iii) Check for buses having negative V-Q sensitivity. This is done by checking for positive dQ_dV elements in the tangent vector z. If found, previous tangent direction is retained. Otherwise, a new direction is calculated as per (i). This resolves the failing 300-bus w/Q lims. (Thanks J. Marin!) All test cases pass with the above fixes.
|
It looks good to me. I will plan to merge it tomorrow unless someone objects. @ElisNycander or @jl-marin, any comments? This should take care of #23. |
…on direction after potential change from stable to unstable manifold. (or vice versa)
rdzman
force-pushed
the
shri/cpf/manifold-change-detection-and-switching
branch
from
1f5ccee
to
3d1e935
Compare
rdzman
added a commit
to MATPOWER/mp-element
that referenced
this pull request
May 3, 2021
rdzman
added a commit
that referenced
this pull request
May 3, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CPF: Change the continuation direction when the operating point moves from stable to unstable manifold.
Elis Nycander, https://www.mail-archive.com/matpower-l@cornell.edu/msg06048.html, brought up a case where the operating point moves from stable to unstable manifold. Once on the unstable manifold, the continuation curve moves in the direction of lambda increase, which seems intuitively opposite to expected behavior (progress along the decreasing lambda direction). The reason for the lambda increase direction when on unstable manifold is because the tangent direction was always set towards lambda increase. This fix checks whether the operating point is on stable or unstable manifold (by checking the sign of minimum eigen value) and changes the direction accordingly. When on stable manifold, an increasing lambda direction is set, while a decreasing lambda direction on unstable manifold.
Relevant discussion can be found here #23
Ray: I have not added the test cases or updated the manual yet. I'll add these once you are ok with the changes.