Skip to content

Make "mode" a Enum#738

Open
dad616610 wants to merge 5 commits intoe2nIEE:developfrom
dad616610:feat_mode_as_enum
Open

Make "mode" a Enum#738
dad616610 wants to merge 5 commits intoe2nIEE:developfrom
dad616610:feat_mode_as_enum

Conversation

@dad616610
Copy link
Contributor

Summary

This PR introduces an Enum class SimMode to replace raw string representations of simulation modes, providing better type safety and developer experience. Additionally, it identifies and implements a new PhysDomain concept to distinguish between simulation modes and physical domains.

Key Changes

  1. Added SimMode Enum:
    class SimMode(Enum):
        HYD = "hydraulics"       # Hydraulic simulation
        HEAT = "heat"             # Thermal simulation
        SEQ = "sequential"        # Sequential coupled simulation
        BIDIR = "bidirectional"   # Bidirectional coupled simulation
    • Replaces raw strings throughout the codebase
    • Provides autocompletion and prevents typos
    • Centralizes mode definitions
  2. Added PhysDomain Enum:
    class PhysDomain(Enum):
        HYD = "hydraulics"        # Hydraulic results domain
        HEAT = "heat_transfer"    # Thermal results domain
    • Separates simulation method from physical domain
    • Clarifies previously ambiguous "mode" concept
  3. API Improvements:
    • Renamed internal mode parameters to sim_mode for clarity
    • Backward compatibility maintained: Users can still call pipeflow(net, mode="hydraulics")
    • Updated function documentation throughout affected modules
  4. Documentation:
    • Updated docstrings for all modified functions
    • Added explanations for new enums in relevant modules

Why Enums?

  • IDE Support: Auto-completion and discoverability
  • Safety: Eliminates string typos in mode specifications
  • Maintainability: All modes defined in single location
  • Clarity: Explicit separation of simulation method vs physical domain

Pending Items (Future PRs)

  • Updating test cases to use new enums (current tests unchanged to limit scope)

Feedback Requested

Naming Concerns

I'm uncertain if these names are optimal. Please suggest alternatives:

  • SimModeCalcMode?
  • PhysDomainResultMode?
  • Is PhysDomain concept actually needed?

The renaming is trivial, so please don't feel burdened by suggesting your preferences!

Import Concert

Currently enums are imported as:

from pandapipes.enums import SimMode

But would this be more user-friendly?

from pandapipes import SimMode  # Direct top-level import

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.

1 participant