Skip to content

resource_family for the resource segmentation #106

Description

@espenbodal

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.

Proposal.

resource_family(p::Resource) = typeof(p)
res_types(𝒫)     = unique(map(resource_family, 𝒫))
res_types_vec(𝒫) = [Vector{rt}(filter(x -> resource_family(x) == rt, 𝒫)) for rt ∈ res_types(𝒫)]

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.

Activity

  1. self-assigned this
    on Oct 7, 2026
  2. JulStraus commented on Oct 7, 2026

    @JulStraus
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions