casella
commented
1 year ago I made some further reflections on this topic. I agree with @ceraolo that the current configuration, in which you are asked values of UStart and UPhase for each component involved in a connection set, is unnecessarily redundant and potentially harmful, and it would be much better if one only had to provide that information on buses, even if that makes adding buses at all connection points compulsory. After all, power engineers are used at putting those buses there all the time anyway.
I actually see two ways of doing that. One is to make UStart and UPhaseStart final in all components except buses, binding them to some global default value, possibly set in the system object. In this way, UStart and UPhaseStart would show up only in the initialization menu of buses. The standard start attribute priority selection mechanism which is already in place in Modelica 3.5 would then guarantee that the values set in the buses are picked. This requires no changes in the connector definition.
However, this only works if the default final values for those start parameters in non-bus components are fixed once and for all in the library. If, e.g., they were parameters in the system object to define global default UStart and UPhaseStart, and they could be changed when instantiating the system object, then the binding equation for those defaults would have the same priority as the ones providing UStart modifiers in buses, so we'd be back to square one.
Also, this solution is a bit fragile, because one could forget to add the bus in some connection sets, and then the bus-less connected components model would get a very bad global default start attribute for voltage, possibly leading to initialization failure. However, the model would be legal and the compiler would issue no warnings of sort and compile it. This is not a recommendable outcome.
If we instead make buses compulsory, the problem is solved in a very robust way:
- the buses provide those start attributes to the connected components using input-output connector variables
- there is no critical dependency on arcane priority rules to pick the right guess values for voltages
- if the bus is omitted, the model won't even compile, because the output variable is missing from the connection set
If we combine this design choice with what I proposed in #60, and with recent changes done by #66, then the connector design would become
type ReferenceAngularSpeed "Overconstrained type for frequency reference"
extends SI.PerUnit;
function equalityConstraint
input ReferenceAngularSpeed omega1;
input ReferenceAngularSpeed omega2;
output SI.PerUnit residue[0];
end equalityConstraint;
end ReferenceAngularSpeed;
connector PowerTerminalACBase "Base class for all AC power connectors"
Types.ComplexVoltage v "Phase-to-ground voltage phasor";
flow Types.ComplexCurrent i "Line current phasor";
ReferenceAngularSpeed omegaRef "Reference angular speed for phasors";
end PowerTerminalACBase;
connector PowerTerminalAC "Base class for non-bus AC power connectors"
extends PowerTerminalACBase;
input Types.ComplexVoltage UStart "Start value of phase-to-phase voltage";
input Types.Angle UPhaseStart "Start value of phase-to-phase voltage angle";
end PowerTerminalAC;
connector PowerTerminalACBus "Base class for bus AC power connector"
extends PowerTerminalACBase;
output Types.ComplexVoltage UStart "Start value of phase-to-phase voltage";
output Types.Angle UPhaseStart "Start value of phase-to-phase voltage angle";
end PowerTerminalACBus;Buses would put their UStart and UPhaseStart parameter values on the power connector, and this would be received by all connected components to set their corresponding fixed = false UStart and UPhaseStart parameter values via initial equations.
Of course we would need to define OnePortAC base class, and a OnePortACBus base class, which differ from this point of view only.
The good news is that all this trickery will be confined to the OnePortAC, OnePortACBus and TwoPortAC classes. Users defining new components just need to extend from one of them, and simply add their model's specific equations. So, from the user's point of view, there's only the added benefit of not needing to worry about start values of voltages except in buses. The only drawback is that buses become compulsory, but since power engineers put them there all the time anyway, that's no big deal.
It goes without saying that PStart and QStart will always have to be provided in all components except buses (where they are structurally equal to zero). This involves some redundancy when only two components are connected through a bus, since their respected PStart and QStart values are the same, except for the sign. However, I see no simple way to avoid the need to provide them both.
AndreaBartolini
ceraolo
In general the
UStartvalue (default =UNom) and theUPhaseStartvalue (default = 0) should be set by the user in every component of the network based on the results of the initial power flow problem. This creates a redundancy because in case of connected components theUStartis the same for all of that. One possibility to solve this redundancy is to use buses to connect the components and to propagate theUStartvalue from theBusto the components connected to it, by adding input/output variables to terminalAC. This has been partially discussed in the issue #49 (last 14 comments), the discussion is moved here because it is an extension of the original issue and the implementation of the solution is independent from the one necesary to close the #49.