You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
resource_family for the resource segmentation #106
Problem.res_types_vec(𝒫) segments the resources by concrete type, and the resource-specific functions (variables_flow_resource, constraints_resource, constraints_couple_resource, also their counterparts in EnergyModelsGeography) are called once per segment. An extension package with a family of resource types, say AbstractElectricPower with one concrete type per power-flow formulation, registers its JuMP variables (reactive power, voltage magnitude) inside these calls. A name can be registered once per model, so a case can contain a single concrete type of the family. Mixed cases, for instance a transmission resource with one formulation coupled to a distribution resource with another through a transformer node, are impossible without name mangling per type.
The package sets resource_family(::AbstractElectricPower) = AbstractElectricPower, receives all its resources in one call, creates each variable once over the union and dispatches on the concrete types internally.
Why non-breaking. The default returns the concrete type, so the segments are exactly the ones of today. Only packages that define the trait see a difference, and only for their own resources. The three call sites in EnergyModelsBase and the four in EnergyModelsGeography do not change.
Tests. Two resource types with a common family return one segment typed with the family; types without the trait keep separate segments.
Seems reasonable to me. In practice, we replace typeof in res_types with the new function.
Just implement it directly in a separate branch and PR, different from #105 and #107. At least to me, it looks as if it is related, but deserves its own commit.
Activity
JulStraus commentedon Oct 7, 2026
Seems reasonable to me. In practice, we replace
typeofinres_typeswith the new function.Just implement it directly in a separate branch and PR, different from #105 and #107. At least to me, it looks as if it is related, but deserves its own commit.