I want to document this approach to implement a general (e.g. non-local) form of control by defining a custom PowerGrid type.
The point is that the vertex (and edge) functions in NetworkDynamics cannot access the state vector for other components. Hence, the controller here is a wrapper around the rhs that has access to
the full state vector u. The result is then passed via the parameter field.
This functionality can be easily added, although it will probably deprecate when NetworkDynamics offers multilayer support (?).
In Any case, I think it's a good idea to document the process of defining custom grids in the official docs.
struct ControlledPowerGrid <: AbstractPowerGrid
graph:: G where G <: AbstractGraph
nodes
lines
controller # oop function
end
# Constructor
function ControlledPowerGrid(control, pg::PowerGrid, args...)
ControlledPowerGrid(pg.graph, pg.nodes, pg.lines, (u, p, t) -> control(u, p, t, args...))
end
#rhs
function rhs(cpg::ControlledPowerGrid)
open_loop_dyn = PowerGrid(cpg.graph, cpg.nodes, cpg.lines) |> rhs
function cpg_rhs!(du, u, p, t)
# Get controller state
control_output = cpg.controller(u, p, t)
# Calculate the derivatives, passing the controller state through
open_loop_dyn(du, u, control_output, t)
end
ODEFunction{true}(cpg_rhs!, mass_matrix=open_loop_dyn.mass_matrix, syms=open_loop_dyn.syms)
end
For many methods, e.g. systemsize, the type doesn't matter as long as we keep the same fields as the PowerGrid type. Hence, it might make sense to dispatch on an AbstractPowerGrid to allow more flexibility without manually extending lot's of methods.
I want to document this approach to implement a general (e.g. non-local) form of control by defining a custom
PowerGridtype.The point is that the vertex (and edge) functions in NetworkDynamics cannot access the state vector for other components. Hence, the controller here is a wrapper around the
rhsthat has access tothe full state vector
u. The result is then passed via the parameter field.This functionality can be easily added, although it will probably deprecate when NetworkDynamics offers multilayer support (?).
In Any case, I think it's a good idea to document the process of defining custom grids in the official docs.
For many methods, e.g.
systemsize, the type doesn't matter as long as we keep the same fields as thePowerGridtype. Hence, it might make sense to dispatch on anAbstractPowerGridto allow more flexibility without manually extending lot's of methods.