Anchor NetworkModel to a declared network source - #152
Conversation
The source pinned a machine-local path that no longer exists, so the environment could not resolve. `main` is not a usable target either: the `AbstractNetworkSource` anchor this branch builds on is not on it. Pin the branch carrying that anchor (Sienna-Platform/InfrastructureOptimizationModels.jl#152) until it merges.
|
Performance Results This branch |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
| reduction_exceptions = Int[], | ||
| duals = Vector{DataType}(), | ||
| evaluations = EvaluationContainer(), | ||
| hvdc_network_model = nothing, |
There was a problem hiding this comment.
Passing the hvdc_network_model is domain specific and doesn't belong in IOM
There was a problem hiding this comment.
This is TBD to be removed
There was a problem hiding this comment.
There is already an open issue for this so it can be tracked and addressed moving forward: #144
| """ | ||
| The network matrix derived during instantiation. Implemented in the matrix-aware | ||
| downstream package, which owns the concrete `AbstractNetworkData`. | ||
| """ | ||
| function get_network_matrix end | ||
|
|
||
| """The contingency matrix derived during instantiation. Implemented downstream.""" | ||
| function get_contingency_matrix end | ||
|
|
||
| """The network reduction derived during instantiation. Implemented downstream.""" | ||
| function get_network_reduction end | ||
|
|
There was a problem hiding this comment.
What is the purpose of defining these in IOM and implementing them downstream in POM? I'm guessing there is a reason but want to understand.
There was a problem hiding this comment.
I think this is because these are methods defined for network model. I think that NetworkModel still has pending work to see how it would generalize to infrastructure networks.
`NetworkModel` previously had no way to say where its network comes from, so consumers reached for whichever matrix they had and could end up building a model whose matrices disagreed about the reduction. Add an `AbstractNetworkSource` field with a `DefaultNetworkSource` default, plus `get_network_source`, so a template declares the network once and the build resolves every matrix from it. Downstream packages supply the concrete sources: PowerOperationsModels adds `NetworkReductionSpec`, `PrebuiltMatrixSource` and `PrebuiltCoreSource` on top of this abstract.
7f75ae1 to
12e0acf
Compare
IS4's own [sources] pin for this unregistered dependency is ignored once InfrastructureSystems is a dependency rather than the root project, so Pkg.instantiate fails to resolve it here without a matching pin.
The source pinned a machine-local path that no longer exists, so the environment could not resolve. `main` is not a usable target either: the `AbstractNetworkSource` anchor this branch builds on is not on it. Pin the branch carrying that anchor (Sienna-Platform/InfrastructureOptimizationModels.jl#152) until it merges.
What
Adds an
AbstractNetworkSourcefield toNetworkModel, defaulting toDefaultNetworkSource(), plus aget_network_sourceaccessor.Why
NetworkModelhad no way to declare where its network comes from. Consumers reached for whichever matrix they happened to hold, so a build could end up with matrices that disagreed about which reduction had been applied.With the source declared on the template, the build resolves every matrix from one declaration — one Ybus per build, therefore one reduction, and derived matrices agree by construction.
Scope
This PR adds only the neutral abstract and the field. The concrete sources are domain-specific and live downstream in PowerOperationsModels (
NetworkReductionSpec,PrebuiltMatrixSource,PrebuiltCoreSource), which subtypes this abstract.