[FEATURE] Controller

[kornerc]

Describe the feature request

Idea

Some power flow solvers support the concept of controllers.
The idea is to have algorithms which run iteratively and adjust parameters of certain elements.
An example would be a controller which adjusts the tapping of an OLTC based on a remote voltage measurement, a Q(U)-controller, feeder-load scaling (scale certain loads in a feeder such that the power flow at the beginning of the feeder is accordingly to a measurement).

The iterative approach is divided into inner and outer loops.

• Inner loops are classical Newton-Raphson load flow iterations
• Outer loops are iterations where algorithms adjust parameters without rerunning the power flow

pandapower has a nice drawing of the concept (reference)

In principal this functionality could be directly internally implemented in the C++ core like it was done for the automatic tap changer.
However, it would be convinient if users can provide their own control-algorithms without touching the C++ core.

In my opinion it would be good if:

• the control loop is implemented in the C++ core
• algorithms can either be provided in
  • C (or C++): fast execution speed
  • Python: fast prototyping and experimentation

pandapower

pandapower has a tutorial how such a controller is implemented.

PowerFactory

DIgSILENT PowerFactory has its own programming language QDSL (Quasi-Dynamic Simulation Language) to model controllers. Example

Assign QDSL model to an element

Parameters

IOs

Model implementation

double u;

u = 1.;
SOC = SOCini;
SOCnext = SOC;
limitP = 0;

!Get the step size of the QDS
timeDif = GetStepSizeSeconds();

! voltage operation area
if ({uFullStore <= uStartStore}.or.{uStartFeed <= uFullFeed}) {
  chargeU = 0;  ! Error
  Warn('uFullStore must be > than uStartStore and uStartFeed > than uFullFeed');
}
else if (u < uStartFeed) {
  chargeU = 3;
}
else if (u > uStartStore) {
  chargeU = 1;
}
else {
  chargeU = 2;
}

! energy operation area
iniSOCoob = 0; ! Inside bounds
if (SOCmin >= SOCmax) {
  chargeE = 0;  ! Error
  Warn('SOCmin must be < than SOCmax.');  
}
else if (SOC > SOCmax) {
  chargeE = 3;
  iniSOCoob = 1;
}
else if (SOC = SOCmax) {
  chargeE = 3;
}
else if (SOC = SOCmin) {
  chargeE = 1;
}
else if (SOC < SOCmin) {
  chargeE = 1;
  iniSOCoob = 1;
}
else {
  chargeE = 2;
}

Summary

• Are controllers a concept which should/could be supported by PGM in the longer run and is there prinzipal interest?
• The description in this issue is not exhaustive. Open points, among others, are
  • serialization/deserialization of controllers
  • API
  • how should state be handled
  • convergence detection

[petersalemink95]

@kornerc interesting proposal! I added it to our roadmap. Note that the estimated quarter will probably change along the way. Anyone could pick this up earlier if this person would like to contribute this to the project :)