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

Dedicated AC Power Flow Solver #590

Closed
jchen975 opened this issue Aug 24, 2019 · 18 comments
Closed

Dedicated AC Power Flow Solver #590

jchen975 opened this issue Aug 24, 2019 · 18 comments

Comments

@jchen975
Copy link

Hi, I just realized this problem, but when I run a solved Matpower case, it takes the same number of iterations as it would with default values. In Matpower,

results = runpf('caseX') 
savecase('caseX', results)
runpf('caseX')

should result in iterations: 1 in the end. When running with default/solved values for case118, and case300, it takes 4 and 5 iterations respectively. I tried both with the case saved from Matpower and with manually updating the vm, va fields of all buses from the solutions dict, and got the same results.

Any idea why this is happening? I know Matpower uses NR for acpf by default, so I'm assuming it has something to do with Ipopt. I'd appreciate any clarifications on this.

@ccoffrin
Copy link
Member

This is a good question and there are quite a few details to get the most out of a warm start in PowerModels. At a high level these are the key points,

  1. you have to provide special values in the data model for providing an initial starting point. In the case of the ACPPowerModel these are pg_start, qg_start, vm_start, va_start, pf_start, pt_start, qf_start, qt_start (note that the ACPPowerModel adds explicit flow variables to the branches). <var name>_start is the pattern for all variables.
  2. After setting these values you then need to set Ipopt's parameters carefully. This includes setting smaller values for mu_init, bound_frac and bound_push. For very large models you might also try hessian_approximation to reduce the time for derivative computations.

I hope that helps. I'll also note that PowerModels was originally designed for solving OPF without a good guess for a starting point. Due to that focus, doing very fast PF solves is not super easy in PowerModels. In the future I plan to add some dedicated AC-PF solvers that assume a good starting point and are much faster and simpler to use for that use case.

@ccoffrin
Copy link
Member

@jchen975, can we close this issue?

@jchen975
Copy link
Author

jchen975 commented Aug 27, 2019

Thank you for your answer and sorry for taking so long to get back to you, I was on vacation and didn't have access to internet until now. If you don't mind, I'll take some time tomorrow to figure out how to do warm-start ACPF properly and close the issue then.

One last thing and please correct me if I'm wrong, currently run_ac_pf() is designed for cold-start ACPF (e.g. vary some PD, QD values of a Matpower case and run ACPF with the default vm, va values), and the summary information printed from Ipopt would be the same from Matpower, right? It's just the warm-start ACPF that I need to set up myself.

@ccoffrin
Copy link
Member

No problem. run_ac_pf solves the feasibility problem that is defined here, which I would characterize as a fairly standard power flow formulation. It does not attempt to change pd or qd values. For a formulation that will consider pd/qd changes I would refer you to the PowerModelsMLD package.

The equations implemented by PowerModels are identical to Matpower when reading matpower case files (as of Matpower v6), so for an identical problem specification they should be the same. You can try the calc_branch_flow_ac and calc_power_balance functions to verify this using a solution that was generated by Matpower.

@jchen975
Copy link
Author

Thanks again for your time! I took a look at the Ipopt documentation and adjusted those parameters, but I couldn't really find anything on <var>_start for ACPPowerModel. Any hints?

@ccoffrin
Copy link
Member

So far there is no documentation on setting the starting point in PowerModels. I am still exploring how to best initialize Ipopt.

You can have a look in this file to see the names of the parameter you need to add in the network data to specify the starting value for each variable.

@jchen975
Copy link
Author

Hi Dr. Coffrin, regarding your previous comment on your plan to add an ACPF solver that accommodates warm-start conditions, has there been any updates? If that's not a short-term priority, I was actually thinking about creating a new package that only solves the PF problem, by rewriting the Matpower runpf related functions in Julia, sometime early next year (I'm finishing my undergrad this coming April so I probably won't be able to finish it while I'm still in school). Unfortunately I eventually switched back to Matpower to continue with my project, but I'd like to get your opinions on this. Thanks!

@jchen975 jchen975 reopened this Nov 17, 2019
@ccoffrin
Copy link
Member

@jchen975 there are not updates per-se, it is still possible to warm-start Ipopt with the current version of PowerModels, although it is not well documented.

Please feel free you write your own power flow solver, I hope to implement something similar in PowerModels in the next 6-12 months, so I might draw some inspiration from your implementation.

@ccoffrin ccoffrin changed the title run_ac_pf with solved Matpower cases still takes more than 1 iteration Dedicated Power Flow Solver Nov 17, 2019
@ccoffrin ccoffrin changed the title Dedicated Power Flow Solver Dedicated AC Power Flow Solver Jan 10, 2020
@ccoffrin
Copy link
Member

a native DC power flow solver is not available. The AdmittanceMatrix data structure as been added to help support this feature.

@timueh
Copy link

timueh commented Jan 23, 2020

Hi @jchen975, is this still an open issue? I'd be interested in a dedicated power flow solver in Julia that uses PowerModels.jl. A first step might be to set up the system of nonlinear equations, and then use it with one of Julia's Newton-type solvers. Then, one could go about implementing decoupled power flow etc..

Any thoughts?

@ccoffrin
Copy link
Member

FYI, @jd-lara as I know you have an interest in this.

@jchen975
Copy link
Author

@timueh Yeah, unfortunately I haven't had the time to get on this... I was going to start in March once I finish a few other things on my hand. But what you suggested made sense!

@ccoffrin Please feel free to close this issue :)

@timueh
Copy link

timueh commented Jan 24, 2020

Sweet! Perhaps there is room for collaboration @jchen975? Perhaps we can talk about details via e-mail? You can find mine on my github profile.

@jd-lara
Copy link
Contributor

jd-lara commented Jan 24, 2020

@timueh we have implemented something similar as what your objective is in PowerSystems.jl where we use Julia's solvers to solve the Non-linear system of equations. The intention for us is to initialize the system with a PowerFlow solution when needed.

https://github.com/NREL/PowerSystems.jl/tree/master/src/utils/power_flow

The tests show examples of how to use it.

https://github.com/NREL/PowerSystems.jl/blob/master/test/test_powerflow.jl

@timueh
Copy link

timueh commented Feb 5, 2020

Thanks. That looks like what I was looking for. Just a quick question---which I could answer myself with playing with the code, but you might know the answer immediately---what's the number of decision variables in the power flow problem? Is it n_{pv} + 2*n_{pq} like in matpower, where n_{pv} is the number of PV buses, and n_{pq} is the number of PQ. buses?

@jd-lara
Copy link
Contributor

jd-lara commented Feb 5, 2020

The number of decision variables is always 2*n_buses. Each PV bus needs a solution for \theta and Q. Each PQ bus needs a solution for \theta and V. Each Slack bus needs a solution for P and Q.

ccoffrin added a commit that referenced this issue Apr 3, 2020
* add NLSolve to deps
* add complex admittance matrix computation
* add julia native ac power flow solver, closes #590
* add tests for native ac pf solver
@ccoffrin
Copy link
Member

ccoffrin commented Apr 6, 2020

A prototype version of this feature is now available in the rc-v0.16 branch. The function is called compute_ac_pf. Feedback is welcome.

@ccoffrin
Copy link
Member

After a long wait, I am happy to report that this has been implemented. Documentation is available here, https://lanl-ansi.github.io/PowerModels.jl/stable/power-flow/

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

4 participants