Bug with "/" in device names

[m-bossart]

This is a bug in reading simulation results due to a component name with "/" which is incompatible with the hdf5 specification. We can either restrict components to not have names with "/" when parsing or do some checks before simulation.

MWE:

using PowerSystemCaseBuilder
using HiGHS
using PowerSimulations
using PowerSystems

c_sys5_uc = build_system(PSITestSystems, "c_sys5_uc"; add_reserves = true)
interface = TransmissionInterface(;
    name = "E/W",   # Fails due to "/" in the name 
    available = true,
    active_power_flow_limits = (min = 0.0, max = 400.0),
)
interface_lines = [
    get_component(Line, c_sys5_uc, "1"),
    get_component(Line, c_sys5_uc, "2"),
    get_component(Line, c_sys5_uc, "6"),
]
add_service!(c_sys5_uc, interface, interface_lines)

template = ProblemTemplate(PTDFPowerModel)
set_device_model!(template, ThermalStandard, ThermalBasicDispatch)
set_device_model!(template, PowerLoad, StaticPowerLoad)
set_device_model!(template, MonitoredLine, StaticBranchBounds)
set_device_model!(template, Line, StaticBranch)
set_device_model!(template, Transformer2W, StaticBranch)
set_device_model!(template, TapTransformer, StaticBranch)
set_device_model!(template, TwoTerminalGenericHVDCLine, HVDCTwoTerminalLossless)
set_service_model!(
    template,
    ServiceModel(TransmissionInterface, ConstantMaxInterfaceFlow; use_slacks = true),
)
solver = optimizer_with_attributes(
    HiGHS.Optimizer,
)
models = SimulationModels(;
    decision_models = [
        DecisionModel(
            template,
            c_sys5_uc;
            optimizer = solver,
            name = "UC",
            optimizer_solve_log_print = true,
        ),
    ],
)
DA_sequence = SimulationSequence(;
    models = models,
    ini_cond_chronology = InterProblemChronology(),
)
dir_name = mktempdir(cleanup = true)
sim = Simulation(;
    name = "ti-key-test",
    steps = 2,
    models = models,
    sequence = DA_sequence,
    simulation_folder = dir_name,
)
build!(sim)
execute!(sim; in_memory = false, enable_progress_bar = true)

res = SimulationResults(dir_name)   #Deserializing the results from hdf5 fails 

[daniel-thom]

Root Cause

When PowerSimulations stores simulation results in HDF5, each optimization container key is encoded into an HDF5 dataset name via encode_key_as_string. For service-related variables, the service instance name (e.g., "E/W" for a TransmissionInterface) is stored in the key's meta field, which gets concatenated into the dataset name:

InterfaceFlowSlackDown__TransmissionInterface__E/W

HDF5 uses / as a path separator in its hierarchical group/dataset structure. When this string is used as a dataset name, HDF5 interprets the / as a path separator, creating a nested group InterfaceFlowSlackDown__TransmissionInterface__E with a child dataset W instead of a single flat dataset.

On deserialization (hdf_simulation_store.jl:859), the code iterates over keys(group) expecting flat dataset names and tries to find a companion __columns dataset by appending __columns to the name. The lookup fails because the structure was silently split by the /, producing the KeyError.

Fix Options

1. Restrict component names in PowerSystems.jl — Disallow / (and potentially other HDF5-unsafe characters) during component construction or parsing.
2. Sanitize the encoded key in PowerSimulations.jl — Replace / with a safe token (e.g., SLASH) before writing to HDF5, and reverse the substitution on read.

[daniel-thom]

@jd-lara @m-bossart Let me know how you'd like to proceed.

[jd-lara]

@jd-lara @m-bossart Let me know how you'd like to proceed.

I am ok with 1. I feel it isn't that problematic since we have never hit it

[daniel-thom]

To be clear, this is exclusively a services problem. That is the only case where a component name gets put into an HDF5 dataset. Do we really want to risk breaking users? Another option is to prohibit the slash for services but not other components. I don't love the idea because it will seem odd to users. A simple rule for all components is better.

[m-bossart]

@jd-lara @m-bossart Let me know how you'd like to proceed.

I am ok with 1. I feel it isn't that problematic since we have never hit it

It is possible that users have datasets with these names for services, but have never actually deserialized a simulation store with them formulated. But I agree that 1 is ok and is the cleanest solution moving forward