Skip to content

Richer scenario components #3

@jaywonchung

Description

@jaywonchung

Today the build-a-simulation form likely covers a feeder + a single model. openg2g supports more: replica ramps, training overlays (multi-thousand-GPU training jobs), PV systems, time-varying loads, multi-DC topologies. The paper figures all rely on these. Without them in the form, every simulation looks the same.

This is groundwork for #4: users can't poke a running simulation interactively if they can't even configure an interesting one to begin with.

Components to expose

Each of these is an openg2g class. The form should let the user add zero-or-more of each.

  • Replica ramps (ReplicaSchedule). Model replicas scaling up or down over a window.
  • Training overlay (TrainingRun). A separate multi-thousand-GPU training workload overlaid on inference.
  • PV systems (PVSystemSpec). Solar generators at specified buses.
  • Time-varying loads (TimeVaryingLoadSpec). Non-datacenter loads with shapes like morning ramp, midday dip, etc.
  • Multiple datacenters. Per-DC bus assignment and model deployment. Only meaningful on ieee34 (2 DC) and ieee123 (4 DC).

OpenG2G's examples/rl_controller/scenarios.py should be a good reference that shows you the breadth of scenario components. The ieee13_experiment / ieee34_experiment / ieee123_experiment factories build these exact components from a config.

Implementation

  1. Define a pydantic ScenarioConfig with one optional field per component above.
  2. Frontend: one "+ Add" card per component type. Each card opens a small form for the parameters. Added components show as removable cards.
  3. Backend builder: given a ScenarioConfig, construct the dc_sites / pv_systems / time_varying_loads / training_base that feed into Coordinator.
  4. Provide one preset per feeder ("IEEE 13 default", a paper scenario). Users edit from there.

Frontend

Making the frontend good is non-trivial. Ideally, frontend interactive elements should reflect the nature of the scenario component.

I can imagine something like this.

  • There's an inventory box (looks like a plot legend box) where each element is an icon + label.
  • The user can click on an icon and drag it towards the grid visualization. The icon will get copied as it gets dragged, and the user can drop the icon onto the grid bus.
  • Upon drop (mouse click release), a configuration window pops up with defaults populated, and the user can adjust configs.
  • Whenever a component dropped onto the grid visualization is hovered, what it is and current config values will show up as a tooltip.
  • Replica schedule could be a plot (X = time, Y = num replicas) that can be tweaked with mouse; training overlay can be similar but draggable over a timeline to configure duration. Before thinking about how to implement it, imagine the best possible interactive interface.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions