draft: start work on solution inspection tools #123
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the start of a new "solution inspection" interface which will be the base for a not-yet-relased package for interactive inspection of NetworkDynamic (and eventually PowerDynamics) solutions. Hopefully, this interface is also usefull for all sorts of solution inspection.
Goals
The main goal of this interface is to be extensible behind the "normal" ode states, so it should also support
Interface
Currently, the interface works as follows:
returns a function, which, applyed to
t
(such asu_r_f(1.0)
oru_r_f(0:0.1:10)
) returns the value of stateu_r
of vertex17
in the solutionsol
usingp
. There is also an option to get several parameters at once likenot yet implemented but also planned is to get the same state for several nodes.
which makes sense performance wise because we only need to evalue the rhs of the DGL once per timestep.
"derived" states
Quite often when dealing with powergrids i find myself recalculating the same derived states again and again. Now it is possible to define "virtual" as algebraic functions of other states such as
will allows to generate a timseries for
:u_mag
directly. Even bettermatches every symbol with ends with
_arg
so you will be able to generate argument timeseries for every pair of complex cart coordinates. Those definitions can depend on eachotherwould allow direct access to
S
,Q
andP
for every node.There is also an even more low level interface which, for example, can be used to
:_i_r
and:_i_i
:_ω
based of the stored derivateives ofu_r
andu_i
in the solution object"observed" states
Not yet implemented in the prototype. The vertex and edge objects need two new fields:
observed_sym
andobserved_f
. Theobserved_f
will be a functionf(u, edges, p, t)
which returns all the observed states for a given statevector. Should be nonbreaking, since those can be allways empty. For vertex and edge functions generated using BlockSystems/MTK this has the advantage of plotting arbtrary internal states using the same interface.Remarks on parameters
Often,
p
will change during the simulations in a callback. For direct states and states which are derived from normal states this isn't a problem. However, if one wants to calculate observed states (or static edge states for that matter) it is necessary to provide the correct parameters for each time. This information is not stored in the solution object. In that PR you can usewhich keeps track of parameter changes to replay them later.