Skip to content

Add FlowSign trait for variable directionality#98

Open
luke-kiernan wants to merge 2 commits into
ac/psi-costexp-parambroad-pfslackfrom
lk/flow-sign-trait
Open

Add FlowSign trait for variable directionality#98
luke-kiernan wants to merge 2 commits into
ac/psi-costexp-parambroad-pfslackfrom
lk/flow-sign-trait

Conversation

@luke-kiernan
Copy link
Copy Markdown
Collaborator

Cleanup get_variable_multiplier. Stacked on top of #97 for convenience, but I'd just merge #97 first, then this.

Holy-traits style: `flow_sign(V)` returns Injection/Withdrawal/Unsigned;
`multiplier_from_sign` resolves ±1.0 via dispatch. Lets POM derive most
power-balance multipliers from the variable type alone.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a flow-direction “trait” layer to encode the sign convention (injection vs withdrawal) associated with variable types, aiming to replace scattered sign/multiplier overrides and centralize directionality logic.

Changes:

  • Introduces FlowSign trait types (Injection, Withdrawal, Unsigned) plus flow_sign and multiplier_from_sign helpers.
  • Defines default and standard mappings for active power variable types.
  • Removes an outdated “not included” note from rate-of-change constraints.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File Description
src/InfrastructureOptimizationModels.jl Exports the new flow-direction trait API.
src/core/standard_variables_expressions.jl Defines FlowSign trait types, default behavior, and mappings for standard power variables.
src/common_models/rateofchange_constraints.jl Removes an obsolete header note.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +55 to +64
struct Unsigned <: FlowSign end

# Default: no directional meaning attached to the variable type.
flow_sign(::Type{<:VariableType}) = Unsigned

multiplier_from_sign(::Type{Injection}) = 1.0
multiplier_from_sign(::Type{Withdrawal}) = -1.0
# Variables without flow semantics (OnVariable, StartVariable, ...) keep the
# legacy 1.0 default so callers that don't care about sign still work.
multiplier_from_sign(::Type{Unsigned}) = 1.0
Comment thread src/InfrastructureOptimizationModels.jl Outdated
export RateofChangeConstraintSlackUp, RateofChangeConstraintSlackDown
export DCVoltage
# Flow-direction trait for variable types
export FlowSign, Injection, Withdrawal, Unsigned
Comment on lines +57 to +69
# Default: no directional meaning attached to the variable type.
flow_sign(::Type{<:VariableType}) = Unsigned

multiplier_from_sign(::Type{Injection}) = 1.0
multiplier_from_sign(::Type{Withdrawal}) = -1.0
# Variables without flow semantics (OnVariable, StartVariable, ...) keep the
# legacy 1.0 default so callers that don't care about sign still work.
multiplier_from_sign(::Type{Unsigned}) = 1.0

# Standard variable types defined here:
flow_sign(::Type{ActivePowerVariable}) = Injection
flow_sign(::Type{ActivePowerInVariable}) = Withdrawal
flow_sign(::Type{ActivePowerOutVariable}) = Injection
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 12, 2026

Performance Results
Main


This branch


Address Copilot review on #98: rename Injection/Withdrawal/Unsigned to
FlowInjection/FlowWithdrawal/FlowUndirected to avoid the name clash with
Base.Unsigned and reduce ambiguity for downstream `using` consumers. Add
test/test_flow_sign.jl covering defaults, standard mappings, and
multiplier roundtrip.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jd-lara
Copy link
Copy Markdown
Member

jd-lara commented May 18, 2026

Flows and injection directions aren't the same ... I am not sure this design is sound

@luke-kiernan
Copy link
Copy Markdown
Collaborator Author

Flows and injection directions aren't the same ... I am not sure this design is sound

Is there some other name you'd suggest?

Goals here were:

  1. More readible than get_[objective]_multipier
  2. Less definition spam: provide defaults on abstract classes then handle edge cases, instead of just slapping a definition on every single component just in case.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants