Open SLiemann opened 3 years ago
Hey, thanks a lot for your thoughts and contribution on this. We still have an open PR where we calculate the initial state with a power flow calculation from PowerModels.jl. Does this also cover your requirements/ ideas?
Hi, overall PowerModels.jl looks very interesting, but I did not get from the docs which functionalities are included in their power flow calculation. In general, I think that their implementation is much faster than my proposal, since there is definitely room for improvements (especially to solve the power flow with nlsolve). However, there focus is only on steady-state and that reduces their number of models significantly, which makes it easier for their power flow implementation. But this could also be an obstacle, as dynamic simulations are to be carried out in PowerDynamics.jl afterwards, for which some other things are important.
Here some thoughts about some requierements/challenges for a "classic" power flow calculation with a subsequent dynamic simulation in PowerDynamics. Some of them are linked with the question how to hand over the additional information that are not a direct part of the model:
How do you define which node is a PQ, PV or slack node?
maximum reactive ( and active) power: How do you want to include power limits in the power flow, so that e.g. a PV node changes to a PQ node? Should it be included? Where shall these limit values be stored or handed over?
internal algebraic equations: e.g. for a synchronous machine you have the field voltage and the synchronous impedance. However in a "classic" power flow calculation you dont specify the field voltage, but you specify the terminal voltage. In addition, your active power setpoint is also at the terminals and so you have to inject more power (increasing you mechanical power) to compensate your inner losses (if modelled). What I want so say is that you can not directly use all the model equations to do a "classic" power flow calculation, since you omit the internal algebraic equations. In Matpower or most of any other steady-state problem formulation you don't have any internal algebraic equations.
initialize interal inputs/variables: From the above point, it naturally follows that you have to initialise your internal inputs (e.g. field voltage) and states (e.g. rotor angle) from the power flow solution. Otherwise, you will not have a flat start.
new models: How will new models of PowerDynamics be supported in the power flow algorithm of Powermodels.jl? For example if you have a Q(V)-characteristic of a DG unit. These characteristics need a similar treatment as voltage dependent loads. Also the automatic tapping of an OLTC inside a power flow could be a challenge.
I know that the initialization is a pure PowerDynamics.jl problem, but in my opinion is linked closely with the power flow and treatment of the models. This could be especially challenging for the last point. Maybe the effort for making the PowerDynamics model run with PowerModels is as high as implementing an own power flow algorithm? However, this is difficult for me to assess as I do not have sufficient experience with both packages.
@SabineAuer I don't think this is closed by #118 since the points raised by Sebastian are still valid.
The internal variables are already initialised from a load flow (e.g. PowerModels) solution in a very simple way that ignores, for instance, the subtleties for sync machines mentioned in the post above. It might be good to have a type-dependent initialisation function?
Also we should explore how the automatic transformer step change can be dealt with in the load flow solution.
Hi,
I talked to @luap-pik some time ago to post my request here. I want to make a suggestion and a first draft for a classic power flow calculation algorithm which includes the definition of PQ, PV and slack (only one) nodes. The motivation is that the finding of the initial operating point is sometimes tricky for some types of grids, especially with reactive power limits or without any SlackAlgebraic node. The result of the power flow is given back as an initial guess for the dynamic simulation where the derivatives are zero. Maybe this can be combined with find_initial_operatingpiont. To check the power flow by the user, also the voltage magnitude and the voltage angles in degree are returned (but this could also be ommited).
The slack node can either specified by the user or the Slackalgebraic node (if present) is taken. If a SlackAlgebraic node is present then the "user node" is ignored. If no SlackAlgebraic node is available and no node has been specified, then the first bus is taken as slack. Furthermore, it is relatively easy to extend the power flow to new node types, as can be seen by the first functions of the code.
The power flow is capable of changing PV nodes into PQ nodes if the reactive power limits of each node are reached. In addition, some extras like Iwamoto multipliers and the pre-calculation of voltage angles are included to increase the robustness of the power flow. Also the voltage dependency of the loads are included.
Update (16.03.21): The vector of SI voltages as well as the base voltage are not longer necessary for the power flow calculation. Now the admittances of each branch have to be related directly to the desired voltage level (see branch 4). This has the advantage, that the admittances can also be used directly for the dynamic simulation. In terms of consistent modelling, I think this is more stringent. I also updated the power flow code below.
However, until now there are some small drawbacks. Up to now only the reference voltages of the SlackAlgebraic and the PVAlgebraic nodes are taken from the nodes for the load flow. For all other PV nodes 1.0 p.u. is the reference value (if it is a PV node). Of course you can specify voltages for FourthOrderEq but then you will need another routine that updates the field voltage of the machine, as it depends on the load flow. But maybe this is another topic.
In addition, the code could still be optimised in some places to be faster, but I am still relatively new with Julia.
Here is a small example and the call of the power flow could look like this:
And here is the code of the power flow: