enerdatasynth generates synthetic energy-resource profiles — electric load and wind — from trained conditional generative models, behind one shared Python interface. You describe the conditions (season, temperature, calendar type); it returns a realistic profile.

Generators

Two resources, one interface: enerdatasynth.model(<name>, zone=...) works the same way for both, regardless of what's running underneath.

PJM Electric Load

Conditional diffusion model for 24-hour PJM load profiles (zone PS), conditioned on month, day-of-week, holiday, and temperature. → PJM Load model report

Wind

Conditional diffusion model for 24-hour (5-minute resolution) wind profiles across three channel presets (1ch/2ch/3ch), conditioned on calendar, temperature, and wind regime. → Wind model report

Quick Start

pip install enerdatasynth

import enerdatasynth

load = enerdatasynth.model("pjm_load", zone="PS")
load.set(month=7, Tmax=86, Tmin=70, weekday=True)
samples = load.sample(n=100, seed=0)     # (100, 24) ndarray, MW

wind = enerdatasynth.model("wind", zone="1ch")
wind.set(wind_regime="mid", month=7, temp_min=10, temp_max=22)
samples = wind.sample(n=10, seed=0)      # (10, 288, 2) ndarray, m/s + degrees — wind sampling is CPU-slow at large n, see docs/models/wind.md

pip install enerdatasynth installs the library only — it does not ship trained checkpoints or data. The example above works as-is if you clone this repository and run from its root (checkpoints are bundled); see docs/installation.md for every install path and docs/quickstart.md for training your own checkpoint from scratch. Note: the version on PyPI today (0.4.1) predates this repository's wind support; install from source for wind.

How It Works

data → conditioning → generative model → synthetic profile → evaluation

Raw data is cleaned and reduced to a conditioning vector (calendar + weather). A conditional diffusion model — a separate, independently-implemented pipeline per resource, since load and wind differ too much scientifically to share one — denoises pure noise into a profile matching that conditioning. Generated profiles are compared against real ones using a metric suite (resource-specific — the two are not the same suite), and — for load — a small post-hoc bias correction. The pipeline differs by resource; the interface you call does not. Full technical detail (architectures, sampling, conditioning schemas, and exactly why the two pipelines differ) lives in the architecture docs and the two model reports, not here.

Model Reports

Each resource has a model report documenting its input data, representation, conditioning, architecture, generative model, training, evaluation, quantitative results, real-vs-generated examples, and known limitations:

• PJM Load Model Report
• Wind Model Report

These reports are the primary scientific documentation for this project — start there for anything beyond basic usage.

Documentation

Full documentation map: docs/README.md.

Data & Reproducibility

No raw or source data is distributed with this package or repository — it ships trained checkpoints and the generation interface, not the datasets behind them.

PJM load's cleaning, conditioning, and reproduction steps are fully documented in its model report and data card; bring your own copy of the source data to data/raw/pjm_load/ to reproduce preprocessing end-to-end (see the placeholder file there). Wind currently has no raw data or reproduction path in this repository at all — its report says so directly. There is no separate public data archive (e.g. Zenodo) for this project today.

Citation

No accompanying paper has been published yet. If you use this software, please cite the repository:

@software{enerdatasynth,
  title  = {enerdatasynth: A Research SDK for Synthetic PJM Energy Resource Profiles},
  author = {Sharma, Sonakshi and Tikkawar, Pranav and Mieth, Robert},
  year   = {2026},
  note   = {Software}
}

License

MIT © 2026 Sonakshi Sharma