From 72dd781dbc9342d98bb061576e72d58e8405de46 Mon Sep 17 00:00:00 2001 From: pepe Date: Sat, 25 Jul 2026 21:20:33 -0700 Subject: [PATCH] Organize documentation into docs/ and superseded/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Audit every document in the repository, convert the non-markdown ones into markdown reports, and split current documentation from outdated material. docs/ — 31 markdown documents in seven numbered sections. Twenty are new reports generated from .docx / .pdf / .xlsx / .mlx / .m sources that were previously unreadable in the browser and undiffable in git. Each report carries a provenance block (source path, format, MD5) and links back to its original; all 13 recorded checksums verify against the files on disk. Machine-extraction losses (PDF table column interleaving, Word OMML equations, embedded figures) are called out explicitly rather than silently smoothed over. superseded/ — outdated material with a documented reason per entry: two byte-identical ClickUp re-exports, an older revision of the BIDMC/UCSD energy-flow doc (the retained copy adds the SoC Violation Rate KPI), a duplicate of Shift input data.docx, the May 2026 simulation plan, the root PV+Battery.md now covered by a fuller report, GitHub's stock demo-repository template, and a zero-byte placeholder. Its README also records what was deliberately NOT retired and why — the "Old Frameworks" and "Old Simulations" folders hold unique Simulink revisions, and "Big Ugly Folder" holds the only copy of framework revision 1.3. Findings worth flagging, all documented in the reports: - Simulink lineage recovered from each .slx's internal coreProperties.xml revision counter. The current model is Current Framework/Bobert0206_Initial_Simulation_Framework.slx (rev 2.7); the top-level copy is rev 1.3, five revisions behind. - Simulations/Constants.m is a truncated byte-prefix of the Current Framework copy, silently missing H2_leak, H2_cap and E_H2_vol_h. - The PEM electrolyser and fuel cell are unmodified MathWorks Simscape examples still at vendor defaults; the "10x bigger" sizing TODO recorded in Constants.m was never carried out. - controller-claude.m does not compile — undefined P_Electro_max, outputs unassigned on several paths. - The specification set uses two incompatible variable naming conventions and disagrees on action-space size (5 vs 16). - MA_hourly_load.csv (13.7 MB) is the same 35,040 rows as 89993-0.parquet (2.4 MB). - Clinical data is the MIMIC-IV *demo* (ODbL, 100 patients), not full MIMIC-IV — redistributable, but the licence and citation are unrecorded. Housekeeping: untrack 21 Simulink build artefacts (slprj/, *.slxc) and add ignore rules for them. Root README rewritten around the new layout. Recruitment notes naming individual candidates are excluded from version control via .gitignore rather than committed; the generic question template is kept in docs/07-team-and-operations/. Co-Authored-By: Claude Opus 5 --- .gitignore | 9 +- README.md | 110 ++++-- .../PEMElectrolysisSystem.slxc | Bin 5777 -> 0 bytes .../Big Ugly Folder/PEMFuelCellSystem.slxc | Bin 6001 -> 0 bytes .../PEMElectrolysisSystem/checksumOfCache.mat | Bin 392 -> 0 bytes .../tmwinternal/simulink_cache.xml | 6 - .../PEMElectrolysisSystem/varInfo.mat | Bin 16008 -> 0 bytes .../PEMFuelCellSystem/checksumOfCache.mat | Bin 392 -> 0 bytes .../tmwinternal/simulink_cache.xml | 6 - .../varcache/PEMFuelCellSystem/varInfo.mat | Bin 21008 -> 0 bytes .../PV+Battery Simulink/SolarPanel.slxc | Bin 5141 -> 0 bytes .../varcache/SolarPanel/checksumOfCache.mat | Bin 392 -> 0 bytes .../SolarPanel/tmwinternal/simulink_cache.xml | 6 - .../slprj/sim/varcache/SolarPanel/varInfo.mat | Bin 1720 -> 0 bytes .../PEMElectrolysisSystem.slxc | Bin 5777 -> 0 bytes .../PEMElectrolysisSystem/checksumOfCache.mat | Bin 392 -> 0 bytes .../tmwinternal/simulink_cache.xml | 6 - .../PEMElectrolysisSystem/varInfo.mat | Bin 16008 -> 0 bytes .../PEMElectrolysisSystem.slxc | Bin 5779 -> 0 bytes .../PEMFuelCellSystem.slxc | Bin 6001 -> 0 bytes .../PEMFuelCellSystem/checksumOfCache.mat | Bin 392 -> 0 bytes .../tmwinternal/simulink_cache.xml | 6 - .../varcache/PEMFuelCellSystem/varInfo.mat | Bin 21008 -> 0 bytes docs/01-project/ai-efficiency-improvements.md | 37 ++ docs/01-project/project-explanation.md | 166 +++++++++ docs/01-project/reference-links.md | 9 + docs/01-project/work-packages.md | 30 ++ .../forecasting-requirements.md | 252 ++++++++++++++ docs/02-specifications/rl-action-variables.md | 111 ++++++ docs/02-specifications/rl-reward-function.md | 128 +++++++ docs/02-specifications/rl-state-variables.md | 128 +++++++ .../rule-based-controller.md | 205 +++++++++++ .../simulator-io-interface.md | 320 ++++++++++++++++++ .../bidmc-datasets-manual.md | 221 ++++++++++++ .../bidmc-digital-twin-readiness-checklist.md | 222 ++++++++++++ .../bidmc-parquet-load-data-manual.md | 164 +++++++++ .../bidmc-ucsd-energy-flow-and-balances.md | 224 ++++++++++++ .../pv-hourly-dataset-manual.md | 84 +++++ .../satellite-pv-dataset-manual.md | 110 ++++++ .../ucsd-equipment-manual.md | 175 ++++++++++ docs/04-simulations/existing-est-model.md | 240 +++++++++++++ .../generation-profiles-workbook.md | 267 +++++++++++++++ docs/04-simulations/matlab-live-scripts.md | 198 +++++++++++ .../pem-electrolyser-and-fuel-cell-models.md | 281 +++++++++++++++ docs/04-simulations/powerworld-microgrid.md | 102 ++++++ docs/04-simulations/pv-battery-simulink.md | 148 ++++++++ .../rule-based-controller-implementation.md | 213 ++++++++++++ docs/04-simulations/shift-input-data.md | 163 +++++++++ .../simulink-model-inventory.md | 300 ++++++++++++++++ docs/05-business-economics/cost-analysis.md | 153 +++++++++ .../social-cost-benefit-analysis.md | 86 +++++ docs/06-data/dataset-inventory.md | 234 +++++++++++++ .../interview-questions.md | 29 ++ docs/07-team-and-operations/team-design.md | 15 + docs/README.md | 181 ++++++++++ .../ACTION VARIABLES AND DESCRIPTIONS.docx | Bin 0 -> 16223 bytes .../_originals/Forecasting requirements.pdf | Bin ... FUNCTION COMPONENTS AND DESCRIPTIONS.docx | Bin 0 -> 17020 bytes .../STATE VARIABLES AND DESCRIPTIONS.docx | Bin 0 -> 14711 bytes ...Simulator Interface Input-Output sheet.pdf | Bin ...gy flow and balances (older revision).docx | Bin ...Cost Analysis Excel File-20260725175434.md | 153 +++++++++ ...Y MONTH SIMULATION PLANS-20260725175516.md | 83 +++++ superseded/PV+Battery.md | 22 ++ superseded/README.md | 188 ++++++++++ .../Shift input data (duplicate copy).docx | Bin ...al Cost-Benefit Analysis-20260725174919.md | 86 +++++ .../.github/workflows/auto-assign.yml | 0 .../.github/workflows/proof-html.yml | 0 .../demo-repository}/README.md | 0 .../demo-repository}/index.html | 0 .../demo-repository}/package.json | 0 .../github-profile-photos-temp.md | 0 73 files changed, 5822 insertions(+), 55 deletions(-) delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/PEMElectrolysisSystem.slxc delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/PEMFuelCellSystem.slxc delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/checksumOfCache.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/varInfo.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/checksumOfCache.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/varInfo.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/SolarPanel.slxc delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/checksumOfCache.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/tmwinternal/simulink_cache.xml delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/varInfo.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/PEMElectrolysisSystem.slxc delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/checksumOfCache.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/varInfo.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/PEMElectrolysisSystem.slxc delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/PEMFuelCellSystem.slxc delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/checksumOfCache.mat delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml delete mode 100644 Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/varInfo.mat create mode 100644 docs/01-project/ai-efficiency-improvements.md create mode 100644 docs/01-project/project-explanation.md create mode 100644 docs/01-project/reference-links.md create mode 100644 docs/01-project/work-packages.md create mode 100644 docs/02-specifications/forecasting-requirements.md create mode 100644 docs/02-specifications/rl-action-variables.md create mode 100644 docs/02-specifications/rl-reward-function.md create mode 100644 docs/02-specifications/rl-state-variables.md create mode 100644 docs/02-specifications/rule-based-controller.md create mode 100644 docs/02-specifications/simulator-io-interface.md create mode 100644 docs/03-energy-management/bidmc-datasets-manual.md create mode 100644 docs/03-energy-management/bidmc-digital-twin-readiness-checklist.md create mode 100644 docs/03-energy-management/bidmc-parquet-load-data-manual.md create mode 100644 docs/03-energy-management/bidmc-ucsd-energy-flow-and-balances.md create mode 100644 docs/03-energy-management/pv-hourly-dataset-manual.md create mode 100644 docs/03-energy-management/satellite-pv-dataset-manual.md create mode 100644 docs/03-energy-management/ucsd-equipment-manual.md create mode 100644 docs/04-simulations/existing-est-model.md create mode 100644 docs/04-simulations/generation-profiles-workbook.md create mode 100644 docs/04-simulations/matlab-live-scripts.md create mode 100644 docs/04-simulations/pem-electrolyser-and-fuel-cell-models.md create mode 100644 docs/04-simulations/powerworld-microgrid.md create mode 100644 docs/04-simulations/pv-battery-simulink.md create mode 100644 docs/04-simulations/rule-based-controller-implementation.md create mode 100644 docs/04-simulations/shift-input-data.md create mode 100644 docs/04-simulations/simulink-model-inventory.md create mode 100644 docs/05-business-economics/cost-analysis.md create mode 100644 docs/05-business-economics/social-cost-benefit-analysis.md create mode 100644 docs/06-data/dataset-inventory.md create mode 100644 docs/07-team-and-operations/interview-questions.md create mode 100644 docs/07-team-and-operations/team-design.md create mode 100644 docs/README.md create mode 100644 docs/_originals/ACTION VARIABLES AND DESCRIPTIONS.docx rename Forecasting requirements.pdf => docs/_originals/Forecasting requirements.pdf (100%) create mode 100644 docs/_originals/REWARD FUNCTION COMPONENTS AND DESCRIPTIONS.docx create mode 100644 docs/_originals/STATE VARIABLES AND DESCRIPTIONS.docx rename Simulator Interface Input-Output sheet.pdf => docs/_originals/Simulator Interface Input-Output sheet.pdf (100%) rename Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/BIDCM-UCSD hybrid hospital energy flow and balances.docx => superseded/BIDCM-UCSD hybrid hospital energy flow and balances (older revision).docx (100%) create mode 100644 superseded/Cost Analysis Excel File-20260725175434.md create mode 100644 superseded/MAY MONTH SIMULATION PLANS-20260725175516.md create mode 100644 superseded/PV+Battery.md create mode 100644 superseded/README.md rename Shift Matlab Drive/Shift Matlab Drive/Simulations/Old Simulations/Shift input data.docx => superseded/Shift input data (duplicate copy).docx (100%) create mode 100644 superseded/Social Cost-Benefit Analysis-20260725174919.md rename {demo-repository => superseded/demo-repository}/.github/workflows/auto-assign.yml (100%) rename {demo-repository => superseded/demo-repository}/.github/workflows/proof-html.yml (100%) rename {demo-repository => superseded/demo-repository}/README.md (100%) rename {demo-repository => superseded/demo-repository}/index.html (100%) rename {demo-repository => superseded/demo-repository}/package.json (100%) rename .github/profile/photos/temp.md => superseded/github-profile-photos-temp.md (100%) diff --git a/.gitignore b/.gitignore index a6b2196..a8d57a9 100644 --- a/.gitignore +++ b/.gitignore @@ -13,6 +13,13 @@ ehthumbs.db Desktop.ini .DS_Store -# MATLAB / Simulink autosaves +# MATLAB / Simulink autosaves and build artefacts *.asv *.autosave +slprj/ +*.slxc +*.slx.r20* + +# Personal data — recruitment notes on named candidates. Kept locally, never committed. +# Root-anchored so it cannot catch the generic question template in docs/. +/Interview Questions-*.md diff --git a/README.md b/README.md index acdbc10..7ff918d 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,31 @@ # ALLSHIFT -> Umbrella repository for **Team SHIFT** — an AI-driven hydrogen microgrid energy-management system for hospitals. +> Umbrella repository for **Team SHIFT** — an AI-driven hydrogen microgrid energy-management +> system for hospitals. -ALLSHIFT is the central hub that ties together the team's repositories, models, data, and planning documents. It links the four clusters — **Energy Management**, **Simulations**, **Business & Economics**, and **AI & Control Systems** — under one roof. +ALLSHIFT is the central hub tying together the team's models, data, planning documents, and +repositories. It links the four clusters — **Energy Management**, **Simulations**, +**Business & Economics**, and **AI & Control Systems** — under one roof. + +**→ [Full documentation index](docs/README.md)** ## Mission -Accelerate the transition to resilient, low-carbon energy systems through AI-driven energy management. We develop intelligent control for critical infrastructure that optimizes renewables, storage, hydrogen technologies, and grid interaction — improving reliability, reducing emissions, and increasing efficiency where uninterrupted power matters most. +Accelerate the transition to resilient, low-carbon energy systems through AI-driven energy +management. We develop intelligent control for critical infrastructure that optimizes +renewables, storage, hydrogen technologies, and grid interaction — improving reliability, +reducing emissions, and increasing efficiency where uninterrupted power matters most. -Founded in 2021 at the TU/e Innovation Space and Neuron (Eindhoven). Case studies: Beth Israel Deaconess Medical Center (BIDMC) and UC San Diego (UCSD). +Founded in 2021 at the TU/e Innovation Space and Neuron (Eindhoven). Case studies: Beth Israel +Deaconess Medical Center (BIDMC) and UC San Diego (UCSD). ## The challenge -Hospitals need reliable, uninterrupted power while the grid grows more congested, less predictable, and more weather-dependent. With the Dutch "balancing system" being phased out from 2025, energy returned to the grid is only partially compensated. SHIFT answers with an AI-driven hydrogen microgrid that forecasts hospital demand, optimizes solar and battery use, and controls electrolyzers and fuel cells so every component runs at its full potential. +Hospitals need reliable, uninterrupted power while the grid grows more congested, less +predictable, and more weather-dependent. With the Dutch "balancing system" being phased out +from 2025, energy returned to the grid is only partially compensated. SHIFT answers with an +AI-driven hydrogen microgrid that forecasts hospital demand, optimizes solar and battery use, +and controls electrolyzers and fuel cells so every component runs at its full potential. ## System architecture @@ -28,37 +41,86 @@ Forecasters ──► Simulator (Gym-style env) ──► RL / rule-based contro Business & Economics analysis ``` -**Dispatch priority cascade:** PV → battery → hydrogen (fuel cell discharge / electrolyser charge) → external grid. Critical hospital load is always prioritised ("critical load is sacred"). +**Dispatch priority cascade:** PV → battery → hydrogen (fuel cell discharge / electrolyser +charge) → external grid. Critical hospital load is always prioritised — *"critical load is +sacred"*. -## Repositories +## Repository layout + +``` +ALLSHIFT/ +├── docs/ ← all current documentation, in markdown +│ ├── 01-project/ vision, work packages, efficiency targets +│ ├── 02-specifications/ simulator contract, RL state/action/reward, forecasting +│ ├── 03-energy-management/ BIDMC & UCSD case studies, datasets, equipment +│ ├── 04-simulations/ Simulink models, controller, PEM models, PowerWorld +│ ├── 05-business-economics/ cost parameter register, SCBA methodology +│ ├── 06-data/ dataset inventory +│ ├── 07-team-and-operations/ +│ └── _originals/ the .docx / .pdf sources for root-level reports +├── superseded/ ← outdated docs, each with a documented reason +├── Shift Matlab Drive/ ← MATLAB/Simulink models and raw data (mirrors MATLAB Drive) +├── website/ ← public site (Astro + Tailwind, Cloudflare Pages) +├── pre_model_01/ ← modelling sandbox +└── .github/ ← organization profile +``` + +### Why documents appear twice + +Anything that arrived as Word, PDF, Excel, or a MATLAB Live Script has a **markdown report** in +`docs/` — readable on the web, diffable in git, greppable. The original binary stays alongside. +Each report records its source path and the file's MD5, so you can tell whether the original has +moved on since the report was written. + +## Clusters + +- **Energy Management** — hospital load characterisation, PV/solar data, datasets and manuals. +- **Simulations** — MATLAB/Simulink physical models: PEM electrolyser, PEM fuel cell, hydrogen + storage, battery, gravity storage; the dispatch controller. +- **Business & Economics** — cost and CO₂ accounting, viability analysis. +- **AI & Control Systems** — forecasting stack and the RL/rule-based control policy. + +## Key documents + +| | | +|---|---| +| [Simulator I/O Interface](docs/02-specifications/simulator-io-interface.md) | The typed contract between the simulator and everything that talks to it — conventions, static config, per-timestep inputs and outputs, KPIs, priority rules | +| [Forecasting Requirements](docs/02-specifications/forecasting-requirements.md) | Specs for three forecasters — PV generation, hospital demand, day-ahead price — with model stacks, metrics, and targets | +| [RL State](docs/02-specifications/rl-state-variables.md) · [Action](docs/02-specifications/rl-action-variables.md) · [Reward](docs/02-specifications/rl-reward-function.md) | The reinforcement-learning problem definition | +| [Simulink Model Inventory](docs/04-simulations/simulink-model-inventory.md) | Which model is the live one, and how the nine framework copies relate | +| [Dataset Inventory](docs/06-data/dataset-inventory.md) | Every data file — provenance, size, and licence obligations | +| [Cost Analysis](docs/05-business-economics/cost-analysis.md) | 48-parameter economic register with per-row confidence status | + +## Related repositories | Repo | Purpose | |------|---------| | [`.github`](https://github.com/Team-SHIFT-Space/.github) | Organization profile — mission, vision, public face | | [`website`](https://github.com/Team-SHIFT-Space/website) | Public site (Astro + Tailwind, Cloudflare Pages) | | [`pre_model_01`](https://github.com/Team-SHIFT-Space/pre_model_01) | Modeling sandbox — early model approaches | -| [`demo-repository`](https://github.com/Team-SHIFT-Space/demo-repository) | GitHub sample template | | **ALLSHIFT** | This repo — project hub and documentation index | -## Clusters - -- **Energy Management** — hospital load characterisation, PV/solar data, datasets and manuals. -- **Simulations** — MATLAB/Simulink physical models: PEM electrolyser, PEM fuel cell, hydrogen storage, battery, gravity storage; the dispatch controller. -- **Business & Economics** — cost and CO₂ accounting, viability analysis. -- **AI & Control Systems** — forecasting stack and the RL/rule-based control policy. - -## Key planning documents - -- **Forecasting requirements** — specs for three forecasters: - - *PV generation* — LightGBM + Temporal Fusion Transformer ensemble; inputs from KNMI NWP, solar position, clear-sky index. - - *Hospital electricity demand* — TFT primary, LightGBM/XGBoost ensemble; ASHRAE Guideline 14 metrics. - - *Day-ahead electricity price* — LEAR baseline → NBEATSx / DNN / TFT → ensemble. - - Methodology: rolling walk-forward cross-validation, post-2022-crisis training data, readiness for the Oct 2025 15-minute market units (24 → 96 outputs/day). -- **Simulator Interface Input/Output sheet** — the typed contract between the simulator and everything that talks to it (controller, validation layer, economics): conventions, static config, per-timestep inputs/setpoints, outputs and KPIs, priority rules. +> `website/` and `pre_model_01/` are also vendored into this repository as directories. The +> GitHub links above are their standalone homes; this repo's own remote is +> `git.teamshiftenergy.com/pepe/ALLSHIFT`. ## Status -Early development. Physical models and planning specs are in place; the simulator environment, forecasters, and control policy are being built out. +Early development. Physical models and planning specs are in place; the simulator environment, +forecasters, and control policy are being built out. + +The honest picture, as of the July 2026 documentation audit: + +- **Specifications** are the most mature layer — but not yet mutually consistent (two variable + naming conventions, action spaces of 5 vs 16, reward weights undefined). +- **Physical models** exist but the PEM electrolyser and fuel cell are still at MathWorks + demo parameters; no SHIFT-specific hydrogen sizing has been applied. +- **The dispatch controller** is a draft that does not yet compile. +- **Data** covers PV and hospital load well (via simulated proxies), but has no measured + hospital load, no electricity price series, and no carbon intensity series. + +Every one of these is tracked in +[Open questions across the project](docs/README.md#open-questions-across-the-project). ## Contact diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/PEMElectrolysisSystem.slxc b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/PEMElectrolysisSystem.slxc deleted file mode 100644 index c69f8e73bf06f696216bd57174b5c62a12e61ae6..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 5777 zcmbtY2UJsAmkuD+P(=wM)rJU!DpI5fBE1)BLc|CNA&@`_O-cwN9VybKE7A!dQbjJB$vVls>m=W~``c&l{hh6+NpXx7Kn0)y006uIHRj6h zx1_5OG5|o9^lcy}A|`nU3~_P-qaX-dh^;*oYyv?j|GcpNbJF_fBCeYpGKNk{2oh zXK?`0v#bOPhn>{@oR-wD`&rAgfh`}6O6AEizMULPPdNal+`4_mr3X!D&W~h8diw9C z5eWTa0~kZiK!X8)%NL2q5g7Ob4S~nVnR&WGesi|YhIX*3y;Ez>OWH3f^V=d`P`)fm%@ptyc@r+)Li zqJA{4ya$&3DNMp@CPE<%85t4XbfIF09Is&O9ke1^#pz_kbtgMfK40%Z(+OYq^}~Acn{TMo(#m7ix_fr^czR5X zY(v~T>=|CI@gKyjRX@fy{U3v-;JTRH)q$D|i-aXV|23nHrDrIkC-@QJtk{IBdC0L* zqm|DO!cb!edxMRV)}B9%4-C0K5%lDAr0?x)DkC}9o_sKzu#EHFwcL$eYlf)$eEtx+ zH15EpJ8OtpqC^UPkGj(C{>JjF=1fPYIshr>y$qIhg0OE!*2z)f(SM zN%g=5?&@mQEX#|S&wxvv4Fvvec};WPcMP;z$a4}A3{7Gal*;Ppr}Ny z_4}R4%)X3U-%snL+6daZ28XyiiS=9~yLfWJbkurY%eCnh`0-d}YE~rOUhtF@=}+q> zOS_>W;&vkMi(htY#uI5PPtFZP! zwW^b(K%e)`+iE**eqTtdZqRZShf_>liPR^yBbUKTDYFiJk9IC7*8 z&rCpjEG!;&Y%ZhwTF9WoxOXyf^g069Od}LdrHbla?C2T`!Z}aM^ge5eofl@cOP!4N z_4KvQ+iC42M$LwoM19JG1Vt0LK_6w#nNXI@9$e?x5@@`2t%s*){hW&TFfJYEyl+|A z5Vthe7@4LRdb{d=cb)dWSz9fl;c?_s-&fOVk5abkW7e&P)}Ug()Z*5_+=X>Qz{;Y` zr|^ZEfMbglrSK)+ajJYTqUek#`T{QETic?m+S{asnR{zua5#k6^h&#ZYh0!o4cYRIgHzKSP$k2B0Hg1*}Bb{4DJnk_s0=EH?2jt8sma#mc zmnE4zFEr3Qa&t-Ra%KBf7l_9e_FSJcX(aTKPgA1 zoztg!%G93w&8A9-sduSZrPy+#s>j#-(?VsO=Pd|=XH{>#%81hsUNn1510N(_f#onx z-wt+mTXz6H4jMRi(kmqUBYN2#YhR#gwsEF86?%057I3`kv&ctE=!>q6jr%9NZD@+A zf9QHqP~|*S)sgD9#5v1TM@oaQ_LQRn#>>0P?#l|9U3ADNo`1j+l^70O7;Q*+OM~E^ z`yqU6$59V{^^@o2c38u7prv8jQpkPOpv~=E>@IAm5cqsr6}eH5PrsvV5-mG3!R>iV zZvyn_a)IBGJWFQCn*W?cFqRwuICnVD{=qjC?S_E-%&7mM8)l%1Oc7yfSTGf-!L&4k zJdUw1^UhVc8`!oDe91ja3khj$R%=;rED_PkQ!f}_-5DKPogE+10Di3G8}Z52lTO^c)Y(4#)}=p8mzFL5p)4=Z zIC5H5Fyw8uOV2BGNra-CWt1;uL zIr7E%z~zTPJYi#bN1CW^{Pawtp`CDKXLnsVbG&28M*ZmJ{;NPyA8_VPNjXbN_9&EV zO$b}(v1UzllSthIx5UMGelE4vZ0>gg%&Gas%ywoS-DU!}Bl=@R=**P{O9Mk_0%p7= z0y)`I)wpsQ5EodRU!qlV?Q0h%(F!r*WvTcp*Fg`|9Ot8nc4NE68S;gn84rgO+YVc9 zKFP!Tq`~=jIN7=*5Kw0~Rk+h#DB?N-?tz3Nenu3mrfA?@Zp(qQ}BMi&Ue&CtQl8RF)SfFgfdmlo6M9H_{u=!fk}7-VLRQ+~vb3(u zK@)zKB}3wDCPOhV#r2YLh^q=yohA>fd5M0<%$xnyl$egP zsEfIYNW!VAFh03C*JkeN=?PQ&u~cn|4;A~(#UF>&hBj7=5rb+Y0WO;F$t*kE&DMD| z3=_{TW(#nA2s!-{@`G|m>Q>Q%H^QSbK3U`LfbWwliAxKx81*b$E&CUjs;=#PLRp_K zIB4=g$F%nO=+}AcD#uraO5R-+fRCql)0g-&1EoSmSvC8eVK?k*HW8A#$-WieZhBBY z`xrgxJ<~g0!+qEltn*7TeIyrHkX-R|yTPDtkh>5!2pHyJ3r9fp5O5bL!p-4Nhd`s7 z?l+47gV#Li=JsYK^gzw7j2N!A&o$I~oPCL-ABP75`j@c7|ZC~(InM}DG}^=q*h{>@+o5#x%T|H%`Db& zS_&7A46T=mcFr)MKtS3|_=~kG_2z_riR<$D16)@2jn zrFu&hHP5)6_Lien8|#!53F~2xM*Jr3ueIr0TuWv6%na(zT-#kyFL3`bI6cFeN2EH; zg_ba|@Mq{vk;aAp#KjG?8`K&3S5>o$>}Cn%0Rh(JDVsT)RAWvL8m7q(QZPNp&-SNC z+}=KzSZt`pm5+4=aZNW*J7IBgkYgsbs8TCz$&(YzAnbFef(v$;Z**xulJ0!nFVY_3 zJjB0URa9Jyra!rAo5~nRHHp#Zl@!=6AlRx^io2P38F9Yn>_qG?alfS5Mg}Y$<9#Kl zY=IR1=4*Xd1u%DRp^#^9Bkz$7-&}^#yS3~6;AFL3KckD_!^W=Zl&HTU87W0_JpX?( z)&S}Rg&?7S$n~E^JW`V}P=qOHZ9lYfr{93_NWP#U9g)?2O%Ba>P&s47dQZy?cS9Lx(jB$$mUH@h< z|JS;i^jLjR%2)_vhiaDw!J$_DJqQnthR1KWH&vj}{_GFlYjhVJZ_Upz8tK}Odn@TgX64J^Q73&V4%3=$PzFjQ z(KvD)P1+NiLCY10mG37rGbc)Wnv4~am zvFda4P%A{k9OZat@Zw>-AKq8c^VN@~d(3;bS!WLz&kde6C~tbQTMDwrHqcdW4H)33 zEH@kP$Af(6h0%grCoUA}wAJ@@8@A+}8-Hfdn>be{nx71z$fsehSK%U;d@Yun|46SJ z5_<0{=uDCTTD8~L+3~ZhZhoJXk3ZJdJzW{LWuP41WAb{oTW+@|`aTYt;VJMKcB*HW z=%p7>8YY`TK)Luyo&h%Q*HAAoocnT4W_nor((#Ky47`veNpoLoTG1V_ISjRf8?*aS z*>)WOPL{xla)#Joc>6Y)+Z9q0IPG${<;SBd@X;%BC;U3}V~f^f+wUu#8)Iu4QnO=C zpuJ>xQPGDsf>qMwOcJc)&f0@4y^@td3NXz8>S9VVqxZLFGt+=lZuP7d)bSdn;L{+j z%c+I#Pe%iVJn#zt`~Ki^%A%4dT>k?g{BHc zyXD<&mrd_w?@((^(z^a#-t+#B^Z?ae;H$@=4ftT{WQ2LMX;;&zvP`!|cVXBduWrO8 zIQG4MD5bq_Jb#gxv5|k7g@y`kACQGLV9kS))9b5#SXrnLM;q@m*NGV?^0*9IqT@8R zlr{N=rJz4wsnRUPXGs0GiO{Exea_iQ>1@3N5g*5V95<|HnX`@ibF-4R`HX4OP7>r| zag%pAn7^gnj^8#CU~9B)!s9a)DMUd`F?>F}7A#4?O1qR@?0O;Bjn+o1Rq`|FCL+Cs ztKhRmd`kU?Y`cV;qjxbJ74Bx+keemiv{9#v?XG?+)-|bBYK`Zu7Ie6lW%f*}QYTxQ zS%Z+X0s4|YXmHjFux%8MDYwWL4Ct~*P!mBSA`J~2GTxffyF_p40KLnc9hPTgkpd4KuVTQK)z`D9z2+5~$k)PHepPiI8TESD1LdMG8wY zav{3kH?&AD{m1M7(cU_`(9zb=uT{87+v$J1&_5bQM;ADH@cgv^A1Uel{up``=jhq$ z7tTYfLl64flh#qhqZSF7XSldH|??d1!7Y~pAJ^AQj68qEI(cRNo$M%mY zA!mrkt|!^Hn}+9SN8tjO53?S&wjM68#`u*c^?!H=UJ8=QnrpP{^`7IbJ3m=`At}`r z{_uR#*#uR^(!?&;fmWzIjrc;@heOAwV40ix(a`=x_`!VG`xvrv>HtZd!g3U*pv)1mNfip7kxX;Ut&hs>IYLDZ<=FLUuHTs2iWgO?o9V8kYd8RRS)j5Z&%o6 z3o;m?Y7eHOS}e1}ih6(aw)oSTcYh_ybp7)EC37?UWIT97Vw1k#Bvu}kn}(|{XqGKdiOt`{=@9pmr* zP5m9y9$DunK6x=$zdZCDq&X4E7}szQv>h566uj+U-<4*i5UEcEj@LSj{AeY6O2n*} zT9;Wzq+NtLbN^btk-miT=6lm09BMC$o|Be5@)$HJ)+@1JaY8p`BDr#-MX46lZX{kQ zL{mzW?rvpy^P$~4o7|gg7|Xx87Q8RlsP=3vn$#f;NRgBO=vmhgNclsntCG}YLibUl zn^Xp@wGFY}P~?*rGNgHUMZxd}m@Tm=Dz~C#^Z0w)`_G)~A-@kD=LuBE8Yr^E|r($trPU>Fc;jrCVaObD^s|foq z`QxWFS7*SRv&-e{(iEMh+PG=lrest(6*^xB>q`_Wm;9e!RUJy(-9p9qw%E#12T34m z1=$f{yM}?wQZ(gz0(gR4Jk3!Kl$=C17Bij!B!N8Hfz4eROE5(7?TCVhmh7}EF6gbG zgvb+WEMur8TJLOMM1Oruw$Gx?l9Lm=QL-7y2EtoT@@%kbv^tBs4DGd<4;}*V65L0L zZeQ<+J7ct(5l4dDi*B)@`|Anp%#h^{r}d+vZfvFJJ+iu!#oiO12Cddv8t2-m$Qg|u zl#(U;S?mA`nmWkkK2MDjfq9(j{d$dZPs!(3MlK^em(=vN&A@pea z$agsZ)>Wro9nv#Z1|7a@E-Otk=J*CJ7KIF9O$s+ul}Ox*Bxo3}#(Pdey-O>u|zpCSC%Fc%>oXD3fRC6^E&WfPh<8PoNIvMq@t{Ka$MoYMFe z9Oef%c_prEO|Kk?YvkWgs;Zka8H%~YXy%VPMxL zKSBjHXOBi2b=?%gK0JwgwB7d+A_3?m1F6zbK$adDBfoA|I z1BQ%&zWcw0k|(bL7*jx?vD>kmlg_)NR8}B-Hxl}Z!3pChJYyO2gIRNOcE*kiS?;;0 z9GB55*SObI1&Zx`yn?Y5(+bDyWOEIY-+OPi+O4UVFbqvnefOM};&qr=$Lk{3xo&4V zIQ?18#4e_*j|B~Cm-z&G51GpgUA?2W6_Ym^vpDgBj>gTT?}metgD|bsssfpQgHR01 z9VsGPy;5y;{8A97IkaKWP?J0MNQ~lU0Zf=6$9{t*y)|9F>X`Ud3ScN*2)V(`l-Qjx zY$zDDUJ8oTN*YF_wz7~Qy=Vsn;eKq*tPHzr#jah==XJE*?6dVkKoQ9_Azluu(fA=A5{%-|=(yvt-Gz zFM9O~IKMiZ{(!!)1ncBe>|p(CKUsUi;ZPS3RhW|v6s`=1dAmd57hB4Cu#xn4Mar;G z#wJCQ%y>`Lg>ozfmDnw{RH;Q8`9(8cz+j}W-pF(gb-#aEY%TiSp4}g(kBdO1g~S;H zBS7hdcM?Xc?g_%b8MZ~yXc?^x@G8r*;ns1kRe!1ZO{nYSqp9<4_>0JnNx5LM zbg_1m&AFatcBf>aiSM!34v@UOyXmRAYf-^zaotBsnT1p9B1CFkKIBV*q&9?RE8jW$ zHx_1g$p394;7`#wnbLX15F5}Z*g^l7jjj;5hk=8g3&g_{4t2kmD1w&1_Bj(-xB9u;?T=5#ld7cQ#JxtZBJHL`I)- z5(0P(j3Py1X}=KU-{?#>sd1&y*J&kKP1zJsA$;^mrl+;X`5><@ZO7MafHQT*?Kbc4 zdoA;li5D$p3v$r)24%LOj zT%m9ehkv^R8rS}~14#A+gCJc#SrXG_=y1Cl!q&aoK%~n$k~&#cIqQWuK>$_9=H5MP z!O)L3mM?bFiZ-f;%)ZH_QJ08~9Sk{@-OA1?T*MU%eij;H9#=S-rW&3R!?@tCl^Uf& zXLLulrzCMNk7kAh&y_hxt1i{f#hHvRDDzWvDMq5%bazxt*`B%NdeUJ~cjHY%F}u^r*ErSICMCt)?Wo8JlF2@XQ^199`6L{ne49n6HW0C$wqRkc4V z24ydTN_*8;jZBD)?d)73fM@d@%U5Q@f!VzKr9^@OWzbdQ4OMpjmumv!yfQf?%eT(< zhs*%G^=;75xChC(w-A}%3JA0x5c4J9kK@Qi5s$rhH5f=4iaC8+b1ajVD9PSndzl*Ayg4x=o6qg@U=oEs-B}jJ6pDK!136`#;=Qy=?fi%N9=ova7T1w;Q zrWWYt@sMEfd`kEI1+uRU&`*qB>#yPYfMtlgm(EyH!W=yXAp1AV+&=U5V=+sdD5)cO z#)x$a!%OL-!H@ij&l}dia^Bc@+GM=wwsTLRBq-|D*Pvs|drv~SKgJivOYXi1W7q3V z-tK)SotE42z7@UjD-WTOEIC|Q4rH*kmHF>H{Ac_p#VhG_T&L;AoY92(-CL6oFW96= z&lCfhE-#U;dO3U7N1X?b{(NUYAbYPm=*q4^Rp47B+iRwK0Y3aVZ=)%D)nusY-i9*~5S^rL zrZx?_U`lC)s>RISiA9YelAumr1FNTkH<8CfD84d#&U22;Vkb8~IZ{H$2P=m}y~Qds ze%jixdAYY2ych#6rI#%IN`_P{xw8ZS05z6eGZmN%cJFvRGDNsS-7PM1d`%))hZ#iq z1am~2T+X{eS@I&-DK6*kdYG!e#fXQudYO;2qb$d#1<@#u>ESozH=3uiyjKw2kMhTi zmOpUnSGA`cS1{OzwUE~AkLfSWoA0$gPGayU7xEFC55~(`?d1@=gz>>!2qdFAe;<)OjQ!*my|67=~XO@cdzP?KI z;Qh9x0omh*xX0Dd90XsyGu`0vk*{u0MU+g=u9quPoQ16Qw1Egs!L`P9d+{Uq)|H!~ z6daH=anpcDB%lLfQ)jP(>M6VPnr>x)aJpDEh&948gkxlnsz)IsnbodO!Vrazgv!prqT44h7bjvqC;0Y6tdELxN zzv_3`VPYIq!LE__&g)8p(i0{IEq+v)XZB>U5TXk2t;r9&z2m&iEl6gSx2W-vTU|NC zTPCyMYyoTzQbK!ro$~~pox#@M4&75VJd$rMKUwj&dDybzhGG15moze`@#J6~DL@1O zT){f>5gh8|E-ZBM-I-)|QKZ8bj%Wv3`jm|*RX`)^zb6n1m)kmpj}C81RQGKz$b{kB zx0648S2x$cCH-hfyJ)WQZnCc^SAsolgl#j2tYL2KHCm#j%^IW|r>wQo-MGhLK@ak% z<}J!UvRaWQ3#YloGe0v*BzZSEeR^M$Iu?XyFd@zNI$8{BiMUtU&w)~m9)*dS#(Rn1 zDPKWwo4_auf(i8!avug+y$R|WR>r5Zc|npL$=btXzwXo#o-Cb3$Z_wO{-{f_2eX}S z)^sOEtS=!z!-~L5Q(KIXX-FKbCHEmsOhW=pEj}fnyy#9gwZ|U^#Un~@{vzeBmry=v9*Y65lSPl=AU z#FfT7+Pyu2OSF7K0__Nmmvr4wUyJu*sB5`Z0hy}m2L))tHL{9uCzixl*^XH2UX8%pm{{{7zLc1)Le?p0q z{t5M;!uc}DWtsOAqy@X1|55Z^hPtehenRz<{R7l5n&~p;Wi9d(^DX&5U|v!tmr*ZQ z_MfP26n{hg&pLk@=yDbN3B*eIKi0I%0GG4pPkf>P6fT&kE0a)WPvN-C0b;pPggC|VcGzQ`{|Xj#AN&4;!CFik{( diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml deleted file mode 100644 index 6528bff..0000000 --- a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml +++ /dev/null @@ -1,6 +0,0 @@ - - - - mbmopmGIoDRt8MVKbX70Ws8wIS5ByX3TRWfEs9xR1RggZQ3FJVfeveSmi2Xzru+1y/KC09UiQWui2s1zeVwxog== - - \ No newline at end of file diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/varInfo.mat b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMElectrolysisSystem/varInfo.mat deleted file mode 100644 index 0706b9d64c47e32b363cade76be0fad8ed09e766..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 16008 zcmeI3-EY${6vaCU5aM&d0}@Yp;BiA;*$}FPl+sCT(psji(s;A7&TXURi!@!~jX#}p zlZJ#UwY{``yOy%{I&qx*bat-oq`l7Itn<}6`p~p`ox%Rd_2iy)?m5XQjQzHC-n}~Q ze>&W=y0LT;d1Hk^+q#?uRzJM6J~pj`R{P*{`|!YOHCsoPVQJ)L=d||%-#=q}gzYi5 z9c)w{VxyQosZjk(Y~Q@_+VQT!_;wmOL)o}b`)6q14TF(8zLd#@93f2G|M{Zse-Fn| z|I}A6ypg5u)4C?=^Xq?r?^N>Zr*>4A-`6gpla@H9bJ^Hb?dX1scG>;=)W0=fdH+@Y zQy=B?P&`gKX7}_%a~2&=T=P2u% z;zHMs8w&?dC&kDOrp()b_c@MH>H6IgZ;C5;N3rWW@o(%zVLw@4=W73!Nh@WKY#f8o(TZ$9bwVt!izh5tLrg(|-nf!@L6y~kxZG)3a*H5s&tZRzL z&QwHhB*ifT6y~hwtkd-ya4d7Ccp7?6ETTB1H>pGv&SgxvnKu~d{94Dm%18d^ow&YC zaWiiN-ZqX=`N(tZFYBA)Y2plT#jzOQc%p-teMGNo8=ThR+-1&NTZhW@?0C_{0cF;+ z$vTt`PAWZDjXxHgF;6GT%-MvqZrwW1r^J)yE)-{+-H?5GeP5>c#mo7R;*774<)&eT zkn)F4Koj{6Swrb71P5fEM zyK=sgj-P$G;GKz^^}UhtUDfYpGJOX#Uks(^@$-T0>N@3&=emIe>a?(L>wVh>se1V_ z;dyu_vyJ%2>TyWMndjkV@8jz9T=m=~^XWw7nUQ^CecxEkc`oSf8**vpyguiudEy+u Pmd0~{e@|SPvzqf?H%$+x diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/checksumOfCache.mat b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/checksumOfCache.mat deleted file mode 100644 index 9045420493e1bc615b0f78c5ab5a1fef83e52447..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 392 zcmeZu4DoSvQZUssQ1EpO(M`+DN!3vZ$Vn_o%P-2cQV4Jk_w+L}(NSB|RX2LLe}5OV-AFA#$OD-eVD zEI`Z%#r#0pJtsdYF(*8~D7&~IF*y~iPXH)>MYiW=Kf@-LmkpdV-u!T?BgI@Epnm84 uytK^p;M9_!)HEQMD&~UR;G3V4isW3lxj#0YoNc!2dnJ4Pzr#+2>G}Wy$VNH< diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml deleted file mode 100644 index 9414d4d..0000000 --- a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml +++ /dev/null @@ -1,6 +0,0 @@ - - - - ekcxxpQ/6HRJC8J/tqoVG16wr9UZSgRqVNb+q5DgwRBcUIvB8a3lJ/vtwwx6/F4OqfWyoMon1TG+xKDQ9uMoYQ== - - \ No newline at end of file diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/varInfo.mat b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Big Ugly Folder/slprj/sim/varcache/PEMFuelCellSystem/varInfo.mat deleted file mode 100644 index ff031c85c14e95db094258073ed08b02b5d07d13..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 21008 zcmeI4-EZ4A6vY*w+k&?1+CCKMn;!Pq4u+QugP)WoKvTd@)68r3MldoR3(?nTrGfwZ zo-0|F>dK^QTTiPR7HNzue>BdhY0C{B|0I>WzCD%50kGXy9I+ zUcbNiSYPo=M%@2US3^-q&{8r=S^vMV)3nAbo2Xukdc z$I%D#LS zT*vGOop9y$s~f#?`_+Q$HtiR@fZH#yt>;nu^4SlZe|5!``vooh;Cu60=#|^AZn$#$ z)q?9b?H4r5?N`h8%foS|{FKHmtGvx|D3&n>0!4Ozqr@4)e7wxV+H{`(`*@;_59MBU z&J_DHo7G8kerC_l&Mi88xyG4dKZ#NiO_EIbiPmB~{0AFRn75s`2TrE%{d4TE>zd-6 zcPg~Zf`n)@=iNCs`E<@%r%|bB=4|J@oqr^uj5876M$>bwV{k}TyEQl0ywsW?Pf6zOq>zZN}e->BxLNMRm`8NH& zPkhJV%zV4!n=;>4zmwSf;iol!pqTW#_|Rwlg2myI4|!^HhH0I25n+ECVeh zCcTSk5F-a_CcZs+cSlZpEi?62#b;uUwFdU?#b zjh}enWa4aWA61rH3F~=xJvaT%veL7jC9LOm?W0Z4P4fj-oHOwt!;t+MV%s%;F>|IV z9_P%t1!r4-uW9_b(lc=$s{hD5P}rw;*L73BW1dO>PMnF`NywZ*U?2UC&75VJ&Lnf* z6X&M9ywEcxiaBQX4Pdafhqm$3vOW=|J~hP!=U~Xb+$rCL`P%t<(4#32Y|2jx{YDs1 zDiUtyygTQg@gC~q8WdNYi$st)+c|I3Z!S4UH(JI@jF!XF-2Op>W&1_itn^v^o@L|R zG(UQc_i~hj^OSw`pPTaUf;Y`3^;L*TVC*AZ>N@Al^X=dlP5<9wlaF{f-qa7-oEK)C ze}f&BefUSyxPRdvnTS-;Lb89@{lmliFzIVBjXEr7NPT zYtYe$gRl4W8LsP!z#&i*2=p~nx)KTjK%=^ue?3D3`E6;r3uFfZNU$?t021O1Sb#7C z_M3=OH$~fl(%3Zt#mf=`3XOub)jSec&lSP|g7=f8%RckAs~!$Vu8td-zU<>~v*gOU zzj#nr-n~6D6qhw5#lz~lc5XB??T{wz)-PAwdVRK93Zj`Y%1!}WhVaMfk%N{1{S*95 zthN`b5xJ=*2LL4h5Bw0x({#OqI^t#3$UwUV!l0+z1{ydF^;>s;(*K4xz+ChKP%r(OInT1m5+817Tu;ns1b-D6plm3Yt(PiDC-QtbXcpm&69MVmvd zBD}cyQh*5orLU;&G^>tDD8|8ls6v}D9Bi;sJ~kLZD)WG|+@&vr(KU3QA=-A^S58*I zZ`OgS;eM64KRvDQ-I#k^Wu|R`@mHtW*Q@+|%6$2+z4zm;4@VSz%f=!59GLwpXBVA7 z?ch;Z=5`rm>IR}r4L1@Py4Q+%w_&ZoZPAD`JY1{8|5&M7wt~luOsS7b&e6vCy&TUa z3@fZOXs3oA46$+~oS9wGT_}O_DDEWf9da}q7V2x8Iq!b~os^}SYoh!jQI;X%U?a-n zNaR`^iNJW+|D+vFq}>taD&~W9@igdiZH6$^ZJkTRN3Vv0;rz4ulm(!dRGlD~bm<$i z^rP7^jU~XFMhWXk?+=nV9AV{E#qYoj)LwBGlqudOf4^p#j%>2AWHhe0)2zWPve7Uu zj%1sXuG;&N_>w!v1A*T9>$cPe)bkrSZvpP*hEGL|{ti!hZ7lCl^FE6$PiKttdzJ56 zPNJCOx2%J2{%8{#H4S9h=GA*gm>41(E)6Gp9&!F*$AZlQjZrG}THjoEt6)Nn7Ma8s zwU1dp)a!3X&bR|x9$`{m-1-Nb5aP0D$kL$Nyy6-p2!tIP&ekkc@O~MJ5DKF;2j6k>DRLgyT3|n1*qZ#vq&!Sj+u>=;Q;k> zW(m6D(aUvGkL}Yw$b`5Dea}kR>OR#G}a4VGr8Kqtv!V(d$OPMKbFcFZ2kiT<0RK z;*+PO=a;~Jst6K$yZ^x)DTjXXuw~?02u-R~liBKIM?JSoqS(i;(M-F6f`VJA$@+L~$qFJ;|Qz;bZ zfj8N?#8cu5w2T6=ukQ2zvPw5@@ujz>hVB_u8RVA7ljk17M>Cti$8vdYHj(cTEqlM| zHf7{6)s44_y#hidz;(Q97?Z+viC#a5Oz8&!sWhM7yFvYvaxnT}PtG-9lg^nYC!KyQi_L_}59G3buPZtvIVlA5!so{W zL;);_LL508(%u7Mhwwm%BfW2<(DwRhl$$-;!|@L}>|>jpS|Bvxcwegd{W&RpaEm)V zmaBcK2Bgn9kUUaWI^pHJ?+Z~IoNSG0z_Y%uEtzRMCt0h3ohZ*>*0>TK-HSa?SbLh8 zH$y5F5)+EGjLjQKQG1Z~==?NBCpl7;#rTFoM?w5{4)ZuA(2YGyrz+XO6-gr$oG}~q z5`U%MeCxfG%3byXo`m_hekH9bGr=9GXWoWho0w%?E&=sg|8sdwKDW#MmsqvNI%TD; zjmU=|11FsD?FJUt(&?5M!9Cgdy;aRuo?}BZvz*Tf|HVcmBOr|dzeCazySPpvKCH~igNNDqeZ$MKieJs?RCRU;>ZsMFHomR@gdt*qCqoWg#{aCs_>%Qpd+`@UN*R$Hd0NsA&nH!TZ?2+gc&)FZk5%qm9Uo?ndIU}T^A=1@v1nuH=xT!+b(5LZsB$N3v zN;5Mb)G*I<%a3(CQZ3{=xA6e=No(e_R$fSJWYs9@jzdy@$sQdnPj~nV<)&qX zl60Bq%Z1b|m&UgeT461$;1-0A^01}3)nffHHbi$Ssoi9n<_p+<_Pp0hF*+A8kHC1r z1{0o4veE&b2H9kHS+49!*^ora63}S_x0ArHt`d4b2**FJS^0AD!sm!O(;4?oZN-A% z$f7U7dp6qPq5L1>^5SH+UW9QQbS7?e##~LwZh6+5~QMgYAcnkeLHdu%^kkQ>{B~zT6LfY11}?}5XnoT3L{fNJ4_r@ zmsXP@{8RT(U|u~JW%r~rDi7QSE!qMEk=it@+;wDe1~q(C3aIME-+7{XTw0%$G2-6) zkGV2Sg(!ij%Dwq?;hSAT%e&-aUK}lF$FRn07Zff@zQLfMha)t?{eN#hxa?cs=*L#V zrXAoTOi~@eAaqIoEKBtRax&0<%4%}m?=n?8Y^LXX5+!=(MM?&pD?85Tp~wh>feS{6 zo9qPoWdn$L3p8I*|5|uuo1d~?bWW+39(-(&hoyloGq*=18wy+^EBkigp!%c&Zdmg7a4!EbqWJ zV~1i|BB#SM?(5^R<g8rE=NPNckSD4^s|`G{HCgd+vn zX^X#~qhGQ*1Qe$j^b$x*rT6>RVrClrnp-oc)r-1DIh+lwBb;97`E(>i%(o0!ZT8(^ zdoO2o4UtjiEon+{uPQ-!%V#`0oYu9JP+s)(`f(}v@DR09-KVW)M7Z8qvcKSO_e;Zq zJO2DhA@3k`bn=Ko3WERuYNC+VXnPloxY*INEnyPY3}J4YCJ3iC;Gzrs!Ql_p&SpwQ zG^Bp^8fB^UdLzpHeV0Weh}I>Xa-*ontdFo`=gmG<6p=0(>+#&KLq4%LCAR|m=MXx_wuH&H|BlaI_>OuL&#RONcKdI}?lcwvt&qr&gYn*EocGoZB1$CzvUJ})Qb>jh(qjB{HGPjHjA?2O+seo6RhB*fZi z-84O&tpt<+Gd#ZF&uhVyLQ~<8wimWh$aS-=(Q1v9!>5TrYvC@EzcQUxKbGr|s6Jwc zWiR(M`-)I6(WQ)GD|V3mRtz(#Rc=e*trl^-mSdJLQ=yl8l~HT!*(P{7a|nLX3h>n^ z3R`B8D-zsok*EQ|prZ{98?xS-(z?a&=+XF{oByM$%n6DUFLsFAl7v*0>Yoo4h?4&0`hOfT zoL=a3cYeGI57C|ew+sEHS3kYL=|1y#fhuA!|L3mrG|uU!>KKRV%!xnxk1f_|#M3qW zG2#v}9R7s)r;7ehsDCPzkD*41ryf6{{$4nr202~k9fQ~sPn!O<=sOK{x=K2Ra;5wi zs1r5QY0T5L$T6lR)xTh#s!UF!p3dyYsCL9S_TNVTJB|RX2LLe}5OV-AFA#$OD-eVD zEI`Z%#r#0pJtsdYF(*8~D7&~IF*y~iPXH)>mo>8MA;&}g)r;-hR9C9cCBNuGb3tl-^HWlhoQu<30B$uz)&Kwi diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/tmwinternal/simulink_cache.xml b/Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/tmwinternal/simulink_cache.xml deleted file mode 100644 index a66b4ca..0000000 --- a/Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/tmwinternal/simulink_cache.xml +++ /dev/null @@ -1,6 +0,0 @@ - - - - x6rvpBDuDjxeqTqNN4wQ8W6lPfPBlUcH5Z+dcPH95lFeAp3H6QSQsSmH2aJFnMg8Zb/yUBwvrskLfnWlTs0keg== - - \ No newline at end of file diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/varInfo.mat b/Shift Matlab Drive/Shift Matlab Drive/Simulations/PV+Battery Simulink/slprj/sim/varcache/SolarPanel/varInfo.mat deleted file mode 100644 index c3efdf75482312e9d4ffb01cb1e2de11f303352e..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1720 zcmeHHQA@)x5KckG2hsh6d+>3S(77RfS}h_2Gm4JQx6-+El(mht9sVtUqIYfMx}j_L zzJv5~m-{a1m&*xz`eHxA;Esc^r@bJIWEb4X&jXdl7P!uQJQ?11!AYf`%O$A90-+KR zehOwEOl}SO7UwuIhtN`(7Go@~asGYI*ahlK97eTJB$vVls>m=W~``c&l{hh6+NpXx7Kn0)y006uIHRj6h zx1_5OG5|o9^lcy}A|`nU3~_P-qaX-dh^;*oYyv?j|GcpNbJF_fBCeYpGKNk{2oh zXK?`0v#bOPhn>{@oR-wD`&rAgfh`}6O6AEizMULPPdNal+`4_mr3X!D&W~h8diw9C z5eWTa0~kZiK!X8)%NL2q5g7Ob4S~nVnR&WGesi|YhIX*3y;Ez>OWH3f^V=d`P`)fm%@ptyc@r+)Li zqJA{4ya$&3DNMp@CPE<%85t4XbfIF09Is&O9ke1^#pz_kbtgMfK40%Z(+OYq^}~Acn{TMo(#m7ix_fr^czR5X zY(v~T>=|CI@gKyjRX@fy{U3v-;JTRH)q$D|i-aXV|23nHrDrIkC-@QJtk{IBdC0L* zqm|DO!cb!edxMRV)}B9%4-C0K5%lDAr0?x)DkC}9o_sKzu#EHFwcL$eYlf)$eEtx+ zH15EpJ8OtpqC^UPkGj(C{>JjF=1fPYIshr>y$qIhg0OE!*2z)f(SM zN%g=5?&@mQEX#|S&wxvv4Fvvec};WPcMP;z$a4}A3{7Gal*;Ppr}Ny z_4}R4%)X3U-%snL+6daZ28XyiiS=9~yLfWJbkurY%eCnh`0-d}YE~rOUhtF@=}+q> zOS_>W;&vkMi(htY#uI5PPtFZP! zwW^b(K%e)`+iE**eqTtdZqRZShf_>liPR^yBbUKTDYFiJk9IC7*8 z&rCpjEG!;&Y%ZhwTF9WoxOXyf^g069Od}LdrHbla?C2T`!Z}aM^ge5eofl@cOP!4N z_4KvQ+iC42M$LwoM19JG1Vt0LK_6w#nNXI@9$e?x5@@`2t%s*){hW&TFfJYEyl+|A z5Vthe7@4LRdb{d=cb)dWSz9fl;c?_s-&fOVk5abkW7e&P)}Ug()Z*5_+=X>Qz{;Y` zr|^ZEfMbglrSK)+ajJYTqUek#`T{QETic?m+S{asnR{zua5#k6^h&#ZYh0!o4cYRIgHzKSP$k2B0Hg1*}Bb{4DJnk_s0=EH?2jt8sma#mc zmnE4zFEr3Qa&t-Ra%KBf7l_9e_FSJcX(aTKPgA1 zoztg!%G93w&8A9-sduSZrPy+#s>j#-(?VsO=Pd|=XH{>#%81hsUNn1510N(_f#onx z-wt+mTXz6H4jMRi(kmqUBYN2#YhR#gwsEF86?%057I3`kv&ctE=!>q6jr%9NZD@+A zf9QHqP~|*S)sgD9#5v1TM@oaQ_LQRn#>>0P?#l|9U3ADNo`1j+l^70O7;Q*+OM~E^ z`yqU6$59V{^^@o2c38u7prv8jQpkPOpv~=E>@IAm5cqsr6}eH5PrsvV5-mG3!R>iV zZvyn_a)IBGJWFQCn*W?cFqRwuICnVD{=qjC?S_E-%&7mM8)l%1Oc7yfSTGf-!L&4k zJdUw1^UhVc8`!oDe91ja3khj$R%=;rED_PkQ!f}_-5DKPogE+10Di3G8}Z52lTO^c)Y(4#)}=p8mzFL5p)4=Z zIC5H5Fyw8uOV2BGNra-CWt1;uL zIr7E%z~zTPJYi#bN1CW^{Pawtp`CDKXLnsVbG&28M*ZmJ{;NPyA8_VPNjXbN_9&EV zO$b}(v1UzllSthIx5UMGelE4vZ0>gg%&Gas%ywoS-DU!}Bl=@R=**P{O9Mk_0%p7= z0y)`I)wpsQ5EodRU!qlV?Q0h%(F!r*WvTcp*Fg`|9Ot8nc4NE68S;gn84rgO+YVc9 zKFP!Tq`~=jIN7=*5Kw0~Rk+h#DB?N-?tz3Nenu3mrfA?@Zp(qQ}BMi&Ue&CtQl8RF)SfFgfdmlo6M9H_{u=!fk}7-VLRQ+~vb3(u zK@)zKB}3wDCPOhV#r2YLh^q=yohA>fd5M0<%$xnyl$egP zsEfIYNW!VAFh03C*JkeN=?PQ&u~cn|4;A~(#UF>&hBj7=5rb+Y0WO;F$t*kE&DMD| z3=_{TW(#nA2s!-{@`G|m>Q>Q%H^QSbK3U`LfbWwliAxKx81*b$E&CUjs;=#PLRp_K zIB4=g$F%nO=+}AcD#uraO5R-+fRCql)0g-&1EoSmSvC8eVK?k*HW8A#$-WieZhBBY z`xrgxJ<~g0!+qEltn*7TeIyrHkX-R|yTPDtkh>5!2pHyJ3r9fp5O5bL!p-4Nhd`s7 z?l+47gV#Li=JsYK^gzw7j2N!A&o$I~oPCL-ABP75`j@c7|ZC~(InM}DG}^=q*h{>@+o5#x%T|H%`Db& zS_&7A46T=mcFr)MKtS3|_=~kG_2z_riR<$D16)@2jn zrFu&hHP5)6_Lien8|#!53F~2xM*Jr3ueIr0TuWv6%na(zT-#kyFL3`bI6cFeN2EH; zg_ba|@Mq{vk;aAp#KjG?8`K&3S5>o$>}Cn%0Rh(JDVsT)RAWvL8m7q(QZPNp&-SNC z+}=KzSZt`pm5+4=aZNW*J7IBgkYgsbs8TCz$&(YzAnbFef(v$;Z**xulJ0!nFVY_3 zJjB0URa9Jyra!rAo5~nRHHp#Zl@!=6AlRx^io2P38F9Yn>_qG?alfS5Mg}Y$<9#Kl zY=IR1=4*Xd1u%DRp^#^9Bkz$7-&}^#yS3~6;AFL3KckD_!^W=Zl&HTU87W0_JpX?( z)&S}Rg&?7S$n~E^JW`V}P=qOHZ9lYfr{93_NWP#U9g)?2O%Ba>P&s47dQZy?cS9Lx(jB$$mUH@h< z|JS;i^jLjR%2)_vhiaDw!J$_DJqQnthR1KWH&vj}{_GFlYjhVJZ_Upz8tK}Odn@TgX64J^Q73&V4%3=$PzFjQ z(KvD)P1+NiLCY10mG37rGbc)Wnv4~am zvFda4P%A{k9OZat@Zw>-AKq8c^VN@~d(3;bS!WLz&kde6C~tbQTMDwrHqcdW4H)33 zEH@kP$Af(6h0%grCoUA}wAJ@@8@A+}8-Hfdn>be{nx71z$fsehSK%U;d@Yun|46SJ z5_<0{=uDCTTD8~L+3~ZhZhoJXk3ZJdJzW{LWuP41WAb{oTW+@|`aTYt;VJMKcB*HW z=%p7>8YY`TK)Luyo&h%Q*HAAoocnT4W_nor((#Ky47`veNpoLoTG1V_ISjRf8?*aS z*>)WOPL{xla)#Joc>6Y)+Z9q0IPG${<;SBd@X;%BC;U3}V~f^f+wUu#8)Iu4QnO=C zpuJ>xQPGDsf>qMwOcJc)&f0@4y^@td3NXz8>S9VVqxZLFGt+=lZuP7d)bSdn;L{+j z%c+I#Pe%iVJn#zt`~Ki^%A%4dT>k?g{BHc zyXD<&mrd_w?@((^(z^a#-t+#B^Z?ae;H$@=4ftT{WQ2LMX;;&zvP`!|cVXBduWrO8 zIQG4MD5bq_Jb#gxv5|k7g@y`kACQGLV9kS))9b5#SXrnLM;q@m*NGV?^0*9IqT@8R zlr{N=rJz4wsnRUPXGs0GiO{Exea_iQ>1@3N5g*5V95<|HnX`@ibF-4R`HX4OP7>r| zag%pAn7^gnj^8#CU~9B)!s9a)DMUd`F?>F}7A#4?O1qR@?0O;Bjn+o1Rq`|FCL+Cs ztKhRmd`kU?Y`cV;qjxbJ74Bx+keemiv{9#v?XG?+)-|bBYK`Zu7Ie6lW%f*}QYTxQ zS%Z+X0s4|YXmHjFux%8MDYwWL4Ct~*P!mBSA`J~2GTxffyF_p40KLnc9hPTgkpd4KuVTQK)z`D9z2+5~$k)PHepPiI8TESD1LdMG8wY zav{3kH?&AD{m1M7(cU_`(9zb=uT{87+v$J1&_5bQM;ADH@cgv^A1Uel{up``=jhq$ z7tTYfLl64flh#qhqZSFf>P6fT&kE0a)WPvN-C0b;pPggC|VcGzQ`{|Xj#AN&4;!CFik{( diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml deleted file mode 100644 index 6528bff..0000000 --- a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/tmwinternal/simulink_cache.xml +++ /dev/null @@ -1,6 +0,0 @@ - - - - mbmopmGIoDRt8MVKbX70Ws8wIS5ByX3TRWfEs9xR1RggZQ3FJVfeveSmi2Xzru+1y/KC09UiQWui2s1zeVwxog== - - \ No newline at end of file diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/varInfo.mat b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM Electrolyzer/slprj/sim/varcache/PEMElectrolysisSystem/varInfo.mat deleted file mode 100644 index 0706b9d64c47e32b363cade76be0fad8ed09e766..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 16008 zcmeI3-EY${6vaCU5aM&d0}@Yp;BiA;*$}FPl+sCT(psji(s;A7&TXURi!@!~jX#}p zlZJ#UwY{``yOy%{I&qx*bat-oq`l7Itn<}6`p~p`ox%Rd_2iy)?m5XQjQzHC-n}~Q ze>&W=y0LT;d1Hk^+q#?uRzJM6J~pj`R{P*{`|!YOHCsoPVQJ)L=d||%-#=q}gzYi5 z9c)w{VxyQosZjk(Y~Q@_+VQT!_;wmOL)o}b`)6q14TF(8zLd#@93f2G|M{Zse-Fn| z|I}A6ypg5u)4C?=^Xq?r?^N>Zr*>4A-`6gpla@H9bJ^Hb?dX1scG>;=)W0=fdH+@Y zQy=B?P&`gKX7}_%a~2&=T=P2u% z;zHMs8w&?dC&kDOrp()b_c@MH>H6IgZ;C5;N3rWW@o(%zVLw@4=W73!Nh@WKY#f8o(TZ$9bwVt!izh5tLrg(|-nf!@L6y~kxZG)3a*H5s&tZRzL z&QwHhB*ifT6y~hwtkd-ya4d7Ccp7?6ETTB1H>pGv&SgxvnKu~d{94Dm%18d^ow&YC zaWiiN-ZqX=`N(tZFYBA)Y2plT#jzOQc%p-teMGNo8=ThR+-1&NTZhW@?0C_{0cF;+ z$vTt`PAWZDjXxHgF;6GT%-MvqZrwW1r^J)yE)-{+-H?5GeP5>c#mo7R;*774<)&eT zkn)F4Koj{6Swrb71P5fEM zyK=sgj-P$G;GKz^^}UhtUDfYpGJOX#Uks(^@$-T0>N@3&=emIe>a?(L>wVh>se1V_ z;dyu_vyJ%2>TyWMndjkV@8jz9T=m=~^XWw7nUQ^CecxEkc`oSf8**vpyguiudEy+u Pmd0~{e@|SPvzqf?H%$+x diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/PEMElectrolysisSystem.slxc b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/PEMElectrolysisSystem.slxc deleted file mode 100644 index dcb0b3668034d961087e305779a3ae723a315048..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 5779 zcmbtY2UJsAvkv6aisg zNCE&r9{+D3E-Ef%1BSY|fW4szTd1ug4161kQ2udY^~Xc29}n@jws(48Qe(4Mnf$iAvUri&l$^>51ZB!I+Cqv=xwF0Om|!2Xwe7_7ik8DpC@bC{oT< z1H>+Xwt-H2Sx3)0vc4VVtRl82g%gz^aa>Ez1KDwE(?e=z;JYzN-S_ z>A3~~NckXYVY=gmbFYxw_!z4m?0U>oT+tiM=wRHu((r<9xrc%QC>=hUQJ@J z>*wdm9Yt0$Izagca*N|)R}$ybv*ydDV%aUTVUbOJjeVWD>DG8-yOnEeIZp$?-?|4s z8+0)uVnv-!7d5?3@5{vD3Yu|kkAysP-lrE1m7Nka8@?&a8P~V)wrYsf8J|lVgh7j) z)%G&$G&iR6PabuSAA(nMaD1qUIrZ0KO$D6ME50r7P&P=@-6iA~-P&^zPMc5f_LaL8 z+*F9tr7C0WmpZ*Z&hwEU34gdEj5J0HFGPq3UML?pzOZBITOw_Riwx7<9eb=lh-n_8 z9uEm%$ms17oY*pTXRqRve4VmwB607_5xT8L=Ol#D{e*C0PQlsy+F|yhmA1zhkKl05 zNgqp!Cd7$zxZom~s?2MPQL^tqQzG!gtl+V{SjT~1b1n+}{tK(PRjEe^k&f|-pl;=L zD<8)izSI^~!-<@pTUp#T>?^TI-BwKWw%{rl@myw6foAi_Y*0@vEI@gUl|jaMvutGN zJk);BI@j#7;Sx@GQ2)JD=c_XKWx6XUo#@K>p|m>U4J4Z(dc{YukzZt%T{X@@t)-Ga z?AQ*OZE{!_OCMG6GF@7x(7*Gwn6cb+=Sg0k(VcXJRlMEEgIg^B3aUCw7HG@t zr6Fxs^e`y6bk=xo|Gg2@h^khM#t>{i{-Q(waFjT5WVXbtZg7i#^VutkPJV~W)>c!K zPnH5UZBFuKzN|oBIe~aSACVBJQ%4yO3I?{ky%CUNRl?~&v*^f@dv(Qhz*Opih`Cko z_f-qETJX*57B%)$awjEo7IIeVT|+3ymQLpYZmM^`Y;{i@(|r8uvg$jpg9F9tdL5bh zS7qQ}IsVlN=jmF-BFhJ{ejKP?7r~Rt2W&}*1;3Y5hc5-LKDp|n9w5hHYHv3^Iw?JZ zv?RTE7!JvhbsK!;f_m9nj^1ROnWkr4fD9afe=PwCtT#pk@zrq}zgX}kzzLt%U^o=% z3Hv?85%?5$a&r~&g}Zp^E4jWFrD@!b?(ylS=1nltkul=hNhk{03aY7Ae3-3L>(sZg zqNi7^v0sbY?DxGb)Djza?QMPShDK6HmdYrm*{MNU-FxG1Mlwu_b|>Q$c9EAwF?%LR zexg2!t%(!Ggj|j!wgH~(k4+@U7`vs7A!|Pj(TJvkC42|H51~yTnS$pA|>;F7@|Wy&S6!&AatojKrhh- zv>Bv9nRuVoHY93!nm<}lW~DmW4Q3{l#4F6VR!XdUd@fJG;>l%{vp$7EE5`oWB}d}4 zC{@Gu5h1k#Ly4Lwc>Ed~@ED#Px?j8$cZK;y8||p6XXpKCrstKw{t;2zRD010>^ijQ zZd5u`M=OJ(Gga;R1Blao>%(|A8)}O>S#S>6`pb$0bmGeq&9D>OCEbBJ**gl}hdqT3 zABPvVs>oAm$C{fK8VbNB1;;OZETiioYRnkr?RtzvoNkQYf}aR3At9edGDd*lRCI#4 zdgkueJZ?5o#$%l0bz`S8wfzi+nZR=<+$1Ac&bLHCRHU&t#0gM{Lgt-vF*SURe^Ih3aVlg!bv`NL%js{whMRGZ z5skrz`3S$*|H>#^F9ZVS>Z$7HVh2OqK)CrJVTd0|1s`l6f2~LpHfv(~T$&XaeM=tm=1R z#5beX7?76n!T{fmYaE1iyz*q{E{auusRB%OMJ*+DEU3P-aNBnXY~6Y2tKA z75TUuN4FQq$G4r4rneLmlAh3gpp=asTNWo#>++?Vdq8eSY`(C2p?_t1VvFhz9|3>r zDz%z-n@0F8eTZL-fBEPRMR*!IIk-YSy$~?u5AU)Q`&>g5L5hK4{k0fiB#0Gz=RIGo zhKi$|Ein_vYf2z+e;?<}I^kNsv_6&f`Savt+gBCD)6Vm{6h%PH1ww-1Tv9`pmDaIA z4k@m0ELfT^M4fUnw$u-??ybXVdG#1k#xmkwuY~tf_rnuN$Sy_tkQOD|>cbl8LBDN1 zmh{t*;EPG3WG-?(GzUBwTNmd_s3-`HSrpc2I85cw!h|UsYtxxmgG%SoTI~v!-nP$2 zFKRprFQ{|+ zsCEWpg8D9HM&mB{XkgnhmE}jSc`8%2oUh*OL4iJ;Yz0HBpM2kazd9Y)_eR`F`nG6{ z2=gp~-0aO4?oxGe$G11r&05TPsC$xa`x+{H7mURAjdqMkn#AwgD4PgwRqf@h3qsx& zzTA7AQ%80EPX+f^AV3Q%iCBC9%<+NvvDx4-PpBQ#6AFg=*t#KLdI&dn7{b%(k8r>e z+ML@(DZ@AX$mb8|B=wluJWFXNV0_n5KGS(# zqTyEPp3X&454I5{KHU40(vxEH6rs7^E6T`Ek>EaSVf@+^Z0un zXo3vr&YG)Lm*(IKrxXazo{cTqxYA^{{Z8_RBP)h0Wj^VxqQ;ad-;TH!dQ+!U1k#v) z;8vlx@}jaVm+15Y<_YwE>b(YPX;-;@B%oX`(TeFChrwb7U0q*N0s&f)};DPSTnnM&rgH0i6t{QtWE@ zclZSc4Zzy&8rrKkb8KLK{`7u}f-fj0+ZD?wQ!Zy{ld2!v+Eb=)Z#ehlUiy^v=TOl{ zj`F~ZQ=#3C`WM4qK)k6rEF9X1h&XO0Z$ifD+>|S_Xux&3VM9Dno0scZ4BV-%$|VV$ zHbCA2PaVnMu#sFnTv}^(9VD;|m(jgVGh}^C2e2CQ`xK1wakFIXtxkco z9LZ6Wep31Y(+(#s_a5kAx z29-={cv>fk004SCt>(&ZuK29+v@-H@haoL~RQH<4+PbV_G~pWu=Tpo1R%kGVAub8I zH)o#&x)`jqe^8jM7fKnvW1t*6c)N9OKmk{u;9L#M^%F>f zGYsMm?&$?r#K`Avd%Fipu~D`h)srkz^Dgnq&5UUCQ(S&X%?(YLG7GRG6Waru!M*pY z#~e;;x^Do$8Isjv?2*=?+}Q85J=Zf+*&Uv7UYkgGF`clcKp)tvpIo|`+~cgoJI2`d z;g$m^m5kr;vZ6oPBaqZ>wsd%}&BlW~z4Ep9KrrdB_vOrtbNBb#O-+I;IMwqyyeaCH z!daNK1hY!Kaz;Z${HlO2O-~%Y&bW`Rr%M)7lU*rA06A(@Vj} z$8O6nhcs1<4z9J7A1?UYSvD_tY%u>?C+wkGT4;PA1xWw^3Va}~5HJ@cSmeiVXUZqt z*P@`#=>x%x=IS_%KT~*=Dm_Xvx;bOTdyJvh`;{=~$sWV4AS#z|vdz)~)1iYMJ0I4m z(&#MV1kdMoJ@Tj_=H6SK=~_2VuK79d$qp0SQNBuI+H!lJ_34pWyGeiBsIuIE#z0BT zdv4uF{BB`y^`nU#byN6C#f^=ED$O-i$gq@jpx_N3BKCXV^kXWcg;~3~3p^%gT?ilN zk{#TgA(6Hs+=2)N@l+_y0lz|<_9vrr?qXf@(@~5=!;e0X`QP2Ln4`@%euvIW-{mnT z%|5@akX-%AhLv_d+cIU>NPw}$s%?7usUlE}i6)W9pWB=+owCLu6Bo8w!f~^+#bTY1 z&A07<3V$LjSf0*o8qaq~RU5SnWqsjgx(ih+*CvZ+DRYq7FVnr207a-90?ZkZ@fpSJCuMb_oN$e z7VZG`GzkcW$^U(%g%9c9KL3va*I7enheJQDaN@Vq|JKmoMnz{0oIQH}G{A!|I{$tU zJ&SYpeDxD2jQE!q{nyjhS;Vsv{wJa*ey;dC%)bfxzo7nVPiK|#PpCU&e?t9JH=hML ztMYz=%#!~Pn(r*sS&{S;Y7Ji<{#8EyBAL!&o|Pg$F()Yh1LhfFau)S$WB-XdPxUv{ yf42FvKxbRoPawH-|7~MC3vjlC{saKh{!&o&G>Py#4gjFUe@pOlRV>|)yZ-`~38B^i diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/PEMFuelCellSystem.slxc b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/PEMFuelCellSystem.slxc deleted file mode 100644 index 51e87eaacbbd3a66e1a13986d70a452e9a77de69..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6001 zcmbtY2UJtrwhg@q2-3Sq5vd6s>7XSldH|??d1!7Y~pAJ^AQj68qEI(cRNo$M%mY zA!mrkt|!^Hn}+9SN8tjO53?S&wjM68#`u*c^?!H=UJ8=QnrpP{^`7IbJ3m=`At}`r z{_uR#*#uR^(!?&;fmWzIjrc;@heOAwV40ix(a`=x_`!VG`xvrv>HtZd!g3U*pv)1mNfip7kxX;Ut&hs>IYLDZ<=FLUuHTs2iWgO?o9V8kYd8RRS)j5Z&%o6 z3o;m?Y7eHOS}e1}ih6(aw)oSTcYh_ybp7)EC37?UWIT97Vw1k#Bvu}kn}(|{XqGKdiOt`{=@9pmr* zP5m9y9$DunK6x=$zdZCDq&X4E7}szQv>h566uj+U-<4*i5UEcEj@LSj{AeY6O2n*} zT9;Wzq+NtLbN^btk-miT=6lm09BMC$o|Be5@)$HJ)+@1JaY8p`BDr#-MX46lZX{kQ zL{mzW?rvpy^P$~4o7|gg7|Xx87Q8RlsP=3vn$#f;NRgBO=vmhgNclsntCG}YLibUl zn^Xp@wGFY}P~?*rGNgHUMZxd}m@Tm=Dz~C#^Z0w)`_G)~A-@kD=LuBE8Yr^E|r($trPU>Fc;jrCVaObD^s|foq z`QxWFS7*SRv&-e{(iEMh+PG=lrest(6*^xB>q`_Wm;9e!RUJy(-9p9qw%E#12T34m z1=$f{yM}?wQZ(gz0(gR4Jk3!Kl$=C17Bij!B!N8Hfz4eROE5(7?TCVhmh7}EF6gbG zgvb+WEMur8TJLOMM1Oruw$Gx?l9Lm=QL-7y2EtoT@@%kbv^tBs4DGd<4;}*V65L0L zZeQ<+J7ct(5l4dDi*B)@`|Anp%#h^{r}d+vZfvFJJ+iu!#oiO12Cddv8t2-m$Qg|u zl#(U;S?mA`nmWkkK2MDjfq9(j{d$dZPs!(3MlK^em(=vN&A@pea z$agsZ)>Wro9nv#Z1|7a@E-Otk=J*CJ7KIF9O$s+ul}Ox*Bxo3}#(Pdey-O>u|zpCSC%Fc%>oXD3fRC6^E&WfPh<8PoNIvMq@t{Ka$MoYMFe z9Oef%c_prEO|Kk?YvkWgs;Zka8H%~YXy%VPMxL zKSBjHXOBi2b=?%gK0JwgwB7d+A_3?m1F6zbK$adDBfoA|I z1BQ%&zWcw0k|(bL7*jx?vD>kmlg_)NR8}B-Hxl}Z!3pChJYyO2gIRNOcE*kiS?;;0 z9GB55*SObI1&Zx`yn?Y5(+bDyWOEIY-+OPi+O4UVFbqvnefOM};&qr=$Lk{3xo&4V zIQ?18#4e_*j|B~Cm-z&G51GpgUA?2W6_Ym^vpDgBj>gTT?}metgD|bsssfpQgHR01 z9VsGPy;5y;{8A97IkaKWP?J0MNQ~lU0Zf=6$9{t*y)|9F>X`Ud3ScN*2)V(`l-Qjx zY$zDDUJ8oTN*YF_wz7~Qy=Vsn;eKq*tPHzr#jah==XJE*?6dVkKoQ9_Azluu(fA=A5{%-|=(yvt-Gz zFM9O~IKMiZ{(!!)1ncBe>|p(CKUsUi;ZPS3RhW|v6s`=1dAmd57hB4Cu#xn4Mar;G z#wJCQ%y>`Lg>ozfmDnw{RH;Q8`9(8cz+j}W-pF(gb-#aEY%TiSp4}g(kBdO1g~S;H zBS7hdcM?Xc?g_%b8MZ~yXc?^x@G8r*;ns1kRe!1ZO{nYSqp9<4_>0JnNx5LM zbg_1m&AFatcBf>aiSM!34v@UOyXmRAYf-^zaotBsnT1p9B1CFkKIBV*q&9?RE8jW$ zHx_1g$p394;7`#wnbLX15F5}Z*g^l7jjj;5hk=8g3&g_{4t2kmD1w&1_Bj(-xB9u;?T=5#ld7cQ#JxtZBJHL`I)- z5(0P(j3Py1X}=KU-{?#>sd1&y*J&kKP1zJsA$;^mrl+;X`5><@ZO7MafHQT*?Kbc4 zdoA;li5D$p3v$r)24%LOj zT%m9ehkv^R8rS}~14#A+gCJc#SrXG_=y1Cl!q&aoK%~n$k~&#cIqQWuK>$_9=H5MP z!O)L3mM?bFiZ-f;%)ZH_QJ08~9Sk{@-OA1?T*MU%eij;H9#=S-rW&3R!?@tCl^Uf& zXLLulrzCMNk7kAh&y_hxt1i{f#hHvRDDzWvDMq5%bazxt*`B%NdeUJ~cjHY%F}u^r*ErSICMCt)?Wo8JlF2@XQ^199`6L{ne49n6HW0C$wqRkc4V z24ydTN_*8;jZBD)?d)73fM@d@%U5Q@f!VzKr9^@OWzbdQ4OMpjmumv!yfQf?%eT(< zhs*%G^=;75xChC(w-A}%3JA0x5c4J9kK@Qi5s$rhH5f=4iaC8+b1ajVD9PSndzl*Ayg4x=o6qg@U=oEs-B}jJ6pDK!136`#;=Qy=?fi%N9=ova7T1w;Q zrWWYt@sMEfd`kEI1+uRU&`*qB>#yPYfMtlgm(EyH!W=yXAp1AV+&=U5V=+sdD5)cO z#)x$a!%OL-!H@ij&l}dia^Bc@+GM=wwsTLRBq-|D*Pvs|drv~SKgJivOYXi1W7q3V z-tK)SotE42z7@UjD-WTOEIC|Q4rH*kmHF>H{Ac_p#VhG_T&L;AoY92(-CL6oFW96= z&lCfhE-#U;dO3U7N1X?b{(NUYAbYPm=*q4^Rp47B+iRwK0Y3aVZ=)%D)nusY-i9*~5S^rL zrZx?_U`lC)s>RISiA9YelAumr1FNTkH<8CfD84d#&U22;Vkb8~IZ{H$2P=m}y~Qds ze%jixdAYY2ych#6rI#%IN`_P{xw8ZS05z6eGZmN%cJFvRGDNsS-7PM1d`%))hZ#iq z1am~2T+X{eS@I&-DK6*kdYG!e#fXQudYO;2qb$d#1<@#u>ESozH=3uiyjKw2kMhTi zmOpUnSGA`cS1{OzwUE~AkLfSWoA0$gPGayU7xEFC55~(`?d1@=gz>>!2qdFAe;<)OjQ!*my|67=~XO@cdzP?KI z;Qh9x0omh*xX0Dd90XsyGu`0vk*{u0MU+g=u9quPoQ16Qw1Egs!L`P9d+{Uq)|H!~ z6daH=anpcDB%lLfQ)jP(>M6VPnr>x)aJpDEh&948gkxlnsz)IsnbodO!Vrazgv!prqT44h7bjvqC;0Y6tdELxN zzv_3`VPYIq!LE__&g)8p(i0{IEq+v)XZB>U5TXk2t;r9&z2m&iEl6gSx2W-vTU|NC zTPCyMYyoTzQbK!ro$~~pox#@M4&75VJd$rMKUwj&dDybzhGG15moze`@#J6~DL@1O zT){f>5gh8|E-ZBM-I-)|QKZ8bj%Wv3`jm|*RX`)^zb6n1m)kmpj}C81RQGKz$b{kB zx0648S2x$cCH-hfyJ)WQZnCc^SAsolgl#j2tYL2KHCm#j%^IW|r>wQo-MGhLK@ak% z<}J!UvRaWQ3#YloGe0v*BzZSEeR^M$Iu?XyFd@zNI$8{BiMUtU&w)~m9)*dS#(Rn1 zDPKWwo4_auf(i8!avug+y$R|WR>r5Zc|npL$=btXzwXo#o-Cb3$Z_wO{-{f_2eX}S z)^sOEtS=!z!-~L5Q(KIXX-FKbCHEmsOhW=pEj}fnyy#9gwZ|U^#Un~@{vzeBmry=v9*Y65lSPl=AU z#FfT7+Pyu2OSF7K0__Nmmvr4wUyJu*sB5`Z0hy}m2L))tHL{9uCzixl*^XH2UX8%pm{{{7zLc1)Le?p0q z{t5M;!uc}DWtsOAqy@X1|55Z^hPtehenRz<{R7l5n&~p;Wi9d(^DX&5U|v!tmr*ZQ z_MfP26n{hg&pLk@=yDbN3B*eIKi0I%0GG4pPkB|RX2LLe}5OV-AFA#$OD-eVD zEI`Z%#r#0pJtsdYF(*8~D7&~IF*y~iPXH)>MYiW=Kf@-LmkpdV-u!T?BgI@Epnm84 uytK^p;M9_!)HEQMD&~UR;G3V4isW3lxj#0YoNc!2dnJ4Pzr#+2>G}Wy$VNH< diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml deleted file mode 100644 index 9414d4d..0000000 --- a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/tmwinternal/simulink_cache.xml +++ /dev/null @@ -1,6 +0,0 @@ - - - - ekcxxpQ/6HRJC8J/tqoVG16wr9UZSgRqVNb+q5DgwRBcUIvB8a3lJ/vtwwx6/F4OqfWyoMon1TG+xKDQ9uMoYQ== - - \ No newline at end of file diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/varInfo.mat b/Shift Matlab Drive/Shift Matlab Drive/Simulations/Ready Made PEM fuel cell/slprj/sim/varcache/PEMFuelCellSystem/varInfo.mat deleted file mode 100644 index ff031c85c14e95db094258073ed08b02b5d07d13..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 21008 zcmeI4-EZ4A6vY*w+k&?1+CCKMn;!Pq4u+QugP)WoKvTd@)68r3MldoR3(?nTrGfwZ zo-0|F>dK^QTTiPR7HNzue>BdhY0C{B|0I>WzCD%50kGXy9I+ zUcbNiSYPo=M%@2US3^-q&{8r=S^vMV)3nAbo2Xukdc z$I%D#LS zT*vGOop9y$s~f#?`_+Q$HtiR@fZH#yt>;nu^4SlZe|5!``vooh;Cu60=#|^AZn$#$ z)q?9b?H4r5?N`h8%foS|{FKHmtGvx|D3&n>0!4Ozqr@4)e7wxV+H{`(`*@;_59MBU z&J_DHo7G8kerC_l&Mi88xyG4dKZ#NiO_EIbiPmB~{0AFRn75s`2TrE%{d4TE>zd-6 zcPg~Zf`n)@=iNCs`E<@%r%|bB=4|J@oqr^uj5876M$>bwV{k}TyEQl0ywsW?Pf6zOq>zZN}e->BxLNMRm`8NH& zPkhJV%zV4!n=;>4zmwSf;iol!pqTW#_|Rwlg2myI4|!^HhH0I25n+ECVeh zCcTSk5F-a_CcZs+cSlZpEi?62#b;uUwFdU?#b zjh}enWa4aWA61rH3F~=xJvaT%veL7jC9LOm?W0Z4P4fj-oHOwt!;t+MV%s%;F>|IV z9_P%t1!r4-uW9_b(lc=$s{hD5P}rw;*L73BW1dO>PMnF`NywZ*U?2UC&75VJ&Lnf* z6X&M9ywEcxiaBQX4Pdafhqm$3vOW=|J~hP!=U~Xb+$rCL`P%t<(4#32Y|2jx{YDs1 zDiUtyygTQg@gC~q8WdNYi$st)+c|I3Z!S4UH(JI@jF!XF-2Op>W&1_itn^v^o@L|R zG(UQc_i~hj^OSw`pPTaUf;Y`3^;L*TVC*AZ>N@Al^X=dlP5<9wlaF{f-qa7-oEK)C ze}f&BefUSyxPRdvnTS-;Lb89@{lmliFzI **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | [`docs/_originals/Forecasting requirements.pdf`](../_originals/Forecasting%20requirements.pdf) | +> | **Format** | PDF, 10 pages, 434 kB | +> | **MD5** | `44db223db7d9301f20dff25b4ab360de` | +> | **Owner** | AI & Control Systems cluster | +> | **Status** | Current — the authoritative forecasting spec | +> | **Report generated** | 2026-07-25 | + +> [!NOTE] +> Tables in the source PDF interleave columns when extracted mechanically. The tables below are +> **reconstructed** from the source content. Where the original author marked a judgement as +> AI-generated rather than their own, that attribution is preserved. + +## Scope + +Specifies three forecasters that feed the simulator's exogenous inputs +(`G(t)`, `L_crit(t)`/`L_noncrit(t)`, `price(t)` — see +[Simulator I/O Interface §2.1](simulator-io-interface.md#21-exogenous-time-series)): + +1. **PV generation forecasting** +2. **Hospital electricity demand forecasting** +3. **Day-ahead electricity price forecasting** + +--- + +## 1. PV generation forecasting + +### 1.1 Inputs + +Most studies show global solar irradiance is the dominant factor; cloudiness, temperature, wind +speed and humidity are the next most important weather variables. Solar position is also usable. + +| Category | Features | Notes | +|---|---|---| +| **NWP forecasts** (primary) | Forecast global irradiance (GHI), DNI, DHI; 2 m temperature; cloud fraction; wind speed; relative humidity | KNMI HARMONIE-AROME model; 2 km resolution; updated hourly | +| **Solar position** | Solar zenith angle, azimuth angle | Computed via `pvlib`; adding these reduced RMSE by **13.1%** in [1] | +| **Clear-sky index** | Actual GHI / clear-sky GHI | Normalises seasonal/diurnal trends; stabilises model variance | +| **Historical PV lags** | t−96 (same time yesterday), t−672 (same time last week) | Valid lags at forecast issuance time | +| **Calendar features** | Hour of day, day of year, month, `is_weekend` | Cyclical encoding avoids discontinuities at midnight/year-end | +| **Panel system config** | Tilt angle (35°), azimuth (180° south-facing), system size (~100 kWp), panel temperature coefficient | Fixed inputs; used to calibrate `pvlib` simulations | + +> [!WARNING] +> The lags `t−96` and `t−672` are **15-minute-resolution** lags (96 steps = 24 h, 672 steps = +> 7 days). The rest of the project — and the simulator's default `dt` — assumes **hourly** +> steps, where the same lags would be `t−24` and `t−168`. Resolve which resolution the PV +> forecaster targets before implementing. + +### 1.2 Models + +Tree-based ensembles — Random Forest, XGBoost, LightGBM — are computationally efficient +baselines. A 2022 benchmark comparing 24 ML models across 16 PV plants at 15-minute resolution +confirmed they are competitive after proper hyperparameter tuning [1]. However, they forecast +each timestep independently, ignoring temporal dependencies across the 96-step output sequence. + +For the primary model a sequence-to-sequence architecture is recommended. Hybrid +CNN-LSTM-Transformer models show state-of-the-art accuracy for day-ahead multi-step PV +forecasting: Kim et al. [2] showed a combined LSTM-Transformer model outperformed a standalone +LSTM by **48.3%** in MAE. A 2024 systematic review in *Heliyon* confirmed Transformer-based +architectures achieve the best accuracy on PV forecasting tasks [3]. + +**Recommended stack:** + +| Model | Role | +|---|---| +| LightGBM or Random Forests *(author's preferred choice)* | Fast, interpretable baseline; also used in the production ensemble | +| LSTM or GRU | Captures intra-day temporal dependencies | +| Temporal Fusion Transformer (TFT) | Best multi-horizon architecture with native probabilistic output | +| **Ensemble** (simple average of LightGBM + TFT) | Consistently reduces error versus any single model | + +Further model comparisons: see [1.1] and [1.2]. + +### 1.3 Metrics + +| Metric | Role | Notes | +|---|---|---| +| nRMSE (% of capacity) | Primary | Normalised by installed capacity; enables comparison across systems | +| MAE (kW) | Primary | Robust to outliers; most intuitive for operations | +| Forecast Skill Score | Essential | `SS = 1 − RMSE_model / RMSE_persistence`. Values > 0 indicate improvement over smart persistence | +| MBE | Secondary | Detects systematic over- or under-prediction bias | +| CRPS | Probabilistic | Continuous Ranked Probability Score; evaluates the full predictive distribution | + +--- + +## 2. Hospital electricity demand forecasting + +### 2.1 Inputs + +| Category | Features | Availability | +|---|---|---| +| **Historical load** | Hourly/15-min lags: t−1, t−24, t−168 (same time last week); rolling 24 h and 168 h statistics *(needs further discussion)* | *"God help us (maybe we can go and measure ourselves IDK)"* | +| **Weather** | Outside temperature **(most important)**, relative humidity, wind speed, global solar radiation *(relative importance needs more research)* | KNMI | +| **Calendar** | Hour of day, day of week, weekend, Dutch public holidays, school holiday periods | *"This should be easy"* | +| **Operational info** | Shift schedules, elective surgery schedule binary (on/off) | *"Got to beg for this I guess"* — recommended by AI, purpose unclear to the author | + +> [!IMPORTANT] +> Historical hospital load is flagged here as the single biggest data risk, and it is not yet +> resolved. See [BIDMC dataset work](../03-energy-management/) — the current proxy is the +> [NREL ComStock hospital load profile](../03-energy-management/bidmc-parquet-load-data-manual.md), +> not measured BIDMC data. + +### 2.2 Models + +For 24-hour-ahead multi-step forecasting, the Temporal Fusion Transformer is the primary +recommendation. TFT processes static metadata, known future inputs, and past-observed variables +through separate attention pathways, and natively supports quantile regression for +probabilistic output [6] — important for RL because of uncertainty. Multiple building-energy +studies confirm it outperforms standalone LSTM at short-term multi-step load forecasting. A +directly relevant 2025 study used LSTM forecasting combined with PPO reinforcement learning for +a **1,500-bed hospital microgrid** and reported strong performance [7]. + +Ensemble methods such as boosted trees and random forests are reasonable baselines but have no +native sequence modelling. Classical linear time-series methods generally perform worse, though +SARIMAX is attractive as it is far less computationally expensive than TFT or LSTM. + +| Model | Strengths | Weaknesses | Verdict *(AI-generated, per author)* | +|---|---|---|---| +| **Temporal Fusion Transformer (TFT)** | Handles mixed input types; native quantile output; interpretable attention | Higher training complexity (too much compute needed) | **Primary model** | +| **LightGBM / XGBoost** | Fast, interpretable, competitive on tabular data | No native temporal sequence modelling | Ensemble component and baseline | +| **SARIMAX** | Statistically rigorous; handles seasonal patterns | Cannot capture non-linear relationships | Baseline benchmark | +| **CNN-BiLSTM** | Captures local and bidirectional temporal patterns | Needs more tuning than TFT | Optional comparison model | + +### 2.3 Evaluation and metrics + +Evaluation **must** use rolling walk-forward cross-validation — not random train/test splits — +to preserve temporal ordering and prevent data leakage. Test data should span **at least four +full seasons**. Always report forecast skill relative to a naive same-weekday-same-hour +persistence baseline. + +| Metric | Role | Target / note | +|---|---|---| +| MAPE (%) | Primary | | +| CV-RMSE (%) | Primary | Target **< 5%**; minimum acceptable **< 10%** for 24 h-ahead hourly forecasts | +| — | Secondary | Target **< 20%** (hourly); ASHRAE Guideline 14 threshold for model calibration | +| R² | Bias check | Target **> 0.95**; intuitive variance-explained measure | +| NMBE (%) | | Normalised Mean Bias Error; target **±5%**; flags systematic over/under-prediction | +| Peak MAE (kW) | Operational | Accuracy specifically during morning and evening demand peaks | + +--- + +## 3. Day-ahead electricity price forecasting + +### 3.1 Inputs + +Feature selection for Dutch electricity price forecasting is well established. The strongest +predictor is the price itself — autoregressive lags dominate — while renewable generation +forecasts provide the key exogenous signal. + +| Feature category | Specific variables | Source | +|---|---|---| +| **Autoregressive price lags** | All 24 hours from days d−1, d−2, d−3, d−7 (**96 lags total**); constitutes the core of the LEAR model | ENTSO-E Transparency Platform | +| **Renewable generation forecast** | Wind generation forecast (onshore + offshore separately); solar PV forecast. In 2024 wind contributed ~27% and solar ~18% of Dutch generation. Correlation with price: **r = −0.84** | ENTSO-E Transparency Platform | +| **Load forecast** | Day-ahead total electricity demand forecast for the Netherlands bidding zone | ENTSO-E Transparency Platform | +| **Fuel price** | TTF natural gas spot price (Dutch Title Transfer Facility): the marginal cost signal for gas-fired generation (~34% of Dutch generation) | ICE Futures Europe | +| **Carbon price** | EU ETS CO₂ allowance price; affects marginal cost of fossil generators | ICE / Trading Economics / Investing.com | +| **Cross-border flows** | Net scheduled import/export with Germany (NL-DE), Belgium (NL-BE), UK, Norway. The Netherlands has **> 9 GW** interconnector capacity | ENTSO-E Transparency Platform | +| **Calendar features** | Hour of day, day of week, `is_weekend`, Dutch public holiday flags | *"Obvious"* | + +### 3.2 Models + +The electricity price forecasting (EPF) literature has converged on a clear hierarchy, anchored +by the benchmark work of Lago, Weron and collaborators [8][9]. + +The **LEAR** model (LASSO-Estimated AutoRegressive) is the gold-standard baseline: 96 +autoregressive price lags (all 24 hours from days d−1, d−2, d−3, d−7) plus exogenous regressors, +with LASSO regularisation for automatic feature selection. Many complex deep learning models +fail to outperform LEAR despite orders of magnitude greater computational cost, making it an +essential benchmark. + +Deep neural networks with 24 (or 96) joint outputs and **NBEATSx** — NBEATS extended with +exogenous variables by Olivares et al. [10] — improve on LEAR by roughly **5–20%**. The TFT +shows strong results for probabilistic price forecasting [11]. The most consistent finding +across the EPF literature is that **ensemble averaging of 2–4 models reliably outperforms any +individual model** [8]. + +| Model | Strength | Weakness | AI verdict | +|---|---|---|---| +| **LEAR** | Fast, interpretable, strong baseline; well studied for EU markets | Linear; cannot capture non-linear price-spike dynamics | Essential baseline — always implement first | +| **NBEATSx** | ~20% improvement over NBEATS; strong exogenous handling | Higher implementation complexity | Strong alternative to DNN | +| **DNN (24-output)** | Captures non-linearities; modest improvement over LEAR | Requires hyperparameter tuning; less interpretable | Recommended primary DL model | +| **Temporal Fusion Transformer** | Native quantile forecasting; handles mixed inputs | Heaviest architecture | Recommended for probabilistic forecasts | +| **Ensemble (LEAR + DNN + TFT)** | Consistently best overall accuracy | Requires all three models to be maintained | Recommended production deployment | + +> Models must be recalibrated **daily** using a rolling **730-day** training window to capture +> evolving market dynamics. All test sets must span at least one full year: the 2022–2023 energy +> crisis fundamentally altered Dutch price distributions, and models trained exclusively on +> pre-crisis data fail to generalise. + +### 3.3 Metrics + +| Metric | Role | Notes | +|---|---|---| +| MAE (€/MWh) | Primary | The standard metric in EPF literature; robust to outliers and sign changes. Typical range: **2–8 €/MWh** in normal market conditions | +| RMSE (€/MWh) | Secondary | Penalises large errors (spikes) more heavily than MAE; useful for tail-risk assessment | +| rMAE | Relative benchmark | Relative MAE versus the naive same-day-last-week persistence benchmark; enables cross-market comparison | +| Diebold-Mariano test | Statistical significance | Use the multivariate DM test (Ziel & Weron, 2018) for a single significance statistic over the full daily output vector | + +### 3.4 Challenges + +Structural features of the Dutch market that make price forecasting harder than demand or PV: + +- **Negative prices are now routine.** Rapid growth of offshore wind (Hollandse Kust projects) + and rooftop solar creates regular oversupply, especially on weekend afternoons. Standard + models struggle with the resulting bimodal price distribution. +- **Price spikes during scarcity events.** Cold, calm periods (*Dunkelflaute*) with low wind and + solar output can drive prices to the market cap of **€3,000/MWh**. Models must handle + heavy-tailed distributions. +- **Market regime changes.** The 2022–2023 energy crisis caused a structural break in price + distributions. All models must include sufficient post-crisis training data. +- **15-minute MTU transition (October 2025).** The shift to 15-minute market time units + **quadruples the forecast output dimension from 24 to 96 values per day**, requiring models + that scale efficiently to higher-dimensional outputs. + +> [!NOTE] +> The 15-minute MTU transition is described here as forthcoming. As of this report's date +> (2026-07-25) that transition has passed, so it is now a live constraint rather than a +> forward-looking one — and it interacts directly with the simulator's open question about +> whether `dt` should be hourly or sub-hourly. + +--- + +## References + +| # | Reference | +|---|---| +| [1] | Mayer, M. J. & Gróf, G. (2022). Extensive comparison of physical models for photovoltaic power forecasting. *Applied Energy*, 324, 119526. DOI: [10.1016/j.apenergy.2022.119526](https://doi.org/10.1016/j.apenergy.2022.119526) | +| [1.1] | Husein M, Gago EJ, Hasan B, Pegalajar MC. Towards energy efficiency: A comprehensive review of deep learning-based photovoltaic power forecasting strategies. *Heliyon*. 2024 Jun 27;10(13):e33419. DOI: [10.1016/j.heliyon.2024.e33419](https://doi.org/10.1016/j.heliyon.2024.e33419). PMID: 39050417; PMCID: PMC11268202 | +| [1.2] | Ahmed, R., Sreeram, V., Mishra, Y., Arif, M.D. A review and evaluation of the state-of-the-art in PV solar power forecasting: Techniques and optimization. *Renewable and Sustainable Energy Reviews*, 124 (2020), 109792. DOI: [10.1016/j.rser.2020.109792](https://doi.org/10.1016/j.rser.2020.109792) | +| [2] | Kim, T. et al. (2024). Day-ahead multi-step PV generation forecasting using LSTM-Transformer hybrid. *Renewable and Sustainable Energy Reviews*, 199, 114479. DOI: [10.1016/j.rser.2024.114479](https://doi.org/10.1016/j.rser.2024.114479) | +| [3] | Al-Rakhami, M. et al. (2024). Deep learning strategies for photovoltaic power forecasting: a systematic review. *Heliyon*, 10(9), e30940. DOI: [10.1016/j.heliyon.2024.e30940](https://doi.org/10.1016/j.heliyon.2024.e30940) | +| [4] | González González, A. et al. (2018). Evaluation of energy consumption in German hospitals: benchmarking in the public sector. *Energies*, 11(9), 2279. DOI: [10.3390/en11092279](https://doi.org/10.3390/en11092279) | +| [5] | Parker, S. A. et al. (2019). Energy consumption analysis and characterisation of healthcare facilities in the United States. *Energies*, 12(19), 3775. DOI: [10.3390/en12193775](https://doi.org/10.3390/en12193775) | +| [6] | Lim, B. et al. (2021). Temporal Fusion Transformers for interpretable multi-horizon time series forecasting. *International Journal of Forecasting*, 37(4), 1748–1764. DOI: [10.1016/j.ijforecast.2021.03.012](https://doi.org/10.1016/j.ijforecast.2021.03.012) | +| [7] | Ahmad, M. et al. (2025). AI-driven energy management for hospital microgrids integrating LSTM forecasting and reinforcement learning. *Scientific Reports*, 15(1). DOI: [10.1038/s41598-025-28907-5](https://doi.org/10.1038/s41598-025-28907-5) | +| [8] | Lago, J. et al. (2021). Forecasting day-ahead electricity prices: a review of state-of-the-art algorithms, best practices and an open-access benchmark. *Applied Energy*, 293, 116983. DOI: [10.1016/j.apenergy.2021.116983](https://doi.org/10.1016/j.apenergy.2021.116983) | +| [9] | Weron, R. (2014). Electricity price forecasting: a review of the state-of-the-art with a look into the future. *International Journal of Forecasting*, 30(4), 1030–1081. DOI: [10.1016/j.ijforecast.2014.08.008](https://doi.org/10.1016/j.ijforecast.2014.08.008) | +| [10] | Olivares, K. G. et al. (2023). Neural basis expansion analysis with exogenous variables: forecasting electricity prices with NBEATSx. *International Journal of Forecasting*, 39(2), 884–900. DOI: [10.1016/j.ijforecast.2022.01.002](https://doi.org/10.1016/j.ijforecast.2022.01.002) | +| [11] | Jiang, W. et al. (2024). Probabilistic electricity price forecasting using LASSO-TFT hybrid models. *Journal of Forecasting*, 43(5). DOI: [10.1002/for.3097](https://doi.org/10.1002/for.3097) | + +Note: references [4] and [5] (hospital energy benchmarking) are listed but not cited anywhere in +the source text. + +## Related + +- [Simulator I/O Interface](simulator-io-interface.md) — consumes these forecasts as `G(t)`, `L(t)`, `price(t)` +- [PV Hourly Dataset Manual](../03-energy-management/pv-hourly-dataset-manual.md) · [Satellite PV Dataset Manual](../03-energy-management/satellite-pv-dataset-manual.md) +- [BIDMC ComStock Load Profile](../03-energy-management/bidmc-parquet-load-data-manual.md) — the current hospital-demand proxy +- [Work Packages](../01-project/work-packages.md) — WP2 covers the forecasting stack diff --git a/docs/02-specifications/rl-action-variables.md b/docs/02-specifications/rl-action-variables.md new file mode 100644 index 0000000..6cfe882 --- /dev/null +++ b/docs/02-specifications/rl-action-variables.md @@ -0,0 +1,111 @@ +# RL Action Variables + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | [`docs/_originals/ACTION VARIABLES AND DESCRIPTIONS.docx`](../_originals/ACTION%20VARIABLES%20AND%20DESCRIPTIONS.docx) | +> | **Format** | Microsoft Word (.docx), 16.2 kB | +> | **MD5** | `9939b9c2f76fbb5bf54fbfeff25a31f4` | +> | **Owner** | AI & Control Systems cluster | +> | **Status** | Current — but broader than the simulator currently accepts | +> | **Report generated** | 2026-07-25 | + +## What this document is + +The action space for the reinforcement-learning controller: every lever the agent is allowed to +pull at each timestep. Sixteen actions, spanning direct power setpoints, discrete mode +selections, and demand-side commands. + +## Action variables + +### Generation and storage setpoints + +| Action | Description | +|---|---| +| `PV_Setpoint` | Command that limits or caps the PV inverter output to avoid overgeneration, match load, or reduce battery stress. | +| `Battery_ChargePower` | Amount of power (kW) the controller instructs the battery to absorb; used when excess solar or cheap grid power is available. | +| `Battery_DischargePower` | Amount of power (kW) the controller instructs the battery to release; used to support critical loads, reduce grid cost, or stabilize voltage. | +| `Battery_Mode` | Direct mode selection (charge, discharge, idle) that constrains what the battery is allowed to do in the next control interval. | + +### Hydrogen chain + +| Action | Description | +|---|---| +| `Electrolyzer_PowerSetpoint` | Electrical power sent to the electrolyzer to control hydrogen production; higher power increases H₂ output but consumes more energy and heats the stack. | +| `Electrolyzer_Mode` | Operating mode such as standby, active production, cooldown, or shutdown; controls whether the electrolyzer is allowed to start producing hydrogen. | +| `FuelCell_PowerSetpoint` | Power command that determines how much hydrogen is converted back into electricity; used to supply critical loads during low-PV or grid failure conditions. | +| `FuelCell_Mode` | Operational mode (idle, ramp-up, nominal, emergency) that governs stack usage and prevents rapid degradation. | +| `HydrogenTank_ValveCommand` | Opening/closing command controlling the flow of hydrogen between the tank and fuel cell or between tank and buffer systems. | + +### Grid exchange + +| Action | Description | +|---|---| +| `Grid_ImportPower` | Amount of electrical power drawn from the grid; controlled to minimize cost, follow load, or maintain battery SOC. | +| `Grid_ExportPower` | Amount of power sent back to the grid; used when PV or fuel cell production exceeds local demand and export is economically or operationally beneficial. | + +### Demand side + +| Action | Description | +|---|---| +| `Load_SheddingCommand` | Decision to temporarily turn off certain non-critical loads to preserve battery SOC, maintain resilience, or avoid overloading. | +| `Load_ShiftingCommand` | Reschedules flexible loads (e.g., HVAC pre-cooling, non-critical equipment) to times of high solar availability or low grid pricing. | +| `ThermalManagement_Command` | Controls cooling or heating for PV inverters, electrolyzers, battery packs, and fuel cells to maintain safe temperatures. | + +### Supervisory + +| Action | Description | +|---|---| +| `Microgrid_Mode` | High-level system mode (normal operation, island mode, emergency mode, cost-optimization mode, resilience mode) determining overall behavior and constraints. | +| `Forecast_UpdateTrigger` | Forces the agent to update internal predictions (PV forecast, load forecast) earlier than scheduled when sudden weather/load changes are detected. | + +## Scope gap against the simulator contract + +The [Simulator I/O Interface](simulator-io-interface.md) defines a much narrower control input +set — five signals, of which two are optional: + +| Simulator control input | Corresponding action here | +|---|---| +| `u_ele(t)` — electrolyser power setpoint, W | `Electrolyzer_PowerSetpoint` | +| `u_fc(t)` — fuel cell power setpoint, W | `FuelCell_PowerSetpoint` | +| `u_batt(t)` — signed battery setpoint, W | `Battery_ChargePower` + `Battery_DischargePower` collapsed into one signed value | +| `sw_ele(t)` — electrolyser ON/OFF (optional) | `Electrolyzer_Mode` (coarser) | +| `sw_fc(t)` — fuel cell ON/OFF (optional) | `FuelCell_Mode` (coarser) | + +**Nine of the sixteen actions listed here have no simulator counterpart:** `PV_Setpoint`, +`HydrogenTank_ValveCommand`, `Grid_ImportPower`, `Grid_ExportPower`, `Load_SheddingCommand`, +`Load_ShiftingCommand`, `ThermalManagement_Command`, `Microgrid_Mode`, and +`Forecast_UpdateTrigger`. + +Two of those gaps are deliberate design decisions recorded in the simulator sheet: + +- **Grid import/export is not an action.** The simulator treats the grid as the *slack bus* — + it absorbs whatever residual remains after every other component acts, bounded by + `P_grid_max` and `grid_on(t)`. Exposing `Grid_ImportPower`/`Grid_ExportPower` as independent + actions would over-determine the power balance. +- **Load shedding is an outcome, not an action.** The simulator reports `unmet_crit(t)` and + `unmet_noncrit(t)` as consequences of the setpoints, and overrides the policy outright if + critical load would go unserved. + +The rest — PV curtailment control, thermal management, mode supervision, forecast triggering — +are genuine capability gaps between the two documents that need a decision. + +## Design questions still open + +The simulator sheet raises two action-space questions this document does not answer: + +1. **Continuous or discrete?** Continuous setpoints (`u_ele ∈ [0, P_ele_max]`) versus discrete + buckets. This document implies continuous power setpoints alongside discrete `*_Mode` + selections — i.e. a hybrid action space — but never says so explicitly. +2. **Should simultaneous electrolyser and fuel cell operation be structurally forbidden** + (via a mode-switch action space) or merely penalised in the reward? This document's + `Electrolyzer_Mode` and `FuelCell_Mode` are independent, which permits the physically + wasteful both-on state. + +## Related + +- [RL State Variables](rl-state-variables.md) — the observation space +- [RL Reward Function](rl-reward-function.md) — the reward terms +- [Simulator I/O Interface](simulator-io-interface.md) — the typed simulator contract +- [Rule-Based Controller](rule-based-controller.md) — the baseline policy diff --git a/docs/02-specifications/rl-reward-function.md b/docs/02-specifications/rl-reward-function.md new file mode 100644 index 0000000..12f4245 --- /dev/null +++ b/docs/02-specifications/rl-reward-function.md @@ -0,0 +1,128 @@ +# RL Reward Function Components + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | [`docs/_originals/REWARD FUNCTION COMPONENTS AND DESCRIPTIONS.docx`](../_originals/REWARD%20FUNCTION%20COMPONENTS%20AND%20DESCRIPTIONS.docx) | +> | **Format** | Microsoft Word (.docx), 17.0 kB | +> | **MD5** | `5d2828ea38008cbeaccd35b4672a9191` | +> | **Owner** | AI & Control Systems cluster | +> | **Status** | Current — component list complete, **weights undefined** | +> | **Report generated** | 2026-07-25 | + +## What this document is + +Twenty-six candidate terms for the reinforcement-learning reward function, each with a sign +(reward or penalty) and a rationale. It enumerates *what* should be rewarded; it does **not** +assign relative weights, and weighting is the entire difficulty of a multi-objective reward +like this one. + +The one ordering constraint the document does state is decisive: +`Penalty_UnservedCriticalLoad` **must dominate** every other term. This is the reward-function +expression of the project-wide rule that *critical load is sacred*. + +## Reward components + +### Economics + +| Term | Sign | Description | +|---|:---:|---| +| `Cost_EnergyImport` | − | Penalizes buying electricity from the grid; higher grid import cost per kWh leads to more negative reward. | +| `Revenue_EnergyExport` | + | Rewards selling excess electricity back to the grid; more export at high price increases positive reward. | +| `Cost_DemandPeak` | − | Penalizes high instantaneous grid power import peaks that could increase demand charges on the electricity bill. | +| `Cost_FuelCellHydrogenUse` | − | Penalizes hydrogen consumption by the fuel cell to reflect the value of stored hydrogen for future emergencies. | +| `Cost_ElectrolyzerEnergyUse` | − | Penalizes energy consumed by the electrolyzer so it does not waste electricity when hydrogen is not needed. | + +### Service continuity — the dominant group + +| Term | Sign | Description | +|---|:---:|---| +| `Penalty_UnservedCriticalLoad` | −− | **Very strong penalty** when critical hospital loads are not fully supplied; represents risk to patient safety and **must dominate the reward**. | +| `Penalty_UnservedNonCriticalLoad` | − | Smaller penalty when non-critical loads are curtailed; this allows controlled load shedding but still discourages unnecessary discomfort. | +| `Penalty_GridOutageViolation` | − | Penalty applied when the microgrid fails to maintain supply during a grid outage despite having theoretical local resources to do so. | +| `Reward_ResilienceScore` | + | Composite reward for meeting resilience objectives during disturbances (grid outage, sudden load spikes, PV drops), e.g. no loss of critical load over an event window. | + +### Battery health + +| Term | Sign | Description | +|---|:---:|---| +| `Reward_BatterySOC_Stability` | + | Rewards keeping the battery state of charge within a desirable mid-range band, avoiding both deep discharge and overcharge regions. | +| `Penalty_BatteryDeepDischarge` | − | Extra penalty when the battery SOC falls below a critical threshold (e.g. 20%), representing accelerated degradation and risk of blackout. | +| `Penalty_BatteryHighSOC` | − | Penalty when battery SOC stays too close to 100% for long periods, representing stress and lack of usable headroom. | +| `Penalty_BatteryC_Rate` | − | Penalizes very high charge or discharge power relative to capacity (high C-rates), which accelerates battery wear. | + +### Hydrogen chain health + +| Term | Sign | Description | +|---|:---:|---| +| `Penalty_FuelCellRamping` | − | Penalizes rapid changes in fuel cell power setpoint to avoid thermal and mechanical stress on the stack. | +| `Penalty_ElectrolyzerRamping` | − | Penalizes large power swings in the electrolyzer to prevent efficiency loss and extend stack lifetime. | +| `Penalty_HydrogenOverfill` | − | Strong penalty when hydrogen tank level approaches or exceeds safe storage capacity. | +| `Reward_HydrogenStrategicReserve` | + | Rewards keeping hydrogen level above a minimum strategic reserve threshold for blackout resilience. | + +### Sustainability + +| Term | Sign | Description | +|---|:---:|---| +| `Reward_RenewableUtilization` | + | Rewards using locally generated solar power instead of drawing from the grid, reflecting decarbonization and self-consumption goals. | +| `Penalty_CurtailmentPV` | − | Penalizes curtailing PV generation (turning down solar output) when there is still unserved load or available storage capacity. | +| `Reward_EmissionReduction` | + | Rewards operating modes that correspond to lower CO₂ emissions (e.g. less grid power during high-carbon periods, more use of PV and stored hydrogen). | + +### Safety, stability, and comfort + +| Term | Sign | Description | +|---|:---:|---| +| `Penalty_TemperatureLimits` | − | Penalty if any component (battery, fuel cell, electrolyzer, inverter) operates outside its safe temperature band. | +| `Penalty_SwitchingFrequency` | − | Penalizes excessively frequent switching of modes (battery charge/discharge, fuel cell on/off, electrolyzer on/off) to avoid wear and control instability. | +| `Penalty_VoltageFrequencyDeviation` | − | Penalty when microgrid bus voltage or frequency deviates outside specified tolerance, representing power quality issues. | +| `Penalty_ConstraintViolation` | − | Generic penalty term that triggers when any hard operational constraint is violated (safety limits, reserve margins, equipment operating envelopes). | +| `Reward_ComfortHVAC` | + | Rewards keeping indoor climate (temperature or inferred comfort) within a comfortable range while still being energy efficient. | + +### Forecast coupling + +| Term | Sign | Description | +|---|:---:|---| +| `Reward_PredictionTracking` | + | Rewards the controller when actual system evolution matches its internal forecasts (for load or PV), encouraging actions that reduce forecast error impact. | + +## Open issues with this reward design + +Four problems are worth resolving before any agent is trained against these terms. + +**1. No weights.** Twenty-six terms with no relative magnitudes is not yet a reward function. +Only one ordering constraint exists (`Penalty_UnservedCriticalLoad` dominates). Everything else +is unranked, and a badly scaled multi-objective reward is the most common cause of degenerate +RL policies. + +**2. Terms the simulator cannot currently compute.** Several components require quantities the +[Simulator I/O Interface](simulator-io-interface.md) does not return: + +| Term | Missing simulator output | +|---|---| +| `Penalty_TemperatureLimits` | No component temperatures are returned (isothermal assumption) | +| `Penalty_VoltageFrequencyDeviation` | No bus voltage or frequency is modelled | +| `Reward_ComfortHVAC` | No thermal/HVAC model exists; HVAC is part of non-critical load | +| `Penalty_BatteryC_Rate` | Requires `Q_rated`, defined as static config but not returned per step | +| `Reward_PredictionTracking` | Requires the policy's internal forecast, which the simulator does not see | + +Either the simulator grows these outputs or these terms are dropped. + +**3. `Penalty_ConstraintViolation` may be unreachable.** The simulator sheet says state limits +are *hard*: setpoints breaching `SoC` or `H2_level` bounds are **clipped**, not permitted. If +violations are clipped before they happen, a violation penalty never fires. The useful signal +is the *clipping magnitude* (`P_batt(t)` vs `u_batt(t)`) — i.e. how far the policy tried to +overreach — not a binary violation flag. + +**4. Double counting.** `Reward_ResilienceScore` is explicitly a composite over disturbance +events, but `Penalty_UnservedCriticalLoad` and `Penalty_GridOutageViolation` already price the +same failures. Likewise `Reward_RenewableUtilization` and `Penalty_CurtailmentPV` reward +opposite sides of one quantity, and `Cost_EnergyImport` overlaps `Reward_EmissionReduction` +whenever carbon intensity tracks price. Overlapping terms are not fatal but they distort +effective weighting in ways that are hard to reason about. + +## Related + +- [RL State Variables](rl-state-variables.md) — the observation space +- [RL Action Variables](rl-action-variables.md) — the action space +- [Simulator I/O Interface](simulator-io-interface.md) — what the simulator can actually return +- [AI Efficiency Improvements](../01-project/ai-efficiency-improvements.md) — the loss targets the reward should attack diff --git a/docs/02-specifications/rl-state-variables.md b/docs/02-specifications/rl-state-variables.md new file mode 100644 index 0000000..89ef4f6 --- /dev/null +++ b/docs/02-specifications/rl-state-variables.md @@ -0,0 +1,128 @@ +# RL State Variables + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | [`docs/_originals/STATE VARIABLES AND DESCRIPTIONS.docx`](../_originals/STATE%20VARIABLES%20AND%20DESCRIPTIONS.docx) | +> | **Format** | Microsoft Word (.docx), 14.7 kB | +> | **MD5** | `59dde2384627aa8cdc0412ed6d7f589f` | +> | **Owner** | AI & Control Systems cluster | +> | **Status** | Current — but see [Naming mismatch](#naming-mismatch-with-the-simulator-io-contract) | +> | **Report generated** | 2026-07-25 | + +## What this document is + +The observation space for the reinforcement-learning controller: everything the agent is +allowed to *see* at each timestep. It is the counterpart to +[RL Action Variables](rl-action-variables.md) (what the agent may *do*) and +[RL Reward Function](rl-reward-function.md) (how it is *scored*). + +Thirty-two variables in eight groups. The source document gives a name and a one-line +description for each; it does **not** specify units, ranges, or datatypes — those are +implied at best. Adding them is the obvious next revision. + +## State variables + +### Photovoltaic array + +| Variable | Description | +|---|---| +| `PV_Generation` | Current electrical power produced by the solar panels. | +| `Solar_Irradiance` | Amount of sunlight hitting the panels (W/m²). | +| `PV_Temperature` | Panel temperature affecting efficiency. | +| `PV_Efficiency` | Conversion efficiency of the PV array at the current moment. | + +### Battery + +| Variable | Description | +|---|---| +| `Battery_SOC` | Battery state of charge (%) indicating energy stored. | +| `Battery_Current` | Charge/discharge current flowing through the battery. | +| `Battery_Voltage` | Terminal voltage of the battery pack. | +| `Battery_Temperature` | Battery temperature affecting performance and lifespan. | + +### Electrolyser + +| Variable | Description | +|---|---| +| `Electrolyzer_Power` | Electrical power supplied to the electrolyzer. | +| `Electrolyzer_H2_ProductionRate` | Amount of hydrogen being produced per unit time. | +| `Electrolyzer_WaterLevel` | Water reservoir level needed for electrolysis. | +| `Electrolyzer_Temperature` | Stack temperature affecting efficiency and safety. | +| `Electrolyzer_StackHealth` | Degradation/health level of the electrolyzer stack. | + +### Hydrogen storage + +| Variable | Description | +|---|---| +| `HydrogenTank_Level` | Current amount of hydrogen stored in the tank. | +| `HydrogenTank_Pressure` | Internal pressure of the hydrogen storage tank. | +| `HydrogenTank_Temperature` | Tank temperature affecting pressure and safety. | + +### Fuel cell + +| Variable | Description | +|---|---| +| `FuelCell_Power` | Current electrical power produced by the fuel cell. | +| `FuelCell_Temperature` | Fuel cell stack temperature. | +| `FuelCell_H2_ConsumptionRate` | Rate at which the fuel cell consumes hydrogen. | +| `FuelCell_StackHealth` | Degradation/health of the fuel cell stack. | + +### Grid + +| Variable | Description | +|---|---| +| `Grid_Status` | Whether the grid is online/offline/faulted. | +| `Grid_Price` | Current real-time electricity price from the grid. | +| `Grid_Availability` | Whether grid import or export is allowed at the moment. | + +### Hospital load + +| Variable | Description | +|---|---| +| `Hospital_Load` | Total electrical demand of the hospital. | +| `Critical_Load` | Portion of the load that must always be powered. | +| `NonCritical_Load` | Flexible load that can be shed or shifted. | +| `Predicted_Load` | Forecasted load in the near future. | + +### Environment and calendar + +| Variable | Description | +|---|---| +| `Ambient_Temperature` | Outside temperature affecting PV, battery, and loads. | +| `Ambient_Humidity` | Humidity affecting cooling and equipment performance. | +| `TimeOfDay` | Current hour used for daily patterns in generation/load. | +| `DayType` | Whether it is a weekday, weekend, or holiday (affects load patterns). | + +## Naming mismatch with the simulator I/O contract + +This document and the [Simulator I/O Interface](simulator-io-interface.md) describe the same +system with **two different naming conventions**, and neither references the other: + +| Concept | This document | Simulator I/O sheet | +|---|---|---| +| Battery state of charge | `Battery_SOC` (%) | `SoC(t)` (0–1) | +| PV power | `PV_Generation` | `P_PV_available(t)` / `P_PV_used(t)` | +| Hydrogen stored | `HydrogenTank_Level` | `H2_level(t)` (mol or kg) | +| Critical demand | `Critical_Load` | `L_crit(t)` (W) | +| Grid availability | `Grid_Availability`, `Grid_Status` | `grid_on(t)` (1/0) | + +The simulator sheet also **omits** several states listed here — stack health, water level, +humidity, and all four component temperatures — because it assumes an isothermal tank and no +degradation model (both flagged as open questions in that document). + +Conversely this document lists no `DayType` or `TimeOfDay` equivalent in the simulator outputs. + +**Neither document is wrong; they are unreconciled.** Before the environment is coded, one +naming convention and one authoritative variable set has to win. The Simulator I/O sheet is the +more rigorous artefact (it has units, ranges, sign conventions, and an explicit power-balance +invariant), so it is the natural base — but it needs the health/temperature states from this +document if degradation or thermal effects are to be modelled at all. + +## Related + +- [RL Action Variables](rl-action-variables.md) — the action space +- [RL Reward Function](rl-reward-function.md) — the reward terms +- [Simulator I/O Interface](simulator-io-interface.md) — the typed simulator contract +- [Rule-Based Controller](rule-based-controller.md) — the baseline policy this agent must beat diff --git a/docs/02-specifications/rule-based-controller.md b/docs/02-specifications/rule-based-controller.md new file mode 100644 index 0000000..810d0a8 --- /dev/null +++ b/docs/02-specifications/rule-based-controller.md @@ -0,0 +1,205 @@ +# **RULE-BASED EMS** + +# [Rule-Based Energy Management System to Enhance PV Self-Consumption in a Building: A Real Case](https://www.mdpi.com/1996-1073/17/23/6099) + +“The EMS presented in this article is a rule-based EMS (RB-EMS) and its objective is to maximize the self-consumption rate (SCR) of PV energy actuating on the heating, ventilation and air conditioning (HVAC) of ESTIA2 building involved in the CSC, taking into account the comfort of users.” + +HVAC: heat, ventilation and air-conditioning + +CSC: collective self-consumption + +“At each time step, the priority is to self-consume the building’s energy production. Then, **any surplus is used to charge the battery** and, finally, **it is exported to the grid in case the storage system is full**. **Import from the grid is the last resort** in case of low local production and not enough stored energy inside the battery. ” + +**This paper uses HVAC as the flexible load** + +rather than a battery. When there is excess + +PV, instead of storing electricity in a battery, + +it runs the heating/cooling system harder + +(pre-heating or pre-cooling the building). + +The building itself acts as a thermal "battery." + +**Step 1 / Read data** +It read PV power being generated (PPV) and building consumption +(PC). Then calculates e \= PPV-PC (the energy surplus or deficit) + +**Step 2 / Compare e against a threshold h** +e \< \-h: More consumption than PV (deficit) +HVAC units are sorted by room temperated, if a room is above +comfort threshold, the corresponding unit is switched OFF to reduce +consumption, then checks if any OFF units can be turned ON for +comfort maintenance +|e| \< h: Roughly balanced +PV and consumption are close enough, so no action needed +e \> h: More PV than consumption (surplus) +Excess solar energy is available, the controller looks for HVAc units that are +OFF and could be switched ON. Switches ON the unit in the coldest room +to absorb the extra PV energy. If more surplus remains, it may switch OFF a unit and ON another to redistribute + +**Step 3 / Wait 5 minutes, then repeat until the end of day (5 minutes is the sampling time)** + +\*Techno Park in France + +--- + +**RB-EMS vs AI-EMS** + +[tibo energy](https://tibo.energy/blog/rule-based-vs-ai-energy-management/) + +**Rule Based EMS How** +A rule-based EMS runs on predefined rules. Think: “if the solar array produces more than 50 kW, switch on the battery” or “only charge the EV fleet between 22:00 and 06:00.” The system follows these instructions literally, regardless of what’s happening in the energy market or on the grid at that moment. +This model works fine in stable, predictable environments. But today’s energy market is anything but stable. Dynamic energy prices change every quarter of an hour, renewable generation fluctuates with the weather, and grid congestion is forcing companies to actively steer their power flows. + +**AI Energy Management** +AI energy management takes a fundamentally different approach. Instead of fixed rules, the system uses machine learning and predictive models to continuously learn from data: historical consumption, weather forecasts, energy prices, grid load and the behaviour of every connected asset. +Based on that data, an AI-driven EMS makes autonomous decisions every few minutes. When to charge? When to store? When to feed back to the grid? The system doesn’t optimise based on a static rule, but based on what is smartest right now. + +--- + +## + +## **HOW WOULD THIS LOOK FOR US?** + +## **1 Objective** + +The purpose of the rule-based controller is to manage energy flows within the hospital energy system using a deterministic set of priorities. This baseline strategy ensures: + +* Reliable supply to hospital demand +* Efficient use of on-site renewable energy (PV) +* Rational use of storage systems (battery and hydrogen) +* Reduced reliance on the grid where possible + +## + +## **2 System Components** + +The controller manages the following energy sources and storage systems: + +* **Photovoltaic (PV) generation** +* **Battery storage system** +* **Hydrogen system** + * Electrolyzer (electricity → hydrogen) + * Fuel cell (hydrogen → electricity) +* **Grid connection** +* **Hospital load demand** + +## + +## **3 Control Philosophy** + +The controller follows a **priority-based dispatch strategy**, where energy is allocated based on predefined rules rather than optimization. + +The general philosophy is: + +1. **Use local renewable energy first** +2. **Store excess energy for future use** +3. **Use stored energy during shortages** +4. **Use the grid as a last resort (or strategically based on price)** + +## + +## **4 Energy Allocation Logic** + +### **4.1 Normal Operation** + +At each time step, the controller compares PV generation with hospital demand. + +### **Case 1: PV Generation Exceeds Demand** + +When on-site renewable generation exceeds the hospital load: + +1. PV energy is first used to fully satisfy the hospital demand +2. The excess energy is allocated as follows: + * Charge the battery until it reaches maximum capacity + * If the battery is full, use excess energy to produce hydrogen via the electrolyzer + * If both battery and hydrogen storage are full, excess energy is exported to the grid + +### **Case 2: PV Generation is Less Than Demand** + +When PV generation is insufficient: + +1. PV energy is used as much as possible +2. The remaining demand is supplied: + * Battery discharge (if sufficient charge is available) + * Hydrogen fuel cell (if hydrogen is available) + * Grid import as the final fallback + +## **5 Cost-Aware Operation (Optional Enhancement)** + +To improve economic performance, electricity price signals can be incorporated: + +* During **peak price periods**: + * Prioritize battery discharge and hydrogen usage + * Minimize grid import +* During **off-peak periods**: + * Prefer grid electricity if it is cheaper + * Preserve stored energy for future high-cost or emergency periods + +## + +## **6 Reliability and Hospital Constraints** + +Given the critical nature of hospital operations, additional constraints are introduced: + +### **6.1 Minimum Battery Reserve** + +A minimum state of charge (for example 20–30%) is maintained to ensure backup availability in case of emergencies. + +### **6.2 Backup Operation (Grid Failure Scenario)** + +In the event of a grid outage: + +1. The battery is used as the primary energy source +2. The hydrogen fuel cell acts as a secondary backup +3. Energy is prioritized for **critical hospital loads** + +### **6.3 Critical vs Non-Critical Loads (Optional)** + +If load segmentation\* is available: + +* **Critical loads** (ICU, operating rooms, emergency systems) are always prioritized +* **Non-critical loads** may be reduced or shed during severe shortages + +\*dividing the hospital’s total electricity demand into different categories based on priority, function, or flexibility, so the energy system can make smarter decisions during shortages or optimization. + +## **7 Hydrogen System Role** + +Due to lower round-trip efficiency compared to batteries: + +* Hydrogen is primarily used for: + * Long-term energy storage + * Backup during extended shortages +* It is only produced when: + * Battery storage is fully utilized + * Excess renewable energy is available + +## + +## + +## **8 Summary of Control Priorities** + +### **Energy Supply Priority (Deficit):** + +1. PV generation +2. Battery storage +3. Hydrogen fuel cell +4. Grid import + +### **Energy Allocation Priority (Excess):** + +1. Serve load +2. Charge battery +3. Produce hydrogen +4. Export + +## **9 Limitations of Rule-Based Approach** + +* Does not anticipate future demand or generation +* Cannot optimally respond to dynamic electricity prices +* May lead to suboptimal use of storage systems +* Lacks adaptability to changing conditions + diff --git a/docs/02-specifications/simulator-io-interface.md b/docs/02-specifications/simulator-io-interface.md new file mode 100644 index 0000000..3466ce5 --- /dev/null +++ b/docs/02-specifications/simulator-io-interface.md @@ -0,0 +1,320 @@ +# SHIFT Simulator — Input/Output Interface + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | [`docs/_originals/Simulator Interface Input-Output sheet.pdf`](../_originals/Simulator%20Interface%20Input-Output%20sheet.pdf) | +> | **Format** | PDF, 10 pages, 556 kB | +> | **MD5** | `0712f05593c39897abc8f651834bebde` | +> | **Owner** | AI & Control Systems cluster | +> | **Document status** | **Draft v0.1** — living document, TBD items unresolved | +> | **Report generated** | 2026-07-25 | + +> [!NOTE] +> Tables in the source PDF are rendered in a layout that machine extraction scrambles +> (symbol, name, unit and note columns interleave). The tables below are **reconstructed** — +> the content is the source's, the column alignment is this report's. Where a mapping was +> ambiguous it is flagged inline. Check against the original PDF before relying on any single +> row for implementation. + +## Purpose + +Defines the contract between the SHIFT microgrid simulator and everything that talks to it: + +- the AI/RL policy, +- the rule-based baseline, +- the validation/benchmark layer, +- the Economics team's downstream cost and CO₂ accounting. + +It covers what the simulator **consumes** (configuration, exogenous time-series, control +actions) and what it **returns** at every timestep. + +> *"It is a living document — items flagged TBD need a decision from the cluster or whoever."* + +This document is the direct descendant of +[Shift Input Data](../04-simulations/shift-input-data.md) — §1 explicitly refers to +*"the constants Robert's doc lists in bold."* + +--- + +## 0. Conventions + +### Timestep + +**Symbol:** `dt` + +Default assumption **1 hour** — matches typical PV/load profiles and the one-year benchmarking +horizon in the project brief. Whether a sub-hourly step is needed for battery fast-response +behaviour is TBD. + +> *"I did 1 hour for this cause 15 mins time steps will be quite compute heavy for RL training, +> so we do need to talk about that."* + +### Sign conventions + +| Quantity | Positive means | Negative means | +|---|---|---| +| `P_battery` | discharging (supplying the bus) | charging (absorbing from the bus) | +| `P_grid` | importing from grid | exporting to grid | +| `n_H2_net` | net production into tank | net consumption from tank | + +All other power values — `P_PV`, `P_electrolyser`, `P_fuelcell`, `P_load` — are **non-negative +by definition**. + +### Power balance + +The invariant the simulator must satisfy at every step: + +``` +P_PV_used + P_fuelcell + P_grid + P_battery + = P_load_served_critical + P_load_served_noncritical + P_electrolyser +``` + +Any residual after the policy's action is absorbed by unmet load — with critical load +prioritised (see [§4](#4-priority-rules-the-simulator-enforces)). + +### Units + +SI throughout: power in W, energy in Wh, mass in kg, amount in mol, time in s (or h for hourly +steps). TBD to lock down before code is written. + +> *"I don't know the conventions for this, I let AI handle this, not an electrical engineer sorry."* + +--- + +## 1. Static configuration inputs + +Set once per simulation run. + +### 1.1 Electrolyser + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `N_c_ele` | Number of cells | — | Usually difficult to find | +| `mu_F` | Faraday efficiency | — | Fall back to literature average (~0.95–0.99 for PEM) | +| `P_ele_max` | Rated / max power | W | | +| `P_ele_min` | Minimum operating power | W | Below this the electrolyser shuts off (efficiency cliff) | +| `I_ele_min` | Minimum operating current | A | Alternative to `P_ele_min` | +| `cal_H2` | H₂ production calibration factor | — | If we end up reading H₂ flow from measured data | + +### 1.2 Fuel cell + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `N_c_fc` | Number of cells | — | | +| `utilisation_fc` | H₂ utilisation | % | | +| `P_fc_max` | Maximum output power | W | **Project spec: 100 kW** | +| `V_fc_min`, `V_fc_max` | Operating voltage range | V | | + +### 1.3 Hydrogen tank + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `V_H2_max` | Maximum stored volume | L (or kg) | **Project spec: up to 200 kg total across two tanks** | +| `V_H2_init` | Initial fill level | L (or kg) | | +| `T_tank` | Operating temperature | K | TBD — isothermal assumption likely fine | +| `p_tank` | Operating pressure | atm (or bar) | TBD — isobaric vs. ideal-gas model | + +### 1.4 PV + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `A_PV` | Total panel area | m² | **Project spec: 2,300 m²** | +| `mu_PV` | Panel efficiency | — | | +| `P_PV_max` | Inverter / rated cap | W | Optional; if set, clipping occurs above this | + +### 1.5 Battery + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `E_rated` | Rated energy capacity | Wh | | +| `Q_rated` | Rated charge capacity | Ah | | +| `P_batt_charge_max` | Max charge power | W | | +| `P_batt_discharge_max` | Max discharge power | W | | +| `SoC_init` | Initial state of charge | — (0–1) | | +| `SoC_min`, `SoC_max` | Operating window | — (0–1) | E.g. 0.1–0.9 | +| `eta_batt_ch`, `eta_batt_dis` | Round-trip efficiencies | — | Often split into charge & discharge | + +### 1.6 Load + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `V_load` | Bus voltage | V | Constant, per Robert's note | + +### 1.7 Grid + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `P_grid_max` | Max connection capacity (import & export) | W | Constant, per Robert's note | +| `V_grid` | Bus voltage | V | | + +--- + +## 2. Per-timestep inputs + +### 2.1 Exogenous time-series + +Read from data; not under policy control. + +| Symbol | Name | Unit | Source / note | +|---|---|---|---| +| `G(t)` | PV generated power | W | Forecasted | +| `L_crit(t)` | Critical hospital load demand | W | ICU, life-support, etc. — must always be served | +| `L_noncrit(t)` | Non-critical hospital load demand | W | Lighting, HVAC, admin | +| `grid_on(t)` | Grid availability (1/0) | — | Models outages | +| `price(t)` | Grid electricity price | €/kWh | Import & export prices — TBD whether they differ | +| `CO2_int(t)` | Grid carbon intensity | kg CO₂/kWh | For emissions accounting | + +### 2.2 Control inputs + +From the AI/RL policy or the rule-based baseline. At each timestep the controller emits +**setpoints, not direct power flows** — the simulator clips them to physical limits and reports +actuals. + +| Symbol | Name | Unit | Range | +|---|---|---|---| +| `u_ele(t)` | Electrolyser power setpoint | W | `[0, P_ele_max]`; values in `(0, P_ele_min)` round to 0 (off) | +| `u_fc(t)` | Fuel cell power setpoint | W | `[0, P_fc_max]` | +| `u_batt(t)` | Battery setpoint (signed) | W | `[-P_batt_charge_max, P_batt_discharge_max]` | +| `sw_ele(t)` | Electrolyser ON/OFF | 1/0 | Optional — can be folded into `u_ele = 0` | +| `sw_fc(t)` | Fuel cell ON/OFF | 1/0 | Optional — can be folded into `u_fc = 0` | + +**On the grid:** the grid is treated as the **slack bus** — whatever the power-balance residual +is after all other components act, the grid absorbs, within `P_grid_max` and `grid_on(t)`. The +RL action space therefore probably does *not* include the grid directly. + +--- + +## 3. Per-timestep outputs + +### 3.1 State variables + +Carried forward to the next step. + +| Symbol | Name | Unit | +|---|---|---| +| `SoC(t)` | Battery state of charge | — (0–1) | +| `H2_level(t)` | H₂ stored in tank | mol (or kg) | +| `T_tank(t)` | Tank temperature | K (only if non-isothermal model) | +| `p_tank(t)` | Tank pressure | bar (if modelled) | + +### 3.2 Power flows + +| Symbol | Name | Unit | +|---|---|---| +| `P_PV_available(t)` | PV power available given irradiance | W | +| `P_PV_used(t)` | PV power actually consumed | W | +| `P_PV_curtailed(t)` | PV potential that was thrown away | W | +| `P_ele(t)` | Actual electrolyser consumption | W | +| `P_fc(t)` | Actual fuel cell output | W | +| `P_batt(t)` | Actual battery flow (signed) | W | +| `P_grid(t)` | Actual grid flow (signed) | W | +| `P_load_served_crit(t)` | Critical load served | W | +| `P_load_served_noncrit(t)` | Non-critical load served | W | + +### 3.3 Mass flows (hydrogen) + +| Symbol | Name | Unit | +|---|---|---| +| `n_H2_prod(t)` | H₂ produced by electrolyser | mol/s (or kg/h) | +| `n_H2_cons(t)` | H₂ consumed by fuel cell | mol/s (or kg/h) | +| `n_H2_net(t)` | Net flow into tank | mol/s | + +### 3.4 KPIs and accounting + +> *"the heart of the task"* + +| Symbol | Name | Unit | Notes | +|---|---|---|---| +| `unmet_crit(t)` | Unserved critical load | W | **Must be near-zero — primary resilience KPI** | +| `unmet_noncrit(t)` | Unserved non-critical load | W | Restated as a KPI for clarity | +| `curtailment(t)` | `= P_PV_curtailed(t)` | W | | +| `cost(t)` | Operating cost of this step | € | TBD — see [§5](#5-open-questions) | +| `CO2(t)` | Emissions of this step | kg CO₂ | TBD — see [§5](#5-open-questions) | + +### 3.5 Diagnostic / efficiency outputs + +Recommended. Ties directly to +[AI Efficiency Improvements](../01-project/ai-efficiency-improvements.md), which flagged +~30–40% electrolyser losses and ~40% fuel-cell losses as the biggest optimisation targets. If +the simulator returns per-step efficiencies, the RL reward and the post-hoc analysis can both +attack those losses directly. + +| Symbol | Name | Unit | +|---|---|---| +| `eta_ele(t)` | Electrolyser efficiency this step | — | +| `eta_fc(t)` | Fuel cell efficiency this step | — | +| `eta_PV(t)` | Effective PV efficiency this step | — | +| `eta_batt(t)` | Battery round-trip-equivalent | — | + +--- + +## 4. Priority rules the simulator enforces + +Not I/O, but contract-level — the policy needs to know what the simulator will do with a +setpoint that violates physics or safety. + +1. **Critical load is sacred.** If the policy's setpoints leave critical load unserved while + the battery has charge, the fuel cell can run, or the grid is available, the simulator + **overrides the policy in that order** and reports the override (e.g. via an output flag) so + it shows up in training. +2. **State limits are hard.** `SoC ∈ [SoC_min, SoC_max]`, `H2_level ∈ [0, V_H2_max]`. Setpoints + that would breach these are **clipped**; the difference shows up as `P_batt(t)` vs + `u_batt(t)`. +3. **Electrolyser dead-zone.** Setpoints in `(0, P_ele_min)` are rounded to 0. +4. **Grid outage.** If `grid_on(t) = 0` then `P_grid(t) = 0` regardless of slack residual; the + residual becomes `unmet_*` or `curtailment`. + +--- + +## 5. Open questions + +Need answers before v1.0. + +- **Cost & CO₂ scope.** Flagged TBD in §3.4. If Economics handles these downstream, the + simulator only needs to return `P_grid(t)` plus exogenous `price(t)` and `CO2_int(t)`, and + Economics computes cost/CO₂ themselves. If the simulator computes them, it also needs to know + whether there is an O&M cost per kWh through the electrolyser/fuel cell, a degradation cost, + and so on. +- **Tank model.** Isothermal + ideal gas, or do we need temperature and pressure dynamics? +- **Battery degradation.** Modelled or ignored? +- **Sub-hourly dynamics.** Does the battery's fast-response role require `dt < 1 h`? If so, + mixed time-scale handling between battery (minutes) and electrolyser (hours) becomes a design + question. +- **Action space format.** Continuous setpoints (`u_ele ∈ [0, P_ele_max]`) vs. discrete buckets + — affects what the RL team expects as input. +- **Forecast vs. realised exogenous inputs.** The policy may see a forecast of `G(t+1)` and + `L(t+1)`; the simulator advances with the realised values. Decide whether the simulator + delivers both or only realised. +- **Critical vs non-critical split — data availability.** Confirm with the hospital data source + whether the load profile can actually be split, or whether we need a proxy fraction (e.g. + assume X% of total load is critical). +- **Mutual exclusion of electrolyser and fuel cell.** Should the action space structurally + prevent simultaneous operation (mode-switch / hybrid action space), or allow them + independently and let the reward penalise simultaneous operation? Has efficiency, + sample-efficiency, and policy-expressiveness trade-offs. + +--- + +## Cross-document notes + +Three consistency issues between this document and its neighbours: + +| Issue | Detail | +|---|---| +| **Naming convention** | This document uses physics-style symbols (`P_PV`, `SoC(t)`, `u_ele`). [RL State Variables](rl-state-variables.md) and [RL Action Variables](rl-action-variables.md) use descriptive identifiers (`PV_Generation`, `Battery_SOC`, `Electrolyzer_PowerSetpoint`). Neither references the other; one must win. | +| **State coverage** | This sheet omits component temperatures, stack health, and water level, which the RL state doc lists. Consistent with the isothermal/no-degradation assumptions flagged TBD above. | +| **Action coverage** | This sheet accepts 5 control signals; the RL action doc lists 16. Grid import/export and load shedding are deliberately excluded here (slack bus, and outcome-not-action respectively); PV curtailment control, thermal management, and mode supervision are genuine gaps. | + +Load-tier terminology also differs from Energy Management's +[BIDMC/UCSD Energy Flow and Balances](../03-energy-management/bidmc-ucsd-energy-flow-and-balances.md), +which uses a **three**-tier model (Tier 1 critical / Tier 2 essential / Tier 3 non-critical) +against this document's **two**-way split (`L_crit` / `L_noncrit`). + +## Related + +- [Shift Input Data](../04-simulations/shift-input-data.md) — the predecessor variable list this sheet formalises +- [RL State Variables](rl-state-variables.md) · [RL Action Variables](rl-action-variables.md) · [RL Reward Function](rl-reward-function.md) +- [Rule-Based Controller](rule-based-controller.md) — the baseline policy that consumes this contract +- [Forecasting Requirements](forecasting-requirements.md) — produces `G(t)`, `L(t)`, `price(t)` diff --git a/docs/03-energy-management/bidmc-datasets-manual.md b/docs/03-energy-management/bidmc-datasets-manual.md new file mode 100644 index 0000000..3d27c41 --- /dev/null +++ b/docs/03-energy-management/bidmc-datasets-manual.md @@ -0,0 +1,221 @@ +# BIDMC Datasets Manual (v2) + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/Beth Israel Deaconess Medical Center/BIDMC_Datasets_Manual_v2.docx` | +> | **Format** | Microsoft Word (.docx), 29.3 kB | +> | **MD5** | `78426a0944272a1549be13772a83e9c1` | +> | **Owner** | Energy Management cluster | +> | **Status** | Current (**v2**) — no v1 exists in this repository | +> | **Report generated** | 2026-07-25 | + +## What this document is + +Manual for the data related to the BIDMC building structure. It documents four datasets — three +clinical and one synthetic building-energy file — and explains how each maps onto the +reinforcement-learning formulation (state space, action space, reward). + +> [!IMPORTANT] +> **Provenance of the clinical files.** The column names, `itemid` codes, and de-identification +> scheme are those of **MIMIC-IV**. The +> [Digital Twin Readiness Checklist](bidmc-digital-twin-readiness-checklist.md) in the same +> folder links to `physionet.org/content/mimic-iv-demo/2.2/icu/inputevents.csv.gz`, and this +> manual records **100 patients** — both consistent with the **MIMIC-IV Clinical Database +> Demo**, which is openly published under the Open Data Commons ODbL v1.0 and does *not* +> require credentialed access. +> +> That makes redistribution here defensible, but the **licence and citation are not recorded +> anywhere in the repository**. ODbL requires attribution and share-alike. Adding a +> `LICENSE`/`SOURCE` note next to these files is a small fix worth making — see +> [Dataset Inventory](../06-data/dataset-inventory.md). +> +> These files are *not* BIDMC's own clinical records. Despite the folder name, no real BIDMC +> patient data is present. + +## How the datasets link together + +All three clinical files share the join key **`subject_id`**. It connects patients +(`patients.csv`) to ICU monitoring (`chartevents.csv`) and treatments (`inputevents.csv`). The +energy file links via **`Patient ID`** (format `P0001`). + +Within the clinical files: + +- `hadm_id` = hospital admission +- `stay_id` = specific ICU stay within that admission +- One patient can have multiple admissions and multiple ICU stays + +> **All dates in the clinical files are shifted forward by around 100 years for +> de-identification.** Only the *length of stay* can be understood from the dates. + +--- + +## 1. `patients.csv` + +- Unique patient data giving an understanding of patient behaviours and needs. + **100 rows, 6 columns**, no repeated rows per patient. +- **Static** dataset, recorded once. +- Can be used as a *"virtual patient avatar"* — by modelling different ages the system can + predict energy used per person. +- For RL, this data is in the **state space**. + +| Column | Type | Example | Description | +|---|---|---|---| +| `subject_id` | Integer | 10014729 | Unique patient identifier. Primary join key across all clinical files. Filter `chartevents` and `inputevents` by this to get one patient's records | +| `gender` | String | F or M | Biological sex at ICU admission | +| `anchor_age` | Integer (years) | 21–91, mean 62 | Patient age at their first ICU admission | +| `anchor_year` | Integer (shifted) | 2110–2201 | De-identified year of first ICU admission. **Cannot be used as a real calendar date** | +| `anchor_year_group` | String | 2011 – 2013 | The real calendar period of the patient's admission. Useful for understanding what medical equipment was in use | +| `dod` | Date or NULL | 2137-09-02 or empty | De-identified date of death. NULL for 69 of 100 patients (alive or unknown) | + +--- + +## 2. `chartevents.csv` + +*(5.29 MB gzipped)* + +- Acts as a chart, tracking how the patient's body is performing while in ICU: heart rate, + blood pressure, oxygen levels, body temperature, ventilator settings. +- **Units:** Heart Rate bpm | Oxygen/SpO2 % | Respiratory Rate breaths/min | Temperature °C or + °F (check `valueuom` per row) | Blood Pressure mmHg | Weight kg +- Data intervals are **irregular** — monitored whenever a nurse takes measurements. Always use + `charttime` (not `storetime`) for time-series work. +- Gives a real-time trajectory of a patient's health in the digital twin. +- Represents the **dynamic state space**. The AI can judge whether a patient is getting better + or worse and thus predict whether more equipment usage will be required. +- Can also feed the **reward**: when the AI adjusts environment flows and an unstable heart rate + returns to a safe range, it can receive a major positive reward. + +| Column | Type | Example | Description | +|---|---|---|---| +| `subject_id` / `hadm_id` / `stay_id` | Integer | 10005817 / 20626031 / 32604416 | `subject_id` links to `patients.csv`. `hadm_id` = hospital admission. `stay_id` = specific ICU stay. One patient can have multiple `stay_id`s. **Always filter by `stay_id` when analysing one ICU episode** | +| `caregiver_id` | Float or NULL | 6770.0 | ID of the nurse or clinician who recorded this reading. NULL means an automated monitor recording. Can be used to model nurse visit frequency, which correlates with lighting and device power usage per room | +| `charttime` | Datetime (shifted) | 2132-12-16 00:00:00 | When the measurement was taken. Use this for all time-series work. Dates are de-identified so use relative time differences only | +| `storetime` | Datetime (shifted) | 2132-12-15 23:45:00 | When the value was entered into the system. Can be ignored; `charttime` is better | +| `itemid` | Integer (code) | 220045, 220050, 220210 | Numeric code identifying what was measured. **Key codes:** 220045 = Heart Rate (bpm), 220050 = Arterial BP Systolic (mmHg), 220051 = BP Diastolic, 220052 = BP Mean, 220210 = Respiratory Rate, 220277 = SpO2 (%), 220048 = Heart Rhythm. **483 unique codes** in this dataset | +| `value` | String | "100" or "On" | Raw recorded value, always stored as text. For numeric readings also use `valuenum`. For categorical readings (e.g. ventilator On/Off) `valuenum` is NULL and you must read `value` | +| `valuenum` | Float or NULL | 100.0 | Numeric version of `value`. Used for all calculations. NULL for categorical readings | +| `valueuom` | String (unit) | %, mmHg, bpm, /min, °C | Unit of measurement for this row. **Temperature appears in both °C and °F** depending on the monitor | +| `warning` | Integer (0/1) | 0 or 1 | Clinical alarm flag. 1 = value was outside normal thresholds at the time of recording. A flagged vital after an AI action should trigger a negative reward | + +--- + +## 3. `inputevents.csv` + +*(0.75 MB gzipped)* + +- Tracks everything actively pumped or injected into the patient's body: IV fluids, active + medications, nutrition. +- Records the type of medication or fluid (`ordercategoryname`), the exact amount, how fast it + was given (`rate`), and exact start and end times. +- **Units:** mL or mg for dosage (`amountuom`); mL/hour or mg/hour for infusion rate + (`rateuom`); weight in kg (`patientweight`). +- Logs continuous periods with exact start and end times, showing how long an infusion lasted. +- If a patient is actively receiving high-risk continuous IV medications, their body is under + high stress. The digital twin can use this timeline to flag that the room environment must + remain perfectly steady — the AI manager reads this status and knows it cannot alter the HVAC + settings in that room right now. + +| Column | Type | Example | Description | +|---|---|---|---| +| `starttime` / `endtime` | Datetime (shifted) | 2132-12-16 19:50:00 | Start and end of the infusion. Any `chartevents.charttime` within this window occurred during active treatment | +| `ordercategoryname` | String | 01-Drips, 08-Antibiotics (IV) | Clinical type of what is being given. **`01-Drips`** = continuous vasopressor or sedative infusions (highly unstable patient — do not alter room). Full list in this dataset: 01-Drips, 02-Fluids (Crystalloids), 05-Med Bolus, 06-Insulin, 07-Blood Products, 08-Antibiotics (IV), 10-Prophylaxis (IV), 13-Enteral Nutrition, 14-Oral/Gastric Intake | +| `amount` / `amountuom` | Float / String | 1.0 / "dose" or 500 / "ml" | Quantity given and its unit. Units seen: ml, mg, mcg, grams, units, mEq, dose. Always read both together. "dose" means a standard clinical dose with no specific volume recorded | +| `rate` / `rateuom` | Float or NULL / String | 5.0 / "mL/hour" | Speed of infusion. NULL = given all at once. Non-NULL = continuous drip, patient is actively on a pump. **Active pumps consume measurable medical equipment power** | +| `statusdescription` | String | FinishedRunning, Stopped, ChangeDose/Rate, Paused, Bolus | Outcome of this infusion record. `FinishedRunning` = completed normally. `Stopped` = discontinued early (possible adverse event). `ChangeDose/Rate` = dose adjusted mid-infusion (a new row follows) | +| `patientweight` | Float (kg) | 91.0 | Patient body weight at the time of this event. Weight-based dosing is common in ICU. Also feeds the virtual avatar: heavier patients have higher metabolic output, affecting room temperature modelling | +| `ordercategorydescription` | String | Drug Push, Continuous Med | How the order was administered. `Drug Push` = fast IV push. `Continuous Med` = ongoing infusion. Useful for classifying clinical intensity | +| `isopenbag` / `continueinnextdept` | Integer (0/1) | 0 or 1 | `isopenbag` = 1 if the bag was already open when this event started. `continueinnextdept` = 1 if the infusion continued after the patient moved to another unit. Both useful for tracking infusion continuity across ICU transfers | + +--- + +## 4. `hospital_communication_energy_system.csv` + +*(3.16 MB)* + +- Merges real-time patient environment data with the hospital's power grid, climate systems, + and hardware performance. **10,000 rows, 25 columns.** 5-minute intervals from + **2025-01-01 to 2025-02-04**. No missing values. +- Contains room and outdoor temperatures/humidity, grid and renewable energy sources, energy + consumed by lighting/HVAC/medical gear, and system health checks. +- **Units:** Power & Energy Consumption kWh | Renewable Energy Usage % | Vitals bpm, mmHg, % | + Temperatures °C | Humidity % +- Synchronised and recorded at exactly 5-minute intervals. +- Creates the digital twin infrastructure of the building, linking patients to environment. Can + be used to predict how a heatwave or sudden grid blackout affects indoor room temperatures and + the power stability of life-support gear. +- Contains the exact switches of AI controls: Energy Saving Mode on/off, HVAC Mode + (Heating/Cooling), power distribution adjustments. +- At every 5-minute interval the AI can look at *Total Power Usage* and *Renewable Energy + Usage*. If it reduces grid reliance or lowers kWh usage while keeping all patient rooms + comfortable, it can receive a positive reward. +- By comparing *Outdoor Temperature* with *Internal Room Temperature*, the AI can predict + upcoming thermal loads (e.g. afternoon heat spikes) and pre-cool the building using cheap, + clean renewable energy before peak pricing hits the main grid. + +> [!WARNING] +> **This is synthetic data.** The manual states the timestamps are *"synthetic operational data +> that is not shifted"*, energy sources are distributed *"~33% each"* across Grid/Solar/Wind, +> and HVAC Mode is a *"~50/50 split"* — signatures of generated rather than measured data. It +> is useful as a schema and an RL-environment mock-up, **not** as evidence about BIDMC's real +> operation. Note also that each row is a *single patient room snapshot*, not a whole-hospital +> total. + +| Column | Type | Example | Description | +|---|---|---|---| +| `Timestamp` | Datetime | 2025-01-01 00:00:00 | The RL time-step index. Each row = one decision point (every 5 min). Sort by this before any time-series work | +| `Patient ID` | String | P0001 | Room/patient identifier. Links to clinical files via `subject_id` mapping. Each row is a different patient's room snapshot | +| `Temperature (°C)` | Float | 35.96 | **Patient body** temperature. Normal ICU range 36.1–37.2 °C. Above 38 °C = fever, below 36 °C = hypothermia. AI uses this to decide if HVAC needs to compensate | +| `Humidity (%)` | Float | 53.1 | Relative humidity near the patient. ICU target 30–60%. High humidity raises infection risk; low humidity causes respiratory discomfort for ventilated patients. Use as an HVAC reward constraint | +| `Oxygen Level (%)` | Float | 98.9 | Blood oxygen saturation (SpO2). Normal 95–100%. Below 90% = clinical emergency | +| `Heart Rate (bpm)` | Integer | 76 | Beats per minute. Normal ICU resting range 60–100 bpm | +| `Blood Pressure (mmHg)` | String | (111, 84) | Stored as a **tuple string** (systolic, diastolic). Normal ICU systolic 90–140 mmHg. *Requires parsing* | +| `Energy Consumption (kWh)` | Float | 16.75 | Total energy consumed in this 5-min window. Primary cost signal for the RL agent. **Distinct from `Total Power Usage`** — this is measured consumption; that is the sum of subsystem loads | +| `Energy Source` | String | Grid, Solar, Wind | Dominant power source at this timestamp (~33% each). RL agent should prefer Solar and Wind over Grid | +| `Renewable Energy Usage (%)` | Float | 52.8 | Percentage of total power drawn from renewable sources. Direct reward component: higher = better | +| `HVAC Power Usage (kWh)` | Float | 5.12 | Energy used by HVAC in this interval. **Controllable by the AI action space.** Reducing this while maintaining Room Temperature = positive reward | +| `Lighting Power Usage (kWh)` | Float | 1.87 | Energy used by lighting. Also controllable. Can be dimmed during low-activity periods without affecting patient safety | +| `Medical Equipment Power Usage (kWh)` | Float | 2.30 | Energy used by medical devices. Treated as a **fixed load** | +| `Total Power Usage (kWh)` | Float | 9.29 | `= HVAC + Lighting + Medical Equipment`. Minimising this while keeping Room Temperature and Humidity in safe ranges is an AI reward | +| `Room Temperature (°C)` | Float | 21.7 | Ambient temperature inside the patient's room — what the HVAC controls. **AI target: 21–23 °C** for ICU comfort | +| `Room Humidity (%)` | Float | 33.7 | Ambient humidity inside the patient room. AI target 30–60% | +| `HVAC Mode` | String | Heating or Cooling | Current HVAC operating mode (~50/50 split). Both an observable state and the AI's last action. Heating = 1, Cooling = 0 | +| `HVAC Efficiency (%)` | Float | 92.9 | How efficiently HVAC converts energy into useful heating/cooling. Low efficiency = system working hard achieving little. Reward penalty: high power + low efficiency = bad | +| `Outdoor Temperature (°C)` | Float | 18.9 | External ambient temperature. Gap between outdoor and room temperature = the thermal load HVAC must overcome. Used for predictive pre-conditioning | +| `Outdoor Humidity (%)` | Float | 58.3 | External ambient humidity. Used alongside outdoor temperature to predict HVAC load and pre-plan energy sourcing | +| `Day of the Week` | Integer (0–6) | 2 | 0 = Monday, 6 = Sunday. Used for time-of-week patterns in energy demand | +| `Season` | String | Fall, Winter, Spring, Summer | Calendar season. Affects expected outdoor temperature range and baseline HVAC load. Context variable in the RL state space | +| `Energy Saving Mode` | Integer (0/1) | 0 or 1 | **AI action flag.** 1 = energy saving mode active (reduced HVAC and lighting intensity). A direct action the RL agent can toggle each step | +| `System Health Check` | Integer (0/1) | 0 or 1 | Hardware status. 0 = all systems healthy, 1 = fault or maintenance alert active. When 1, the AI should avoid aggressive energy optimisation and prioritise stability | +| `AI Predicted Health Status` | String | Healthy, Unhealthy | AI's prediction of overall patient/system health at this timestep. When Unhealthy, the RL agent should weight patient safety constraints more heavily | + +--- + +## How this fits the wider project + +This manual describes a **building-and-patient digital twin** — HVAC control, room comfort, +patient vitals as reward signals. That is a materially different system from the one the +[Simulator I/O Interface](../02-specifications/simulator-io-interface.md) specifies, which is a +**power-dispatch** environment: PV, battery, electrolyser, fuel cell, H₂ tank, grid. + +The two are complementary rather than contradictory — HVAC is the largest shiftable load in the +[tier model](bidmc-ucsd-energy-flow-and-balances.md) — but nothing yet connects them. In +particular: + +- No hydrogen, electrolyser, fuel cell, or battery SoC appears in any of these datasets. +- `Season` covering all four values within a 2025-01-01 → 2025-02-04 window is internally + inconsistent, reinforcing that the file is generated. +- Clinical reward signals (heart rate returning to safe range) are not present in the RL + [reward specification](../02-specifications/rl-reward-function.md), which is purely + energy/resilience-oriented. + +Deciding whether the clinical layer is in scope is an open project question, not a documentation +gap. + +## Related + +- [BIDMC ComStock Load Profile](bidmc-parquet-load-data-manual.md) — the whole-building load proxy that complements these files +- [BIDMC Digital Twin Readiness Checklist](bidmc-digital-twin-readiness-checklist.md) — the readiness assessment over this data +- [BIDMC/UCSD Energy Flow and Balances](bidmc-ucsd-energy-flow-and-balances.md) — where the tier power figures come from +- [Dataset Inventory](../06-data/dataset-inventory.md) — every data file in the repo diff --git a/docs/03-energy-management/bidmc-digital-twin-readiness-checklist.md b/docs/03-energy-management/bidmc-digital-twin-readiness-checklist.md new file mode 100644 index 0000000..aa6d2fd --- /dev/null +++ b/docs/03-energy-management/bidmc-digital-twin-readiness-checklist.md @@ -0,0 +1,222 @@ +# AI & Digital Twin Readiness Checklist — BIDMC + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/Beth Israel Deaconess Medical Center/Hospital_AI_DigitalTwin_Readiness_Checklist for BIDMC.docx` | +> | **Format** | Microsoft Word (.docx), 29.6 kB | +> | **MD5** | `f7d1d4b7877b5f96cff9204012d4071f` | +> | **Owner** | Energy Management cluster | +> | **Status** | Current — **partially completed** (sections 1–3 scored, 4–8 blank) | +> | **Report generated** | 2026-07-25 | + +## Scope + +Covers Energy Microgrid (Shift data) + Clinical Operations + Integration + Governance. + +**How to use it:** for each criterion, mark ☑ PASS, △ PARTIAL, or ✗ FAIL in the rightmost +column. **Any FAIL in Sections 1–4 is a blocker** for RL training or digital twin deployment. + +**Clinical gap:** Sections 5–8 represent data that must be sourced from the hospital EMR, CMMS, +HR systems, and governance processes before a whole-hospital digital twin can be deployed. + +Referenced data source: `https://physionet.org/content/mimic-iv-demo/2.2/icu/inputevents.csv.gz` + +### Scoring legend + +| Mark | Meaning | +|---|---| +| ☑ **PASS** | Criterion fully met | +| △ **PARTIAL** | Partially met; gap plan required | +| ✗ **FAIL** | Not met; deployment blocker | + +> [!IMPORTANT] +> **Completion status.** Sections 1–3 have been scored. Sections 4–8 — including +> *Operational Constraints & Safety*, which the document itself declares a blocker section — +> are **entirely unscored**. This is the single most important open item in this document: the +> safety gate has been written but not walked through. +> +> The scorer also introduced two verdicts outside the legend — **"No need"** and +> **"No need for now"** — used 7 times. These are scope decisions, not readiness assessments, +> and they are recorded below verbatim. + +--- + +## 1. Data infrastructure & temporal fidelity — *"The Substrate"* + +Focuses on whether the raw data is granular and consistent enough for model training. Directly +maps to Shift input variables (V, I, P, SoC, irradiance, n_H2, etc.). + +| Criterion | What to verify / acceptance standard | Verdict | +|---|---|---| +| **Data Resolution** | Time-series data available at ≤ 15-minute intervals. Applies to all dynamic variables (P, I, V, SoC) | ☑ Pass | +| **Timestamp Synchronization** | All generation (PV/fuel cell), storage (BESS), electrolyzer, and load meters time-aligned to a single master clock. Max drift < 1 second | △ Partial | +| **Historical Depth** | Minimum 12 months of continuous data to capture seasonal variability in load, solar irradiance (W/m²), and hospital occupancy patterns | ☑ Pass | +| **Telemetry Reliability** | Missing/null values < 5% across all channels. Gaps flagged with error codes rather than zero-filled. Consistent sampling rate | ☑ Pass | +| **Data Schema & Ontology** | Unified data dictionary maps every sensor tag (e.g. `V_electrolyzer`, `SoC_battery`, `n_H2_in`) to physical asset, engineering unit, and measurement type | *No need for now* | +| **Multi-System Integration Readiness** | Energy (SCADA/BMS), clinical (EHR/EMR), and facility (CMMS) data agree on one timing format. ETL pipeline or middleware (HL7 FHIR, OPC-UA, Brick Schema) documented; data repeatable and up to date | △ Partial | + +## 2. Reinforcement learning readiness — *"The Agent"* + +Shift data covers the energy action space and state space well; clinical rewards and +multi-agent aspects are absent. + +| Criterion | What to verify / acceptance standard | Verdict | +|---|---|---| +| **Action Space Definition** | Enumerated list of controllable setpoints: charge/discharge power (kW), electrolyzer ON/OFF & power setpoint, fuel cell ON/OFF, HVAC setpoints, OR scheduling levers | △ Partial — *reward function should be defined* | +| **Control Latency Documentation** | Round-trip delay (command → hardware response) measured and documented for each actuator: electrolyzer ramp, BESS response, fuel cell throttle. Required for accurate environment simulation | △ Partial — *hydrogen ramp needed* | +| **Economic Reward Signals** | Local electricity tariffs (time-of-use, peak demand charges), carbon intensity factors, and cost-per-bed-day metrics available as time-series for RL reward shaping | ☑ Pass | +| **Clinical Reward Signals** | Outcome-linked metrics available: patient wait time, length-of-stay, readmission rate, adverse event rate — to define a multi-objective reward beyond energy cost alone | ☑ Pass | +| **Environmental Stochasticity** | Time-aligned local weather (irradiance W/m², ambient temperature K — from Shift data) plus demand shocks (mass-casualty events, seasonal disease surges) to model real-world uncertainty | ☑ Pass | +| **State Space Completeness** | All observable variables logged: Shift energy states (SoC, V, I, P, n_H2, p_tank) plus clinical census and equipment status. Partially observable regions identified and quantified | ☑ Pass | +| **Multi-Agent Considerations** | Interdependencies between semi-autonomous units (ED, ICU, OR, pharmacy, energy microgrid) mapped. Conflict-resolution protocol defined for competing RL agents | *No need* | +| **Simulation Environment (Gym)** | A simulator or emulator exists where the RL agent trains without affecting the live hospital. Electrolyzer, fuel cell, BESS, and PV physics models (using Shift parameters) implemented offline | *No need* | +| **Minimum Operating Constraints** | Minimum operating current (electrolyzer) and operating voltage range (fuel cell) that cannot be violated by any RL action | ☑ Pass | +| **Hydrogen Production Calibration** | Measured hydrogen production rate calibration factor (Shift data) applied to the `n_H2` output model to correct for real-world deviation from theoretical Faraday efficiency μ_F | ☑ Pass | + +> [!WARNING] +> **"Simulation Environment (Gym) — *No need*"** directly contradicts the rest of the project. +> Building exactly this Gym-style environment is what the +> [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) exists to specify, +> and it is [WP3/WP4](../01-project/work-packages.md) of the work plan. The most likely reading +> is *"not needed as a prerequisite from the hospital"* — i.e. SHIFT builds it, so BIDMC does +> not have to supply it. Worth clarifying in the source document, because as written it reads +> as a scope cut. +> +> Similarly, **"Clinical Reward Signals — Pass"** is optimistic: the +> [RL reward specification](../02-specifications/rl-reward-function.md) contains no clinical +> outcome term at all, and Section 5 of this same checklist marks all clinical operations data +> as *"entirely absent from the Shift input data."* + +## 3. Digital twin & physics-based modelling — *"The Twin"* + +Shift data provides good component constants (N_c, μ, A_PV, E_rated, Q_rated); topology and +clinical process models are missing. + +| Criterion | What to verify / acceptance standard | Verdict | +|---|---|---| +| **Electrolyser Physics Model** | N_c (cells), μ_F (Faraday efficiency), operating voltage V, minimum current, power setpoint range, n_H2 output — all documented | ☑ Pass | +| **Fuel Cell Physics Model** | N_c (cells), voltage range, max output power, utilization %, n_H2_in and n_H2_used documented. Efficiency-vs-load curves at 25/50/75/100% utilization required | ☑ Pass | +| **Hydrogen Tank Model** | V_H2 max & initial (L), temperature T (K), pressure p (atm), n_H2_in and n_H2_out flow rates available for tank thermodynamic (ideal gas) model | ☑ Pass | +| **PV & Battery Parameters** | A_PV (m²), panel efficiency μ, E_rated, Q_rated (charge capacity), max charge/discharge power, SoC max & initial — all in Shift data | ☑ Pass | +| **Component Performance Curves** | Non-linear efficiency-vs-load curves for fuel cell/CHP at multiple load points, chiller COP curves, generator fuel consumption. PV I-V curve under varying irradiance | △ Partial — *manufacturer data sheet might be needed* | +| **System Topology — Energy** | Detailed electrical single-line diagram (SLD) and connection topology (PV→BESS→Electrolyser→Fuel Cell→Load→Grid) in machine-readable format (CIM XML or equivalent) | ☑ Pass | +| **System Topology — Facility & Clinical** | Floor plans, room-to-department mappings, HVAC zone layouts. Hospital load P_load disaggregated by unit (ICU, OR, wards, labs) for clinical-energy co-simulation | ☑ Pass | +| **Thermal Inertia & Dynamics** | Thermal mass of building envelope, hot-water storage, and critical rooms (OR, ICU) documented. Required for multi-energy modelling and infection-control simulation | *No need for now* | +| **Asset Health / Degradation** | Historical SoH or cycle-count data for BESS; maintenance logs for electrolyzer membrane and fuel cell stack to model long-term degradation | △ Partial — *historical maintenance logs for electrolyser membranes not included* | +| **Patient Flow Physics Model** | Stochastic arrival models (Poisson / time-varying) calibrated to historical ED arrivals. Service-time distributions per acuity level and DRG/care-pathway | *No need for now* | +| **Infection & Environmental Models** | HVAC air-change rates, filtration levels, and room-pressure differentials per zone documented to support the infection-risk component | *No need for now* | +| **Twin Validation Dataset** | ≥ 3 months of historical data withheld from training for twin accuracy validation. Covers both energy and clinical domains | ☑ Pass | +| **Uncertainty Quantification** | Method defined for reporting confidence intervals. Ensemble, Bayesian, or conformal prediction approach specified. Sim-to-real gap assessment methodology documented | *No need for now* | + +> **"System Topology — Facility & Clinical — Pass"** sits awkwardly against the +> [Simulator I/O Interface](../02-specifications/simulator-io-interface.md#5-open-questions), +> which lists *"Critical vs non-critical split — data availability"* as an unresolved open +> question, and against §6 below, which marks Hospital Load Disaggregation as unscored. + +## 4. Operational constraints & safety — *"The Boundary"* + +Guardrails ensuring the AI or twin does not simulate or propose dangerous actions. Shift data +covers energy hard limits partially; clinical safety floors and full islanding sequences are +absent. + +> **Not yet scored.** Every verdict below is blank in the source. Per the document's own rule, +> any FAIL here is a deployment blocker — so this section must be completed before RL training +> is considered ready. + +| Criterion | What to verify / acceptance standard | Verdict | +|---|---|---| +| **Hard Safety Interlocks — Energy** | Controller limits documented: min/max BESS SoC, electrolyser minimum current, fuel cell voltage range and max output power, maximum grid connection capacity | *(blank)* | +| **Hard Safety Interlocks — Clinical** | Clinical safety floors documented: minimum nurse-to-patient ratios per acuity, minimum OR turnaround time, ICU bed reserve thresholds. Encoded as inviolable RL constraints | *(blank)* | +| **Ramping Constraints** | Maximum ramp rates (MW/min) for gas engines, fuel cells, and HVAC plant. Clinical analogue: maximum safe admission rate per hour per unit during demand surge | *(blank)* | +| **Critical Load Ranking** | Quantified load priority list: Tier 1 (ICU/OR/Life Safety), Tier 2 (Labs/Pharmacy/NICU), Tier 3 (Admin/Amenities). Machine-readable for automated load-shedding decisions | *(blank)* | +| **Islanding Protocols** | Grid-disconnection and reconnection sequence fully documented and machine-readable. Islanded-mode operating limits for all critical loads. Grid ON/OFF flag is necessary but not sufficient | *(blank)* | +| **Regulatory & Compliance Constraints** | HIPAA, CMS Conditions of Participation, Joint Commission, and local fire/life-safety codes encoded as hard constraints in the RL reward/penalty function | *(blank)* | +| **Fail-Safe & Override Modes** | Human override capability exists for every AI-controlled setpoint (electrolyser, BESS, fuel cell, load-shed relay). Override events logged. Manual-control fallback tested and certified | *(blank)* | +| **Adverse Event Taxonomy** | Formal taxonomy of AI-attributable adverse events defined: loss of life-safety power, inadvertent ICU load shed, delayed discharge due to energy curtailment. Used for reward shaping | *(blank)* | + +> Note: the Tier 2 membership here (**Labs/Pharmacy/NICU**) differs from the tier definition in +> [Energy Flow and Balances](bidmc-ucsd-energy-flow-and-balances.md) (**Clinical HVAC, Imaging, +> Medical Wards, Critical Lighting**). Two different tier taxonomies are in circulation. + +## 5. Clinical & operational data — *"The Patient Flow Engine"* + +Core hospital operations data — **entirely absent from the Shift input data**. Essential for a +whole-hospital digital twin beyond the energy microgrid subsystem. *Not scored.* + +| Criterion | Acceptance standard | +|---|---| +| **ADT Event Logs** | Admission, Discharge, Transfer events with timestamps, patient acuity (ESI/DRG), and destination unit. Minimum 24 months for seasonal modelling | +| **Bed Occupancy Time-Series** | Per-unit bed census at ≤ 1-hour intervals. Staffed vs licensed bed counts distinguished. Surge capacity thresholds and escalation triggers documented | +| **ED Arrival Patterns** | Hourly ED arrival counts with triage acuity (ESI 1–5) for ≥ 24 months. Required to fit time-varying Poisson arrival distributions | +| **Length-of-Stay Distributions** | LOS distributions per DRG/condition for inpatient and observation stays. Geometric mean LOS and outlier thresholds (± 1 SD) per condition group | +| **OR Scheduling & Utilisation** | Scheduled vs actual case start/end times, case type, room, turnover durations for ≥ 12 months. Block-time rules and add-on case policies documented | +| **Staffing & Shift Patterns** | Nurse, physician, and tech staffing levels per unit per shift, linkable to patient outcomes (falls, medication errors, HCAHPS). Shift handoff protocols documented | +| **Equipment Utilisation Logs** | Utilisation rates for ventilators, imaging (CT/MRI), infusion pumps, dialysis machines. Required to model equipment bottlenecks and energy demand spikes | +| **Lab & Radiology Turnaround** | Order-to-result turnaround for STAT and routine orders. Essential for care-pathway twin fidelity and discharge delay modelling | +| **Medication Dispensing Patterns** | Pharmacy dispense records with timestamps and location. Enables supply-chain and medication-delay modelling | +| **Readmission & Outcome Data** | 30-day readmission rates, in-hospital mortality, HAI rates, and patient satisfaction scores linkable to admission episodes for RL reward calibration | + +## 6. Multi-domain integration & interoperability — *"The Connective Tissue"* + +Assesses whether energy (Shift data), clinical (EMR), and facility (CMMS) data can be +semantically and temporally linked into one twin environment. *Not scored.* + +| Criterion | Acceptance standard | +|---|---| +| **Common Data Model** | Unified ontology adopted or cross-schema mapping documented: FHIR R4 (clinical), CIM XML (energy), Brick Schema (facility/HVAC). Shift variable names mapped to ontology terms | +| **Cross-Domain Time Alignment** | Clinical (EMR), energy (SCADA/BMS/Shift), and facility (CMMS) data share ISO 8601 UTC timestamps and can be inner-joined without resampling artefacts | +| **Semantic Linkage — Energy to Clinical** | Energy demand surge events (BESS discharge, fuel cell activation) causally linked to clinical triggers (census spike, OR activation) via a shared event log | +| **Hospital Load Disaggregation** | The lumped `P_load` variable disaggregated into sub-meter readings per clinical unit (ICU, OR, wards, labs) for unit-level load forecasting and clinical-energy co-optimisation | +| **Data Governance & Access Controls** | Data sharing agreements, de-identification protocols (HIPAA Safe Harbor or Expert Determination), and role-based access controls documented and active for all data streams | +| **Real-Time API / Feed Availability** | Live data feeds (REST/MQTT/OPC-UA/HL7) from BMS, EMR, and SCADA available for real-time twin synchronisation. Latency < 30 s per stream documented | +| **Master Asset Register** | Single register links physical assets across EMR billing codes, CMMS maintenance IDs, and SCADA tag names (e.g. electrolyser unit ↔ maintenance record ↔ SCADA tag) | + +## 7. Reward function & objective completeness — *"The Goal"* + +Ensures the RL reward captures all hospital objectives. Shift data provides only energy-side +inputs; clinical outcome metrics and multi-objective weighting are absent. *Not scored.* + +| Criterion | Acceptance standard | +|---|---| +| **Multi-Objective Reward Definition** | Formal reward function with explicit weights or Pareto constraints across energy cost, patient outcomes, throughput, safety violations, and staff workload | +| **Reward Shaping for Safety** | Safety violations (loss of life-safety power, ICU boarding > threshold, electrolyser overcurrent) incur large negative rewards. Magnitudes validated by clinical and engineering experts | +| **Reward Time Horizon** | Discount factor (γ) and episode length balance short-term energy cost savings vs long-term asset health (BESS degradation, electrolyser membrane life) and patient outcome improvement | +| **Reward Signal Observability** | All reward components measurable in real time or near real time (< 5-min lag). Proxy metrics defined for unobservable outcomes | +| **Reward Alignment Validation** | Clinical, engineering, and operations SMEs reviewed and signed off the reward function. Ethics policy confirmed. **Reward not gameable by trivial policy** (e.g. always import grid power) | + +> This section is the direct counterpart to the +> [RL Reward Function specification](../02-specifications/rl-reward-function.md), whose central +> open problem — *no weights defined across 26 terms* — is precisely "Multi-Objective Reward +> Definition" here. + +## 8. Validation, uncertainty & governance — *"The Trust Framework"* + +Criteria for testing the twin against reality, quantifying uncertainty, and governing AI +decisions before and after deployment. *Not scored.* + +| Criterion | Acceptance standard | +|---|---| +| **Held-Out Validation Dataset** | ≥ 3 months of historical data withheld from training. Twin predictions compared to actuals: energy forecast MAPE ≤ 5%, bed census MAPE ≤ 10%, LOS prediction within ± 0.5 days | +| **Key Accuracy Thresholds** | Minimum accuracy targets defined per output before deployment sign-off: energy, bed census, LOS, equipment utilisation, and hydrogen production rate | +| **Sim-to-Real Gap Assessment** | Formal protocol to measure and track divergence between twin predictions and real outcomes over time. Drift threshold triggers automatic re-calibration | +| **Uncertainty Quantification** | Confidence/prediction intervals reported for all twin outputs. Ensemble, Bayesian, or conformal prediction approach specified and propagated through multi-step forecasts | +| **Explainability Requirements** | RL policy actions explainable to clinical and operational staff. SHAP or LIME applied to high-stakes decisions (load shedding, electrolyser curtailment during peak clinical demand) | +| **Model Governance & Versioning** | All model versions tracked with training data lineage, hyperparameters, and performance metrics. Rollback to prior version possible. Change-control process documented | +| **Continuous Monitoring Plan** | Post-deployment dashboard covers model drift, data quality degradation (sensor failures), and safety-constraint violations. Alert thresholds and escalation paths defined | +| **Ethics & Bias Review** | Training data audited for demographic bias in clinical submodels. Outputs reviewed for disparate impact across patient subgroups (race, age, insurance). Review board sign-off required | +| **Regulatory / SaMD Assessment** | If the digital twin or RL agent constitutes Software as a Medical Device (SaMD), FDA 510(k)/De Novo or EU MDR classification assessed and submission strategy documented | + +> The **energy forecast MAPE ≤ 5%** threshold here matches the CV-RMSE < 5% target in the +> [Forecasting Requirements](../02-specifications/forecasting-requirements.md#23-evaluation-and-metrics), +> though one is MAPE and the other CV-RMSE — worth reconciling so a single number gates +> deployment. + +## Related + +- [BIDMC Datasets Manual](bidmc-datasets-manual.md) — the data this checklist assesses +- [BIDMC ComStock Load Profile](bidmc-parquet-load-data-manual.md) +- [RL Reward Function](../02-specifications/rl-reward-function.md) — §7 is its readiness gate +- [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) — the Gym environment §2 refers to +- [UCSD Equipment Manual](ucsd-equipment-manual.md) — component specs §3 depends on diff --git a/docs/03-energy-management/bidmc-parquet-load-data-manual.md b/docs/03-energy-management/bidmc-parquet-load-data-manual.md new file mode 100644 index 0000000..5e4449b --- /dev/null +++ b/docs/03-energy-management/bidmc-parquet-load-data-manual.md @@ -0,0 +1,164 @@ +# BIDMC Load Profile — NREL ComStock Parquet Manual + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/Beth Israel Deaconess Medical Center/BIDMC_Parquet_Load_Data_Manual.docx` | +> | **Format** | Microsoft Word (.docx) | +> | **MD5** | `af1178d355dda935363046f04a64e34d` | +> | **Describes** | `89993-0.parquet` (2.37 MB) in the same folder | +> | **Owner** | Energy Management cluster | +> | **Status** | Current | +> | **Report generated** | 2026-07-25 | + +## What the file contains + +`89993-0.parquet` holds **a full year of simulated energy consumption** for a 500,000 sq ft +hospital building in Massachusetts. It was generated by NREL's **ComStock** simulation platform +using EnergyPlus and actual 2018 meteorological weather data (AMY2018) for the Boston climate. + +Building **ID 89993** was selected as the best available public proxy for Beth Israel Deaconess +Medical Center based on: + +- similar floor area (~500,000 sq ft), +- building date (late-1950s construction), +- HVAC system type (VAV chiller + gas boiler), +- climate zone. + +This is the **baseline** scenario (`upgrade00`). + +> [!IMPORTANT] +> This is **simulated stock-model data, not measured BIDMC data**. It is a proxy. The +> [Forecasting Requirements](../02-specifications/forecasting-requirements.md#21-inputs) flags +> real historical hospital load as the project's biggest data gap — this file is the current +> stand-in for it, not a resolution of it. + +## File overview + +| Property | Value | +|---|---| +| File name | `89993-0.parquet` | +| Building ID | 89993 | +| Source | NREL End-Use Load Profiles for US Building Stock (ComStock 2025) | +| Building type | Hospital | +| State | Massachusetts (Climate Zone 5A — Boston) | +| Floor area | 500,000 sq ft (46,450 m²) | +| Vintage / year built | 1946–1959 (built 1959) | +| Number of floors | 4 | +| File version | Upgrade 00 — Baseline | +| Time resolution | **15 minutes** | +| Total rows | 35,040 (full year 2018) | +| Time period | 2018-01-01 00:15 to 2019-01-01 00:00 | +| HVAC system | VAV chiller with gas boiler reheat | +| Heating fuel | Natural gas | + +## Column reference + +Each energy end use appears in **two forms** across the 64 columns: absolute consumption (kWh +per 15-minute interval) and intensity (kWh per sq ft per 15-minute interval). The intensity +columns are useful for scaling the data to BIDMC's exact floor area. + +| Column name | Unit | Annual total | Peak (15-min) | +|---|---|---|---| +| `bldg_id` | — | 89993 (constant) | — | +| `timestamp` | date | 2018-01-01 to 2019-01-01 | — | +| `out.electricity.cooling.energy_consumption` | kWh | 1,025,061 | 210.14 | +| `out.electricity.fans.energy_consumption` | kWh | 1,042,572 | 131.76 | +| `out.electricity.interior_equipment.energy_consumption` | kWh | 3,247,485 | 170.15 | +| `out.electricity.interior_lighting.energy_consumption` | kWh | 1,597,696 | 118.15 | +| `out.electricity.pumps.energy_consumption` | kWh | 544,941 | 25.12 | +| `out.electricity.heat_recovery.energy_consumption` | kWh | 186,740 | 7.69 | +| `out.electricity.heat_rejection.energy_consumption` | kWh | 81,596 | 22.49 | +| `out.electricity.exterior_lighting.energy_consumption` | kWh | 107,751 | 6.69 | +| `out.electricity.water_systems.energy_consumption` | kWh | 153,266 | 4.51 | +| `out.electricity.refrigeration.energy_consumption` | kWh | 39,259 | 2.79 | +| `out.electricity.purchased.energy_consumption` | kWh | 8,026,366 | — | +| `out.electricity.total.energy_consumption` | kWh | 8,026,366 | — | +| `out.natural_gas.heating.energy_consumption` | kWh | 6,893,812 | — | +| `out.natural_gas.water_systems.energy_consumption` | kWh | 1,195,680 | — | +| `out.natural_gas.interior_equipment.energy_consumption` | kWh | 861,204 | — | +| `out.site_energy.total.energy_consumption` | kWh | 16,977,060 | — | + +**All-zero columns:** `out.electricity.heating`, `out.electricity.pv`, +`out.district_cooling.*`, `out.district_heating.*`, `out.fuel_oil.*`, and `out.propane.*`. This +building uses natural gas for heating and has no on-site PV or district energy connections in +the baseline case. + +> The absence of an `out.electricity.pv` signal is convenient rather than limiting: SHIFT +> supplies its own PV generation from the +> [PV hourly dataset](pv-hourly-dataset-manual.md), so the ComStock profile provides pure +> *demand* with no embedded generation to net out. + +## Filling gaps in the existing datasets + +These values are complementary to those in `hospital_communication_energy_system.csv` (see the +[BIDMC Datasets Manual](bidmc-datasets-manual.md)). Only the rows marked *New column* do not +exist in that CSV, but can be added. + +| Parquet data | Maps to | How it's used | +|---|---|---| +| `electricity.interior_equipment` | Medical Equipment Power Usage (kWh) | Equipment load correlated with MIMIC clinical events | +| `electricity.cooling + fans + pumps` | HVAC Power Usage (kWh) | RL action target for demand shifting | +| `electricity.interior_lighting` | Lighting Power Usage (kWh) | Partially controllable — follows occupancy/shift schedule | +| `electricity.purchased` (hourly sum) | Total Power Usage (kWh) | RL environment state: total demand the agent must satisfy | +| `natural_gas.heating` | **New column** — Thermal Load (kWh) | Drives HVAC heating decisions; links to UCSD thermal storage data | +| All intensity columns (`*_intensity`) | **New column** — Load per sq ft | Normalization factor for scaling BIDMC to actual floor area | + +## Overall energy statistics + +### Annual summary + +| Metric | Value | +|---|---| +| Total electricity purchased from grid | **8,026,366 kWh/year** | +| Total natural gas consumed | **8,950,696 kWh** equivalent/year | +| Total site energy (all fuels) | **16,977,060 kWh/year** | +| Energy use intensity (EUI) | **33.9 kWh/sq ft/year** | + +At 8,026 MWh/year the building averages **≈ 916 kW** of continuous electrical demand. + +### Electricity end-use breakdown + +| End use | Annual (kWh) | Share of electricity | +|---|---:|---:| +| Interior equipment (medical devices, computers, plug loads) | 3,247,485 | **40.5%** | +| Interior lighting | 1,597,696 | 19.9% | +| HVAC fans | 1,042,572 | 13.0% | +| Cooling (chiller) | 1,025,061 | 12.8% | +| Pumps (HVAC circulation) | 544,941 | 6.8% | +| Heat recovery | 186,740 | 2.3% | +| Water systems | 153,266 | 1.9% | +| Exterior lighting | 107,751 | 1.3% | +| Cooling tower (heat rejection) | 81,596 | 1.0% | +| Refrigeration | 39,259 | 0.5% | + +### Natural gas breakdown + +| End use | Annual (kWh) | Note | +|---|---:|---| +| Space heating | 6,893,812 | Mostly in Boston winters | +| Service water heating | 1,195,680 | Hot water for clinical/kitchen use | +| Interior equipment (gas-fired) | 861,204 | Kitchen equipment, sterilizers | + +## Practical notes + +- **Resolution matches the forecasting spec, not the simulator default.** 15-minute resolution + lines up with the `t−96`/`t−672` lags in the + [PV forecasting inputs](../02-specifications/forecasting-requirements.md#11-inputs), but the + [Simulator I/O Interface](../02-specifications/simulator-io-interface.md#timestep) defaults to + hourly steps. Aggregating 4→1 is trivial; the reverse is not. +- **No critical/non-critical split.** ComStock reports by *end use*, not by clinical criticality. + Deriving `L_crit` / `L_noncrit` requires the tier mapping in + [Energy Flow and Balances](bidmc-ucsd-energy-flow-and-balances.md) or a proxy fraction — an + open question the simulator sheet explicitly flags. +- **Natural gas is larger than electricity.** 8,951 MWh gas vs 8,026 MWh electricity. A + hydrogen microgrid that only displaces *electricity* addresses under half of this building's + site energy. + +## Related + +- [BIDMC Datasets Manual](bidmc-datasets-manual.md) — the clinical and synthetic-energy datasets this complements +- [BIDMC/UCSD Energy Flow and Balances](bidmc-ucsd-energy-flow-and-balances.md) — the load-tier model +- [Forecasting Requirements](../02-specifications/forecasting-requirements.md) — §2, hospital demand forecasting +- [Dataset Inventory](../06-data/dataset-inventory.md) — every data file in the repo diff --git a/docs/03-energy-management/bidmc-ucsd-energy-flow-and-balances.md b/docs/03-energy-management/bidmc-ucsd-energy-flow-and-balances.md new file mode 100644 index 0000000..8ba116b --- /dev/null +++ b/docs/03-energy-management/bidmc-ucsd-energy-flow-and-balances.md @@ -0,0 +1,224 @@ +# Energy Flow and Specifications for the Hybrid Hospital + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/Beth Israel Deaconess Medical Center/BIDCM-UCSD hybrid hospital energy flow and balances.docx` | +> | **Format** | Microsoft Word (.docx), 162 kB | +> | **MD5** | `27a86f331086ce60c078b412d5205e5b` | +> | **Owner** | Energy Management cluster | +> | **Status** | **Current revision.** An earlier copy sits in [`superseded/`](../../superseded/) — see [Revision history](#revision-history) | +> | **Report generated** | 2026-07-25 | + +> [!NOTE] +> The source document contains one embedded figure (`Fig-1: Energy Flow Diagram`) and twelve +> OOXML equations. The equations are transcribed below in plain notation. **The figure is not +> reproducible in this report** — open the original `.docx` to see it. +> +> The document title spells the hospital *"BIDCM"*; the correct abbreviation is **BIDMC** +> (Beth Israel Deaconess Medical Center). Filename retained as-is for traceability. + +## Dispatch priority + +| Priority | Source | Mode | Purpose | +|---|---|---|---| +| **Level 1** | Solar PV | Sustainability | Normal daylight operations & storage charging | +| **Level 2** | Battery / H₂ | Resilience | After-hours operations and bridging short gaps | +| **Level 3** | MATEP CHP | Reliability | Constant baseload and thermal support | +| **Level 4** | Eversource Grid | Redundancy | Last-resort emergency backup for critical areas | + +*MATEP* — Medical Area Total Energy Plant, the CHP plant serving the Longwood Medical Area. +*Eversource* — the New England utility serving Boston. + +### Primary generation (daytime) + +- **Solar lead.** Solar energy is the main source. +- **Direct supply.** Solar energy flows to the AC electrical bus (distribution point) to power + the hospital immediately. +- **The "deposit".** Any electricity not needed by the hospital is diverted to charge the + battery and run the electrolyzer. + +### Transition to storage (evening) + +- **Solar fade.** Solar production stops. +- **The "withdrawal".** The battery is the *first responder*, discharging immediately to keep + the bus powered. If the battery runs low, the hydrogen fuel cell activates, converting the + stored hydrogen back into electricity. +- **Baseload support.** The MATEP CHP plant provides a steady stream of natural-gas-generated + power to bridge any gaps. + +### The safety net (emergency) + +- **Grid activation.** The Eversource grid stays on standby until a major failure occurs or + on-site storage is depleted. +- **Load shedding.** To protect the most critical patients, the system pauses power to Tier 2 + loads (HVAC, general wards, imaging) to ensure Tier 1 loads (ICU, operating rooms, life + safety) stay running indefinitely. + +## Critical load management + +### Load tiers + +| Tier | Priority | Includes | Status in emergency | +|---|---|---|---| +| **Tier 1** | Critical | ICU, Operating Rooms (OR), Life Safety (fire/alarms), Critical Communications | **Always on** — guaranteed by battery, fuel cell, and grid | +| **Tier 2** | Essential | Clinical HVAC, Imaging (MRI/CT), Medical Wards, Critical Lighting | **Shiftable** — may be curtailed or cycled to preserve storage | +| **Tier 3** | Non-critical | Administrative Offices, Cafeteria, Gift Shop, Non-essential Lighting | **Shed first** — paused immediately during a grid emergency | + +**Tier 1 — what should not go down.** These systems are defined as *never interrupted* and are +the only loads guaranteed during an emergency grid backup scenario: intensive care units +(continuous monitoring and life-support), operating rooms (surgical equipment and critical +environment controls), and life safety (emergency lighting, fire systems, critical +communications). + +**Tier 2 — shiftable/interruptible.** Considered *essential* but may be paused if on-site +storage is depleted or during a grid emergency to prioritise Tier 1: building climate control +(HVAC), diagnostic imaging (MRI, CT), and general wards. + +### Approximate power requirements + +Derived from `hospital_communication_energy_system.csv` at 5-minute intervals: + +| Tier | Average per interval | Approx. continuous | Note | +|---|---|---|---| +| Tier 1 — Medical Equipment | ~3.01 kWh | **~36 kW** | Baseline for patient monitoring and life-support machines that must never be interrupted | +| Tier 2 — HVAC & Clinical Support | ~4.99 kWh | **~60 kW** | Largest single draw. Essential for patient comfort, but designed to be shifted when running solely on backup storage | +| Tier 3 — Lighting & Admin | ~2.00 kWh | **~24 kW** | General lighting and non-clinical support. First area reduced in "Energy Saving Mode" | + +> [!WARNING] +> These figures come from a **synthetic** dataset (`hospital_communication_energy_system.csv`, +> 10,000 rows covering 2025-01-01 to 2025-02-04) that represents a *single patient room +> snapshot per row*, not whole-hospital totals. The ~36/60/24 kW figures are therefore not +> whole-building loads. For comparison, the +> [NREL ComStock hospital profile](bidmc-parquet-load-data-manual.md) puts a comparable +> 500,000 sq ft hospital at **8,026 MWh/year** ≈ 916 kW average. Treat the tier split as a +> *ratio* (roughly 26% / 44% / 18% by these numbers), not as absolute magnitudes. + +## Energy balances + +### Overall balance + +``` +P_solar(t) + P_CHP(t) + P_Grid(t) + P_FuelCell(t) + P_Battery_discharge(t) + = P_Load(t) + P_Battery_charging(t) + P_Electrolyzer(t) +``` + +where `P_Load` is the sum of all tiers (Tier 1 + 2 + 3) and `P_Grid` is typically zero unless +there is an emergency. + +### Battery storage — state of charge update + +``` + P_Battery_charging(t) × η_charging × Δt P_Battery_discharging(t) × Δt +SoC(t) = SoC(t−1) + ──────────────────────────────────────── − ───────────────────────────── + E_cap E_cap × η_discharging +``` + +where `η` are the round-trip efficiencies and `E_cap` is the total energy the battery can store +when fully charged (kWh). `SoC(t)` should remain between its min and max values. + +### Hydrogen loop + +**Electrolyzer (charging):** + +``` + P_Electrolyzer × Δt +m_H2_produced = ───────────────────────── + LHV_H2 × η_electrolyzer +``` + +**Fuel cell (discharging):** + +``` + P_FuelCell × Δt +m_H2_consumed = ───────────────────────── + LHV_H2 × η_fuel_cell +``` + +**Hydrogen tank balance:** + +``` +Mass(t) = Mass(t−1) + m_H2_produced − m_H2_consumed +``` + +where `LHV_H2` is the heat released by combusting a given amount of hydrogen — +**approximately 33.3 kWh/kg, or 120 MJ/kg**. + +### Load tier dispatch logic + +- If `P_available ≥ P_Total_Load` → all tiers are powered +- If `P_available < P_Total_Load` → shed Tier 3 (not critical) +- If `P_available < (Tier 1 + Tier 2)` → shed Tier 2 +- `P_available` **must always exceed Tier 1**, as it is critical + +## KPI formulae + +**Self-Sufficiency Rate (SSR)** + +``` + Σ (P_solar + P_CHP + P_FuelCell + P_Battery_discharge) +SSR = ───────────────────────────────────────────────────── × 100 + Σ P_Load +``` + +**Grid Dependency Ratio** — aiming for **0%** in normal operation + +``` + Σ P_Grid +GDR = ────────── × 100 + Σ P_Load +``` + +**Critical Load Uptime** — aiming for **100%**, showing critical points have power at all times + +``` + Total hours of full Tier 1 powered +CLU = ──────────────────────────────────── × 100 + Total hours in period +``` + +**SoC Violation Rate** — aiming for **0%**, so the battery never goes dangerously low (risking +loss of Tier 1 load) or overcharges (risking hardware damage) + +``` + # of intervals where SoC < SoC_min or SoC > SoC_max +SVR = ──────────────────────────────────────────────────── × 100 + Total intervals +``` + +## Revision history + +Two copies of this document exist in the repository with different content: + +| Location | Size | MD5 | Status | +|---|---|---|---| +| `Energy_Managment/Beth Israel Deaconess Medical Center/` | 161,868 B | `27a86f33…` | **Current** — this report | +| `Energy_Managment/` (parent folder) | 161,536 B | *(differs)* | **Superseded** | + +The only difference: the current revision adds the **SoC Violation Rate** KPI and its target. +Everything else is byte-identical in content. The parent-folder copy is retired to +[`superseded/`](../../superseded/). + +## Notes on scope + +The title and content mix two case studies. The dispatch chain described here — MATEP CHP, +Eversource grid, Boston — is **BIDMC-specific**. UCSD's microgrid uses entirely different +plant (a 2.8 MW molten-carbonate fuel cell, 30 MW of gas turbines, a 2.5 MW / 5 MWh BYD +battery) documented separately in the [UCSD Equipment Manual](ucsd-equipment-manual.md). The +"hybrid" in the title refers to combining lessons from both sites, not to a single physical +plant. + +Note also that this document's **three-tier** load model does not match the **two-way** +`L_crit` / `L_noncrit` split in the +[Simulator I/O Interface](../02-specifications/simulator-io-interface.md). Mapping Tier 1 → +critical and Tiers 2+3 → non-critical is the obvious reconciliation, but it has not been +written down anywhere as a decision. + +## Related + +- [UCSD Equipment Manual](ucsd-equipment-manual.md) — the other case study's plant +- [BIDMC Datasets Manual](bidmc-datasets-manual.md) — the `hospital_communication_energy_system.csv` schema +- [BIDMC ComStock Load Profile](bidmc-parquet-load-data-manual.md) — the whole-building load proxy +- [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) — the simulator contract these balances must satisfy +- [Rule-Based Controller](../02-specifications/rule-based-controller.md) — the dispatch logic in policy form diff --git a/docs/03-energy-management/pv-hourly-dataset-manual.md b/docs/03-energy-management/pv-hourly-dataset-manual.md new file mode 100644 index 0000000..8cb7830 --- /dev/null +++ b/docs/03-energy-management/pv-hourly-dataset-manual.md @@ -0,0 +1,84 @@ +# PV Hourly Dataset Manual + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/PV hourly data/Readme- Manual.docx` | +> | **Format** | Microsoft Word (.docx) | +> | **MD5** | `420336b9a65140e7390bdf3ab21349bb` | +> | **Describes** | `pvwatts_hourly.csv` (0.57 MB) in the same folder | +> | **Owner** | Energy Management cluster | +> | **Status** | Current — **this is the recommended PV dataset** | +> | **Report generated** | 2026-07-25 | + +## Summary + +This dataset contains all the PV hourly performance data of last year for **BIDMC's location**. +A DC array output and an AC system output are available in watts, along with a few +meteorological variables such as albedo and wind speed. + +> *"Very easy to understand, would be recommended over the complex second dataset."* + +The "complex second dataset" is the +[satellite meteorological dataset](satellite-pv-dataset-manual.md) — 167 MB of NSRDB-style +data that the same author explicitly does **not** recommend for extracting PV rates. + +Generated by NREL **PVWatts** (per the filename `pvwatts_hourly.csv`). + +## Column reference + +| Physical quantity | Definition | Units | +|---|---|---| +| **Beam Irradiance** | The amount of solar radiation received per unit area by a surface held perpendicular (normal) to the rays that come in a straight line from the direction of the sun | W/m² | +| **Diffuse Irradiance** | The solar radiation that reaches the Earth's surface after being scattered out of the direct beam by molecules, aerosols, dust, and clouds in the atmosphere | W/m² | +| **Ambient Temperature** | Temperature of the surrounding air in the immediate environment | °C | +| **Wind Speed** | — | m/s | +| **Albedo** | A measure of the reflectivity of a surface | — | +| **Plane of Array Irradiance** | — | W/m² | +| **Cell Temperature** | The actual operating temperature of the individual solar cells inside the solar module | °C | +| **DC Array Output** | — | W | +| **AC Array Output** | — | W | + +## Remarks + +- **Cell Temperature can take negative values**, which is when it is most efficient. +- **Ambient Temperature can also take negative values.** +- The AC output **includes an overall inverter efficiency**. + +> [!NOTE] +> Because the AC figure already has inverter losses baked in, do not apply a second inverter +> efficiency when feeding this into the simulator. The +> [Simulator I/O Interface](../02-specifications/simulator-io-interface.md#14-pv) treats +> `P_PV_max` as an optional inverter/rated cap that clips output — using **AC Array Output** +> as `G(t)` is the consistent choice; using DC would double-count the conversion stage. + +## Fit for the forecasting spec + +The [PV forecasting inputs](../02-specifications/forecasting-requirements.md#11-inputs) call +for GHI, DNI, DHI, 2 m temperature, cloud fraction, wind speed, relative humidity, plus solar +zenith/azimuth and a clear-sky index. + +| Required feature | Present here? | +|---|---| +| DNI (beam irradiance) | ✅ | +| DHI (diffuse irradiance) | ✅ | +| GHI | ⚠️ Not listed directly; derivable from beam + diffuse and solar geometry | +| Ambient temperature | ✅ | +| Wind speed | ✅ | +| Cloud fraction | ❌ | +| Relative humidity | ❌ | +| Solar zenith / azimuth | ❌ — compute via `pvlib` as the spec advises | +| Clear-sky index | ❌ — needs a clear-sky GHI reference | +| Historical PV output (target) | ✅ DC and AC array output | + +For the missing meteorological variables the +[satellite dataset](satellite-pv-dataset-manual.md) is the complement — it has clear-sky +irradiance, humidity, dew point, precipitable water, and solar angles. Use this dataset for the +**PV target and core drivers**, and the satellite dataset for **extra meteorological features**. + +## Related + +- [Satellite PV Dataset Manual](satellite-pv-dataset-manual.md) — the detailed meteorological complement +- [Forecasting Requirements](../02-specifications/forecasting-requirements.md) — §1, PV generation forecasting +- [Dataset Inventory](../06-data/dataset-inventory.md) — every data file in the repo diff --git a/docs/03-energy-management/satellite-pv-dataset-manual.md b/docs/03-energy-management/satellite-pv-dataset-manual.md new file mode 100644 index 0000000..d46910d --- /dev/null +++ b/docs/03-energy-management/satellite-pv-dataset-manual.md @@ -0,0 +1,110 @@ +# Satellite PV / Meteorological Dataset Manual (2019) + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/Sattelite PV data/Data-set2/readme.docx` | +> | **Format** | Microsoft Word (.docx) | +> | **MD5** | `1843622a8681b1814ce6777a6d5360b7` | +> | **Describes** | `2019-1338340-one_axis.csv` — **167.9 MB**, the largest file in the repository | +> | **Owner** | Energy Management cluster | +> | **Status** | Current — but **not recommended** for PV rate extraction | +> | **Report generated** | 2026-07-25 | + +## Summary + +Very detailed satellite meteorological data from **Boston, Massachusetts**, for **2019**. +Hourly performance rates for solar panels could be derived from this data, but that would +require thorough analysis and effort. + +> *"This dataset is not recommended for extracting PV rates, but it is perfect for other more +> detailed meteorological variables that could be useful down the line."* + +For PV output, use the [PV hourly dataset](pv-hourly-dataset-manual.md) instead. + +The `one_axis` in the filename indicates a **single-axis tracking** array configuration. The +folder name `Sattelite` is a typo for *Satellite* preserved from the original. + +## What the dataset covers + +The dataset tracks the physical environment of the solar array across four distinct categories: + +- **Atmospheric / weather data** (pressure, humidity, dew point, precipitable water) — measure + the state of the air around the project, which directly affects how much sunlight can pass + through the atmosphere. +- **Solar geometry / angles** (zenith, azimuth, panel tilt) — track the geometry of the system: + where the sun is in the sky versus which way the panels face. +- **Irradiance data** (GHI, DNI, DHI, clear-sky variants) — the raw energy resource, measuring + the actual power of sunlight hitting the earth under both real-world and perfectly clear skies. +- **Technology performance** (Si, GaAs, CdTe, cell temperature) — the hardware's physical + response, showing how different solar panel chemistries perform and heat up under those + environmental conditions. + +## Column reference + +### Atmospheric and location + +| Column | Definition | Units | +|---|---|---| +| **Solar Zenith Angle** | The angle between the sun's position in the sky and the point directly overhead (the zenith). If the sun is straight up the angle is 0; if it is on the horizon, 90 | Degrees | +| **Surface Albedo** | The fraction of sunlight reflected by the ground (grass, snow, asphalt) back up into the atmosphere or onto the panels | — | +| **Precipitable Water** | The total amount of water vapour in a vertical column of the atmosphere if it were all to condense and fall as rain. Higher values mean more moisture in the air, which absorbs specific wavelengths of sunlight before they reach the panels | cm | +| **Solar Azimuth Angle** | The compass direction of the sun in the sky. Usually measured from due North (0°) moving clockwise — East 90°, South 180°, West 270° | Degrees | + +### Solar panel technologies + +| Technology | Description | +|---|---| +| **Si** (BPR, Wacker, Eurosil) | Different types or manufacturing variations of standard silicon solar cells | +| **GaAs** (Gallium Arsenide) | A highly advanced, very efficient, but very expensive solar cell material. Because of the high cost, GaAs panels are primarily used in space satellites and aerospace applications | +| **InGaP** (Indium Gallium Phosphide) | Another high-efficiency semiconductor material, often layered with GaAs in *multijunction* solar cells to capture different colours of the solar spectrum | +| **CdTe** (Cadmium Telluride) | A common thin-film solar panel technology. These panels are flexible and perform well in low-light conditions, often used in large industrial-scale solar farms | + +### Panel setup + +| Column | Definition | Units | +|---|---|---| +| **Panel Tilt** | The angle at which the panels are tilted up from flat ground. A tilt of 0 means completely flat; 90 means standing straight up like a wall | Degrees | +| **Panel Azimuth** | The compass direction the face of the panels points. In the Northern Hemisphere panels are typically faced South (azimuth 180°) to capture maximum daily sunlight | Degrees | + +### Clear-sky vs standard irradiance + +| Column group | Meaning | +|---|---| +| **Standard** (DHI / DNI / GHI) | The actual or predicted solar radiation hitting the ground, taking real-world weather, clouds, and smog into account | +| **Clearsky** (Clearsky DHI / DNI / GHI) | Theoretical calculation of how much solar radiation would hit the panels if the sky were 100% perfectly clear with zero clouds or pollution | + +## Why this dataset still matters + +Despite the "not recommended" verdict for PV rates, it is the **only** source in the repository +for several features the +[forecasting spec](../02-specifications/forecasting-requirements.md#11-inputs) asks for: + +| Forecasting feature | Only available here | +|---|---| +| Clear-sky index (`actual GHI / clear-sky GHI`) | ✅ — needs both GHI and Clearsky GHI, and only this dataset has clear-sky | +| Relative humidity | ✅ | +| Solar zenith and azimuth angles | ✅ (otherwise compute via `pvlib`) | +| Precipitable water, dew point, pressure | ✅ | + +The spec notes that adding solar-position features **reduced RMSE by 13.1%** in the reference +study, and that the clear-sky index *"normalises seasonal/diurnal trends; stabilises model +variance"*. Both come from here. + +## Size caveat + +At **167.9 MB**, `2019-1338340-one_axis.csv` is by a wide margin the largest file in the +repository — more than 12× the next largest. It dominates clone time and repository size for +everyone on the team. + +Because it covers a single year at hourly resolution for one location, most of that bulk is the +per-technology performance columns (Si/GaAs/InGaP/CdTe variants), which SHIFT does not use — the +project models a single PV array with a scalar efficiency `mu_PV`. Extracting the ~15 columns +the forecasting stack actually needs would shrink it by well over an order of magnitude. + +## Related + +- [PV Hourly Dataset Manual](pv-hourly-dataset-manual.md) — the recommended PV source +- [Forecasting Requirements](../02-specifications/forecasting-requirements.md) — §1, PV generation forecasting +- [Dataset Inventory](../06-data/dataset-inventory.md) — every data file in the repo, with sizes diff --git a/docs/03-energy-management/ucsd-equipment-manual.md b/docs/03-energy-management/ucsd-equipment-manual.md new file mode 100644 index 0000000..a44a74f --- /dev/null +++ b/docs/03-energy-management/ucsd-equipment-manual.md @@ -0,0 +1,175 @@ +# UCSD Microgrid Equipment Manual + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/UCSDEquipmentManual.docx` | +> | **Format** | Microsoft Word (.docx) | +> | **MD5** | `6d5a080fc2b3adfa49a8cc9469c458ac` | +> | **Owner** | Energy Management cluster | +> | **Status** | Current | +> | **Report generated** | 2026-07-25 | + +## What this document is + +Equipment specifications for the **UC San Diego** campus microgrid — the second SHIFT case +study alongside [BIDMC](bidmc-ucsd-energy-flow-and-balances.md). Covers the fuel cell, battery +system, combined heat and power (CHP) plant, and the planned electrolyser. + +Every parameter carries an **AI RL tag** marking how it is expected to enter the +reinforcement-learning formulation: + +| Tag | Meaning | +|---|---| +| **S** | State variable — the agent observes it | +| **A** | Action variable — the agent controls it | +| **R** | Reward component — it scores the agent | + +This tagging is what makes the document more than a datasheet: it is the Energy Management +cluster's proposal for how physical plant maps onto the +[RL specification](../02-specifications/rl-state-variables.md). + +## Fuel cell + +**Equipment:** DFC3000 molten carbonate fuel cell, manufactured by FuelCell Energy. + +| Parameter | Value | Units | AI RL | +|---|---|---|:---:| +| Rating | 2800 | kW | A | +| Standard output AC voltage | 13800 | V | S | +| Standard frequency | 60 | Hz | S | +| Natural gas consumption | 364 | Scfm (standard cubic feet/min) | A/S | +| Heat rate | 7260 | Btu/kWh | R | +| Initial operation LHV | 47 ± 2 | % | R | +| Water consumption average | 9 | gpm | S | +| Exhaust temperature | 371 ± 10 | °C | S | +| Exhaust flow | 16601 | kg/h | S | +| NOx emissions | 4.54 | g/MWh | R | +| SOx emissions | 0.05 | g/MWh | R | +| PM10 emissions | 0.009 | g/MWh | R | +| CO₂ emissions | 444.52 | kg/MWh | R | +| CO₂ emissions with waste heat recovery | 235 – 308 | kg/MWh | R | + +**Applications** + +- Converts wastewater-treatment methane to electricity +- Continues operation during outages, critical for the hospital +- Performs permanent load shifting: during off-peak hours when electricity is cheapest, the + fuel cell pumps power into the grid to charge the batteries + +> [!IMPORTANT] +> This is a **molten carbonate** fuel cell running on **natural gas** — fundamentally different +> from the **PEM hydrogen** fuel cell SHIFT models in +> [its Simulink work](../04-simulations/pem-electrolyser-and-fuel-cell-models.md) and specs at +> 100 kW in the [Simulator I/O Interface](../02-specifications/simulator-io-interface.md#12-fuel-cell). +> UCSD's unit is 28× larger and emits 444.52 kg CO₂/MWh because it burns methane. It is a +> reference for *microgrid operation at scale*, not a model of SHIFT's intended hydrogen chain. + +## Battery system + +UCSD uses a **2.5 MW / 5 MWh** battery from BYD; the exact model is not published. The BYD +standard 3U battery (U3A1-50E-A) is taken as a reference: + +| Parameter | Value | Units | AI RL | +|---|---|---|:---:| +| Nominal voltage | 51.2 | V | S | +| Energy efficiency | > 97 | % | S/R | +| Working voltage | 44.8 – 57.6 | V | S | +| Battery cycle life | 6000 | — | R | +| Operating temperature | 0 – 55 | °C | S | +| Storage temperature | −20 – 55 | °C | S | +| State of charge | 0 – 100 | % | S | +| Nominal energy | 2.56 | kWh per module | S | +| Total system energy | 5 | MWh | S | + +**Applications** + +- Increases grid reliability by reducing disturbances that could affect hospital operations +- Discharges on peak hours to reduce demand charges + +## Combined heat and power (CHP) + +The microgrid uses two gas turbines (Solar Turbines Titan 130) and one steam bottoming-cycle +turbine (Dresser-Rand). + +| Property | Value | +|---|---| +| Total CHP electrical capacity | **30 MW** (2 × 13.5 MW gas + 3 MW steam) | +| Campus electricity share | 72% of annual campus electricity needs | +| Heating supply | 95% of campus heating needs | +| Cooling needs | 95% of campus cooling needs | +| CHP total efficiency | 66% | +| CO₂ savings | 82,500 tonnes CO₂ per year | + +### Solar Turbines (Titan 130) + +| Parameter | Value | Units | AI RL | +|---|---|---|:---:| +| Power | 16,530 | kWe | S | +| Heat rate | 10,160 | kJ/kW·hr | S | +| Exhaust flow | 202,510 | kg/hr | S | +| Exhaust temperature | 490 | °C | S | +| Energy efficiency | 35.4 | % | R | +| Simple-cycle thermal efficiency | 34 | % | R | +| Primary fuel type | Natural gas | — | A | +| Secondary fuel type | Light distillate | — | A | + +> The datasheet figure of **16,530 kWe** per turbine does not match the summary line's +> "2 × 13.5 MW". The summary describes UCSD's installed/derated operating capacity; 16.5 MWe is +> the Titan 130's nameplate rating. Both numbers are in the source document. + +### Steam bottoming-cycle turbine + +Electric capacity **3 MW**. The steam source is the exhaust of the Solar Titan 130 gas turbine. +It produces domestic hot water for campus buildings. + +**Applications** + +- High-temperature exhaust gas boils water into high-pressure steam, which powers the steam + turbine and provides hot water and heating for the campus +- The captured thermal energy also drives three steam-turbine absorption chillers, producing + chilled water to fill the Thermal Energy Storage tank +- The turbines are also the primary electricity supply for the campus + +## Electrolyser (planned, not installed) + +UCSD does **not** currently operate an electrolyser. One is planned under the **SDG&E UCSD +Hydrogen Blending Pilot Project**: if approved, the electrolyser would be placed on campus to +produce hydrogen for the campus gas distribution network, with the aim of injecting **up to 20% +hydrogen into the natural gas pipeline**. + +The exact model and brand are not yet known, but it will be a **Proton Exchange Membrane (PEM)** +electrolyser. Representative PEM specifications: + +| Parameter | Value | Units | AI RL | +|---|---|---|:---:| +| Temperature | 50 – 80 | °C | S | +| Efficiency | 50 – 83 | % | R | +| Consumption | 4.3 – 5.1 | kWh/Nm³ | A | +| Pressure | 30 – 40 | Bar | S | +| Current density | 1 – 2 | A | S | +| Voltage range | 1.4 – 2.5 | V | S | + +> The current density unit is given as **A** in the source; current *density* is conventionally +> A/cm². Likely a units slip in the original. + +## Sources + +| Topic | Link | +|---|---| +| Fuel cell specifications | https://go.fuelcellenergy.com/hubfs/3000-fuel-cell-power-plant.pdf | +| Battery reference specifications | https://sunsol.pl/wp-content/uploads/2021/11/Akumulatory-BYD-ENERGY-STORAGE-PRODUCTS.pdf | +| CHP general information | https://chptap.ornl.gov/profile/356/UCSDMicrogrid-Project_Profile.pdf | +| CHP general information | https://microgrid-symposiums.org/microgrid-examples-and-demonstrations/uc-san-diego-microgrid/ | +| Solar turbines | https://www.solarturbines.com/en_US/products/power-generation-packages/titan-130.html | +| Solar turbines | https://www.industrialmarinepower.com/solar-titan-130/ | +| Electrolyser | https://www.frontiersin.org/journals/energy-research/articles/10.3389/fenrg.2024.1358333/full | +| Electrolyser | https://www.sempra.com/sdge-hydrogen-pilot-project-aims-advance-cas-clean-energy-goals | + +## Related + +- [BIDMC/UCSD Energy Flow and Balances](bidmc-ucsd-energy-flow-and-balances.md) — dispatch model for the other case study +- [RL State Variables](../02-specifications/rl-state-variables.md) — where the S-tagged parameters land +- [RL Reward Function](../02-specifications/rl-reward-function.md) — where the R-tagged parameters land +- [BIDMC Digital Twin Readiness Checklist](bidmc-digital-twin-readiness-checklist.md) — the readiness gate these specs feed diff --git a/docs/04-simulations/existing-est-model.md b/docs/04-simulations/existing-est-model.md new file mode 100644 index 0000000..af6fe34 --- /dev/null +++ b/docs/04-simulations/existing-est-model.md @@ -0,0 +1,240 @@ +# Existing EST Model (vendored) + +> **Markdown report of a vendored third-party subtree.** +> +> | | | +> |---|---| +> | **Location** | `Shift Matlab Drive/Shift Matlab Drive/Simulations/Exisiting EST Model/est-model-main/` | +> | **Upstream** | `https://gitlab.tue.nl/p.b.r.arnaud.de.calavon/est-model.git` (TU/e GitLab) | +> | **Licence** | **MIT** — © 2023 Energy Storage and Transport | +> | **Status** | **Vendored — do not reorganise.** SHIFT modifications live in the outer layer | +> | **Report generated** | 2026-07-25 | + +> [!IMPORTANT] +> This subtree is **not SHIFT's own work**. It is an externally authored, MIT-licensed model +> reused as a baseline. Its internal structure — including its duplicate data files and its +> ~100 MATLAB Project bookkeeping XMLs — is upstream's business, not a documentation defect. +> Nothing inside it has been moved, renamed, or retired. +> +> The folder name `Exisiting EST Model` contains a typo for *Existing*. It is left as-is: +> renaming it changes paths for no benefit. + +## What EST is + +**EST — Energy Storage and Transport.** From the upstream README: + +> This project contains the *Simulink model* for the **Energy Storage and Transport (EST)** +> project. This Simulink model contains a simplified version of a real-life energy storage and +> transport system, which describes the flow of energy in such a system. Supporting MATLAB +> files are provided which can be used to predefine parameters and to post-process data into +> figures. + +It is a TU/e teaching/reference model for generic energy storage — supply, storage, transport, +demand, with dissipation coefficients on each stage. SHIFT uses it as a **starting framework**, +not as a hydrogen model. + +## The double-nested structure + +``` +Exisiting EST Model/ +└── est-model-main/ ← SHIFT's working layer (modifications + stock GitLab README) + ├── README.md ← stock GitLab template boilerplate, NOT project docs + ├── ModelDevelopment.prj ← MATLAB Project file (essentially empty) + ├── Add_Mu_and_Gen_eff.m ← SHIFT modification + ├── Control_to_sell_and_buy.m ← SHIFT modification + ├── injection.m ← SHIFT modification + ├── Injection_run.m ← SHIFT modification + ├── run2.m ← SHIFT modification + ├── resources/project/ ← ~100 machine-generated MATLAB Project XMLs + └── EST-model-main/ ← pristine upstream copy + ├── README.md ← the REAL EST documentation + ├── LICENSE ← MIT + ├── EST.slx ← the model + ├── preprocessing.m / postprocessing.m + ├── scripts/ ← constants.m, loadDemandData.m, loadSupplyData.m + ├── data/ ← Team03_demand.csv, Team03_supply.csv + ├── images/ ← README screenshots + └── versions/ ← EST_R2021a/b, R2022a +``` + +**The inner `EST-model-main/` is the pristine upstream copy.** It holds the LICENSE, the real +README, the model, and the version ladder. **The outer `est-model-main/` is SHIFT's layer** — +five new `.m` files sitting beside a GitLab-template README that nobody edited. + +> The outer `README.md` is entirely GitLab's *"To make it easy for you to get started with +> GitLab, here's a list of recommended next steps"* boilerplate — checkbox lists about setting +> up CI/CD and inviting collaborators. It contains **zero project information**. Do not read it +> looking for EST documentation; read `EST-model-main/README.md`. + +## Upstream requirements and usage + +From the real README: + +- **Requires MATLAB R2022b or newer** with the Simulink toolbox. +- Install by cloning/downloading the **entire** repository and opening `EST.slx`. Downloading + only `EST.slx` does not work. +- Older, untested versions are in `versions/` — copy the file matching your release into the + main directory and restart both MATLAB and Simulink before running. +- `preprocessing.m` runs automatically before the model (`initFcn` callback) to define + parameters and read supply/demand data; `postprocessing.m` runs after to plot results. +- The MATLAB working directory must be the folder containing `EST.slx`. + +### Version ladder + +| File | MATLAB release | +|---|---| +| `EST.slx` | **R2022b+ — current** | +| `versions/EST_R2022a.slx` | R2022a | +| `versions/EST_R2021b.slx` | R2021b | +| `versions/EST_R2021a.slx` | R2021a | + +The `versions/` files are upstream's deliberate backwards-compatibility exports, not stale +drafts. They stay. + +### Default parameters + +From `preprocessing.m`: + +```matlab +timeUnit = 's'; +supplyFile = "SolarExample_supply.csv"; supplyUnit = "kW"; +demandFile = "SolarExample_demand.csv"; demandUnit = "kW"; + +deltat = 5*unit("min"); +stopt = min([Supply.Timeinfo.End, Demand.Timeinfo.End]); + +aSupplyTransport = 0.01; % Dissipation coefficient +``` + +> Note the mismatch: `preprocessing.m` references `SolarExample_supply.csv` / +> `SolarExample_demand.csv`, but the files actually present in `data/` are +> **`Team03_demand.csv` and `Team03_supply.csv`**. Running the model as shipped will fail on +> the missing example files unless `preprocessing.m` is edited or the data files renamed. This +> is an upstream/vendoring seam, not a SHIFT bug. + +## SHIFT's modifications — gravity storage, not hydrogen + +The five `.m` files in the outer layer model a **gravity storage** system: electric motors +lifting mass blocks up towers to store energy, releasing them to generate. This is a +storage technology SHIFT evaluated alongside hydrogen; it does not appear in the current +[system architecture](../02-specifications/simulator-io-interface.md). + +### `injection.m` — the core function + +```matlab +function [PfromInjection, DInjection, nUse, aInjection] = injection( ... + Psupply, massBlock, v, rho, Cd, areaBlock, n, mu, eta_motor) + g = 9.81; % Gravity [m/s²] + + P_lift = massBlock * g * v; % Mechanical power to lift [W] + + P_drag = 0.5 * rho * Cd * areaBlock * abs(v)^3; % Air drag [W] + P_fric = mu * massBlock * g * abs(v); % Friction [W] + Ploss = P_drag + P_fric; + + P_required = (P_lift + Ploss) / eta_motor; % Electrical input [W] + + aInjection = Ploss / P_required; % Dynamic loss coefficient + DInjection = aInjection * P_required; % Power lost [W] + PfromInjection = P_required - DInjection; % Net stored [W] + + if Psupply == 0 + nUse = 0; + elseif Psupply <= n * P_required + nUse = ceil(Psupply / P_required); % Towers needed + else + nUse = n; % All towers active + end +end +``` + +The interesting idea here is `aInjection` — replacing EST's **fixed** dissipation coefficient +with one **computed from physics** at the current operating point. That is exactly the move the +hydrogen models need too, and it is the reusable insight from this branch of work. + +### Parameter sets + +| Parameter | `run2.m` | `Injection_run.m` | Unit | +|---|---:|---:|---| +| `massBlock` | 10,000 | 10,000 | kg | +| `v` | 2 | 2 | m/s | +| `rho` | **1.225** | **1.293** | kg/m³ | +| `Cd` | 1.05 | 1.05 | — | +| `areaBlock` | 100 | 100 | m² | +| `n` | 10 | 10 | towers | +| `mu` | 0.05 | 0.05 | — | +| `eta_motor` | 0.85 | 0.85 | — | +| `Psupply` | 1e6 (1 MW) | 1e6 | W | + +`run2.m` is annotated *"Constants from poster"*. The two scripts differ only in air density — +1.225 kg/m³ (ISA sea level, 15 °C) versus 1.293 kg/m³ (0 °C). `Injection_run.m` also notes +`v = 2` is *"slower than extraction to reduce losses"*. + +### The other three files + +| File | Content | State | +|---|---|---| +| `Add_Mu_and_Gen_eff.m` | Sets `mu = 0.1`, `eff_gen = 0.9`, then calls `dissipationBeta(...)` | **Broken** — passes `eta_gen` (undefined; the variable set is `eff_gen`) and calls `dissipationBeta`, which is not defined anywhere in the repository | +| `Injection_run.m` | Parameter block, then calls `injectionBeta(...)` | **Broken** — `injectionBeta` is not defined anywhere in the repository; the defined function is `injection` | +| `Control_to_sell_and_buy.m` | 211 bytes | Stub | + +Three of the five SHIFT files call functions (`dissipationBeta`, `injectionBeta`) that do not +exist in this repository. Only `run2.m` → `injection.m` is a runnable pair. The missing +`*Beta` functions were presumably a later iteration that never got committed here. + +## Duplicate data files + +`Team03_demand.csv` and `Team03_supply.csv` each exist **twice**, byte-identical: + +| Path | MD5 | +|---|---| +| `EST-model-main/Team03_demand.csv` | `26553f17` | +| `EST-model-main/data/Team03_demand.csv` | `26553f17` | +| `EST-model-main/Team03_supply.csv` | `7ce0330e` | +| `EST-model-main/data/Team03_supply.csv` | `7ce0330e` | + +0.65 MB each, so ~1.3 MB duplicated. `preprocessing.m` reads from the `data/` directory, so the +root-level copies are the redundant ones — but they are **inside the vendored subtree** and are +left untouched. Removing them would create a divergence from upstream for a 1.3 MB saving. + +## `resources/project/` — machine-generated + +Roughly 100 XML files with opaque hash names +(`8d6963sHFjo3KDafHny-kBqH4Ew/HzZAGbjCGV27z4vxUS7B-4SgGnAd.xml` and similar), organised into +hash-named directories with paired `…d.xml` / `…p.xml` files. + +This is **MATLAB Project bookkeeping** — the metadata store behind `ModelDevelopment.prj`, +tracking file labels, dependencies, and project structure. It is machine-generated, unreadable, +and carries no documentation value. It is **not** documentation and is excluded from all +documentation indexes. + +`ModelDevelopment.prj` itself is essentially empty: + +```xml + + +``` + +## Disposition + +Everything in this subtree is **kept in place**: + +| Item | Why kept | +|---|---| +| Inner `EST-model-main/` | Pristine upstream, MIT-licensed — keeping it intact preserves attribution and the ability to diff against upstream | +| `versions/EST_R202*.slx` | Deliberate upstream compatibility exports, not stale drafts | +| Duplicate `Team03_*.csv` | Inside the vendored tree; divergence not worth 1.3 MB | +| `resources/project/**` | Machine-generated, but deleting it breaks the MATLAB Project | +| Outer stock `README.md` | Boilerplate, but it is upstream's file — flagged here instead of deleted | +| SHIFT's five `.m` files | Contain the reusable physics-based dissipation-coefficient idea | + +The one thing worth adding is a short `NOTE.md` in `Exisiting EST Model/` recording the upstream +URL, the MIT licence, and the fact that three of the five SHIFT scripts reference undefined +functions — so the next person does not spend an afternoon discovering it. + +## Related + +- [Simulink Model Inventory](simulink-model-inventory.md) — SHIFT's own models +- [PV + Battery Simulink Model](pv-battery-simulink.md) +- [Work Packages](../01-project/work-packages.md) — WP3, simulation environment diff --git a/docs/04-simulations/generation-profiles-workbook.md b/docs/04-simulations/generation-profiles-workbook.md new file mode 100644 index 0000000..58ffe56 --- /dev/null +++ b/docs/04-simulations/generation-profiles-workbook.md @@ -0,0 +1,267 @@ +# Generation Profiles Workbook + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/.../Simulations/Current Framework/Profiles SHIFT(Generators Factors + Battery).xlsx` | +> | **Duplicate** | `Shift Matlab Drive/.../Simulations/PV+Battery Simulink/Profiles SHIFT(Generators Factors + Battery).xlsx` — **byte-identical**, MD5 `cb529138` | +> | **Format** | Excel workbook (.xlsx), 2 sheets | +> | **Owner** | Simulations cluster | +> | **Status** | Current | +> | **Report generated** | 2026-07-25 | + +## What this workbook is + +Two unrelated jobs sharing one file: + +1. **Sheet `Profiles SHIFT(Generators Facto...`** — a 24-hour campus-scale generation and + battery dispatch profile, plus the **results analysis from a PowerWorld run**. +2. **Sheet `Fake Simulink Data`** — a small placeholder dataset and the constant block that + [`PVBatteryRead.mlx`](pv-battery-simulink.md) parses into the MATLAB workspace. + +The two sheets operate at **completely different scales** — sheet 1 in MW/MWh, sheet 2 in the +W/Wh range of a single building. See [Scale mismatch](#scale-mismatch) below. + +--- + +## Sheet 1 — Generation profiles and PowerWorld results + +### Hourly capacity factors and generation + +Reference day: **2025-09-30**. + +| Hour | Solar CF | Wind CF | Max PV (MW) | Max Wind (MW) | Actual PV (MW) | Actual Wind (MW) | +|---|---|---|---|---|---|---| +| 00:00 | 0.000 | 0.448 | 151.095 | 2.0 | 0.000 | 0.896 | +| 01:00 | 0.000 | 0.462 | 151.095 | 2.0 | 0.000 | 0.924 | +| 02:00 | 0.000 | 0.465 | 151.095 | 2.0 | 0.000 | 0.930 | +| 03:00 | 0.000 | 0.471 | 151.095 | 2.0 | 0.000 | 0.942 | +| 04:00 | 0.006 | 0.468 | 151.095 | 2.0 | 0.907 | 0.936 | +| 05:00 | 0.042 | 0.497 | 151.095 | 2.0 | 6.346 | 0.994 | +| 06:00 | 0.113 | 0.560 | 151.095 | 2.0 | 17.074 | 1.120 | +| 07:00 | 0.184 | 0.608 | 151.095 | 2.0 | 27.802 | 1.216 | +| 08:00 | 0.234 | 0.640 | 151.095 | 2.0 | 35.356 | 1.280 | +| 09:00 | 0.306 | 0.622 | 151.095 | 2.0 | 46.235 | 1.244 | +| 10:00 | 0.416 | 0.572 | 151.095 | 2.0 | 62.856 | 1.144 | +| 11:00 | 0.514 | 0.534 | 151.095 | 2.0 | 77.663 | 1.068 | +| 12:00 | **0.532** | 0.492 | 151.095 | 2.0 | **80.383** | 0.984 | +| 13:00 | 0.523 | 0.448 | 151.095 | 2.0 | 79.023 | 0.896 | +| 14:00 | 0.442 | 0.387 | 151.095 | 2.0 | 66.784 | 0.774 | +| 15:00 | 0.334 | 0.318 | 151.095 | 2.0 | 50.466 | 0.636 | +| 16:00 | 0.213 | 0.224 | 151.095 | 2.0 | 32.183 | 0.448 | +| 17:00 | 0.093 | 0.161 | 151.095 | 2.0 | 14.052 | 0.322 | +| 18:00 | 0.019 | 0.123 | 151.095 | 2.0 | 2.871 | 0.246 | +| 19:00–23:00 | 0.000 | 0.110 → 0.143 | 151.095 | 2.0 | 0.000 | 0.220 → 0.286 | + +**Summary figures on the sheet:** + +| Quantity | Value | +|---|---| +| Sum (total generation factor) | 3.971 | +| Energy to hospital + battery per day | **600.0 MWh** | +| Max PV power | **151.095442 MW** | + +### Battery dispatch schedule + +Marked *"Adjustable (not yet fully adjusted)"*. + +| Parameter | Value | +|---|---| +| Initial state of charge | 0.63 | +| Size storage | **140.0 MWh** | +| Charge/discharge rate | 0.1 (10%) | +| Power | **17.5 MW** (−ve charging, +ve discharging) | +| Number of charge/discharge cycles | 8.0 | +| Desired power to/from battery per day | 140.0 MWh | +| Effective power per day | 140.0 MWh — *"has to be the same as desired"* ✅ | +| Balance check total | **0.0** — *"has to be zero to ensure charge/discharge balance"* ✅ | +| Cyclical check (hour 24 vs hour 0) | −87.5 = −87.5 ✅ | + +The schedule discharges overnight (00:00–04:00), idles 05:00–07:00, charges through the solar +peak (08:00–15:00) down to the −140 MWh floor, holds 16:00–19:00, then discharges again +20:00–23:00. Max capacity −140.0, min capacity 0.0 throughout. + +### PowerWorld results analysis + +Three findings recorded on the sheet, quoted verbatim: + +> **No major voltage problems.** + +> **Generators work as intended.** + +> **Grid has reasonable values and doesn't pull energy when battery is active, but does pull +> more energy when battery is also pulling. Consider shorter but stronger charge cycles in the +> middle of the day and discharge cycles at night.** + +> **The line/transformer is overloaded at multiple times.** This can be partially helped by the +> battery fix mentioned, however the battery is too small to fix all of this. It's more likely +> the line data like the Rating and distance are unrealistic. + +#### Line loading — `1 TO 2 CKT 1`, % of MVA limit + +| Hour | % of limit | | Hour | % of limit | +|---|---:|---|---|---:| +| 00:00 | 64.95 | | 12:00 | 28.95 | +| 01:00 | 64.95 | | 13:00 | 27.35 | +| 02:00 | 78.17 | | 14:00 | 78.27 | +| 03:00 | 96.83 | | 15:00 | **233.17** | +| 04:00 | **118.70** | | 16:00 | **195.77** | +| 05:00 | **316.68** | | 17:00 | **366.49** | +| 06:00 | **263.11** | | 18:00 | **428.26** ← worst | +| 07:00 | **197.75** | | 19:00 | **390.76** | +| 08:00 | **357.06** | | 20:00 | **160.07** | +| 09:00 | **266.88** | | 21:00 | **128.24** | +| 10:00 | **119.18** | | 22:00 | 96.82 | +| 11:00 | 1.75 | | 23:00 | **266.22** | + +**19 of 24 hours exceed 100%**, peaking at **428%** at 18:00. Only hours 00–03, 11–14 and 22 +are within limit. The sheet's own reading — that the line rating/distance data is unrealistic +rather than the dispatch being wrong — is well supported: a battery is not going to absorb a +4× overload, and the minimum at 11:00 (1.75%) sits right where PV output is highest, which is +the opposite of what a genuine thermal-limit problem would look like. + +#### Generator dispatch under the analysed case + +| Hour | Gen 1 `#Po` (MW) | Gen 2 `#Ba` (MW) | Gen 2 `#PV` (MW) | +|---|---:|---:|---:| +| 00:00 | 6.50 | 17.50 | 0.00 | +| 04:00 | 11.87 | 17.50 | 0.91 | +| 05:00 | 31.65 | 0.00 | 6.35 | +| 08:00 | 35.68 | −17.50 | 35.36 | +| 11:00 | **−0.18** | −17.50 | 77.66 | +| 12:00 | **−2.88** | −17.50 | 80.38 | +| 13:00 | **−2.72** | −17.50 | 79.02 | +| 18:00 | 42.79 | 0.00 | 2.87 | +| 23:00 | 26.61 | 0.00 | 0.00 | + +Negative `#Po` values at 11:00–13:00 indicate the conventional generator is being back-driven +during peak solar — the model is exporting rather than curtailing. + +--- + +## Sheet 2 — `Fake Simulink Data` + +The sheet name is literal: this is placeholder data used to wire up the +[PV+Battery Simulink pipeline](pv-battery-simulink.md), not a real profile. + +### Time series + +Header format is `Name - var (unit)`, which is exactly the pattern `PVBatteryRead.mlx` parses +with the regex `-\s*(.*?)\s*\(`. + +| Time — `t` (h) | Irradiance — `E_e` (W/m²) | Battery Current — `I_B` (A) | +|---|---:|---:| +| 00:00–06:00 | 0 | 0 | +| 07:00 | 2 | 0 | +| 08:00 | 134 | 500 | +| 09:00 | 291 | 600 | +| 10:00 | 430 | 750 | +| 11:00 | 534 | 1000 | +| 12:00 | **570** | 1000 | +| 13:00 | 375 | 750 | +| 14:00 | 157 | 500 | +| 15:00 | 134 | 500 | +| 16:00 | 118 | 500 | +| 17:00 | 114 | 500 | +| 18:00 | 41 | 0 | +| 19:00–23:00 | 0 | 0 | + +**Sources cited on the sheet:** + +- Irradiance — `https://en.tutiempo.net/solar-radiation/eindhoven.html` +- Battery current — a Google search for *"what is the current in giant batteries"* + +> The irradiance profile is for **Eindhoven** (TU/e's location), while the PV and load datasets +> elsewhere in the project are for **Boston** (BIDMC). Placeholder data, so this is not an +> error — but it is a reason not to read anything physical into results from this sheet. + +### Constants block + +| Constant | Symbol | Value | Unit as labelled | +|---|---|---:|---| +| PV Area | `A_PV` | 3060 | m² | +| Panel Efficiency | `mu_PV` | 0.2 | % | +| PV Voltage | `V_PV` | 24 | V | +| Electrolyzer Power Consumption | `P_ele` | 1,500,000 | W | +| Initial Battery Energy | `E_t0` | 0 | Wh | +| Battery Rated Energy | `E_rated` | 170,000 | W | +| Battery Rated Charge Capacity | `Q_rated` | 100,000 | W | +| Maximum Charge | `Charge_max` | 1 | % | +| Maximum Discharge | `Disharge_max` | 2 | % | +| SoC limit | `SoC_max` | 1 | % | +| Initial SoC | `SoC_t0` | 0 | % | +| Initial battery power | `P_B_int` | 0 | — | +| Initial battery current | `I_B_int` | 0 | — | + +These are **identical** to the values hard-coded in +[`Constants.mlx`](pv-battery-simulink.md#3-constantsmlx) — consistent with the note in +`PV+Battery.docx` that *"the constants reading would not function for some reason"*, so the +values were transcribed into a script instead. + +Two in-sheet notes on unit handling: + +- `Charge_max` — *"If NOT in %, divide by `E_rated`"* +- `Disharge_max` — *"If NOT in %, divide by `Q_rated`"* + +`E_rated` and `Q_rated` are annotated *"From Paper 1"*. + +### Provenance of the constants + +The source links attached to the constants are: + +| Constant | Cited source | +|---|---| +| `A_PV` | Google search — *"solar panel area m2"* | +| `mu_PV` | Google search — *"solar panel efficiency"* | +| `V_PV` | Google search — *"solar panel voltage hospital"* | +| `P_ele` | Google search — *"hospital electrolyzer power consumption"* | +| `E_rated`, `Q_rated` | Google search — *"hospital with PV and hydrogen storage rated energy and capacity"* | +| Context | `https://www.equans.com/news/first_all_electric_hospital_netherlands` | + +> [!WARNING] +> Every parameter except those "From Paper 1" traces to a generic web search, not a datasheet +> or the project specification. `A_PV = 3060 m²` in particular contradicts the +> [project spec of 2,300 m²](../02-specifications/simulator-io-interface.md#14-pv). These are +> placeholder values that need replacing with the specified figures before any result is +> quoted. + +--- + +## Scale mismatch + +The two sheets are not describing the same system: + +| Quantity | Sheet 1 (PowerWorld) | Sheet 2 / `Constants.mlx` | Project spec | +|---|---|---|---| +| PV capacity | **151 MW** | 3060 m² × 20% ≈ **0.6 MW** peak | 2,300 m² ≈ **0.46 MW** peak | +| Storage | **140 MWh** | `E_rated` 170 kWh | — | +| Daily energy | **600 MWh/day** | — | BIDMC proxy ≈ **22 MWh/day** ([ComStock](../03-energy-management/bidmc-parquet-load-data-manual.md)) | + +Sheet 1 is at the scale of a **campus or distribution network** — consistent with a PowerWorld +transmission study and with the UCSD campus microgrid (30 MW CHP). Sheet 2 is at the scale of a +**single hospital building**. Both are legitimate, but nothing in the workbook says which +scenario is which, and the ~300× gap is large enough to cause real confusion if the sheets are +read as one model. + +## Duplicate copies + +The same workbook exists in two folders with identical MD5: + +| Path | Disposition | +|---|---| +| `Simulations/Current Framework/Profiles SHIFT(...).xlsx` | **Keep** — the current framework location | +| `Simulations/PV+Battery Simulink/Profiles SHIFT(...).xlsx` | Kept in place — `PVBatteryRead.mlx` opens it by bare filename, so it must sit beside the script | + +Note that `PVBatteryRead.mlx` reads `filename = 'Profiles SHIFT(Generators Factors + Battery).xlsx'` +with **no path**, meaning MATLAB resolves it from the current working directory. Removing either +copy risks breaking the script depending on where it is run from — so both are retained. + +A third, related export exists as CSV: +`Simulations/PowerWorld/New Powerworld/Profiles SHIFT(Generators Factors + Battery).csv`. + +## Related + +- [PV + Battery Simulink Model](pv-battery-simulink.md) — the consumer of sheet 2 +- [PowerWorld Microgrid Model](powerworld-microgrid.md) — the source of sheet 1's results +- [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) — the parameter spec these constants should match diff --git a/docs/04-simulations/matlab-live-scripts.md b/docs/04-simulations/matlab-live-scripts.md new file mode 100644 index 0000000..a774c31 --- /dev/null +++ b/docs/04-simulations/matlab-live-scripts.md @@ -0,0 +1,198 @@ +# MATLAB Live Scripts (`.mlx`) Inventory + +> **Markdown report of non-markdown source files.** +> +> | | | +> |---|---| +> | **Sources** | All five `.mlx` MATLAB Live Scripts in `Shift Matlab Drive/` | +> | **Format** | MATLAB Live Script — an OPC (zip) package; `matlab/document.xml` holds the code | +> | **Status** | Current inventory | +> | **Report generated** | 2026-07-25 | + +MATLAB Live Scripts are binary-ish packages, so their contents are invisible to `git diff` and +to anyone browsing the repository on the web. This report transcribes all five. + +## Summary + +| File | Cluster folder | Content | Verdict | +|---|---|---|---| +| `Simulations/PV+Battery Simulink/Constants.mlx` | Simulations | 13 parameter assignments | **Substantive** | +| `Simulations/PV+Battery Simulink/PVBatteryRead.mlx` | Simulations | ~110-line Excel→Simulink importer | **Substantive** | +| `RL_ML/Empty.mlx` | AI & Control Systems | `'Test'` | **Placeholder** | +| `Energy_Managment/Emptier.mlx` | Energy Management | `'Exam'` | **Placeholder** | +| `Business_Economics/Emptiest.mlx` | Business & Economics | `'Attempt'` | **Placeholder** | + +## The three placeholder files + +`Empty.mlx`, `Emptier.mlx` and `Emptiest.mlx` each contain **a single string literal** and +nothing else: + +| File | Entire contents | +|---|---| +| `RL_ML/Empty.mlx` | `'Test'` | +| `Energy_Managment/Emptier.mlx` | `'Exam'` | +| `Business_Economics/Emptiest.mlx` | `'Attempt'` | + +The escalating names are deliberate. These are **directory placeholders** — MATLAB Drive, like +many sync services, will not preserve an empty folder, so a token file was added to each of the +three non-Simulations cluster folders to keep the structure alive. + +The consequence is worth stating plainly: **of the four SHIFT clusters, only Simulations has +any MATLAB code in this repository at all.** `RL_ML/`, `Energy_Managment/` and +`Business_Economics/` contain nothing else — Energy Management's actual output is the document +and dataset set covered in [03-energy-management](../03-energy-management/), and AI & Control +Systems' output is the specifications in [02-specifications](../02-specifications/) plus +[`controller-claude.m`](rule-based-controller-implementation.md), which sits at the +`Shift Matlab Drive/` root rather than in `RL_ML/`. + +These three files are retained in place — they are structural, not content, and deleting them +would drop the folders. + +## `Constants.mlx` + +Parameter definitions for the PV + Battery Simulink models. Must be run **before** the models. + +```matlab +A_PV = 3060; % PV Area (m2) +mu_PV = 0.2; % Panel Efficiency (%) +V_PV = 24; % PV Voltage (V) + +P_ele = 1500000; % Electrolyzer Power Consumption (W) +E_t0 = 0; % Initial Battery Energy (Wh) +E_rated = 170000; % Battery Rated Energy (W) +Q_rated = 100000; % Battery Rated Charge Capacity (W) +Charge_max = 1; % Maximum Charge (%) +Disharge_max = 2; % Maximum Discharge (%) +SoC_max = 1; % SoC limit (%) +SoC_t0 = 0; % Initial SoC (%) + +P_B_int = 0; % Initial Battery power (W) +I_B_int = 0; % Initial Battery current (A) +``` + +These duplicate the constants block in the +[Generation Profiles Workbook](generation-profiles-workbook.md#constants-block), which is +deliberate — `PVBatteryRead.mlx` was meant to read them from the spreadsheet but that path +does not work, so they were transcribed here. See +[PV + Battery Simulink](pv-battery-simulink.md#3-constantsmlx) for the parameter cross-check +against the project specification (three unit-comment errors and one value that contradicts the +spec). + +## `PVBatteryRead.mlx` + +Reads the `Fake Simulink Data` sheet out of +`Profiles SHIFT(Generators Factors + Battery).xlsx` and pushes Simulink-ready signals into the +base workspace. + +```matlab +close all; clear all +%% File settings +filename = 'Profiles SHIFT(Generators Factors + Battery).xlsx'; +sheet = 'Fake Simulink Data'; + +%% Read Excel while preserving headers +T = readtable(filename, ... + 'Sheet', sheet, ... + 'HeaderLines', 1, ... + 'VariableNamingRule', 'preserve'); + +%% Remove completely empty columns +T = T(:, ~all(ismissing(T))); + +headers = T.Properties.VariableNames; +``` + +**Step 1 — convert data types.** For each column: cell-text numbers are converted to double, +first replacing `,` with `.` so European decimal commas parse; `duration` columns are converted +to hours. + +```matlab +for i = 1:length(headers) + col = T.(headers{i}); + if iscell(col) + col = strrep(col, ',', '.'); + col = cellfun(@str2double, col); + end + if isduration(col) + col = hours(col); + end + T.(headers{i}) = col; +end +``` + +**Step 2 — detect last valid signal row.** Numeric columns are stacked into `signalMatrix` +(skipping any column whose header contains `Date`); rows are valid where any signal is non-NaN +*and* the date is after 2000-01-01. The table is truncated at the last valid row. + +**Step 3 — extract variables and constants.** Variable names are parsed out of headers of the +form `Name - var (unit)`: + +```matlab +token = regexp(header, '-\s*(.*?)\s*\(', 'tokens'); +varName = matlab.lang.makeValidName(strtrim(token{1}{1})); +``` + +Time is special-cased and normalised to **seconds**: + +```matlab +if strcmpi(varName, 't') + if isduration(values) + t = seconds(values); + elseif isnumeric(values) + if max(values) <= 1 + t = values * 24 * 3600; % fraction of day -> seconds + else + t = values * 3600; % hours -> seconds + end + end + assignin('base', 't', t); +end +``` + +Every other column is classified by cardinality — a column with exactly one unique non-NaN +value becomes a scalar **constant**, otherwise a **time series**: + +```matlab +u = unique(values(~isnan(values))); +if numel(u) == 1 + assignin('base', varName, double(u)); +else + assignin('base', varName, double(values)); +end +``` + +**Step 4 — create Simulink-ready signals.** Every numeric workspace variable whose length +matches `t` gets a companion `_simulink = [t, values]` — the two-column `[time, data]` +matrix a Simulink *From Workspace* block expects. + +```matlab +val = evalin('base', v); +if isnumeric(val) && numel(val) == n + simData = [t val(:)]; + assignin('base', [v '_simulink'], simData); +end +``` + +### Notes on this script + +- **The time-unit conversion here is the prime suspect for the known model bug.** Step 3 emits + `t` in **seconds**; if the Simulink models' stop time is configured in hours, the simulated + window covers only the first few samples and every signal looks constant. That matches the + symptom recorded in [PV + Battery Simulink](pv-battery-simulink.md#known-issue--model-is-not-time-dependent) + exactly. +- **`clear all` at the top** wipes the workspace — including anything `Constants.mlx` set. The + documented run order (`PVBatteryRead` then `Constants`, per `PV+Battery.docx`: *"Remember to + run both this and the previous code"*) is therefore load-bearing, and running them in the + other order silently loses the constants. +- **The filename is unqualified**, so MATLAB resolves it against the current working directory. + The script only works when run from a folder containing the workbook — which is why the + workbook is duplicated into `PV+Battery Simulink/`. +- **The constants-detection heuristic is fragile**: any genuine time series that happens to hold + a single repeated value (e.g. an all-zero night-time signal over a short window) would be + silently collapsed to a scalar. + +## Related + +- [PV + Battery Simulink Model](pv-battery-simulink.md) — what these scripts drive +- [Generation Profiles Workbook](generation-profiles-workbook.md) — the spreadsheet they read +- [Simulink Model Inventory](simulink-model-inventory.md) — the `.slx` models diff --git a/docs/04-simulations/pem-electrolyser-and-fuel-cell-models.md b/docs/04-simulations/pem-electrolyser-and-fuel-cell-models.md new file mode 100644 index 0000000..0e60194 --- /dev/null +++ b/docs/04-simulations/pem-electrolyser-and-fuel-cell-models.md @@ -0,0 +1,281 @@ +# PEM Electrolyser and Fuel Cell Models (MathWorks Simscape examples) + +> **Markdown report of non-markdown source files.** +> +> | | | +> |---|---| +> | **Sources** | `Simulations/Ready Made PEM Electrolyzer/` · `Simulations/Ready Made PEM fuel cell/` · duplicated in `Simulations/Big Ugly Folder/` | +> | **Origin** | **MathWorks Simscape shipped examples**, obtained via `openExample(...)` | +> | **Licence** | © 2020–2024 The MathWorks, Inc. — see [Provenance](#provenance-and-licensing) | +> | **Status** | Current — but **still at vendor default parameters** | +> | **Report generated** | 2026-07-25 | + +## Provenance and licensing + +> [!WARNING] +> **This is unmodified third-party code.** Every `.m` and `.ssc` file in both folders carries a +> MathWorks copyright line; not one carries SHIFT attribution. Unlike the +> [EST model](existing-est-model.md) — which ships its MIT LICENSE and upstream URL — this +> vendored code is **marked nowhere in the repository**. + +``` +Ready Made PEM Electrolyzer/Electrolyzer.ssc:9 % Copyright 2021-2024 The MathWorks, Inc. +Ready Made PEM Electrolyzer/PEMElectrolysisSystemExample.m:57 % Copyright 2021 The MathWorks, Inc. +Ready Made PEM Electrolyzer/PEMElectrolysisSystemParameters.m:6 % Copyright 2021 The MathWorks, Inc. +Ready Made PEM fuel cell/FuelCell.ssc:10 % Copyright 2020-2024 The MathWorks, Inc. +Ready Made PEM fuel cell/PEMFuelCellSystemExample.m:64 % Copyright 2020-2021 The MathWorks, Inc. +Ready Made PEM fuel cell/PEMFuelCellSystemParameters.m:6 % Copyright 2020 The MathWorks, Inc. +…and 8 more Plot*.m files, all MathWorks +``` + +How they were obtained is recorded only as a comment in `Constants.m`: + +```matlab +%openExample('simscape/PEMElectrolysisSystemExample') +%openExample('simscape/PEMFuelCellSystemExample') +``` + +**Recommended:** add a `PROVENANCE.md` to each folder stating that the contents are unmodified +MathWorks Simscape examples retrieved via `openExample`, and that redistribution is governed by +the MathWorks licence terms. + +## The unfinished sizing work + +`Constants.m` records the requirement and the plan, verbatim: + +> `%Ready made electrolyser -` +> `%Good news: it has a solar profile.` +> `%Bad news: random constants - we want it at 128m3 hydrogen production a day` +> `%I have attempted to find volume via the volumetric flow rate, however this` +> `%uses "standard conditions". THIS BRINGS IT TO 12.8m3, JUST ADJUST (power?)` +> `%SO ITS 10 TIMES BIGGER AND WE ARE GOOD!` +> +> `%openExample('simscape/PEMFuelCellSystemExample')` +> `%This one is also PEM so it should work?` +> +> `%To do: Check if PEM is ok, change parameters for electrolyzer so that` +> `%production is exactely 10times bigger, adjust fuel cell, create grid,` +> `%ensure its power output is appropriate` + +> [!IMPORTANT] +> **That TODO has not been carried out.** The parameter files are still at MathWorks demo +> defaults: +> +> - The electrolyser's 24-hour `solar_profile_power` still peaks at exactly **100 kW** — the +> vendor's round demo number, not a SHIFT-derived profile. +> - The fuel cell still loads **`PEMFuelCellSystemDriveCycle.mat`** — an *automotive drive +> cycle*, wholly inappropriate for a hospital microgrid. +> +> **No SHIFT-specific hydrogen system parameterisation exists anywhere in this tree**, despite +> `Constants.m` recording the requirement since the earliest revision. This is the single +> largest gap between the [simulator specification](../02-specifications/simulator-io-interface.md) +> and the models that are supposed to implement it. + +Note also that the "just multiply by 10" approach to sizing is recorded as an unverified +assumption (*"This one is also PEM so it should work?"*), and that scaling a Simscape +electrolyser's hydrogen output by 10× is not achieved by scaling power alone — cell count, +active area, and current density all enter. + +## Electrolyser parameters + +`PEMElectrolysisSystemParameters.m` — 71 lines, 11,972 B, MD5 `7871b9ab`. Byte-identical in +`Ready Made PEM Electrolyzer/` and `Big Ugly Folder/`. + +### Environment + +| Parameter | Value | Unit | +|---|---:|---| +| `env_p` | 0.101325 | MPa | +| `env_T` | 20 | °C | + +### Solar profile (24 h) + +| Parameter | Value | Unit | +|---|---|---| +| `solar_profile_time` | `(0:23)' * 3600` | s | +| `solar_profile_power` | `[0 0 0 0 0 0 0.572 13.1 44.9 74.5 96.4 100 97.5 89.5 65.8 34.0 7.61 0 0 0 0 0 0 0]'` | kW | + +### Stack + +The comment header in the source says *"Fuel cell stack"* — a MathWorks copy-paste artefact in +the *electrolysis* file. + +| Parameter | Value | Unit | Description | +|---|---:|---|---| +| `stack_num_cells` | 50 | – | Number of cells | +| `stack_area` | 280 | cm² | Cell area | +| `stack_t_membrane` | 125 | µm | Membrane thickness | +| `stack_t_gdl_A` | 25 | µm | Anode gas diffusion layer thickness | +| `stack_t_gdl_C` | 250 | µm | Cathode gas diffusion layer thickness | +| `stack_w_channels` | 1 | cm | Gas channel width and height | +| `stack_num_channels` | 8 | – | Gas channels per cell | +| `stack_io` | 1e-04 | A/cm² | Exchange current density | +| `stack_alpha` | 0.7 | – | Charge transfer coefficient | +| `stack_D_gdl_A` | 0.07 | cm²/s | Water diffusivity in anode GDL | +| `stack_D_gdl_C` | 0.07 | cm²/s | Water diffusivity in cathode GDL | +| `stack_membrane_rho` | 2000 | kg/m³ | Density of dry membrane | +| `stack_membrane_MW` | 1.1 | kg/mol | Equivalent weight of dry membrane | +| `stack_mea_rho` | 1800 | **kg/s** *(sic)* | Overall density of MEA — vendor unit typo, should be kg/m³ | +| `stack_mea_cp` | 870 | J/(kg·K) | Overall specific heat of MEA | + +### Piping and heat exchanger + +| Parameter | Value | Unit | Description | +|---|---:|---|---| +| `water_pipe_D` | 0.01 | m | Water pipe diameter | +| `gas_pipe_D` | 0.01 | m | Gas pipe diameter | +| `exchanger_L` | 1 | m | Overall radiator length | +| `exchanger_W` | 0.025 | m | Overall radiator width | +| `exchanger_H` | 0.5 | m | Overall radiator height | +| `exchanger_N_tubes` | 25 | – | Number of coolant tubes | +| `exchanger_tube_H` | 0.0015 | m | Height of each coolant tube | +| `exchanger_fin_spacing` | 0.002 | – | Fin spacing | +| `exchanger_eta_fin` | 0.7 | – | Fin efficiency | + +Derived quantities computed in the script: `exchanger_gap_H`, `exchanger_air_area_primary`, +`exchanger_N_fins`, `exchanger_air_area_fins`, `exchanger_tube_Leq`. + +## Fuel cell parameters + +`PEMFuelCellSystemParameters.m` — 94 lines, 12,709 B, MD5 `6eaf6bf3`. Byte-identical in +`Ready Made PEM fuel cell/` and `Big Ugly Folder/`. Line 8 executes +`load PEMFuelCellSystemDriveCycle.mat` (13,667 B). + +### Environment + +| Parameter | Value | Unit | +|---|---:|---| +| `env_p` | 0.101325 | MPa | +| `env_T` | 20 | °C | +| `env_RH` | 0.5 | – (relative humidity) | +| `env_yO2` | 0.21 | – (oxygen mole fraction) | + +### Fuel tank + +| Parameter | Value | Unit | +|---|---:|---| +| `tank_p` | 70 | MPa | +| `tank_yH2` | `1 − 3e-4` | – (hydrogen mole fraction) | +| `tank_V` | 120 | L | + +> `tank_V = 120 L` at 70 MPa is an **automotive** hydrogen tank. The +> [project spec](../02-specifications/simulator-io-interface.md#13-hydrogen-tank) calls for +> **up to 200 kg across two tanks** — roughly three orders of magnitude larger. Another +> consequence of the untouched vendor defaults. + +### Stack + +| Parameter | Value | Unit | Description | +|---|---:|---|---| +| `stack_num_cells` | **400** | – | Number of cells (vs. 50 in the electrolyser) | +| `stack_area` | 280 | cm² | Cell area | +| `stack_t_membrane` | 125 | µm | Membrane thickness | +| `stack_t_gdl` | 250 | µm | Gas diffusion layer thickness | +| `stack_w_channels` | 1 | cm | Gas channel width/height | +| `stack_num_channels` | 8 | – | Gas channels per cell | +| `stack_io` | 1e-04 | A/cm² | Exchange current density | +| `stack_iL` | 1.4 | A/cm² | Limiting current density | +| `stack_alpha` | 0.7 | – | Charge transfer coefficient | +| `stack_D_gdl` | 0.07 | cm²/s | Water diffusivity in GDL | +| `stack_membrane_rho` | 2000 | kg/m³ | Density of dry membrane | +| `stack_membrane_MW` | 1.1 | kg/mol | Equivalent weight of dry membrane | +| `stack_mea_rho` | 1800 | **kg/s** *(sic)* | Vendor unit typo, should be kg/m³ | +| `stack_mea_cp` | 870 | J/(kg·K) | Overall specific heat of MEA | + +### Gas tubes and coolant + +| Parameter | Value | Unit | Description | +|---|---:|---|---| +| `anode_tube_D` | 0.01 | m | Hydrogen tube diameter | +| `cathode_tube_D` | 0.05 | m | Air tube diameter | +| `coolant_w_channels` | 1 | cm | Coolant channel width/height | +| `coolant_num_passes` | 12 | – | Coolant channel passes per layer | +| `coolant_num_layers` | 20 | – | Coolant layers in stack | +| `coolant_tube_D` | 0.05 | m | Coolant tube diameter | + +### Radiator + +| Parameter | Value | Unit | Description | +|---|---:|---|---| +| `radiator_L` | 1 | m | Overall radiator length | +| `radiator_W` | 0.025 | m | Overall radiator width | +| `radiator_H` | 0.5 | m | Overall radiator height | +| `radiator_N_tubes` | 25 | – | Number of coolant tubes | +| `radiator_tube_H` | 0.0015 | m | Height of each coolant tube | +| `radiator_fin_spacing` | 0.002 | – | Fin spacing | +| `radiator_eta_fin` | 0.7 | – | Fin efficiency | +| `radiator_t_wall` | 1e-4 | m | Material thickness | +| `radiator_rho` | 2700 | **kg/s** *(sic)* | Vendor unit typo, should be kg/m³ (2700 = aluminium) | +| `radiator_cp` | 910 | J/(kg·K) | Radiator material specific heat | + +### Compressor map + +| Parameter | Value | Unit | +|---|---|---| +| `comp_p_ratio_TLU` | `[1; 1.25; 1.5; 1.75; 2]` | – (pressure ratio) | +| `comp_rpm_TLU` | `[0, 1800, 3600]` | rpm | + +```matlab +comp_mdot_corr_TLU = [ + 0, 0.05, 0.1; + 0, 0.0375, 0.075; + 0, 0.025, 0.05; + 0, 0.0125, 0.025; + 0, 0, 0] * 4; % [kg/s] Corrected mass flow rate table +``` + +## Gas properties (shared by both files) + +| Gas | `_R` [J/(kg·K)] | `_D` [mm²/s] | +|---|---:|---:| +| H₂ | 4124.48151675695 | 74 | +| O₂ | 259.836612622973 | 18 | +| N₂ | 296.802103844292 | — | + +Each gas also carries 52-element lookup vectors sharing the temperature grid +`_T = [-56.55, -50:10:-10, -5:1:5, 10:10:350]` °C, with `_h` in kJ/kg (specific enthalpy), +`_mu` in µPa·s (dynamic viscosity), and `_k` in mW/(m·K) (thermal conductivity). + +## What differs between the two models + +The two parameter files share identical gas property tables and identical membrane/MEA +parameters. The substantive differences: + +| Aspect | Electrolyser | Fuel cell | +|---|---|---| +| `stack_num_cells` | 50 | **400** | +| Limiting current density | — | `stack_iL = 1.4 A/cm²` | +| Gas diffusion layer | Split anode/cathode (`_A` 25 µm / `_C` 250 µm) | Single `stack_t_gdl` = 250 µm | +| Fuel storage | — | `tank_*` block, 120 L @ 70 MPa | +| Air handling | — | `env_RH`, `env_yO2`, compressor map | +| Cooling | Heat exchanger | Coolant channels + radiator | +| Drive input | 24 h solar profile | Automotive drive cycle `.mat` | + +## Supporting scripts + +Both folders ship MathWorks' plotting and example scripts, all copyright MathWorks: + +| Electrolyser | Fuel cell | +|---|---| +| `PEMElectrolysisSystemExample.m` | `PEMFuelCellSystemExample.m` | +| `PEMElectrolysisSystemPlot1IV.m` | `PEMFuelCellSystemPlot1IV.m` | +| `PEMElectrolysisSystemPlot2Power.m` | `PEMFuelCellSystemPlot2Power.m` | +| `PEMElectrolysisSystemPlot3Hydrogen.m` | `PEMFuelCellSystemPlot3Efficiency.m` | +| | `PEMFuelCellSystemPlot4T.m` | +| | `PEMFuelCellSystemPlot5Energy.m` | + +The `Plot*.m` files carry polished vendor documentation citing textbook figures — for example +*"The theoretical maximum efficiency for a PEM fuel cell is 83%. However, actual efficiency is +around 60% due to internal losses"*, which lines up with the 40% fuel-cell loss figure in +[AI Efficiency Improvements](../01-project/ai-efficiency-improvements.md). + +The `.ssc` component sources use the Simscape `foundation.moist_air.moist_air` and +`foundation.thermal_liquid.thermal_liquid` domains. + +## Related + +- [Simulink Model Inventory](simulink-model-inventory.md) — including the `Constants.m` staleness +- [Simulator I/O Interface §1.1–1.3](../02-specifications/simulator-io-interface.md#11-electrolyser) — the parameters these should match +- [UCSD Equipment Manual](../03-energy-management/ucsd-equipment-manual.md) — real-world PEM electrolyser specifications +- [AI Efficiency Improvements](../01-project/ai-efficiency-improvements.md) — the loss targets +- [Existing EST Model](existing-est-model.md) — the other vendored subtree diff --git a/docs/04-simulations/powerworld-microgrid.md b/docs/04-simulations/powerworld-microgrid.md new file mode 100644 index 0000000..7bc1a8f --- /dev/null +++ b/docs/04-simulations/powerworld-microgrid.md @@ -0,0 +1,102 @@ +# PowerWorld Microgrid Model + +> **Markdown report of non-markdown source files.** +> +> | | | +> |---|---| +> | **Sources** | `Shift Matlab Drive/Shift Matlab Drive/Simulations/PowerWorld/New Powerworld/` | +> | **Formats** | PowerWorld binary case files, CSV export, MP4 screen recording | +> | **Owner** | Simulations cluster | +> | **Status** | Current | +> | **Report generated** | 2026-07-25 | + +## Folder contents + +| File | Size | Format | What it is | +|---|---:|---|---| +| `Shift Powerworld Microgrid EASI.mp4` | **10.9 MB** | MP4 video | Screen recording / demonstration of the model — see [The video](#the-video) | +| `microgrid_OG.PWB` | 28 kB | PowerWorld Binary | The **case file** — the actual network model (buses, lines, generators, loads) | +| `final_base_v5.tsb` | 14 kB | PowerWorld Time Step Base | Time-step simulation definition — `v5` implies at least five iterations | +| `microgrid_OG.pwd` | 5.6 kB | PowerWorld Display | The one-line diagram / display layout for `microgrid_OG.PWB` | +| `Profiles SHIFT(Generators Factors + Battery).csv` | 9 kB | CSV | Input profile — see [The CSV](#the-csv-input-profile) | + +`.PWB`/`.pwd`/`.tsb` are proprietary PowerWorld Simulator formats. They are **binary and +unreadable without a PowerWorld licence**, and nothing in this repository records which +PowerWorld version or licence tier is required to open them. + +> [!NOTE] +> `microgrid_OG` — "OG" reads as *original*. `final_base_v5.tsb` carries both "final" and "v5". +> The two naming schemes do not agree about which artefact is the settled one. The `.tsb` +> version number is the only explicit version marker anywhere in this folder. + +## The CSV input profile + +`Profiles SHIFT(Generators Factors + Battery).csv` is a **semicolon-delimited, comma-decimal** +export — European locale — of the first sheet of the +[Generation Profiles Workbook](generation-profiles-workbook.md). + +``` +;Solar Capacity Factor;Wind Capacity Factor;Max Power PV (MW);Max Power Wind;Actual Pv Power (MW);Actual Wind Power (MW);Min Power (MW) +00:00;0;0,448;151,095442;2;0;0,896;0 +01:00;0;0,462;151,095442;2;0;0,924;0 +... +``` + +The values match the workbook exactly — 151.095442 MW max PV, 2 MW max wind, the same hourly +capacity factors. It is a **derived export, not an independent source**: 24 hourly rows, +followed by trailing empty columns from the spreadsheet's used range. + +This closes the loop on where the workbook's *"Results Analysis"* section came from — the +workbook supplies the generation profile to PowerWorld via this CSV, PowerWorld runs the +time-step study, and the results are pasted back into the workbook. + +> The decimal-comma format means this CSV will parse incorrectly under a default (US-locale) +> reader. `PVBatteryRead.mlx` handles exactly this case for the `.xlsx` +> (`col = strrep(col, ',', '.')`), but nothing in the repository reads this CSV programmatically. + +## What the model shows + +The findings from the PowerWorld run are recorded in the workbook rather than here, and are +reproduced in +[Generation Profiles Workbook → PowerWorld results analysis](generation-profiles-workbook.md#powerworld-results-analysis). +In summary: + +- No major voltage problems; generators work as intended. +- The grid does not pull energy when the battery is active, but pulls more when the battery is + also pulling — the recommendation is shorter, stronger midday charge cycles and night-time + discharge. +- **The line/transformer is overloaded in 19 of 24 hours**, peaking at **428% of MVA limit**. + The workbook's own conclusion is that the line rating and distance data are unrealistic + rather than the dispatch being wrong. + +That unresolved line-rating question is the main open item for this model. + +## Scale + +This model runs at **151 MW PV / 140 MWh storage / 600 MWh per day** — campus or +distribution-network scale, roughly 300× the single-hospital scale used everywhere else in the +project (a 2,300 m² rooftop array is ~0.46 MW peak). It is closer to the +[UCSD campus microgrid](../03-energy-management/ucsd-equipment-manual.md) (30 MW CHP) than to +BIDMC. + +Whether that is deliberate — a network-level study to complement the building-level Simulink +work — or an uncorrected placeholder is not recorded anywhere. Worth a note in the folder. + +## The video + +`Shift Powerworld Microgrid EASI.mp4` (10.9 MB) is the **third-largest file in the repository** +and the only video. Its content cannot be transcribed into this report — it is a screen +recording, and no accompanying description exists. + +**Recommendation, not yet applied:** a 10.9 MB binary video in git is the kind of file that is +better hosted alongside the team's other media (ClickUp, Drive, or the website) with a link +from here. If it is a demo of the model running, a few captioned screenshots plus a paragraph +would serve the repository better and cost ~100 kB. Left in place pending the team's decision — +deleting the only recording of a model nobody can open without PowerWorld would be the wrong +call to make unilaterally. + +## Related + +- [Generation Profiles Workbook](generation-profiles-workbook.md) — the input profile and the results analysis +- [Simulink Model Inventory](simulink-model-inventory.md) — the MATLAB-side models +- [UCSD Equipment Manual](../03-energy-management/ucsd-equipment-manual.md) — the campus-scale case study diff --git a/docs/04-simulations/pv-battery-simulink.md b/docs/04-simulations/pv-battery-simulink.md new file mode 100644 index 0000000..5c18b57 --- /dev/null +++ b/docs/04-simulations/pv-battery-simulink.md @@ -0,0 +1,148 @@ +# PV + Battery Simulink Model + +> **Markdown report consolidating two non-markdown sources plus one duplicate markdown file.** +> +> | | | +> |---|---| +> | **Sources** | `Shift Matlab Drive/.../Simulations/PV+Battery Simulink/PV+Battery.docx`
`Shift Matlab Drive/.../Simulations/PV+Battery Simulink/PVBatteryRead.mlx`
`Shift Matlab Drive/.../Simulations/PV+Battery Simulink/Constants.mlx` | +> | **Also duplicated as** | `PV+Battery.md` at the repository root — **retired to [`superseded/`](../../superseded/)** | +> | **Owner** | Simulations cluster | +> | **Status** | Current — **model has a known unresolved bug** (see [Known issue](#known-issue--model-is-not-time-dependent)) | +> | **Report generated** | 2026-07-25 | + +## What this is + +The Simulations cluster's first end-to-end vertical slice: read real profile data out of a +spreadsheet, hand it to Simulink, and run coupled PV and battery models against it. It is a +methodology trial as much as a model — the closing question in the source is *"Discuss if this +is a good standard for all parts."* + +## Components + +### 1. Profiles SHIFT (spreadsheet) + +- A new tab has been added to the existing Excel data sheet. +- Quick-search data has been filled in for fast experimentation with the Simulink models. + +See [Generation Profiles Workbook](generation-profiles-workbook.md) for the sheet contents. + +### 2. `PVBatteryRead.mlx` + +- Code developed with large assistance from ChatGPT. +- Originally intended to read *everything* off the spreadsheet; it currently reads **dynamic + data** and prepares it for Simulink use. +- The constants reading would not function, for reasons not established — so constants are set + in `Constants.mlx` instead. + +**What the script actually does**, step by step: + +| Step | Behaviour | +|---|---| +| File settings | Reads `Profiles SHIFT(Generators Factors + Battery).xlsx`, sheet **`Fake Simulink Data`**, with `HeaderLines = 1` and `VariableNamingRule = 'preserve'` | +| 1 — Type conversion | Converts cell-text numbers to double, **replacing `,` with `.`** for decimal commas; converts `duration` columns to hours | +| 2 — Trim | Detects the last valid signal row (any non-NaN numeric, and a date after 2000-01-01) and truncates the table there | +| 3 — Extract | Parses variable names out of headers of the form `Name - var (unit)` via the regex `-\s*(.*?)\s*\(`, then `matlab.lang.makeValidName`. Time (`t`) is converted to **seconds** — a max ≤ 1 is treated as fraction-of-day, otherwise as hours. A column whose values are all identical becomes a **constant**; otherwise a time series | +| 4 — Simulink signals | For every numeric variable of the same length as `t`, creates `_simulink = [t, values]` in the base workspace — the two-column `[time, data]` format Simulink's *From Workspace* block expects | + +> The sheet name is literally **`Fake Simulink Data`** — placeholder data for wiring up the +> pipeline, not a real profile. + +### 3. `Constants.mlx` + +Remember to run this **and** `PVBatteryRead.mlx` before attempting to run the Simulink models. + +```matlab +A_PV = 3060; % PV Area (m2) +mu_PV = 0.2; % Panel Efficiency (%) +V_PV = 24; % PV Voltage (V) + +P_ele = 1500000; % Electrolyzer Power Consumption (W) +E_t0 = 0; % Initial Battery Energy (Wh) +E_rated = 170000; % Battery Rated Energy (W) +Q_rated = 100000; % Battery Rated Charge Capacity (W) +Charge_max = 1; % Maximum Charge (%) +Disharge_max = 2; % Maximum Discharge (%) +SoC_max = 1; % SoC limit (%) +SoC_t0 = 0; % Initial SoC (%) + +P_B_int = 0; % Initial Battery power (W) +I_B_int = 0; % Initial Battery current (A) +``` + +**Parameter cross-check against the project spec:** + +| Constant | Value here | Project spec | Comment | +|---|---|---|---| +| `A_PV` | 3060 m² | **2,300 m²** ([Simulator I/O §1.4](../02-specifications/simulator-io-interface.md#14-pv)) | 33% larger than spec | +| `mu_PV` | 0.2 | — | Reasonable for commercial silicon | +| `P_ele` | 1.5 MW | — | Large relative to a 2,300 m² × 20% array (~460 kW peak) | +| `E_rated` | 170000, commented **W** | Rated energy capacity in **Wh** | Unit comment is wrong; should be Wh | +| `Q_rated` | 100000, commented **W** | Rated charge capacity in **Ah** | Unit comment is wrong; should be Ah | +| `Disharge_max` | 2 | — | Commented "%" but a discharge *limit* of 2 with `SoC_max = 1` is dimensionally inconsistent. Also a typo for `Discharge_max` | +| `SoC_t0` | 0 | — | Starting from an empty battery | + +None of these break the model — they are annotation errors and a not-yet-calibrated parameter +set — but they should be reconciled with the simulator contract before results are quoted. + +### 4. `SolarPanel.slx` + `Battery.slx` (and `SolarPanel_n_Battery.slx`) + +- Two individual models using the equations from *paper 1* to derive the desired outputs over + time. +- **Both do this in two different ways**, using different variables, to compare consistency. +- Most SoC-related quantities are handled in **%**. The dynamic data found is likely in + another unit — that is what `Q_rated` and `E_rated` are for, to be used according to paper 1. + +## Known issue — model is not time-dependent + +> *"An issue was encountered where this code does not appear to be time dependant despite +> drawing the appropriate `_simulink` matrices from the workspace. This is most likely some +> kind of conversion issue between time in seconds in code and time measured in the simulinks +> themselves."* + +This is unresolved and is the first item on the to-do list. The author's diagnosis is +consistent with what `PVBatteryRead.mlx` does: it converts `t` to **seconds** in step 3, so any +Simulink block configured in hours — or a solver whose stop time is set in hours — will see a +signal that appears constant across the run because the simulated interval covers only the +first few samples. + +**Where to look first:** the `[t, values]` matrices are built with `t` in seconds; check the +Simulink model's configured stop time and the *From Workspace* block's sample-time +interpretation match that unit. + +## To be continued + +Carried forward verbatim from the source: + +- Fix the aforementioned time-dependency issue. +- Test and see if these values make sense. Compare the two versions for both. +- Discuss if this is a good standard for all parts. + +## File locations + +All of these files were submitted on MATLAB Drive and ClickUp under +*Simulations → PV+Battery Simulink*. In this repository: + +| File | Size | Note | +|---|---|---| +| `PV+Battery.docx` | 1.6 kB | Source of this report | +| `PVBatteryRead.mlx` | — | Data import script | +| `Constants.mlx` | — | Parameter definitions | +| `SolarPanel.slx` | — | PV model | +| `Battery.slx` | — | Battery model | +| `SolarPanel_n_Battery.slx` | — | Combined model | +| `SolarPanel.slxc` | — | Simulink cache — build artefact | +| `Profiles SHIFT(Generators Factors + Battery).xlsx` | — | Byte-identical to the copy in `Current Framework/` | +| `slprj/` | — | Simulink build cache — machine-generated | + +## Duplicate source note + +The repository root contained `PV+Battery.md`, a markdown transcription of `PV+Battery.docx` +with the same content. Since this report supersedes both, the root markdown copy is retired to +[`superseded/`](../../superseded/) and the `.docx` remains in place as the original. + +## Related + +- [Generation Profiles Workbook](generation-profiles-workbook.md) — the spreadsheet this reads +- [MATLAB Live Scripts](matlab-live-scripts.md) — inventory of all `.mlx` files +- [Simulink Model Inventory](simulink-model-inventory.md) — all `.slx` files and their lineage +- [Simulator I/O Interface §1.4–1.5](../02-specifications/simulator-io-interface.md#14-pv) — the parameter spec these constants should match diff --git a/docs/04-simulations/rule-based-controller-implementation.md b/docs/04-simulations/rule-based-controller-implementation.md new file mode 100644 index 0000000..28771af --- /dev/null +++ b/docs/04-simulations/rule-based-controller-implementation.md @@ -0,0 +1,213 @@ +# Rule-Based Controller — MATLAB Implementation + +> **Markdown report of a non-markdown source file.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/controller-claude.m` | +> | **Format** | MATLAB, 92 lines, 7,388 B | +> | **MD5** | `745f573a203238a32cbcd5b1a3d6ecc7` | +> | **Status** | **Draft — does not run.** See [Blocking defects](#blocking-defects) | +> | **Report generated** | 2026-07-25 | + +## What it is + +The MATLAB implementation of the priority-cascade dispatch policy specified in +[Rule-Based Controller](../02-specifications/rule-based-controller.md). Written as the body of +a Simulink **MATLAB Function block** — the signature is `function [...] = fcn(...)`, and `fcn` +is Simulink's default block function name. + +```matlab +function [P_load_P, P_load_PB, P_battery_cont, P_load_PBH, P_FuelCell_cont, P_Electro_cont] = ... + fcn(Current_A, P_load, P_PV, E_battery_SOC, P_battery_max, E_battery_max, ... + E_H2_SOC, P_FuelCell_max, E_H2_max) +``` + +It resolves load in a fixed merit order, exactly as the specification describes: + +| Stage | Lines | Behaviour | +|---|---|---| +| 1. PV direct | 8 | `P_load_P = P_load - P_PV` — residual after solar | +| 2. Battery | 11–36 | Residual > 0 → discharge (capped by `P_battery_max` or remaining SOC); residual < 0 → charge (capped by max power or remaining headroom) | +| 3. Hydrogen | 39–64 | Same two-sided pattern — fuel cell discharges the tank, electrolyser charges it | +| 4. Grid | 67–72 | Whatever remains is bought or sold | + +> [!WARNING] +> **This file does not run.** It has hard undefined-variable errors and cannot compile as a +> Simulink MATLAB Function block. It is an explicitly-marked work in progress — the author's +> own notes at lines 74–79 say as much. The defect list below is documentation of a known +> draft, not a code review of something anyone claimed was finished. + +## Blocking defects + +**B1 — undefined `Electro_max` (line 54).** + +```matlab +P_Electro_cont = -Electro_max % The ELECTROLYZER charges at it's maximum power allowed +``` + +`Electro_max` exists nowhere. Intended `P_Electro_max` — missing the `P_` prefix. + +**B2 — `P_Electro_max` is never defined either (lines 52, 53, 54).** + +The signature declares nine inputs; `P_Electro_max` is not among them and is never assigned in +the body. Even after fixing B1, the reference is still undefined. **The entire electrolyser +branch (lines 51–63) is dead.** The function signature needs a tenth input. + +**B3 — outputs not assigned on all paths.** + +A Simulink MATLAB Function block requires every declared output to be assigned on every path. + +| Output | Unassigned when | +|---|---| +| `P_FuelCell_cont` / `P_Electro_cont` | Mutually exclusive — the `if` at line 39 assigns only the first, the `else` at 51 only the second. Both are declared outputs | +| `P_load_PB` | Never assigned on the path through lines 20–21 (battery too empty to discharge at max) | +| `P_load_PBH` | Never assigned on the path through lines 48–49 (tank too empty) | + +Consequently line 39 can read an unassigned `P_load_PB`, and line 67 an unassigned +`P_load_PBH`. + +## Logic defects — silently wrong results + +**B4 — wrong right-hand side (line 43).** + +```matlab +P_FuelCell_cont = P_load_PBH; +``` + +The battery analogue it was copied from (line 15) is `P_battery_cont = P_load_P;` — the +*incoming* residual. Here `P_load_PBH` is, under the guard at line 42 (`P_load_PBH < 0`), the +**negative overshoot**. It should read `P_FuelCell_cont = P_load_PB;`. As written the fuel cell +is commanded to a negative power — to consume — exactly when it is supposed to supply. + +**B5 — sign convention inverted (lines 33 and 61).** + +The stated convention (line 29) is *"negative `P_battery_cont` is battery charging, positive is +discharging"*. Line 26 respects it (`-P_battery_max`). But in the same charging branch: + +```matlab +33: P_battery_cont = E_battery_max - E_battery_SOC; % headroom — POSITIVE +61: P_Electro_cont = E_H2_max - E_H2_SOC; % headroom — POSITIVE +``` + +Both assign **positive** values while on the charging path. Storage will be commanded to +discharge when it should charge. + +**B6 — energy and power conflated throughout.** + +Energy variables (`E_*`, kWh) are compared against and assigned to power variables (`P_*`, kW) +with no timestep factor: + +| Line | Expression | Problem | +|---|---|---| +| 12 | `if E_battery_SOC > P_battery_max` | kWh compared to kW | +| 21 | `P_battery_cont = E_battery_SOC;` | kWh assigned to a kW command | +| 40 | `if E_H2_SOC > P_FuelCell_max` | kWh compared to kW | +| 49 | `P_FuelCell_cont = E_H2_SOC;` | kWh assigned to a kW command | +| 24, 33, 52, 61 | headroom expressions | same | + +The author flags this at lines 78–79: + +> `%IMPLEMENT THE ARRAY-SCANNING FOR-LOOP AND MAKE SURE THE Power = Energy` +> `%Equations make sense????` + +The arithmetic is only correct if the timestep is exactly 1 h *and* units are consistent — +neither is enforced anywhere. This is the same `dt` question the +[Simulator I/O Interface](../02-specifications/simulator-io-interface.md#timestep) leaves open. + +**B7 — load sign clashes with `Constants.m`.** + +```matlab +if P_load < 0 + P_load = 0; +end +``` + +`Constants.m` defines `E_HospitalLoad = -1000000; %kWh` — hospital load is stored **negative**. +If that convention feeds `P_load`, this guard zeroes out the entire hospital demand and the +controller does nothing. + +## Console output + +**B8/B9 — two assignments missing a terminating semicolon**: line 26 +(`P_battery_cont = -P_battery_max`) and line 54 (`P_Electro_cont = -Electro_max`). Both echo to +the console on every hit, every timestep. An automated scan found exactly these two. + +**B10 — unconditional `disp` every timestep** (lines 67–72): + +```matlab +if P_load_PBH > 0 + disp('buy') +else + disp('sell') +end +disp(P_load_PBH) +``` + +Beyond the spam, `disp` is an extrinsic function in a Simulink MATLAB Function block — +unsupported for code generation. It will either force interpreted execution or fail the build. + +## Incomplete sections + +**I1 — grid exchange is never returned.** Lines 67–72 determine buy vs. sell but only *print* +it. There is no output argument for grid power. The author's note at lines 74–76: + +> `%Doublecheck these and repeat the logic for the hydrogen, finally` +> `%selling/buying the rest from the grid. Make sure the discharging is at the` +> `%tank level and charging at hydrogen level` + +**I2 — the time-series loop was never implemented** (lines 78–79, quoted above). + +**I3 — dead commented-out hydrogen integrator (lines 83–89):** + +```matlab +%for t = 1:24 %Check if this makes sense +% H2_stor(end) = H2_stor(end)*(1-H2_leak); +% H2_stor(end+1) = H2_stor(end)+H2_vol(t); +% H2_Flow_L_min(t) = (-P_H2(t)/E_H2_vol_h(t))*(1000/60); +%end +%E_H2_stor = H2_stor*E_H2_vol_h; +``` + +Uncommenting it would still fail. `H2_stor`, `H2_vol` and `P_H2` are undefined anywhere in the +repository. `H2_leak` and `E_H2_vol_h` do exist — but **only in the complete `Constants.m`**, +not the stale top-level copy (see +[Simulink Model Inventory](simulink-model-inventory.md#constantsm--the-top-level-copy-is-stale)). +And line 86 indexes `E_H2_vol_h(t)` as an array when it is the scalar `3000` — out of bounds +for any `t > 1`. + +## Other observations + +| # | Observation | +|---|---| +| Q1 | Input `Current_A` is declared but **never used** in the 92-line body — a dead parameter | +| Q2 | **The filename is not a legal MATLAB function file.** `controller-claude.m` contains a hyphen; MATLAB identifiers cannot. It can never be called as `controller-claude(...)`. It only works pasted into a Simulink MATLAB Function block — consistent with the function being named `fcn` | +| Q3 | It is the **only file at the `Shift Matlab Drive/Shift Matlab Drive/` root**, outside `Simulations/` entirely, and is not attached to any model in the repository | +| Q4 | The hydrogen block is a verbatim copy of the battery block with incomplete renaming. Lines 45–46 sit in the *fuel cell* branch but say "max **battery** power"; line 57 references `P_battery_cont` inside the *electrolyser* branch; line 61's comment says "**Battery** charges only as much as there is space left" while assigning `P_Electro_cont`. **This is how B4 and B5 arose** | +| Q5 | Comment typos: `dirrectly` (7), `to empty` for "too empty" (20, 48), `ELETROLYZER` (52), `SOTRAGE` (60) | + +## Fixing it + +In rough dependency order: + +1. Add `P_Electro_max` as a tenth input; fix the `Electro_max` typo (B1, B2). +2. Assign every output on every path — initialise all six to `0` at the top (B3). +3. Fix line 43 to `P_FuelCell_cont = P_load_PB;` (B4). +4. Negate lines 33 and 61 (B5). +5. Decide the timestep and make every `E_*`/`P_*` conversion explicit (B6). +6. Settle the load sign convention against `Constants.m` (B7). +7. Add a grid-power output; delete the `disp` calls (I1, B10). +8. Rename the file to a legal MATLAB identifier, e.g. `rule_based_controller.m`, and move it + next to the model it drives. + +Steps 5 and 6 are the ones that need a decision rather than an edit — they are the same +open questions the +[Simulator I/O Interface](../02-specifications/simulator-io-interface.md#5-open-questions) +raises. + +## Related + +- [Rule-Based Controller](../02-specifications/rule-based-controller.md) — the specification this implements +- [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) — the contract, including sign conventions and the `dt` question +- [Simulink Model Inventory](simulink-model-inventory.md) — the `Constants.m` staleness this depends on +- [RL Action Variables](../02-specifications/rl-action-variables.md) — what an RL policy would emit instead diff --git a/docs/04-simulations/shift-input-data.md b/docs/04-simulations/shift-input-data.md new file mode 100644 index 0000000..61af3c7 --- /dev/null +++ b/docs/04-simulations/shift-input-data.md @@ -0,0 +1,163 @@ +# Shift Input Data — Component Variable List + +> **Markdown report of a non-markdown source document.** +> +> | | | +> |---|---| +> | **Source** | `Shift Matlab Drive/Shift Matlab Drive/Simulations/Shift input data.docx` | +> | **Format** | Microsoft Word (.docx) | +> | **MD5** | `b4e1cea6…` — **an identical copy** exists at `Simulations/Old Simulations/Shift input data.docx` | +> | **Author** | Robert (Simulations cluster) | +> | **Status** | Current, but **largely absorbed** by the [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) | +> | **Report generated** | 2026-07-25 | + +## What this document is + +The first systematic enumeration of every variable each physical component needs — the raw +material from which the +[Simulator I/O Interface](../02-specifications/simulator-io-interface.md) was built. That +document cites this one directly: + +> *"Set once per simulation run. These are the constants **Robert's doc** lists in bold."* +> — Simulator I/O Interface §1 + +It is therefore the **ancestor** of the current simulator contract, not a competitor to it. +It is kept because it records the per-component reasoning (and the alternatives considered) +that the formalised contract compressed away. + +## Reading the original + +The source document's structure is a single wide table whose header row explains the column +semantics. Extracted verbatim, that header reads: + +> Component · Desirable Outputs — constant (if it can be found, good to compare against) · +> Necessary Inputs — full name (unit) — Which element it applies to (less ideal alternative, +> has to be consistent throughout inputs found) · Other alternatives · Required together · +> Output data — dynamic · Can most likely be read off the data · Unsure if it can be +> realistically acquired / if it's necessary at all *(post-processing ChatGPT assistance, thus +> it may not actually be needed)* + +In practice the column-to-variable assignment does not survive extraction — the body is a flat +list per component. It is reproduced faithfully below, grouped as in the original. **Open the +original `.docx` if you need to know which column a given variable sat in.** + +## Variables by component + +### Electrolyser + +| Symbol | Name | +|---|---| +| `N_c` | Number of cells — electrolyser | +| `P_ele` | Electrolyzer power consumption | +| `mu_F` | Faraday efficiency — electrolyser | +| `I` | Current (A) — electrolyser | +| `n_H2` | Hydrogen flow rate (mol/s) — electrolyser | +| `m_H2` | Hydrogen mass flow rate (kg/s) — electrolyser | +| `v_H2` | Hydrogen volume flow rate (L/s) — electrolyser | +| `P` | Power (W) — electrolyser | +| `V` | Voltage (V) — electrolyser | + +Also listed: operating power setpoint · electrolyzer ON/OFF control signal · minimum operating +current · measured hydrogen production rate calibration factor. + +### Fuel cell + +| Symbol | Name | +|---|---| +| `N_c` | Number of cells — fuel cell | +| `I` | Current (A) — fuel cell | +| `Utilisation` | Percentage (%) — fuel cell | +| `n_H2_in` | Hydrogen flow rate into the fuel cell (mol) | +| `n_H2_used` | Hydrogen flow rate consumed by the fuel cell (mol) | +| `P` | Power (W) — fuel cell | +| `V` | Voltage (V) — fuel cell | + +Also listed: fuel cell operating voltage range · maximum fuel cell output power · fuel cell +ON/OFF control signal. + +### Hydrogen tank + +| Symbol | Name | +|---|---| +| `V_H2` | Volume of hydrogen stored (L) + maximum + initial | +| `T` | Temperature (K) | +| `p` | Atmospheric pressure (atm) | +| `n_H2_in` | Hydrogen flow rate into the tank (mol) | +| `n_H2_used` | Hydrogen flow rate output by tank (mol) | + +### PV + +| Symbol | Name | +|---|---| +| `mu` | Panel efficiency | +| `P_PV` | Solar panel power | +| — | Irradiance (W/m²) — PV throughout the day | +| `A_PV` | Area of the solar cell | +| `I` | Current (A) — PV | +| `P` | Power (W) — PV | +| `V` | Voltage (V) — PV | + +### Battery + +| Symbol | Name | +|---|---| +| — | Maximum charge/discharge power | +| `SoC` | State of charge + maximum + initial | +| `E_rated` | Rated voltage | +| `Q_rated` | Rated charge capacity | +| `I` | Current (A) — battery | +| `P` | Power (W) — battery | +| `V` | Voltage (V) — battery | + +> [!WARNING] +> `E_rated` is glossed here as **"rated voltage"**. In the +> [Simulator I/O Interface §1.5](../02-specifications/simulator-io-interface.md#15-battery) and +> in [`Constants.mlx`](matlab-live-scripts.md) it is **rated energy capacity in Wh**. The +> later definition is the one in use; this line is an early slip. + +### Load (hospital / wards / rooms) + +| Symbol | Name | +|---|---| +| `P` | Power (W) | +| `V` | Voltage (V) | +| `I` | Current (A) | + +### External power (grid / microgrid) + +| Symbol | Name | +|---|---| +| `P` | Power (W) + import/export | +| `V` | Voltage (V) | +| `I` | Current (A) | +| — | Grid availability (ON/OFF) | +| — | Maximum grid connection capacity | + +## What changed on the way to the simulator contract + +| This document | Simulator I/O Interface | Note | +|---|---|---| +| `N_c`, `mu_F`, `I` per component | `N_c_ele` / `N_c_fc`, `mu_F`, `I_ele_min` | Namespaced per component to remove collisions | +| `V_H2` in L | `V_H2_max` in **L or kg**; `H2_level(t)` in **mol or kg** | Unit still unresolved — flagged TBD there | +| `E_rated` = rated voltage | `E_rated` = rated energy capacity (Wh) | Corrected | +| Per-component `V` and `I` everywhere | Dropped; only `V_load`, `V_grid`, `V_fc_min/max` survive | The simulator is a power-flow model, not a circuit model | +| Operating setpoints listed inline | Split into a distinct §2.2 control-input block (`u_ele`, `u_fc`, `u_batt`, `sw_*`) | Setpoints separated from measurements | +| — | Sign conventions, power-balance invariant, priority rules, KPI block | New — these are the genuinely additive parts | + +The one thing this document has that the successor lacks is the **per-component electrical +detail** (`V` and `I` for every element). If the project ever moves from power-flow to circuit +simulation — for example to use the PowerWorld model — this list is the starting point. + +## Duplicate copy + +An identical file (same MD5) sits at +`Shift Matlab Drive/Shift Matlab Drive/Simulations/Old Simulations/Shift input data.docx`. The +copy in `Old Simulations/` is retired to [`superseded/`](../../superseded/); the one in +`Simulations/` remains. + +## Related + +- [Simulator I/O Interface](../02-specifications/simulator-io-interface.md) — the formalised successor +- [MATLAB Live Scripts](matlab-live-scripts.md) — `Constants.mlx` implements a subset of these +- [PV + Battery Simulink Model](pv-battery-simulink.md) +- [BIDMC Digital Twin Readiness Checklist](../03-energy-management/bidmc-digital-twin-readiness-checklist.md) — repeatedly refers to "Shift data" meaning this variable set diff --git a/docs/04-simulations/simulink-model-inventory.md b/docs/04-simulations/simulink-model-inventory.md new file mode 100644 index 0000000..934df24 --- /dev/null +++ b/docs/04-simulations/simulink-model-inventory.md @@ -0,0 +1,300 @@ +# Simulink Model Inventory + +> **Markdown report of non-markdown source files.** +> +> | | | +> |---|---| +> | **Sources** | Every `.slx`, `.slxc` and `.mat` under `Shift Matlab Drive/Shift Matlab Drive/Simulations/` (excluding the vendored [EST model](existing-est-model.md)) | +> | **Format** | Simulink models — **binary**, not readable or diffable outside MATLAB | +> | **Status** | Current inventory | +> | **Report generated** | 2026-07-25 | + +Simulink `.slx` files are opaque to everyone without MATLAB and carry no readable git history. +This inventory makes their lineage legible. + +> [!IMPORTANT] +> **Filesystem timestamps are useless here.** Every file in `Shift Matlab Drive/` carries an +> mtime inside a 4-second window on `2026-06-16 10:15` — the whole tree was bulk-copied from +> MATLAB Drive in one operation. +> +> **The lineage below comes from inside the files.** An `.slx` is a ZIP archive; its +> `metadata/coreProperties.xml` records Simulink's own **revision counter**, **release +> version**, **creation date**, and **last-modified-by username**. That is authoritative +> version data, and it is what every ordering claim on this page rests on. + +## The current model + +**`Current Framework/Bobert0206_Initial_Simulation_Framework.slx`** — revision **2.7**, +MATLAB **R2026a**, last saved by **`robert`**. + +Three independent lines of evidence agree: + +1. It carries the highest Simulink revision anywhere in the tree. +2. It sits in the folder literally named `Current Framework`. +3. `Current Framework/` is the only folder that also holds the live `Constants.m` (the complete + variant — see [below](#constantsm--the-top-level-copy-is-stale)) and the input workbook. + +`Bobert0206` reads as *Bobert* (robert) + `0206` — a date-stamped personal save. + +## The `Initial_Simulation_Framework` family + +Nine files, **seven distinct byte-states**. All share `dcterms:created = 2025-11-30T10:58:42Z`, +so every one descends from a single original model. + +| Rev | Release | Saved by | Size | MD5 | Path (under `Simulations/`) | +|:---:|---|---|---:|---|---| +| **2.7** | R2026a | `robert` | 173,799 | `ba7f9f6e` | **`Current Framework/Bobert0206_Initial_Simulation_Framework.slx`** ← current | +| 2.6 | R2026a | `chal` | 157,508 | `306c11f9` | `Current Framework/Initial_Simulation_Framework_CLEAR_CONNECTIONS.slx` | +| 2.2 | R2026a | `20243274` | 169,553 | `95d08300` | `Old Frameworks/Copy_of_Initial_Simulation_Framework.slx` | +| 2.0 | R2026a | `20243274` | 162,353 | `b766d7d6` | `Old Frameworks/Initial_Simulation_Framework.slx` | +| 2.0 | R2026a | `20243274` | 162,353 | `b766d7d6` | `Old Simulations/Initial_Simulation_Framework.slx` | +| 1.3 | R2025b | `robert` | 105,571 | `e30dbf8a` | `Initial_Simulation_Framework.slx` *(top level)* | +| 1.3 | R2025b | `robert` | 105,571 | `e30dbf8a` | `Old Simulations/Initial_Simulation_Framework.slx.r2025b` | +| 1.3 | R2025b | `20243274` | 1,033,972 | `46010d0d` | `Big Ugly Folder/Initial_Simulation_Framework.slx` | +| 1.2 | R2025b | `20243274` | 1,007,485 | `541b7087` | `Old Simulations/Initial_Simulation_Framework.slx.autosave` | + +### Reconstructed history + +``` +rev 1.2 (autosave, 20243274, R2025b) + │ +rev 1.3 ── forks ──┬── 20243274's copy → Big Ugly Folder/ (1.03 MB) + │ └── robert's copy → top level + .r2025b (106 KB) + │ + │ [upgraded R2025b → R2026a] +rev 2.0 (20243274) → Old Frameworks/ and Old Simulations/ +rev 2.2 (20243274) → Old Frameworks/Copy_of_... +rev 2.6 (chal) → Current Framework/..._CLEAR_CONNECTIONS +rev 2.7 (robert) → Current Framework/Bobert0206_... ← CURRENT +``` + +### Findings + +**The top-level model is *not* the newest.** `Simulations/Initial_Simulation_Framework.slx` is +byte-identical to `Old Simulations/Initial_Simulation_Framework.slx.r2025b` and is revision +**1.3** — five revisions behind current. Its prominent top-level position is misleading. + +**`_CLEAR_CONNECTIONS` is a parallel branch, not a predecessor.** Revision 2.6 by `chal`, one +revision behind `robert`'s 2.7. The name suggests a signal-routing cleanup fork that was not +merged before 2.7 was saved. Whether that cleanup still needs merging is an open question for +the Simulations cluster — it is the one piece of work in this family that may have been lost. + +**`Old Frameworks/` and `Old Simulations/` hold the same rev-2.0 file** (identical MD5). One of +the two folders is redundant. + +**The two ~1 MB outliers** (`Big Ugly Folder` rev 1.3, and the rev 1.2 `.autosave`) are 6× +larger than every other variant and are the two oldest revisions. Likely they retain cached +simulation output that later saves discarded. + +### Contributors + +Four usernames appear across the tree: **`robert`**, **`chal`**, **`nallu`**, and +**`20243274`** (a TU/e student number). + +## `Big Ugly Folder/` versus the two "Ready Made" folders + +**21 of the 22 files** in `Big Ugly Folder/` are byte-identical to a file in +`Ready Made PEM Electrolyzer/` or `Ready Made PEM fuel cell/` — the `.ssc` sources, the `.svg` +icons, the `.slx` models, the `.slxc` caches, `PEMFuelCellSystemDriveCycle.mat`, all the +`PEM*System*.m` scripts, and all six `slprj/` cache files. + +The set difference is exactly one file each way: + +| Only in `Big Ugly Folder` | Only in the clean folders | +|---|---| +| `Initial_Simulation_Framework.slx` (`46010d0d`, rev 1.3, 1.03 MB) | `Ready Made PEM fuel cell/PEMElectrolysisSystem.slxc` (`f8c088e4`) | + +**Verdict: `Big Ugly Folder` is the unsplit predecessor.** Someone downloaded both MathWorks +example packages into one directory alongside the team's own framework model, then later split +the vendor code into two tidy folders. Supporting evidence: + +1. Its content is the **exact union** of the two clean folders, with zero drift across 21 files + — consistent with copy-then-split, not independent work. +2. Its unique extra file is the framework at **revision 1.3 / R2025b**, the *oldest* era. A + folder assembled later by merging the clean folders would not contain an obsolete rev-1.3 + model. +3. The stray `.slxc` is a **newer build** of the electrolysis cache (5,779 B) than the one in + both `Big Ugly Folder` and `Ready Made PEM Electrolyzer` (5,777 B) — so the clean folders + were opened and re-simulated *after* the split, while `Big Ugly Folder` was frozen. + +**This folder cannot simply be deleted.** Its rev-1.3 `Initial_Simulation_Framework.slx` +(`46010d0d`) is unique — it exists nowhere else. Roughly 470 kB of the folder is pure +redundancy, but that one file is not. See [`superseded/README.md`](../../superseded/README.md) +for the disposition. + +## The "Ready Made" folders are unmodified MathWorks code + +> [!WARNING] +> **Every `.m` and `.ssc` file in `Ready Made PEM Electrolyzer/`, `Ready Made PEM fuel cell/` +> and `Big Ugly Folder/` carries a MathWorks copyright line.** Not one file lacks it, and there +> is no SHIFT attribution anywhere. + +``` +Electrolyzer.ssc:9 % Copyright 2021-2024 The MathWorks, Inc. +PEMElectrolysisSystemExample.m:57 % Copyright 2021 The MathWorks, Inc. +PEMElectrolysisSystemParameters.m:6 % Copyright 2021 The MathWorks, Inc. +FuelCell.ssc:10 % Copyright 2020-2024 The MathWorks, Inc. +PEMFuelCellSystemExample.m:64 % Copyright 2020-2021 The MathWorks, Inc. +PEMFuelCellSystemParameters.m:6 % Copyright 2020 The MathWorks, Inc. +…and 8 more Plot*.m files +``` + +`Constants.m` records how they were obtained: + +```matlab +%openExample('simscape/PEMElectrolysisSystemExample') +%openExample('simscape/PEMFuelCellSystemExample') +``` + +These are the canonical Simscape shipped-example IDs, and `Constants.m` calls the electrolyser +*"Ready made electrolyser"* — the origin of the folder names. + +Unlike the [EST model](existing-est-model.md), which carries its MIT LICENSE and upstream URL, +**this vendored code is marked nowhere**. A short `PROVENANCE.md` in each folder recording +"unmodified MathWorks Simscape example, obtained via `openExample(...)`" would close the gap. + +See [PEM Electrolyser and Fuel Cell Models](pem-electrolyser-and-fuel-cell-models.md) for the +parameter sets and the unfinished sizing work. + +## `FC_DigitalTwin_MathModel.slx` + +SHIFT-authored (no MathWorks markers), separate from the Simscape package. Two revisions, same +creation date `2026-03-18T18:14:27Z`: + +| Rev | Saved by | Size | MD5 | Path | +|:---:|---|---:|---|---| +| **1.2** | `robert` | 84,858 | `3b17283e` | **`Fuelcell/FC_DigitalTwin_MathModel.slx`** ← current | +| 1.1 | `nallu` | 75,673 | `d0dcd69c` | `Old Frameworks/FC_DigitalTwin_MathModel.slx` | + +`Fuelcell/` holds the newer revision, so the `Old Frameworks/` label is accurate for this file. +`Fuelcell/` is a bare single-file directory — no `Constants.m`, no data, no README. + +## Electrolyser models in `Old Frameworks/` + +| File | Rev | Release | Saved by | Created | Size | +|---|:---:|---|---|---|---:| +| `EL20N_Electrolyser_Model.slx` | 1.3 | R2025b | `chal` | 2026-02-11 | 116,355 | +| `electrolyserNEW.slx` | 1.1 | R2025b | `chal` | **2026-05-26** | 119,836 | + +Both by `chal`. `electrolyserNEW.slx` was **created three months later** but carries a *lower* +revision — it is a fresh model, not a continuation of `EL20N`. `EL20N` encodes a specific +commercial unit choice. + +Both sit in `Old Frameworks/` and are superseded in practice by the MathWorks PEM package that +`Constants.m` points at. They are retired rather than deleted — `EL20N` in particular records a +real product decision worth recovering. + +## `Constants.m` — the top-level copy is stale + +| MD5 | Size | Path | +|---|---:|---| +| `4a4bac92` | 839 B | `Simulations/Constants.m` | +| `b3cf89c4` | 1,006 B | `Simulations/Current Framework/Constants.m` | +| `b3cf89c4` | 1,006 B | `Simulations/Old Simulations/Constants.m` | + +**`Simulations/Constants.m` is a strict byte-prefix of the other two** — its first 839 bytes are +bit-for-bit identical, and it is simply missing the final 167 bytes: + +```matlab +%%------------------------------------------------------------------------- +H2_leak = 0.001; %Fraction (%) +H2_cap = 128; %m3 +E_H2_vol_h = 3000; %Wh/m3 +``` + +> [!WARNING] +> Despite occupying the most prominent position, the top-level `Constants.m` is an **older, +> truncated snapshot**. Anyone who runs it gets a workspace silently missing `H2_leak`, +> `H2_cap`, and `E_H2_vol_h`. +> +> The corroboration is decisive: `controller-claude.m`'s commented-out hydrogen block +> references `H2_leak` and `E_H2_vol_h` — variables that exist **only** in the longer version. +> The controller was written against `b3cf89c4`. + +Shared content (the common 839-byte prefix): + +```matlab +%Energy production +E_PV = 460000; %kWh +E_Grid = 140000; %kWh +E_ExternalGrid = 400000; %kWh + +E_HospitalLoad = -1000000; %kWh +``` + +followed by the developer's notes, verbatim: + +> `%Ready made electrolyser -` +> `%Good news: it has a solar profile.` +> `%Bad news: random constants - we want it at 128m3 hydrogen production a day` +> `%I have attempted to find volume via the volumetric flow rate, however this` +> `%uses "standard conditions". THIS BRINGS IT TO 12.8m3, JUST ADJUST (power?)` +> `%SO ITS 10 TIMES BIGGER AND WE ARE GOOD!` +> … +> `%To do: Check if PEM is ok, change parameters for electrolyzer so that` +> `%production is exactely 10times bigger, adjust fuel cell, create grid,` +> `%ensure its power output is appropriate` + +**That TODO is still unresolved** — see +[PEM Electrolyser and Fuel Cell Models](pem-electrolyser-and-fuel-cell-models.md). + +## `PV+Battery Simulink/` + +| File | Size | Purpose | +|---|---:|---| +| `SolarPanel.slx` | 108,605 | PV model | +| `Battery.slx` | 89,343 | Battery model | +| `SolarPanel_n_Battery.slx` | 126,034 | Combined model | +| `SolarPanel.slxc` | 5,141 | Build cache | +| `slprj/` | 2,488 | Build cache | + +Documented in full in [PV + Battery Simulink Model](pv-battery-simulink.md). + +## Zero-byte placeholders + +An exhaustive `find . -type f -size 0` over `Simulations/` returns exactly three files: + +- `Simulations/Some.m` +- `Simulations/Old Simulations/Some.m` +- `Simulations/Current Framework/TEST.txt` + +Empty placeholders carrying no content or structural role. Safe to delete. + +## Build artefacts + +`.slxc` files and `slprj/` directories are machine-generated Simulink caches — regenerated on +demand, no information content, spurious diffs. + +**All 15 `slprj/` files are committed to git**, across four directories: + +| Directory | Cached models | Files | Bytes | +|---|---|---:|---:| +| `Big Ugly Folder/slprj/` | `PEMElectrolysisSystem`, `PEMFuelCellSystem` | 6 | 38,176 | +| `Ready Made PEM fuel cell/slprj/` | `PEMFuelCellSystem` | 3 | 21,776 | +| `Ready Made PEM Electrolyzer/slprj/` | `PEMElectrolysisSystem` | 3 | 16,776 | +| `PV+Battery Simulink/slprj/` | `SolarPanel` | 3 | 2,488 | + +Six of the fifteen are byte-identical duplicates between `Big Ugly Folder/` and the clean +folders — further corroboration of the split. + +The root `.gitignore` covers `*.asv` and `*.autosave` but **has no `slprj/` rule**. That is a +genuine gap: `slprj/` is by far the more common MATLAB build artefact. Suggested addition: + +```gitignore +slprj/ +*.slxc +*.slx.r20* +``` + +`Old Simulations/Initial_Simulation_Framework.slx.autosave` (1 MB) is a MATLAB crash autosave. +It is correctly ignored by `*.autosave` and **untracked** — but still sitting in the working +tree. It is the only surviving trace of revision 1.2. + +## Related + +- [PEM Electrolyser and Fuel Cell Models](pem-electrolyser-and-fuel-cell-models.md) — vendor parameter sets +- [Rule-Based Controller Implementation](rule-based-controller-implementation.md) — `controller-claude.m` +- [PV + Battery Simulink Model](pv-battery-simulink.md) +- [PowerWorld Microgrid Model](powerworld-microgrid.md) +- [Existing EST Model](existing-est-model.md) — the vendored model, excluded here +- [`superseded/README.md`](../../superseded/README.md) — disposition of retired folders diff --git a/docs/05-business-economics/cost-analysis.md b/docs/05-business-economics/cost-analysis.md new file mode 100644 index 0000000..0422a9f --- /dev/null +++ b/docs/05-business-economics/cost-analysis.md @@ -0,0 +1,153 @@ +# Cost Analysis Excel File + +All\_parameters + +| index | Category | Parameter | Symbol | Units | Value | SourceType | SourceRef | WhyItMatters | Status | +| ---| ---| ---| ---| ---| ---| ---| ---| ---| --- | +| 35 | AI | Additional CO₂ savings vs rule-based | ΔCO2^(S2-S1) | kg/year | | ModelOutput | Emission factors + model | Shows climate benefit of AI beyond existing pilot. | Missing | +| 34 | AI | Additional gas savings vs rule-based | ΔV\_gas^(S2-S1) | m³/year | | ModelOutput | Thermal model + AI scheduling | Extra gas reduction thanks to smarter use of FC heat. | Missing | +| 31 | AI | Average effective electricity price paid for H₂ | p\_H2\_el^(S2) | €/kWh | | ModelOutput | Use hourly tariffs and AI schedule | Feeds into levelised cost of hydrogen. | Missing | +| 32 | AI | Cost of electricity from hydrogen (AI) | C\_H2^(S2) | €/kWh | | ModelOutput | From E\_el, η\_FC, p\_H2\_el | Compare vs peak grid price to see if H₂ is cheaper. | Missing | +| 30 | AI | Energy shifted from peak to off-peak | ΔE\_shift | MWh/year | ModelOutput | Simulation of net grid imports | Key quantity for calculating € savings from off-peak shifting. | Missing | +| 29 | AI | Increase in off-peak H₂ production vs S1 | Δβ\_off | percentage points | ModelOutput | Compare S2 vs S1 | Shows how much extra off-peak shifting AI achieves. | Missing | +| 33 | AI | Peak demand reduction (peak shaving) | ΔP\_peak | kW | | ModelOutput | Net load analysis | Reduced contracted capacity/peak charges → extra savings. | Missing | +| 28 | AI | Share of H₂ production done off-peak | β\_off^(S2) | % | | ModelOutput | RL/AI simulation with ToU tariffs | Core KPI for off-peak generation savings. | Missing | +| 10 | Demand | Annual electricity demand of hospital | E\_hosp | MWh/year | 1000 | Public | Rijnstate Elst hydrogen project description – 1,000 MWh/year consumption | Base load used to scale PV/H2 coverage and express % cost and CO₂ savings. | Confirmed | +| 14 | Demand | Baseline annual gas consumption | V\_gas\_0 | m³/year | | Internal | Gas utility bills | Baseline fossil gas use to compare against H₂-based heating and FC heat recovery. | Missing | +| 12 | Demand | Hourly load profile | L\_t | kW (time series) | Internal | SCADA / metering data | Essential to simulate operation of PV, H₂, battery and grid. | Missing | +| 11 | Demand | Peak electrical demand | P\_peak | kW | | Internal | Load curve / SCADA | Needed to quantify peak shaving from H₂ and batteries. | Missing | +| 13 | Demand | Share of critical loads | α\_crit | % of total load | Internal | Hospital engineering department | Used to quantify resilience and guaranteed power to ICUs etc. | Missing | +| 23 | Pilot | Annual gas savings (rule-based pilot) | ΔV\_gas^(S1) | m³/year | 42000 | Public | Rijnstate H₂ pilot article | Reference performance of current P2P system vs old baseline. | Confirmed | +| 24 | Pilot | CO₂ avoided (rule-based pilot, annualised) | ΔCO2^(S1) | kg/year | 133333 | Derived | 2,000,000 kg CO₂ over 15 years reported by PowiDian → ≈133,333 kg/year | Baseline CO₂ savings from rule-based system. | Derived | +| 47 | Pilot | Cumulative CO₂ avoided over 15 years (rule-based pilot) | m\_CO2\_avoid\_15y | kg CO₂ | 2000000 | Public | Rijnstate pilot figures – 2,000,000 kg CO₂ avoided over 15 years. | Headline climate impact metric for the existing system, used as baseline to compare AI gains. | Confirmed | +| 46 | Pilot | Cumulative gas savings over 15 years (rule-based pilot) | V\_gas\_save\_15y | m³ | 600000 | Public | Rijnstate pilot figures – approx. 600,000 m³ gas saved over 15 years. | Long-horizon view of gas savings; useful for NPV and business case. | Confirmed | +| 25 | Pilot | Energy self-sufficiency (rule-based) | SS^(S1) | % of annual demand | 60 | Public | Rijnstate hydrogen system articles – target up to 60% self-sufficiency | Indicates share of electricity demand covered by local PV+H₂+FC under rule-based control. | Confirmed | +| 27 | Pilot | Fuel cell power profile (rule-based) | P\_FC\_t^(S1) | kW | | Internal/Model | SCADA / H2B2-PowiDian control | Indicates when H₂ displaces grid power today. | Missing | +| 26 | Pilot | Hydrogen production profile (rule-based) | m\_H2\_t^(S1) | kg/hour | | Internal/Model | SCADA / H2B2 control logic | Used for comparison with AI-controlled operation. | Missing | +| 15 | Prices | Average electricity price | p\_el\_avg | €/kWh | 0,18 | Secondary | Anchored on NL non-household medium electricity prices ~0.15 €/kWh (Eurostat/TradingEconomics) plus network/taxes | For high-level cost savings estimation. | Estimated | +| 22 | Prices | Carbon price / shadow price | p\_CO2 | €/ton CO₂ | 70 | Secondary | EU ETS allowance prices in 2024–2025 mostly in €65–75/tCO₂ range; mid-value 70 €/t used | Optional: lets us monetise CO₂ reductions. | Estimated | +| 20 | Prices | Grid CO₂ emission factor | ε\_el | kg CO₂/kWh | 0,315 | Public | PowiDian Rijnstate case: Dutch grid emits on average 0.315 kg CO₂ per kWh consumed | Used to convert reduced grid imports into CO₂ savings. | Confirmed | +| 48 | Prices | Grid electricity CO₂ emission factor (Netherlands) | ε\_el | kg CO₂/kWh | 0,315 | Public | PowiDian case – Dutch grid emits on average 0.315 kg CO₂ per kWh. | Used to translate reduced grid imports into CO₂ savings. | Confirmed | +| 18 | Prices | Grid tariff reduction for off-peak | grid\_disc\_off | % | 65 | Secondary | TenneT flexible off-peak contracts can reduce grid tariffs by up to ~65% for large users | Impacts savings from shifting load away from congested periods. | Estimated | +| 21 | Prices | Natural gas CO₂ emission factor | ε\_gas | kg CO₂/m³ | 1,79 | Secondary | RVO NL "CO2 emission factors for fuels" list: 56.5 kg CO₂/GJ and 31.65 MJ/m³ → ≈1.79 kg CO₂/m³ | Used to quantify CO₂ savings from reduced gas usage. | Estimated | +| 19 | Prices | Natural gas price | p\_gas | €/m³ | 0,6 | Secondary | Based on NL non-household gas prices ~0.04–0.08 €/kWh (Eurostat/CEIC) and ~10 kWh per m³ → ~0.4–0.8 €/m³; mid-range 0.60 €/m³ used | Gas savings (€) = gas saved (m³) × p\_gas. | Estimated | +| 17 | Prices | Off-peak electricity price | p\_off | €/kWh | 0,14 | Secondary | Assumed ~20% below average NL non-household electricity price for valley hours | Used to value electricity used for off-peak hydrogen production. | Estimated | +| 16 | Prices | Peak electricity price | p\_peak | €/kWh | 0,22 | Secondary | Assumed ~20% above average NL non-household electricity price to represent peak ToU tariff | Used to value avoided grid imports at peak times. | Estimated | +| 8 | System | Battery energy capacity | E\_bat | kWh | 500 | Secondary | Order-of-magnitude assumption based on similar PV–H2 microgrid projects (hundreds of kWh Li-ion BESS) | Short-term storage for intra-day balancing and peak shaving. | Estimated | +| 9 | System | Battery round-trip efficiency | η\_bat | \- | 0,9 | Secondary | Li-ion stationary storage typically achieves 85–95% round-trip efficiency | Impacts whether AI should prefer battery vs hydrogen. | Estimated | +| 41 | System | Effective electrical energy per kg of stored H₂ | e\_H2,eff | kWh/kg H₂ | 33 | Derived | 6.6 MWh / 200 kg ≈ 33 kWh/kg usable electrical energy equivalent. | Helps approximate coverage time and compare with other storage technologies. | Approximate | +| 36 | System | Electrolyzer hydrogen production rate | Ṽ\_H2,el | Nm³ H₂ / h | 20 | Public | PowiDian / Rijnstate article – 20 Nm³/h electrolyzer | Links kW input to hydrogen flow; used to derive kWh/kg H₂ and cost per kg. | Confirmed | +| 37 | System | Electrolyzer hydrogen production rate (mass) | ṁ\_H2,el | kg H₂ / h | 1,8 | Derived | 20 Nm³/h × 0.0899 kg/Nm³ ≈ 1.8 kg/h | Used together with power to compute specific energy consumption and H₂ availability per hour. | Approximate | +| 2 | System | Electrolyzer rated power | P\_el | kW | 100 | Public | Rijnstate electrolyzer spec (H2B2) | Limits rate of converting cheap electricity into hydrogen. | Confirmed | +| 3 | System | Electrolyzer specific energy consumption | E\_el | kWh/kg H₂ | 55,6 | Derived | 100 kW electrolyzer / 1.8 kg H₂ per hour ≈ 55.6 kWh/kg | Determines cost and efficiency of converting electricity into hydrogen. | Approximate | +| 50 | System | Environmental classification of hydrogen installation | env\_class | \- | Milieuklasse 3 | Public | Rijnstate article – installation falls under environmental class 3 as closed system. | Indicates permitting complexity and replicability in similar zoning contexts. | Confirmed | +| 6 | System | Fuel cell electrical efficiency | η\_FC | \- | 0,6 | Secondary | Typical PEM fuel cell electrical efficiency for stationary 100 kW systems (~50–60%) | Used to compute kWh output from each kg of H₂. | Estimated | +| 42 | System | Fuel cell inlet hydrogen pressure | p\_FC\_in | bar | 8 | Public | Rijnstate description – pressure reduced from 30 bar to 8 bar for FC. | Relevant for modelling regulation valves, efficiency and safety. | Confirmed | +| 5 | System | Fuel cell rated power | P\_FC | kW | 100 | Public | Rijnstate fuel cell spec (PowiDian) | Maximum power that can be supplied from H₂ instead of grid. | Confirmed | +| 43 | System | Fuel cell waste heat temperature | T\_FC\_heat | °C | 80 | Public | Rijnstate article – fuel cell heat available at ~80°C. | Determines usefulness of waste heat for domestic hot water and space heating. | Confirmed | +| 44 | System | Hot water supply temperature from FC heat | T\_HW\_supply | °C | 50–60 | Public | Rijnstate description – heat exchanger cools to 50–60°C for building systems. | Indicates compatibility with hospital hot water and heating circuits. | Confirmed | +| 45 | System | Hydrogen pipeline diameter to fuel cell | D\_pipe | mm | 12 | Public | Rijnstate article – 12 mm hydrogen pipeline from tanks to FC. | Relevant for flow constraints and pressure drop in the hydrogen supply line. | Confirmed | +| 4 | System | Hydrogen storage capacity | M\_H2\_max | kg | 200 | Public | Rijnstate H₂ storage spec (PowiDian) | Defines how much off-peak energy can be buffered as hydrogen. | Confirmed | +| 39 | System | Hydrogen storage pressure | p\_store | bar | 30 | Public | Rijnstate H₂ storage at 30 bar | Determines storage density and safety classification; relevant for modelling compression losses. | Confirmed | +| 51 | System | Hydrogen system remote monitoring and leak detection | H2\_monitor | yes/no | Yes | Public | Rijnstate description – remote monitoring and H₂ leak sensors around installation. | Supports claims around safety, resilience and AI-enabled monitoring. | Confirmed | +| 49 | System | Number of hydrogen system containers | N\_containers | \- | 2 | Public | Rijnstate description – two containers: one for production, one for FC and power conversion. | Gives physical layout; relevant for replication at other hospitals (footprint). | Confirmed | +| 38 | System | Number of hydrogen tanks | N\_tanks | \- | 2 | Public | Rijnstate hydrogen system description – two 100 kg tanks | Clarifies modularity and possible expansion (space for a third tank). | Confirmed | +| 0 | System | PV area | A\_PV | m² | 2300 | Public | Rijnstate H2 P2P case | Used to estimate PV capacity and annual kWh production. | Confirmed | +| 1 | System | PV capacity (approx.) | P\_PV | kWp | 460 | Secondary | Estimated from 2,300 m² PV area × ~0.2 kWp/m² (typical crystalline PV specific power) | Needed to simulate PV generation profile. | Estimated | +| 7 | System | Recoverable heat fraction from FC | η\_heat | \- | 0,45 | Secondary | Typical CHP fuel cell installations recover ~40–50% of input as usable heat | If heat replaces gas boiler heat, adds extra gas savings. | Estimated | +| 40 | System | Usable stored hydrogen energy | E\_H2,store | MWh | 6,6 | Public | Rijnstate article – 200 kg at 30 bar corresponds to 6.6 MWh. | Quantifies how long the hospital can run on stored hydrogen at a given power. | Confirmed | + +Missing parameters + +| index | Category | Parameter | Symbol | Units | Value | SourceType | SourceRef | WhyItMatters | Status | +| ---| ---| ---| ---| ---| ---| ---| ---| ---| --- | +| 35 | AI | Additional CO₂ savings vs rule-based | ΔCO2^(S2-S1) | kg/year | | ModelOutput | Emission factors + model | Shows climate benefit of AI beyond existing pilot. | Missing | +| 34 | AI | Additional gas savings vs rule-based | ΔV\_gas^(S2-S1) | m³/year | | ModelOutput | Thermal model + AI scheduling | Extra gas reduction thanks to smarter use of FC heat. | Missing | +| 31 | AI | Average effective electricity price paid for H₂ | p\_H2\_el^(S2) | €/kWh | | ModelOutput | Use hourly tariffs and AI schedule | Feeds into levelised cost of hydrogen. | Missing | +| 32 | AI | Cost of electricity from hydrogen (AI) | C\_H2^(S2) | €/kWh | | ModelOutput | From E\_el, η\_FC, p\_H2\_el | Compare vs peak grid price to see if H₂ is cheaper. | Missing | +| 30 | AI | Energy shifted from peak to off-peak | ΔE\_shift | MWh/year | | ModelOutput | Simulation of net grid imports | Key quantity for calculating € savings from off-peak shifting. | Missing | +| 29 | AI | Increase in off-peak H₂ production vs S1 | Δβ\_off | percentage points | | ModelOutput | Compare S2 vs S1 | Shows how much extra off-peak shifting AI achieves. | Missing | +| 33 | AI | Peak demand reduction (peak shaving) | ΔP\_peak | kW | | ModelOutput | Net load analysis | Reduced contracted capacity/peak charges → extra savings. | Missing | +| 28 | AI | Share of H₂ production done off-peak | β\_off^(S2) | % | | ModelOutput | RL/AI simulation with ToU tariffs | Core KPI for off-peak generation savings. | Missing | +| 14 | Demand | Baseline annual gas consumption | V\_gas\_0 | m³/year | | Internal | Gas utility bills | Baseline fossil gas use to compare against H₂-based heating and FC heat recovery. | Missing | +| 12 | Demand | Hourly load profile | L\_t | kW (time series) | | Internal | SCADA / metering data | Essential to simulate operation of PV, H₂, battery and grid. | Missing | +| 11 | Demand | Peak electrical demand | P\_peak | kW | | Internal | Load curve / SCADA | Needed to quantify peak shaving from H₂ and batteries. | Missing | +| 13 | Demand | Share of critical loads | α\_crit | % of total load | | Internal | Hospital engineering department | Used to quantify resilience and guaranteed power to ICUs etc. | Missing | +| 27 | Pilot | Fuel cell power profile (rule-based) | P\_FC\_t^(S1) | kW | | Internal/Model | SCADA / H2B2-PowiDian control | Indicates when H₂ displaces grid power today. | Missing | +| 26 | Pilot | Hydrogen production profile (rule-based) | m\_H2\_t^(S1) | kg/hour | | Internal/Model | SCADA / H2B2 control logic | Used for comparison with AI-controlled operation. | Missing | + +Directly derrived values and secondary souced values + +| index | Category | Parameter | Symbol | Units | Value | SourceType | SourceRef | WhyItMatters | Status | +| ---| ---| ---| ---| ---| ---| ---| ---| ---| --- | +| 10 | Demand | Annual electricity demand of hospital | E\_hosp | MWh/year | 1000 | Public | Rijnstate Elst hydrogen project description – 1,000 MWh/year consumption | Base load used to scale PV/H2 coverage and express % cost and CO₂ savings. | Confirmed | +| 23 | Pilot | Annual gas savings (rule-based pilot) | ΔV\_gas^(S1) | m³/year | 42000 | Public | Rijnstate H₂ pilot article | Reference performance of current P2P system vs old baseline. | Confirmed | +| 24 | Pilot | CO₂ avoided (rule-based pilot, annualised) | ΔCO2^(S1) | kg/year | 133333 | Derived | 2,000,000 kg CO₂ over 15 years reported by PowiDian → ≈133,333 kg/year | Baseline CO₂ savings from rule-based system. | Derived | +| 47 | Pilot | Cumulative CO₂ avoided over 15 years (rule-based pilot) | m\_CO2\_avoid\_15y | kg CO₂ | 2000000 | Public | Rijnstate pilot figures – 2,000,000 kg CO₂ avoided over 15 years. | Headline climate impact metric for the existing system, used as baseline to compare AI gains. | Confirmed | +| 46 | Pilot | Cumulative gas savings over 15 years (rule-based pilot) | V\_gas\_save\_15y | m³ | 600000 | Public | Rijnstate pilot figures – approx. 600,000 m³ gas saved over 15 years. | Long-horizon view of gas savings; useful for NPV and business case. | Confirmed | +| 25 | Pilot | Energy self-sufficiency (rule-based) | SS^(S1) | % of annual demand | 60 | Public | Rijnstate hydrogen system articles – target up to 60% self-sufficiency | Indicates share of electricity demand covered by local PV+H₂+FC under rule-based control. | Confirmed | +| 20 | Prices | Grid CO₂ emission factor | ε\_el | kg CO₂/kWh | 0,315 | Public | PowiDian Rijnstate case: Dutch grid emits on average 0.315 kg CO₂ per kWh consumed | Used to convert reduced grid imports into CO₂ savings. | Confirmed | +| 48 | Prices | Grid electricity CO₂ emission factor (Netherlands) | ε\_el | kg CO₂/kWh | 0,315 | Public | PowiDian case – Dutch grid emits on average 0.315 kg CO₂ per kWh. | Used to translate reduced grid imports into CO₂ savings. | Confirmed | +| 41 | System | Effective electrical energy per kg of stored H₂ | e\_H2,eff | kWh/kg H₂ | 33 | Derived | 6.6 MWh / 200 kg ≈ 33 kWh/kg usable electrical energy equivalent. | Helps approximate coverage time and compare with other storage technologies. | Approximate | +| 36 | System | Electrolyzer hydrogen production rate | Ṽ\_H2,el | Nm³ H₂ / h | 20 | Public | PowiDian / Rijnstate article – 20 Nm³/h electrolyzer | Links kW input to hydrogen flow; used to derive kWh/kg H₂ and cost per kg. | Confirmed | +| 37 | System | Electrolyzer hydrogen production rate (mass) | ṁ\_H2,el | kg H₂ / h | 1,8 | Derived | 20 Nm³/h × 0.0899 kg/Nm³ ≈ 1.8 kg/h | Used together with power to compute specific energy consumption and H₂ availability per hour. | Approximate | +| 2 | System | Electrolyzer rated power | P\_el | kW | 100 | Public | Rijnstate electrolyzer spec (H2B2) | Limits rate of converting cheap electricity into hydrogen. | Confirmed | +| 3 | System | Electrolyzer specific energy consumption | E\_el | kWh/kg H₂ | 55,6 | Derived | 100 kW electrolyzer / 1.8 kg H₂ per hour ≈ 55.6 kWh/kg | Determines cost and efficiency of converting electricity into hydrogen. | Approximate | +| 50 | System | Environmental classification of hydrogen installation | env\_class | \- | Milieuklasse 3 | Public | Rijnstate article – installation falls under environmental class 3 as closed system. | Indicates permitting complexity and replicability in similar zoning contexts. | Confirmed | +| 42 | System | Fuel cell inlet hydrogen pressure | p\_FC\_in | bar | 8 | Public | Rijnstate description – pressure reduced from 30 bar to 8 bar for FC. | Relevant for modelling regulation valves, efficiency and safety. | Confirmed | +| 5 | System | Fuel cell rated power | P\_FC | kW | 100 | Public | Rijnstate fuel cell spec (PowiDian) | Maximum power that can be supplied from H₂ instead of grid. | Confirmed | +| 43 | System | Fuel cell waste heat temperature | T\_FC\_heat | °C | 80 | Public | Rijnstate article – fuel cell heat available at ~80°C. | Determines usefulness of waste heat for domestic hot water and space heating. | Confirmed | +| 44 | System | Hot water supply temperature from FC heat | T\_HW\_supply | °C | 50–60 | Public | Rijnstate description – heat exchanger cools to 50–60°C for building systems. | Indicates compatibility with hospital hot water and heating circuits. | Confirmed | +| 45 | System | Hydrogen pipeline diameter to fuel cell | D\_pipe | mm | 12 | Public | Rijnstate article – 12 mm hydrogen pipeline from tanks to FC. | Relevant for flow constraints and pressure drop in the hydrogen supply line. | Confirmed | +| 4 | System | Hydrogen storage capacity | M\_H2\_max | kg | 200 | Public | Rijnstate H₂ storage spec (PowiDian) | Defines how much off-peak energy can be buffered as hydrogen. | Confirmed | +| 39 | System | Hydrogen storage pressure | p\_store | bar | 30 | Public | Rijnstate H₂ storage at 30 bar | Determines storage density and safety classification; relevant for modelling compression losses. | Confirmed | +| 51 | System | Hydrogen system remote monitoring and leak detection | H2\_monitor | yes/no | Yes | Public | Rijnstate description – remote monitoring and H₂ leak sensors around installation. | Supports claims around safety, resilience and AI-enabled monitoring. | Confirmed | +| 49 | System | Number of hydrogen system containers | N\_containers | \- | 2 | Public | Rijnstate description – two containers: one for production, one for FC and power conversion. | Gives physical layout; relevant for replication at other hospitals (footprint). | Confirmed | +| 38 | System | Number of hydrogen tanks | N\_tanks | \- | 2 | Public | Rijnstate hydrogen system description – two 100 kg tanks | Clarifies modularity and possible expansion (space for a third tank). | Confirmed | +| 0 | System | PV area | A\_PV | m² | 2300 | Public | Rijnstate H2 P2P case | Used to estimate PV capacity and annual kWh production. | Confirmed | +| 40 | System | Usable stored hydrogen energy | E\_H2,store | MWh | 6,6 | Public | Rijnstate article – 200 kg at 30 bar corresponds to 6.6 MWh. | Quantifies how long the hospital can run on stored hydrogen at a given power. | Confirmed | +| 15 | Prices | Average electricity price | p\_el\_avg | €/kWh | 0,18 | Secondary | Anchored on NL non-household medium electricity prices ~0.15 €/kWh (Eurostat/TradingEconomics) plus network/taxes | For high-level cost savings estimation. | Estimated | +| 22 | Prices | Carbon price / shadow price | p\_CO2 | €/ton CO₂ | 70 | Secondary | EU ETS allowance prices in 2024–2025 mostly in €65–75/tCO₂ range; mid-value 70 €/t used | Optional: lets us monetise CO₂ reductions. | Estimated | +| 18 | Prices | Grid tariff reduction for off-peak | grid\_disc\_off | % | 65 | Secondary | TenneT flexible off-peak contracts can reduce grid tariffs by up to ~65% for large users | Impacts savings from shifting load away from congested periods. | Estimated | +| 21 | Prices | Natural gas CO₂ emission factor | ε\_gas | kg CO₂/m³ | 1,79 | Secondary | RVO NL "CO2 emission factors for fuels" list: 56.5 kg CO₂/GJ and 31.65 MJ/m³ → ≈1.79 kg CO₂/m³ | Used to quantify CO₂ savings from reduced gas usage. | Estimated | +| 19 | Prices | Natural gas price | p\_gas | €/m³ | 0,6 | Secondary | Based on NL non-household gas prices ~0.04–0.08 €/kWh (Eurostat/CEIC) and ~10 kWh per m³ → ~0.4–0.8 €/m³; mid-range 0.60 €/m³ used | Gas savings (€) = gas saved (m³) × p\_gas. | Estimated | +| 17 | Prices | Off-peak electricity price | p\_off | €/kWh | 0,14 | Secondary | Assumed ~20% below average NL non-household electricity price for valley hours | Used to value electricity used for off-peak hydrogen production. | Estimated | +| 16 | Prices | Peak electricity price | p\_peak | €/kWh | 0,22 | Secondary | Assumed ~20% above average NL non-household electricity price to represent peak ToU tariff | Used to value avoided grid imports at peak times. | Estimated | +| 8 | System | Battery energy capacity | E\_bat | kWh | 500 | Secondary | Order-of-magnitude assumption based on similar PV–H2 microgrid projects (hundreds of kWh Li-ion BESS) | Short-term storage for intra-day balancing and peak shaving. | Estimated | +| 9 | System | Battery round-trip efficiency | η\_bat | \- | 0,9 | Secondary | Li-ion stationary storage typically achieves 85–95% round-trip efficiency | Impacts whether AI should prefer battery vs hydrogen. | Estimated | +| 6 | System | Fuel cell electrical efficiency | η\_FC | \- | 0,6 | Secondary | Typical PEM fuel cell electrical efficiency for stationary 100 kW systems (~50–60%) | Used to compute kWh output from each kg of H₂. | Estimated | +| 1 | System | PV capacity (approx.) | P\_PV | kWp | 460 | Secondary | Estimated from 2,300 m² PV area × ~0.2 kWp/m² (typical crystalline PV specific power) | Needed to simulate PV generation profile. | Estimated | +| 7 | System | Recoverable heat fraction from FC | η\_heat | \- | 0,45 | Secondary | Typical CHP fuel cell installations recover ~40–50% of input as usable heat | If heat replaces gas boiler heat, adds extra gas savings. | Estimated | +| 52 | Cost\_savings | Annual gas bill savings (rule-based pilot vs baseline) | C\_gas\_save^(S1) | €/year | 25200 | Derived | ΔV\_gas^(S1) \* p\_gas | Monetises the pilot’s gas savings baseline, used to benchmark AI gains. | Derived | +| 53 | Cost\_savings | Annual CO₂ value (rule-based pilot vs baseline) | C\_CO2\_save^(S1) | €/year | 9333,31 | Derived | ΔCO2^(S1) / 1000 \* p\_CO2 | Values the rule-based CO₂ reductions using a CO₂ price. | Derived | +| 54 | AI\_scenario | Additional annual gas savings enabled by AI vs rule-based | ΔV\_gas^(S2-S1) | m³/year | | Scenario | To be set based on AI controller simulations. | Captures extra gas savings potential relative to the current pilot. | To be filled (AI scenario) | +| 55 | Cost\_savings | Annual gas bill savings (AI-optimised, total vs baseline) | C\_gas\_save^(S2) | €/year | 25200 | Derived | Uses rule-based gas savings plus additional AI gas savings times gas price. | Shows total gas bill reduction when AI is deployed. | Derived | +| 56 | Cost\_savings | Additional annual gas bill savings from AI vs rule-based | ΔC\_gas\_save^(S2-S1) | €/year | 0 | Derived | C\_gas\_save^(S2) - C\_gas\_save^(S1) | Explicitly quantifies the incremental euro savings from AI on the gas bill. | Derived | +| 57 | AI\_scenario | Additional CO₂ avoided by AI vs rule-based | ΔCO2^(S2-S1) | kg/year | | Scenario | To be set based on AI controller simulations. | Captures extra CO₂ savings potential relative to the current pilot. | To be filled (AI scenario) | +| 58 | Cost\_savings | Annual CO₂ value (AI-optimised, total vs baseline) | C\_CO2\_save^(S2) | €/year | 9333,31 | Derived | Uses rule-based CO₂ savings plus additional AI CO₂ savings times CO₂ price. | Shows total CO₂-related value when AI is deployed. | Derived | +| 59 | Cost\_savings | Additional annual CO₂ value from AI vs rule-based | ΔC\_CO2\_save^(S2-S1) | €/year | 0 | Derived | C\_CO2\_save^(S2) - C\_CO2\_save^(S1) | Shows extra monetised CO₂ savings due to AI. | Derived | +| 60 | AI\_scenario | Energy shifted from peak to off-peak by AI (vs rule-based) | ΔE\_shift | MWh/year | | Scenario | To be set based on AI controller simulations. | Quantifies how much load AI moves from expensive to cheap hours. | To be filled (AI scenario) | +| 61 | Cost\_savings | Annual energy price savings from peak→off-peak shifting (AI vs rule-based) | C\_shift | €/year | 0 | Derived | ΔE\_shift \* 1000 \* (p\_peak - p\_off) | Values the benefit of buying more electricity off-peak instead of at peak prices. | Derived | +| 62 | AI\_scenario | Reduction in grid peak demand enabled by AI vs rule-based | ΔP\_peak | kW | | Scenario | To be set based on AI controller simulations. | Captures reduction in contracted/measured peak load due to AI scheduling. | To be filled (AI scenario) | +| 63 | Prices | Grid capacity tariff (indicative, adjust to contract) | p\_cap | €/kW/year | 100 | Secondary | Indicative Dutch-style capacity tariff; replace with hospital-specific value. | Allows monetisation of ΔP\_peak as annual euro savings. | Estimated | +| 64 | Cost\_savings | Annual capacity tariff savings from AI vs rule-based | C\_cap\_save | €/year | 0 | Derived | ΔP\_peak \* p\_cap | Values the benefit of reducing grid peak demand through AI scheduling. | Derived | + +Cost Savings (Needs the missing values to show valuable info) + +| Metric | Symbol | Units | Baseline S0 (no H₂) | Rule-based S1 (pilot) | AI-optimised S2 | Δ S1–S0 | Δ S2–S1 | +| ---| ---| ---| ---| ---| ---| ---| --- | +| Annual gas savings vs baseline | ΔV\_gas | m³/year | 0 | 42000 | 42000 | 42000 | 0 | +| Gas bill savings vs baseline | C\_gas\_save | €/year | 0 | 25200 | 25200 | 25200 | 0 | +| CO₂ avoided vs baseline | ΔCO2 | kg/year | 0 | 133333 | 133333 | 133333 | 0 | +| CO₂ value vs baseline | C\_CO2\_save | €/year | 0 | 9333,31 | 9333,31 | 9333,31 | 0 | +| Energy price savings from peak→off-peak shifting | C\_shift | €/year | 0 | 0 | 0 | 0 | 0 | +| Capacity tariff savings | C\_cap\_save | €/year | 0 | 0 | 0 | 0 | 0 | +| Total annual impact (gas + CO₂ value + shifting + capacity) | C\_total | €/year | 0 | 167866,31 | 167866,31 | 0 | 0 | + +AI scenario + +| C\_shift^(S2-S1) \[€/year\] | C\_cap\_save^(S2-S1) \[€/year\] | ΔC\_tot^(S2-S1) \[€/year\] | C\_tot^(S1-S0) \[€/year\] | C\_tot^(S2-S0) \[€/year\] | +| ---| ---| ---| ---| --- | +| 4000 | 5000 | 10523,13 | 167866,31 | 178389,44 | +| 8000 | 10000 | 21046,26 | 167866,31 | 188912,57 | +| 16000 | 15000 | 35569,39 | 167866,31 | 203435,7 | \ No newline at end of file diff --git a/docs/05-business-economics/social-cost-benefit-analysis.md b/docs/05-business-economics/social-cost-benefit-analysis.md new file mode 100644 index 0000000..f4b358e --- /dev/null +++ b/docs/05-business-economics/social-cost-benefit-analysis.md @@ -0,0 +1,86 @@ +# Social Cost-Benefit Analysis + +A robust SCBA addresses several fundamental questions: +* **What is the purpose of the proposed intervention?** Clarifying the objective helps set the stage for a targeted analysis. +* **What are the available alternatives?** This relates to the concept of _opportunity cost_, whereby resources used for one project could have been allocated to another. An analysis of alternatives includes the _base case_ or _zero alternative_: what happens if no intervention is made. +* **Who are the stakeholders?** Identifying all relevant stakeholders is crucial, as the distribution of benefits and costs may vary significantly among groups. Excluding stakeholders can lead to biased or incomplete analyses. +* **What are the costs and benefits over time?** All future costs and benefits must be discounted to their present value to allow meaningful comparison (see next module). This includes both direct financial effects and indirect or social impacts, such as improved air quality or reduced travel time. +* **What are the present values of these costs and benefits?** Discounting future impacts to present value is essential for comparing long-term projects fairly. +* **What is the net present value (NPV) of each alternative?** The NPV helps determine whether the benefits exceed the costs over the life of the project (see next module). +* **What recommendations can be derived from the analysis?** This includes determining whether the intervention creates a net social benefit and whether it is preferable to other alternatives. +# 3.3 Using Excel for Discounting +While the above process can be completed manually, spreadsheet software such as Microsoft Excel provides built-in functions to streamline the calculation. This becomes especially useful when analyzing long-term projects, some of which may span 50 years or more, where manual calculations would be impractical and error-prone. +We will illustrate the use of Excel for computing the NPV with the following example: +Imagine a small wind farm is going to be constructed. An initial investment of 10 million euros is needed. After the construction period, it will be operated for 15 years. The income from electricity production is 3 million euros per year. Assume that the discount rate is 5 percent. What is the NPV? +To compute the NPV: +1. Enter all costs and benefits into a spreadsheet, organized by year. +2. Apply the discount factor for each year using the formula 1\\(1+r)t +3. Multiply each year’s net benefit (benefit – cost) by its corresponding discount factor to obtain the present value. +4. Sum all present values to obtain the total NPV. +You can also use the NPV() command, i.e., = NPV(discount rate, series of Benefit/Cost that require discounting). The NPV() function automates the discounting of future values, though it assumes the initial investment occurs at the beginning of the time horizon and may need to be adjusted depending on project structure. +**Steps to Calculate NPV in Excel** +1. _Set Up Your Data Table_ +Create a spreadsheet like this: + +| A | B | C | +| ---| ---| --- | +| Year | Benefits | Costs | +| 0 | | 10.000.000 | +| 1 | 3.000.000 | | +| 2 | 3.000.000 | | +| ... | ... | | +| 15 | 3.000.000 | | + +Note: Row 3 will be Year 0, Row 4 Year 1, and so on. +1. _Use the NPV Function in Excel_ +In Excel, the formula to calculate NPV is: +\=NPV(discount\_rate, value1, \[value2\], ...) +Note: the NPV function assumes cash flows start in period 1, so the initial investment in period 0 must be added separately. +**In our case:** +* Discount rate is in cell G3 \*\*\*\*(5%) +* Cash flows from years 1 to 15 are in cells B3:B17 +* Initial investment is in cell C2 \*\*\*\*(10.000.000) +Then, the full Excel formula is: +\=NPV(G3, B3:B17) - C2 +This will return the Net Present Value of the project: €21.138.974,11 (see Figure 3.1). +_Figure 3.1 Calculation of NPV in Excel_ +_Explanation_ +* NPV(G3, B3:B17) calculates the present value of the future income (€3 million per year for 15 years). +* C2 subtracts the initial investment (€–10 million in Year 0). +* Since Year 0's cash flow is not discounted, it must be added separately to the result of NPV(). +To get the column for PV (D) you put the formula for PV in Year 1 in cell D3: +\= B3 / (1 + $G$3)^A3 +$G$3 locks the discount rate cell so it doesn’t shift as you drag the formula down. A3 and B3 reference the year and cash flow dynamically. To drag down the formula you click on the cell (D3) with the formula. This will highlight the cell and show a small square in the bottom-right corner (called the "fill handle"). Hover over the bottom-right corner of the cell (the small square). Your cursor will change to a small black cross (✛). Click and drag down the fill handle as far as needed (i.e., down to row 17 for 15 years). Excel will copy the formula, automatically updating relative references (like A2 → A3, A4, etc.). +In this example, the project results in a positive NPV, indicating it is financially viable under the given assumptions. +**Costs** +* **CAPEX**: €2.5M (PV, electrolyzer, storage, fuel cell, battery). +* **OPEX**: €150k/year (maintenance, replacements, AI operation). +* **Training costs**: Staff to manage AI system. +**Benefits** +* **Financial**: Gas savings (€50k/year), electricity cost reductions (€100k/year), potential grid participation revenue (€50k/year). +* **Environmental**: 2 million kg CO₂ avoided over 15 years. +* **Social**: Improved healthcare reliability, job creation, innovation leadership. +* **Resilience**: Island-mode operation during outages → critical in healthcare. + +| Category | Description | Estimated Benefit (€ / Qualitative) | +| ---| ---| --- | +| AI Model Development (RL & ML) | Develop and train intelligent algorithms to optimize hospital energy use | Reduces overall energy costs by ~10–15% annually (~€5,000 savings/year) | +| Data Acquisition & Integration | Collect and clean hospital or synthetic data for model training | Improved decision-making accuracy; forms dataset for future expansion | +| Software Infrastructure & Tools | Cloud computing and simulation environments | Enables scalable AI testing at low ongoing cost | +| Workshops & Training | Training staff or students to understand and use the AI tools | Builds in-house knowledge and reduces dependency on external support | +| Program Coordination & Management | Planning, communication, and reporting | Ensures project delivery on time and within scope | +| Public Relations & Outreach | Materials to communicate project impact | Enhances hospital image, potential for green funding or publicity value (~€2,000) | +| Testing & Validation | System testing in a simulated or limited real setting | Validates feasibility, increasing future funding chances (~€5,000+ potential grants) | +| Contingency & Maintenance | Minor software updates and troubleshooting | Extends system usability and ensures long-term reliability | + +**RISKS** + +| Risk | Description | Mitigation / Solution | +| ---| ---| --- | +| System Reliability | Failures in AI control, hydrogen storage, or power conversion could disrupt hospital energy supply. | Use redundant AI controllers and backup systems (battery or diesel). Implement real-time monitoring, predictive maintenance, and fail-safe protocols. | +| Data Quality & Availability | Incomplete or poor-quality hospital energy data reduces AI accuracy and decision reliability. | Establish continuous data validation, standardized data collection, and backup data storage. Use synthetic or historical datasets to train and test models. | +| Regulatory & Safety Compliance | Strict EU and Dutch regulations on hydrogen safety and AI autonomy in healthcare. | Engage early with regulatory bodies, follow ISO and IEC hydrogen standards, and obtain required certifications. Conduct regular safety audits and staff training. | +| Environmental & Resource Risks | High water use for electrolysis or unsustainable material sourcing. | Implement water recycling for electrolysis, prioritize certified green materials, and monitor life-cycle environmental impact. | + +# Untitled + diff --git a/docs/06-data/dataset-inventory.md b/docs/06-data/dataset-inventory.md new file mode 100644 index 0000000..7cded1d --- /dev/null +++ b/docs/06-data/dataset-inventory.md @@ -0,0 +1,234 @@ +# Dataset Inventory + +> **Markdown report of the repository's data files.** +> +> | | | +> |---|---| +> | **Scope** | Every `.csv`, `.csv.gz`, `.parquet` and `.xlsx` data file in the repository | +> | **Total data volume** | **≈ 194 MB** — the great majority of the repository's size | +> | **Status** | Current inventory | +> | **Report generated** | 2026-07-25 | + +Data files carry no README of their own, so this page records what each one contains, where it +came from, and how it relates to the others. + +## Summary + +| File | Size | Rows | Source | Role | +|---|---:|---:|---|---| +| `2019-1338340-one_axis.csv` | **167.9 MB** | 8,762 | NREL NSRDB | Satellite meteorology, Boston 2019 | +| `MA_hourly_load.csv` | 13.7 MB | 35,040 | NREL ComStock | ⚠️ **CSV twin of the parquet below** | +| `hospital_communication_energy_system.csv` | 3.2 MB | 10,000 | Synthetic | Building + patient environment mock-up | +| `89993-0.parquet` | 2.4 MB | 35,040 | NREL ComStock | Hospital load profile (BIDMC proxy) | +| `chartevents.csv.gz` | 5.3 MB | 668,862 | MIMIC-IV Demo | ICU vital signs | +| `inputevents.csv.gz` | 0.75 MB | 20,404 | MIMIC-IV Demo | ICU infusions | +| `patients.csv.gz` | small | 100 | MIMIC-IV Demo | Patient demographics | +| `pvwatts_hourly.csv` | 0.58 MB | 8,760 | NREL PVWatts | PV performance, Boston | +| `Profiles SHIFT(...).xlsx` ×2 | 16 kB each | 24 | SHIFT | Generation profiles (identical copies) | +| `Profiles SHIFT(...).csv` | 9 kB | 24 | SHIFT | CSV export of the above | +| `Team03_demand.csv` ×2 | 0.65 MB each | — | EST model (vendored) | Demand example (identical copies) | +| `Team03_supply.csv` ×2 | 0.65 MB each | — | EST model (vendored) | Supply example (identical copies) | + +All the Boston-area datasets converge on the same coordinates — **latitude 42.33, longitude +−71.10** — which is BIDMC's location at 330 Brookline Avenue, Boston MA 02215. + +--- + +## Hospital load + +### `89993-0.parquet` — 2.4 MB + +NREL ComStock simulated hospital load profile, building ID 89993, Massachusetts Climate Zone 5A. +15-minute resolution, 35,040 rows covering 2018. Fully documented in +[BIDMC ComStock Load Profile](../03-energy-management/bidmc-parquet-load-data-manual.md). + +### `MA_hourly_load.csv` — 13.7 MB ⚠️ + +> [!WARNING] +> **This is the same dataset as `89993-0.parquet`, stored as CSV.** Verified: +> +> | Property | `MA_hourly_load.csv` | `89993-0.parquet` | +> |---|---|---| +> | `bldg_id` | 89993 | 89993 | +> | Columns | 64 | 64 | +> | Data rows | 35,040 | 35,040 | +> | First timestamp | `01/01/2018 00:15` | 2018-01-01 00:15 | +> | Last timestamp | `01/01/2019 00:00` | 2019-01-01 00:00 | +> +> The CSV is **5.8× larger** than the parquet for identical content. The filename +> (`MA_hourly_load`) is also misleading — the data is at **15-minute**, not hourly, resolution. + +Keeping the parquet and dropping the CSV would save **13.7 MB** with no information loss. +Left in place for now because some team tooling may read the CSV directly — but nothing in the +repository does, and this is the single easiest size win available. + +### `hospital_communication_energy_system.csv` — 3.2 MB + +10,000 rows, 25 columns, 5-minute intervals from 2025-01-01 to 2025-02-04. **Synthetic.** Each +row is a single patient-room snapshot combining vitals, room climate, and subsystem power. +Schema documented in [BIDMC Datasets Manual §4](../03-energy-management/bidmc-datasets-manual.md). + +--- + +## Clinical data — MIMIC-IV Demo + +| File | Rows | Columns | +|---|---:|---:| +| `patients.csv.gz` | 100 | 6 | +| `chartevents.csv.gz` | 668,862 | 11 | +| `inputevents.csv.gz` | 20,404 | 26 | + +> [!IMPORTANT] +> **Provenance and licence.** These are the **MIMIC-IV Clinical Database Demo**, not full +> MIMIC-IV and not BIDMC's own records. Three lines of evidence: +> +> 1. `patients.csv.gz` contains exactly **100 patients** — the demo's size. +> 2. The [Digital Twin Readiness Checklist](../03-energy-management/bidmc-digital-twin-readiness-checklist.md) +> links directly to `physionet.org/content/mimic-iv-demo/2.2/icu/inputevents.csv.gz`. +> 3. Column names, `itemid` codes, and the ~100-year date shift are MIMIC-IV's de-identification +> scheme. +> +> The demo is published under the **Open Data Commons Open Database License (ODbL) v1.0** and, +> unlike full MIMIC-IV, does **not** require credentialed PhysioNet access. Redistribution here +> is therefore permissible — but ODbL requires **attribution and share-alike**, and neither the +> licence nor the citation is recorded anywhere in this repository. +> +> **Recommended:** add a `SOURCE.md` beside these three files with the PhysioNet DOI, version +> (2.2), and the ODbL notice. Small fix, closes a real obligation. + +All dates are shifted forward ~100 years for de-identification; only lengths of stay are +meaningful. See [BIDMC Datasets Manual](../03-energy-management/bidmc-datasets-manual.md) for +full column references. + +--- + +## Solar and meteorological data + +### `pvwatts_hourly.csv` — 0.58 MB + +NREL **PVWatts** hourly PV performance simulation. 8,760 rows (one year, hourly). + +| Header field | Value | +|---|---| +| Requested location | 330 Brookline Avenue, Boston, Massachusetts 02215, United States | +| Solar resource data | NSRDB Lat/Lng 42.33, −71.10 | +| **DC system size** | **4 kW** | +| Module type | Standard | +| Array type | Fixed (open rack) | +| Array tilt | 20° | +| Array azimuth | 180° | +| System losses | 14.08% | +| DC-to-AC size ratio | 1.2 | +| Inverter efficiency | 96% | +| Albedo | From weather file | +| Bifacial | No | + +> [!WARNING] +> **The simulated array is 4 kW — a residential system.** The project specifies **2,300 m²** +> of panels (≈ 460 kW peak at 20% efficiency), and the +> [forecasting spec](../02-specifications/forecasting-requirements.md#11-inputs) assumes tilt +> **35°** and system size **~100 kWp**. Three different array configurations are in circulation: +> +> | Source | System size | Tilt | +> |---|---|---| +> | This dataset | 4 kW | 20° | +> | Forecasting Requirements | ~100 kWp | 35° | +> | Simulator I/O Interface | 2,300 m² ≈ 460 kW | — | +> +> The **shape** of the generation profile is reusable — it scales linearly with array size at +> fixed tilt — but the tilt difference (20° vs 35°) changes the seasonal profile, and the +> absolute values are 100× too small. Rerunning PVWatts at the specified configuration would +> take minutes and remove the ambiguity. + +Documented in [PV Hourly Dataset Manual](../03-energy-management/pv-hourly-dataset-manual.md). + +### `2019-1338340-one_axis.csv` — 167.9 MB + +NREL **NSRDB** satellite meteorological data, location ID 1338340, latitude 42.33, longitude +−71.1, elevation 14 m, time zone −5. Version 3.2.2. 8,762 rows (2019, hourly). + +Column groups: clear-sky DHI/DNI/GHI, measured DHI/DNI/GHI, dew point, temperature, pressure, +relative humidity, precipitable water, wind direction and speed, solar zenith and azimuth, +surface albedo, panel tilt and azimuth, spectral data, plus cloud-type and fill-flag +categoricals and per-technology performance columns (Si, GaAs, InGaP, CdTe). + +**This single file is 87% of the repository's data volume and roughly 12× the next largest +file.** It covers one year, one location, hourly — 8,762 rows. The bulk is column count, not +row count, and most of those columns (the per-technology performance series) are unused: SHIFT +models a single array with a scalar efficiency `mu_PV`. + +Extracting the ~15 columns the forecasting stack actually needs — GHI, DNI, DHI, their clear-sky +counterparts, temperature, humidity, wind speed, pressure, precipitable water, solar zenith and +azimuth — would reduce it by well over an order of magnitude while losing nothing the project +uses. + +Documented in [Satellite PV Dataset Manual](../03-energy-management/satellite-pv-dataset-manual.md). + +--- + +## SHIFT-generated profiles + +| File | Location | Note | +|---|---|---| +| `Profiles SHIFT(Generators Factors + Battery).xlsx` | `Simulations/Current Framework/` | MD5 `cb529138` | +| `Profiles SHIFT(Generators Factors + Battery).xlsx` | `Simulations/PV+Battery Simulink/` | MD5 `cb529138` — **identical** | +| `Profiles SHIFT(Generators Factors + Battery).csv` | `Simulations/PowerWorld/New Powerworld/` | Semicolon-delimited, comma-decimal export of sheet 1 | + +Both `.xlsx` copies are retained: `PVBatteryRead.mlx` opens the workbook by **bare filename**, +so MATLAB resolves it from the working directory and the copy beside the script is load-bearing. + +Contents documented in [Generation Profiles Workbook](../04-simulations/generation-profiles-workbook.md). + +--- + +## Vendored data (EST model) + +| File | Size | Copies | +|---|---:|---| +| `Team03_demand.csv` | 0.65 MB | `EST-model-main/` and `EST-model-main/data/` — byte-identical | +| `Team03_supply.csv` | 0.65 MB | `EST-model-main/` and `EST-model-main/data/` — byte-identical | + +~1.3 MB duplicated, but **inside the vendored MIT-licensed subtree**. Left untouched — see +[Existing EST Model](../04-simulations/existing-est-model.md). + +--- + +## Size analysis + +| Category | Size | Share | +|---|---:|---:| +| Satellite meteorology (1 file) | 167.9 MB | 87% | +| Hospital load — CSV twin | 13.7 MB | 7% | +| Clinical (MIMIC-IV demo, 3 files) | 6.1 MB | 3% | +| Synthetic building energy | 3.2 MB | 2% | +| Hospital load — parquet | 2.4 MB | 1% | +| PV performance | 0.6 MB | <1% | +| Vendored EST data | 2.6 MB | 1% | +| SHIFT profiles | 41 kB | <1% | + +**Two changes would remove ~150 MB** without losing anything the project uses: + +1. Column-subset `2019-1338340-one_axis.csv` to the ~15 forecasting features (~−160 MB). +2. Drop `MA_hourly_load.csv`, keeping the identical `89993-0.parquet` (−13.7 MB). + +Neither is applied here — pruning datasets is a data-team decision, not a documentation one. +Both are recorded so the choice is available. + +## Gaps + +| Gap | Detail | +|---|---| +| **No measured hospital load** | Every load figure traces to NREL ComStock simulation or synthetic generation. The [forecasting spec](../02-specifications/forecasting-requirements.md#21-inputs) flags this as the project's biggest data risk, and it is unresolved | +| **No electricity price series** | `price(t)` is a required simulator input ([§2.1](../02-specifications/simulator-io-interface.md#21-exogenous-time-series)) and the price forecaster needs ENTSO-E data. Nothing here | +| **No carbon intensity series** | `CO2_int(t)` likewise | +| **No hydrogen system data** | No electrolyser, fuel cell, or H₂ tank measurements anywhere | +| **Geographic split** | All datasets are **Boston** (BIDMC). The price forecaster targets the **Dutch** market, and the placeholder irradiance in the profiles workbook is **Eindhoven**. The two case studies have not been reconciled | +| **No licence/citation files** | MIMIC-IV demo (ODbL), NREL ComStock, NSRDB and PVWatts all have attribution expectations; none are recorded | + +## Related + +- [BIDMC Datasets Manual](../03-energy-management/bidmc-datasets-manual.md) +- [BIDMC ComStock Load Profile](../03-energy-management/bidmc-parquet-load-data-manual.md) +- [PV Hourly Dataset Manual](../03-energy-management/pv-hourly-dataset-manual.md) · [Satellite PV Dataset Manual](../03-energy-management/satellite-pv-dataset-manual.md) +- [Generation Profiles Workbook](../04-simulations/generation-profiles-workbook.md) +- [Forecasting Requirements](../02-specifications/forecasting-requirements.md) diff --git a/docs/07-team-and-operations/interview-questions.md b/docs/07-team-and-operations/interview-questions.md new file mode 100644 index 0000000..6192bff --- /dev/null +++ b/docs/07-team-and-operations/interview-questions.md @@ -0,0 +1,29 @@ +# Interview Questions + +1. Can you briefly introduce yourself and your academic background - name, age, study, year of study, previous education, etc. +2. What attracted you to Team SHIFT and this project specifically? +3. What do you hope to gain from joining the team? +4. What does your course load look like/How many hours per week can you realistically commit? +5. Are you planning any exchanges, internships, or heavy semesters that may affect your availability? +6. What motivates you more: technical challenges, real-world impact, teamwork, or something else? +## **A. For Technical Cluster Candidates:** +**Questions:** +1. What technical skills do you feel most confident in? (Python, ML, control, simulations, electronics, energy systems…) +2. Have you worked with machine learning, reinforcement learning, or control systems before? +3. How comfortable are you with learning new tools on your own? +4. Do you prefer theoretical modelling, coding, hands-on engineering tasks, or data analysis? +* Explain how you would design a simple forecasting model for solar energy or energy demand. +* Explain what an energy management system is in your own words. +## **B. For Business & Economics Candidates:** +**Questions:** +1. Have you worked with business modelling, financial analysis, or market research before? +2. What interests you about the hydrogen and AI–energy sector? +3. How would you estimate the economic value of an AI-based energy management system for a hospital? +4. How comfortable are you with presenting findings to technical team members? +## **C. For PR & Communications Candidates:** +**Questions:** +1. What experience do you have in PR, branding, or social media management? +2. What would you improve about our current communication or website? +3. Are you confident producing content (graphics, articles, videos, LinkedIn posts)? +4. Mention that they will have a lot of control and creative freedom in PR and designing things +Then say thank you for your time, do you have any questions for us, etc. \ No newline at end of file diff --git a/docs/07-team-and-operations/team-design.md b/docs/07-team-and-operations/team-design.md new file mode 100644 index 0000000..1334e95 --- /dev/null +++ b/docs/07-team-and-operations/team-design.md @@ -0,0 +1,15 @@ +# Team Design + +**Polo & Sweatshirt** +Color - Navy Blue +Left side - TU/e and  Eindhoven University of Technology on the side of TU/e (not under) +Right side - The logo +Back - Team SHIFT writing with logo or just SHIFT logo + +Logo: SHIFT but “I” can be the green energy symbol (like lightning) + +![](https://t90151962997.p.clickup-attachments.com/t90151962997/44b6e9b3-2f74-496a-aac6-4c4bffbb0350/image.png) ![](https://t90151962997.p.clickup-attachments.com/t90151962997/18114963-afe4-49d7-92e9-636de41610d1/image.png) + +**Business Card** + +![](https://t90151962997.p.clickup-attachments.com/t90151962997/7bc1e87c-7253-4c87-abc4-ec583ce1b6ae/image.png) \ No newline at end of file diff --git a/docs/README.md b/docs/README.md new file mode 100644 index 0000000..9005b38 --- /dev/null +++ b/docs/README.md @@ -0,0 +1,181 @@ +# SHIFT Documentation + +Every current document in the project, in markdown, in one place. + +Documents that arrived as Word, PDF, Excel, or MATLAB Live Script have a **markdown report** +here — readable in the browser, diffable in git, searchable with `grep`. The originals are kept +alongside (root-level ones in [`_originals/`](_originals/), the rest in place under +`Shift Matlab Drive/`); each report links back to its source and records the file's MD5. + +Outdated material lives in [`../superseded/`](../superseded/README.md), with the reason for +each retirement. + +--- + +## Start here + +| If you want to… | Read | +|---|---| +| Understand what SHIFT is building | [Project Explanation](01-project/project-explanation.md) | +| Know what the simulator must accept and return | [Simulator I/O Interface](02-specifications/simulator-io-interface.md) | +| Know what the RL agent sees, does, and is scored on | [State](02-specifications/rl-state-variables.md) · [Action](02-specifications/rl-action-variables.md) · [Reward](02-specifications/rl-reward-function.md) | +| Find which Simulink model is the live one | [Simulink Model Inventory](04-simulations/simulink-model-inventory.md) | +| Know what data exists and where it came from | [Dataset Inventory](06-data/dataset-inventory.md) | +| See what is unresolved | [Open questions across the project](#open-questions-across-the-project) | + +--- + +## 01 · Project + +| Document | What it covers | +|---|---| +| [Project Explanation](01-project/project-explanation.md) | Vision, mission, values, the five departments, benchmarking against Tibo/Zympler and the H2B2–PowiDian Rijnstate pilot, business case and routes to market | +| [Work Packages](01-project/work-packages.md) | WP1–WP7: literature review, forecasting, simulation, RL control, evaluation, extensions, reporting | +| [AI Efficiency Improvements](01-project/ai-efficiency-improvements.md) | Where the losses are — ~30–40% electrolyser, ~40% fuel cell — and the scheduling changes that attack them | +| [Reference Links](01-project/reference-links.md) | Four external sources: two IEEE/ScienceDirect papers, a review, and the H2B2–PowiDian announcement | + +> [!NOTE] +> [Work Packages](01-project/work-packages.md) WP6 describes *"a basic crop growth/CO₂ +> enrichment module"*, *"greenhouse-to-grid interactions"*, and *"scalability tests for multiple +> greenhouses"*. SHIFT builds a **hospital** microgrid. WP6 is a leftover from an earlier +> greenhouse concept and does not describe current scope. It is kept rather than retired +> because WP1–WP5 and WP7 are current and still the project's work breakdown — but WP6 needs +> rewriting, not reading. + +## 02 · Specifications + +The contract layer. These define what gets built. + +| Document | Source | Status | +|---|---|---| +| [Simulator I/O Interface](02-specifications/simulator-io-interface.md) | PDF, 10 pp | **Draft v0.1** — 8 open questions | +| [RL State Variables](02-specifications/rl-state-variables.md) | Word | 32 variables, no units | +| [RL Action Variables](02-specifications/rl-action-variables.md) | Word | 16 actions; 9 have no simulator counterpart | +| [RL Reward Function](02-specifications/rl-reward-function.md) | Word | 26 terms, **no weights** | +| [Forecasting Requirements](02-specifications/forecasting-requirements.md) | PDF, 10 pp | Complete; PV, demand, and price forecasters | +| [Rule-Based Controller](02-specifications/rule-based-controller.md) | markdown | The baseline policy RL must beat | + +> [!WARNING] +> **The specification set is not internally consistent.** Two naming conventions are in use — +> the Simulator I/O sheet says `SoC(t)`, `P_PV`, `u_ele`; the RL documents say `Battery_SOC`, +> `PV_Generation`, `Electrolyzer_PowerSetpoint` — and neither references the other. The action +> spaces disagree in size (5 vs 16), and five reward terms need quantities the simulator does +> not return. Each report documents its own mismatches; resolving them is a decision, not an +> edit. + +## 03 · Energy Management + +Case-study data and equipment for the two reference sites: **BIDMC** (Beth Israel Deaconess +Medical Center, Boston) and **UCSD** (UC San Diego). + +| Document | What it covers | +|---|---| +| [BIDMC/UCSD Energy Flow and Balances](03-energy-management/bidmc-ucsd-energy-flow-and-balances.md) | Four-level dispatch priority, three-tier load model, energy balance equations, four KPI formulae | +| [UCSD Equipment Manual](03-energy-management/ucsd-equipment-manual.md) | DFC3000 fuel cell, BYD battery, 30 MW CHP, planned PEM electrolyser — each parameter tagged State / Action / Reward | +| [BIDMC Datasets Manual](03-energy-management/bidmc-datasets-manual.md) | Full column reference for the three MIMIC-IV demo clinical files and the synthetic building-energy CSV | +| [BIDMC ComStock Load Profile](03-energy-management/bidmc-parquet-load-data-manual.md) | The hospital load proxy: 8,026 MWh/yr electricity, 15-min resolution, full end-use breakdown | +| [BIDMC Digital Twin Readiness Checklist](03-energy-management/bidmc-digital-twin-readiness-checklist.md) | 8-section readiness gate. **Sections 1–3 scored; 4–8 blank** | +| [PV Hourly Dataset Manual](03-energy-management/pv-hourly-dataset-manual.md) | The recommended PV dataset | +| [Satellite PV Dataset Manual](03-energy-management/satellite-pv-dataset-manual.md) | The 167.9 MB NSRDB meteorological dataset — detailed, but not recommended for PV rates | + +## 04 · Simulations + +| Document | What it covers | +|---|---| +| [Simulink Model Inventory](04-simulations/simulink-model-inventory.md) | Every `.slx`, with **real lineage** from Simulink's internal revision metadata. Identifies the current model | +| [Rule-Based Controller Implementation](04-simulations/rule-based-controller-implementation.md) | `controller-claude.m` — the dispatch cascade in MATLAB, and why it does not yet run | +| [PEM Electrolyser and Fuel Cell Models](04-simulations/pem-electrolyser-and-fuel-cell-models.md) | The MathWorks Simscape packages and their full parameter sets | +| [PV + Battery Simulink Model](04-simulations/pv-battery-simulink.md) | The Excel→Simulink vertical slice, and its known time-dependency bug | +| [MATLAB Live Scripts](04-simulations/matlab-live-scripts.md) | All five `.mlx` files transcribed | +| [Generation Profiles Workbook](04-simulations/generation-profiles-workbook.md) | Both sheets of the profiles spreadsheet, plus the PowerWorld results analysis | +| [PowerWorld Microgrid Model](04-simulations/powerworld-microgrid.md) | The campus-scale network study | +| [Shift Input Data](04-simulations/shift-input-data.md) | The per-component variable list the simulator contract grew from | +| [Existing EST Model](04-simulations/existing-est-model.md) | The vendored MIT-licensed TU/e model, and SHIFT's gravity-storage experiments on top | + +## 05 · Business & Economics + +| Document | What it covers | +|---|---| +| [Cost Analysis](05-business-economics/cost-analysis.md) | A 48-row parameter register — value, source, why it matters, and a **Confirmed / Estimated / Derived / Missing** status per row. The most rigorous single artefact in the project | +| [Social Cost-Benefit Analysis](05-business-economics/social-cost-benefit-analysis.md) | SCBA methodology: the questions a robust analysis must answer, discounting, NPV in Excel | + +> The SCBA document is **methodology, not a SHIFT analysis** — it is course material on how to +> run an SCBA, worked through a generic wind-farm example. The SHIFT-specific analysis has not +> been written yet. The parameter register in [Cost Analysis](05-business-economics/cost-analysis.md) +> is what would feed it. + +## 06 · Data + +| Document | What it covers | +|---|---| +| [Dataset Inventory](06-data/dataset-inventory.md) | Every data file: size, rows, provenance, licence obligations, and the redundancies | + +## 07 · Team & Operations + +| Document | What it covers | +|---|---| +| [Interview Questions](07-team-and-operations/interview-questions.md) | The recruitment question template — general, technical, business, PR | +| [Team Design](07-team-and-operations/team-design.md) | Polo/sweatshirt and business card design, logo concept | + +--- + +## Open questions across the project + +Collected from the individual reports. Each links to where it is documented in full. + +### Blocking + +| Question | Where | +|---|---| +| **Timestep**: hourly or sub-hourly? Affects RL compute cost, battery fast-response fidelity, and every energy/power conversion | [Simulator I/O §0](02-specifications/simulator-io-interface.md#timestep) | +| **Reward weights**: 26 terms, no relative magnitudes beyond "critical load dominates" | [RL Reward](02-specifications/rl-reward-function.md#open-issues-with-this-reward-design) | +| **Naming convention**: two incompatible variable vocabularies across the spec set | [RL State](02-specifications/rl-state-variables.md#naming-mismatch-with-the-simulator-io-contract) | +| **Critical / non-critical load split**: can the hospital profile actually be split, or is a proxy fraction needed? | [Simulator I/O §5](02-specifications/simulator-io-interface.md#5-open-questions) | +| **PEM models are still at vendor defaults** — the "10× bigger" sizing TODO was never done, and the fuel cell still runs an automotive drive cycle | [PEM Models](04-simulations/pem-electrolyser-and-fuel-cell-models.md#the-unfinished-sizing-work) | +| **The dispatch controller does not compile** — undefined variables, outputs unassigned on several paths | [Controller Implementation](04-simulations/rule-based-controller-implementation.md#blocking-defects) | +| **Readiness checklist §4 (Safety) is unscored** — the document's own rule makes any FAIL here a deployment blocker | [Readiness Checklist](03-energy-management/bidmc-digital-twin-readiness-checklist.md#4-operational-constraints--safety--the-boundary) | + +### Data + +| Question | Where | +|---|---| +| **No measured hospital load** — every figure is simulated or synthetic | [Dataset Inventory](06-data/dataset-inventory.md#gaps) | +| **No price or carbon-intensity series** — both are required simulator inputs | [Dataset Inventory](06-data/dataset-inventory.md#gaps) | +| **PV array configuration is inconsistent** — 4 kW / 100 kWp / 460 kW across three documents | [Dataset Inventory](06-data/dataset-inventory.md#pvwatts_hourlycsv--058-mb) | +| **Boston or Netherlands?** — all datasets are Boston; the price forecaster targets the Dutch market | [Dataset Inventory](06-data/dataset-inventory.md#gaps) | +| **Licence and citation files missing** for MIMIC-IV demo (ODbL), ComStock, NSRDB, PVWatts | [Dataset Inventory](06-data/dataset-inventory.md#clinical-data--mimic-iv-demo) | + +### Modelling + +| Question | Where | +|---|---| +| Tank model — isothermal + ideal gas, or full pressure/temperature dynamics? | [Simulator I/O §5](02-specifications/simulator-io-interface.md#5-open-questions) | +| Battery degradation — modelled or ignored? | [Simulator I/O §5](02-specifications/simulator-io-interface.md#5-open-questions) | +| Should simultaneous electrolyser + fuel cell operation be structurally forbidden, or merely penalised? | [Simulator I/O §5](02-specifications/simulator-io-interface.md#5-open-questions) | +| Two-tier or three-tier load model? The specs and the energy-flow doc disagree | [Energy Flow](03-energy-management/bidmc-ucsd-energy-flow-and-balances.md#notes-on-scope) | +| Is the clinical/patient layer in scope at all? | [BIDMC Datasets](03-energy-management/bidmc-datasets-manual.md#how-this-fits-the-wider-project) | +| Was `chal`'s `_CLEAR_CONNECTIONS` cleanup (rev 2.6) ever merged into rev 2.7? | [Simulink Inventory](04-simulations/simulink-model-inventory.md#findings) | + +--- + +## Conventions used in these reports + +Every report generated from a non-markdown source opens with a provenance block: + +| Field | Meaning | +|---|---| +| **Source** | Repo-relative path to the original file | +| **Format** | File type and size | +| **MD5** | Checksum at the time of writing — lets you tell whether the original has changed since | +| **Status** | Current, superseded, or draft | +| **Report generated** | The date this markdown was produced | + +Where machine extraction was lossy — PDF tables that interleave columns, Word equations, images +— the report says so explicitly and points back to the original. Reconstructed tables are +labelled as reconstructed. Author asides and first-person notes from the sources are preserved +as quotes rather than smoothed away, because they usually mark exactly the parts that are +uncertain. + +Observations that go beyond the source — inconsistencies between documents, unit errors, +scale mismatches — are marked with callouts and attributed to this audit, not to the original +author. diff --git a/docs/_originals/ACTION VARIABLES AND DESCRIPTIONS.docx b/docs/_originals/ACTION VARIABLES AND DESCRIPTIONS.docx new file mode 100644 index 0000000000000000000000000000000000000000..c18fb218f790dbe2dd216cb7a48e81cd849d6bf5 GIT binary patch literal 16223 zcmeIZbyOwEvNyVMZ`^4d8g1O&-QC^Yp>cP2cXxMpcZbGl+^wO3$IQLwn>l^vy|>o) z@4dCx&Q-f2e^I-#A|oO*B4i~%Kv4kT07w7;KmeeRwNWt!0ssoZ003kFB(R2njkTkZ zwWE%ro2`+9)>l_6OZ+@gV6q$l@JIjuJ^lxeKtsZ~c|R?J&|~16|7_EWcpF*az-V5y z5w__wP#B}M;5~nS$6MDPD_tQm9pmT_{`7|XG$ft>>{^;76k?+b$tgNll5f1W84Km= z@;nB$cxClJS63Sr^=QjAZv=UT91H}3EnuS3XZi=c7O;vfcVyjQK&t-E+>YnFl zdC5MaF4j`B$`v!#)7}aF)MqG!Ms1cYZyJ_$c$Z^*D**?RX{Zk7lNw2cemy! z-4h&q6l0korM}|^4NI8_p-TY9t+!PijdX?B1-2+|{K~|q=-Nm3eB~dEwmvC$$12OD zardjYe4TM9B_OLF?S{cTACmR{4g!$Q^(%O(t+mdAMO86 z%m2Z1@o$e_5!d@MEn#^t{a^iOJLT4TG4iEp3})6bRv{oY#3Yf|SIn2+UO87*fVGbG zM8@al<7d7(WC%NLCum(^B`Lv$bwVxu)b7`K>2L)k26hzExh~o6!loZS7{87YiII=_ zhpVB6O=E$_K82)A_8=cn2tFJX!|`(CFtpm-ABLLX^PeouvENlQbL5vyMTjdj&Ad-5&6yLd1( zkP0dnDwO8M!&nnZ{q0BCAtn#=C4pLl&W;Ush8ExLhmrcv`9Y=V@hAla0JJgy0Ei!h z;$mZONMmSY;AHh-!~QT{XX)$K>#SJAm*^`l_#TVE&inPBn@4++GR=H&BZ%iaVNFBh zLS*xj3eH+o{M`aQ``zMRxy5gCFC0-^YObg>a}tF@z2z68w|o`1-tKT<>I}slQZ*OV z(I>I=Lce%s1*kOY;96t#W6cJUa--7gsWdXpH)dD8|BP-fkEQ9PG7crck3E{DxUVvg zr8^$6Ye26}ISEg37dOXDfsq-Cf(5>yGa*U5Y)G#xdQGG_rmM{5N+y*kvk1(1)RdZ3 zaRf`0t2uQ=R0`sec=X=@gCRr~R4iK1$(v zsQ*4%!5ohQE=u79hXO8IfxU;E8&tE1$~W9sk&el>jQ>l~3AqF|eujKMx~6SC_@r@n zLN2Epd!C4_MLvSdFLX-S4Ao~z$6xY7+Kcpw5n<1fQl4keWYs!2%uFdIOH_<5$2BHI z4dka~6b8vE*=Rw7QEB-pK6VMAQLb&ZpRQ}oZRse4lD4pYjHt$5l+DU_6<>(vnJ0Dn zm21Qw!(GtBJAQ1bSTa#|NF}T+l*|RbGLL5s@Lo0T*lM6g%8<`+BOJL`HV?o1!9nEkhpTolbZPD%9-Pvb4b=mmcx+M(aK!rT7kX0sTVf9rAx2&9Y*tE=<3!e~$zkPREWj<-# zzKj*Uo}SnGEWDEd#)y1)HRe$~@}OUJm2=~tBL>OxmAq#xZfN+C>Bn=Wf~Iqmi+BC` z=gdHZcc(@!FBK;y`elR1origm8#fOZj;xOC&G_qK^3pymh1m;nMT^7CijpdvrM%wnc?J^gU{ew45Saw8Qm~~82yvyD66omPC0&7A6ZOJI zCJIssgpt}3Xoratf~oYzhM1jz(PqO#Viv0NgY>-)>FRR8DXIxT{FCm5z-+KPNq5M=E7xhN`}=I-a1)v7p4Bbij!WF?)tY3maD zW@?ahGLN_G)?M69x*mQ$145sVWtk4b+=8}GfMx-q!MNcaVD)tXqL_lQ9UqC4&>mJq4Xv002puEche83ng3UVIjx4PF8-QUp{6RF~-0> zdJ%4ABzxyJ`DK11WozwRO9Ct>K2%cOE>KNH0HOMeIRA=Z&Yo@n!T<~Lt{!MJ>esK= zC~0(3-(TO>ZH!hLN9+mfF}@DS^T8l|3$*at!FC<(!}3GC%_;*dXHKm7AI@-rJi={D zkAL$Nw~BzfcK}J^OObNwDy~&sh5`#qvVT5%;fcr0{HdUK)h$)aF`}APdt6@PMo;q#d9DkhT0VE~xb99(t)Q%QP#QmiNM+&jDAXDbLeGj3 zBy4--d?BuavY}E=#n;DdYXqD@AI4()H|iP>s^S*=pL*0ifzrx^KzNG0)VJn$w2k-y z_Szbmsj3Wv)n9$x=Udr=mB3_q{KdRGBI#gwRuhBfjI4HDH<~0xa||u@_?jC+GX*bZ zd&I9XmZ5JB{CV|f8nk{5yb6JMvq0^=erbm0?tE}PYML5{a(|l0lEKQ(+?WpH69P_A zsMlJX5Xh+PTn##PUX17CB_^gnVz8LLqN$gO%0&bD)x*^16q3&?V*QyMg$f@X7XPrU zX=$d*jIU(jGJ{~8z#YE+;hI~Y+l$`W{>^%fGb+1DtqMb3zKpfQA-)v!3dV=jNJ@$@ zenRSciMwM)pwlI8Bu#-w0+tDz13`+0+^=KM4o9l=l((|! zTmNcY71C=HK(`BXypyNRDwMRuE$EnxZ5w*JhCmaYS{nF-I{%#yreiL&bmfOyJ7k`= zbF))R=SX^zr1Sp7DTR_Rqr9r=-9uw<+my93*UM2u0|zwPMRrrG4@A&wQ#-(nUnbB( zjDXkCQ6D9nVbJkCrnL8H^Se%h&F5Td*G{!xb@(8S2&S>(`Pa$PFJR$EapTBP9^srE zTWAc4q}uI^Sr1=LSox-q;n5EZ^l>G-hjrw$u^w_fL0)fFyOKeJ2)3rjELCn_ zB{f_9DY%n( zD@_i+aFq>?;cj@Qyn}7}0xNN1o2zLh8Mo-DWD=SA$B@6a^K(<20(bLks<+Xx<@@yH zz4t%*UiDq!pTRyTO&|aO4geD9Pv7gm7ASxB!2Y#Z0s7cO_~`vV`>2SY{9_Fra2eR; zzv52KVI=?+>p95jZ%`nm-t8$QjuZ?&?;pjWZ_*XG`0ch5l_Tf2lL@$v z7%Zr$&dEj{2ygIV2Q1}_nR#gi9}v;EmHkJTQx?UzzL?AB-uf8*4xcDfRlAGwPmOn> zpJxJ+huEpfMVD{*l(XxEx_|dM`A;U``87VS=aqcxe(dxgSIfZ_;^dMl>a6lMOK|nFS2DVM; zHfA2a!imqV4T4rHgBo5<^LGt{x(+;e$&SxR`GVkezkY-F@$UcAg`ZJ!j-!GA0N@A# z0Mw5je~OW#sgact&7UpZpKiRmMl?1PikHYPkLqofv9W!1TAn8Pxpn*6CffCpVFo5k z*7b<9GYh|H3Foz60B8tAjO!i{K@2bObzgMpLfCk8&x0iC-hcr4W*+pp@Y>T&=HB!V z9K38v`@P8U6d#5G)*`X3>#EjIyrUW5tWYmguk&V=r+}}zNWA>W3oc6`95x#suZ`GO zZ6UG|J_#~UPAe{i1aqhN?AhabBh|AgB=**PYOsN4bv3xOu3ztm3NG5M+i?XlSn+*p z72R!WdmKQe6UBcV3jYik@ebWK*Ogugm5+pliiAtb`nG4mO$eL8H|Mg?4#dSHgx&`P zYESUxIja0U<9QPMosQZxaA%P3a!$qS_kNZy{!u)1S6C>B8B~w6=hDsVQ?p=(e52Hq9n043nRcJH@=gkm z#`clrP%Y>@L{}Ao8ys?bpb$<`sJAtD!Ao;+BIsnGG&%4Cp$_aZwde1{lbcvO zqIAXBvD0ol2?imq*!oM4IGPKUi$UFPZl|O1UZ0+3WukeWwy*Oqdw@O>>BY8##n(_h z4lm=q|2%lve#Gl~-iwzxchw%^d41?F?*8@cauUdQT7Q}S_VgM*&GUSoE<<$%iyb{G8?z&N?88ii8La}XcT}H^tcb{7 ztyT`NfH36s6?lYANaeHOL@g;0=_Z~?HK8yxF#A&yVj*M&nd81#Ftfl;1>QM^K!U{s z?5yKkhnK)NIb;v1%h%yY*_mS{w+rFi0OZs}!;WlWx*6(hd&Cq5Te}jNc?dXidL(?4 z$a&9m@U*3lk024SE<7)mTghf4xcKJAgO(z|a<`mSqrimeH$dT$C>**gSfBfqOamT( z_(8M!0R*=1)Yw@?L6gk|HX`)p8~n`c8$reuWnO+Q6^V*=26j}3!XsHZG0InLnwP{` zOp^K|WsF-|X#@lWi+geQ8d%SpD)4PXXbqw8fBo! zd9S*Oy&sIH>1xoWDPF4u(J7cJ6(?z5ltQ&`F2a;U+g9l=!0cDD57?*H_tjQnR6(75 z@5(D>pH^|2Q2OkkG`u3D&HuTcTI&uZXVL(-lBCMxu)ZfCBZP?$LKB@!GwW5C0>ViI z1~ocmPL%of09JD(#~MUx!eU>)Ce(On$e}cUl>#<(BH4~rmH38hs7uT}B zIT@xx0Lr>uvr@!3p_F0%`P2iVX|DDo|7(hq0PiR_eCV7$X=qTOpb5hhEYdfV!;*Z$$Mu0g5(>L zNQJZ!`vBLUx=gsIus*r+CtDd++<~q86oLVHr+g zkpwda>9;|<*ny~eu!RF9NcBo{=tI}Q@lTcn8DLLa(CA3tjMUuG``W0Q$q~>8$1u4a zRAZU!B}z5xO@w}~M)%GhT5M8fp3F*xbs^{u+HScmTfwCfbu*Q_H#3MX*dB5ZgKYG0**l^cqrq8!X-xr6rp)GZLU;R4S z;t?$uReu|>cn0xS#E$HAt~`!jZ?rC^D~bH|u!1)t`915?cZZ%-aQFUeS9YtPjSr%` zX%{(4*s$37>g^nu&k8nkIPFLo9J_?my{**Da&EUY|7czrI8{KTK>>gU*uU+NIT$%Q znpvAT{9#%fRJLr^nGwA3YTkQiZgJG=443&c`)c<{gf>1o1#u}58X*!0`F`w=^}juS zCZCN<&k51E8_c^Hb{XCq=J@#hGubHC$ zfS}mn_gJ#a{`<@BP9EYgQ#fOD079X-EAu0CW%14f*4Ikg`k(B20gk0((C z;d2^}-&Z@{&l%wkFQFG1KEAzy`Ev-}OcCEn-_Sp$ejFhmS6_gZw62(&w6((Y8tQ7K zok5Xi{#)Q;<^JmKIML_-{ zp{!@WDoU+ENlEL~=bG_i?P_NITkvkyd4a)$3Q{=J!fftiW0{D%3w1{G2JkEj$??~g zo{=#;|v z)i`w#LH1|73E5c)y#X1tff*Sb$JAKM@9Sr$+U$ zs#5ilD&%{H8+&kQ56xPnv8G8UoqKXDQ`r<>FT`!|9P}eI^uNbh8;NplM-C%hE6Ovj zq>x`?hbwY#&dePv09S_HF|D&ZjqTLPkwsx>2)JeT6%8RvDm4GK|gdGFKNxI>Oyzaz<|9d1C1(!p^M#SU)f4A7 zZRSmqkaNxXrr@4dZ-Sq2@}SM^Kd@M;-oK)S+i|8#2VLviaYXbTTe>1wn)IvHKz}(U z%cv9{e_xY0d9&7hhyN$vUJ?_-`S@db_yrvRK>C+&Z|!8IZ)E?We*Vxt6UpNr`|~J4 zk028qkZWHWzIH)5g%t>aW5R|3OVL@V=UEYSKoTE}Q@zmNLV8wo@xznLHSI0M98fhN zl4Ln>qWRo3bpRWZxd)?=l8R~d0<(88h9E6(l$`7g;Ku{&ub}8iXC5G_ z{3WLa8M2O@0IogO>)IjTy5K5-@j^IES}fkWAbw{+8lr^^5@L^EG>FM#j6`3xD`61M z2d3iIP1>Ook zV?qb9s%y+irGzvaG$C>5xbc-iBElNfreWhXN!MzCE>`&P(8f&J?&KF<9qFB$3c?Qqi_+4{4o1q7da2?3mnQ-&CA2o?AROrB zq{%@xh(z=ZBRn+)HX3r0wovb&$ca=hkC*QY@0o4t;%JTT*J^7XydiCl+%uphu_(Z8 zb~tO@0`9{Z>F+EVW6*e%6Uh%4xRDtyQprx&WG%|VPKk%K^4(`EnzGp6;Qerw_HlYJ z)pQZ6#uQ(F&|AdSY8t+uH#+*}nyv`xQEDUKdNwBP!Ue$YK4ru$Z3vCQ=OwVke*aR( zHgoHA-k29;Lvs>s^WN=Sp*M4MN2ylX8eZ}4*W9XJ1|k=IT9wFnQdtmhF7%RFFti~f zw$~*Njg%R`koH1;TvHu4G`pHP`p0=mb=)TilV&oDi{gU4@8ay-?ObXOJS3TSN^^1^ z&hB-GU7}%87nqHzS)OSU!E9w~?vind4@m};U*c(TgXe4He;sA*syjs5fmDv2blE>5 z|C3_i7zY@^BLDzDivWNR&GBE0eg{W4OQS!1k~6J!`*mR?&#kgoh=eR>Je*K;xjG7Q z@woFw3nP)*{mEMdjIa=19~hsc#Oke9Ae=fn{BJY*D9cIZR7kqnm=nkIDb|{Y!`a=` zaod#B;j9wV@ZdZ+pFug{>dB-pr{TLcI^CVVA)t^*5G5Is^YFOt4)#v-yuRA-aA%<& zDD;K%0tyCK2|0OEk`Hdqu4*8Ec=U$h)se^yPN^l)sFHUbJ_f@i@l+&L_gU5&8gWL( zw|KDQ;C`0+1S|O+j3j+>H>P{EZ_%%~u#RWKjS!)}A!T?xkKg^w?;+)2mVTOF8)Y{K zJ#y{l#toBuI%eV5@j9@D_WBri_?4ivyuz=SXIyHhNf*VnaBEgtNQCzwjx^ zaK}G#)Xv{o6NH%bs|`ekS9d$ zMNE`stdGTGNLfs6r240nbyu3r$#gpvb@=vm1gaj+R_I%pFnX=&`>T-p0E9lgiIAJz zK!x28O)t|8WVFJ@pY&0?{sODJAkzx9FOc@#U?biv z;Fj%Q(oYWJ0&7oD(i1fW8+-RfAMits5I$#RDC=-n6DM0L85bdf<-9M|1pCk-o(Uec zFCwa*9n@RwSa7yc4@TXBEGDfy9rR1#nzV-0{eY;}NsnyyKg-OeSO=$EZaHqsvr&_@H|!LzY>y$SE)!ur_1`MLA;iiMdsh{U*|tw4&VW2cjtnQS zcx(0bJI=-;OLy3Sb1NyZjEw)W{&d)$#SXNC&Ti52Is^+)6_`K-l@ zqKdcQ4hZX#J{On2fwcJwlT=|vi)u6B#`c(Zydk}i6^+{aJ!Fw)w`xg^3(ry%NauAL zjf%^dzLZBMzH(Vo`?%O?$BgD+CiVF9j2>4M#1r0By03N{SX8{#two6!Y%;`vb|#=} zn)O}16q8H~sXxqMA8REMuM$NcA=r#_&UYD0c$JVH6aQ=uKgd9>9ZO`!Z_7R@Z>RB# zwp@Mju|`5G{>X{)Y}B7uSslHs6d2B2+hluA89D@AgJ*L{7=W5(`E z5Vw67dSpryGA00hMnTFtYFa==$d5EX!5S$xl?#2j^~)@+mNSp9eYCX;uW(;5q}j4| zA^sDvRcOl-*)DvqrRdIU@Ih?_j9lnR6zBv6Hd^`dCFdF53AYiDn9)(PQt3&wd0BbI z@%FO}GV@1+h?2g0hyR+qt;@3gjCTf(v)HRmQbDHwgGAAWv#h`JswBGE`^My|j(FUp zJir=2$yOUl~4|E$l=rv6mji=j(&E9(h}Z5OxQ>H-hIPLNF?AZN0-}EVk)bv zh(ksz5B$89Yv6m|Ej0{$>RlZLPLu|$s;lTF{O$Qm+n9l`+|N|t{2K-^;R6%sh_Pv5 z8({AAP%+v~@*%&18#b7@3&Hp#kJ<_QBpyV*E~zIjBC;6shIG#K(Jy*+idzFx0CI~3 zs2xL%e!19R*x7MTQu=Za;W>n3am3>x<`$>OQFR*~E>_8@-;fGi&_7V7btu z+!O7f;lie>+g*^|{fboh^*7R5J-3Znq$ajitJW+M8`Uhwh5)N9=LSXg%^J)3e(WS3 zM)p3j^!Ej}tp1TA5n&r- z7;LR_?5AUJv!pfCzbvSx&r)(q*UB%m0CqZ3c^pDhIx4AE>o%IUCvURL5Oj9pFu07n z5p6mxYa#R(c4s)&8wiC;C=BV6 z8Qd?5rk6yDA-f-6KQxMf|APFh&$p@b%tLMdKr+)@e#iz{0#Nl5^R5+v|34T%WP+@3 zYqBf>w0a2wFtsA2FIt(`!i>)U4X#b~|KfhLhuMcng{RCfKwT%t9R}Smg_QH9(+~L@ z%nKzPii?yi%8w?9U+d2ZOg*k_3vME<@vj*}8I3u^?~2CNg-8$m*}P~&O@4g11QtuGCK9yXKT(t$=;+nD8NwIgb1 zCD|{79+t(>5_2GOG@6c_Nfc%Q4wLx;o2ANvlBUO!fVU`XtXlROcp}^*4~N)M0#5s; zC_rXYM({zQrPVJDg8ZQR*JJmFn*;V_m;!E!u=szI#+1K49tQnoSFWOkXw3^VWD++drQ4 z|Bd{CWs=*x4LA$9F8(-gl#d)w+W3PH=?5QqwhEuc_;fn zkbe^Y{2S4I#H6lZ3+H|ZM!b(*Esqr`$rbP8P~8P=G(!iAG^-Y=Df&N4Ep8vGUjuro z(VOL|B~w|;boNbsh7^A44+Ndh5tN-PF{n5sopxHNRC*Z2<78X+QM*yooo}v5MCL<>`>!S~^XWI^Y-_fQ-27Gd51GSIA$J>~1`MwvcZ&EMc%} z_)0(QWus;&ec@rzH2R8tI$@<+wVWECPIKyX$X|NXrgJ&;1^EE`WS9at1CO@w{odG3 zAq>#wQH;1WKBt79er|Mp$86EdiuVJPJ##olXpgi1(^P#@;oD{qS@vq@M4KDOW_cLw zR;qjC#LVhNVe`FXb?kiS#5peG1=F+iMmd&!u=}}vo@dM0%)|yW+KA%%x3;mBV~WE! zTr3sLZd(<$My^8Wml=fwk0UOUrFWg<@AvoVS-5s*caRQSXptf~-gvmViZ?g8w#uNkUa{fw72;;r@MEkGyYalXG*!{7gY z+D-Pph`>|4dyEM`s9QhNk+LZ#!T>|HXagxfPHFYxXMjoy5naRz9^&BAkZ`b`Bwco6 zZ80dL;**)RxY{^ome-1k$6YX2k6Wm*z!lj=2S@Utb4~nnw8n>t=NmBhMh750S8L& zn$7OW-D78($thig3XmyfPzy&7m5nmZHPreIxubU{dB(!Fg5x|#QNhxk;#0Gu7n2s5 zQl!zEDvCA?Ttqrc=-fNlcQwrJN#$&Ff;eie6^B|TQvLA-LY+?P9qhuee_-A{atjK$%Oc38IJ)Tag{4 zmqnaU9x-H+gw3pq8mGxtnHyaxnrsuZp#`SR8 z>ezU&l3{bc+W1}g%NUb?r1qRjWKwx+=AMypl2tBVo#P}~#9xP;bv0ExR>C*d$zXD}&vQz7fjZTC>n^I>r z$Qesx)&3ip5~et{Aukg2^M#lW6bss(o zVEcu{Jvhj{kex}wfJqH4d6P<_i3`wIN&;LAr0FEXQ?j_|YT%;qY3BCeibdz5QM{{{ zJ(ToIzMeP|Elwa~dWMH*6?inUT^4393f9Od5RTf{i_1eN<^E@o4tVc2VzMElv>yd` zU1MZU9iWpN2$ZyXb-d-N@LKJ;X{+Z|ShfqOxAxSDcM$B-^O$Cs?%{qy1Z{P#KsfsE~a`~UhtOzUL ze9U-sJ-{Yd&t5R2EBOSBmt*s?88|rP9W&lh=Ya;Q(CNHb7ZKA_zSm}4<(&;@PK69< z9;%IMx{;%mWwRcK48s(~*tC=0tv4KFavr$`rI}P?`zKW@#q?E5_6>?-v3m9Y94La) z+lm;rGV|vj#6Mdj?9i#`Sh#^uHqEA5`a~7kFG*gpwWZA;tj&2d_|GAyP20z1laGRh z`;Wxz|Fi3B{83k=sHbmf^vAC6MxsRY8ZE-`W#aSayp3c|*Ze@G_IA zm+Avh$zdX@*SfjtB5+f2d$nv$+E-G6VpQvr9&=JvP@BksHt5Fj$|Otf7*<6RquETd z#|?B?k8zY4iBaj;^_~-m@42EZVK~4D{a`CT6Pu4T9D9Bmq4gE4%-JTvF>BW_<*=%o zGaUoe7?V?E5o>1Bj^=>HWnjUvH*--HO^xK!a)x%23}Vurfs1PRAR4_`M~F>^(AJIa zsIg2P4eY4--@1=70#=KV3D5CvZT(?vYVhmTX5n1U~q>0gk^OsG< z6q)4gCBpN)C172c6cu`wS!;cjA~K$#DP{b;MU%4{8jHM-bF&y)?}#Iro+e6=a!3YX zl41R-Ezv!0Q*{&u&NJjTL`cA&q-L=+RR(yDr%~O8GUk6A+*FJZeH)73`H@68|A=zk zEH>Dx6)Vz7mw{P4iftYt=Ub{WSW0(P5VU~Fu)II=Gs~#ig6`-Yj@oN?y|)u}Co+Dn zjXeXUuJ##^oh)0toD$RegyD>pxA;arnU5Vad%V2f+~s-m=9d-y`HGp2_SHZx%KjBz zq8fJ1(?>DeehQQzxU;x{}gf<&l%#qP0baI)sJ1L&^Oh)m%JHHX9 zd!79cY zTd^|N1px#`@}rjtWg&AiUQwCDdVp8ZY%f03U;P|Jt?3GoBI<~V?c1yO5L+h#SZBa86$c*C9;#~AzlL8XZf%bomWNGFL9HItrO*roi4d(I zhLNygFv0>hX5p{f+I^g*A`gxyw)oI@B;M)Wx-yLKJdK?DMxL$=pT2wy`hSTl5HR(J z1NP6A#DBh>?+pIE*70vxK=wxn`EQkvzXN|S0{aWv4gL=$VZX!wJ&*Y> zFaW^u5uy73%4+_d)9A!RM-E;hlgCgU9bNDwu z@^}2doA|%b0Kh3T0Pr6M|9AMm>)gM?Q`!Co|8ET}D*^T)UH|~>#|P*`LPa_M`1St) DQaOG( literal 0 HcmV?d00001 diff --git a/Forecasting requirements.pdf b/docs/_originals/Forecasting requirements.pdf similarity index 100% rename from Forecasting requirements.pdf rename to docs/_originals/Forecasting requirements.pdf diff --git a/docs/_originals/REWARD FUNCTION COMPONENTS AND DESCRIPTIONS.docx b/docs/_originals/REWARD FUNCTION COMPONENTS AND DESCRIPTIONS.docx new file mode 100644 index 0000000000000000000000000000000000000000..82582390662c8c3aded719ad3c0aee9a6ad74cad GIT binary patch literal 17020 zcmeIZb9AKJwl`d{ZQFJ_PCDt>wr$(CZQHhOyW@0{j*U*|%RadKoPEzbzVW{Q-di23u29N%wB;a zSY?DCgbKTU_Z)CC6_YZtj*k$|Zh6i^G6l|WWLQBVHM^4i#NbWwPt-Bzpjlr%r1Lex zBHv45{4O}o?q|i?)r}>^4#Y^(JeV-82rZjcm=%bo_6&%jPL5R}1)Uezc;F2tx2A?)1abS5j&BS|UNe$n3! z?L=!E zBR#KDHD@#Hn>0vwj!I0$fUuz9Dx|l8**A&8+OvHVhYVE%ROfgptk!>jXMx%~#VtrZ zksVgigYMD7{!}^_I zcLHh|$hudjQ7Hc>XMKEt0ObDdc;d%nw_bhD$b6nYn9t*>>tJl<$Uy(c_`k>UfACrS zmrJio=>I&HumV?s?}78(@*Dk_g)$6=bDNm!5RjVUQYf2i7OTJCdDhl|wNLd$Cl?kI z=R6#!gDACF35%!#RHmkdc83v=w1SD(^+Sn|@DmRBsqG(90Ictv_b@H%F& ze4tJE>r+|i;$jEBH)szjoh7z0M_W)m&|+ILGLU7(8&pAKUw6%)c@*}R4u=QRLghn+ zGrW13Xd!F-{tIC}7FwlXjX}rI~v@?d5(vyYNORrIku)0FxJCRX1K2#H(dS zXGo)v(-t3lPkgP8inw@_E0#tZP@Anq>&oatf~s`$jGMf-QXJk6Ae9?|P6mb&EbW6>k=bf#i>8>G|I?VFhb*)X#dS z7ho_r+%k)293}fVX`OR5xqLH=O*xBafmE>)>sVB{iqZMbj9H3biDqZ|?7q?I+Vx+6 zTeW}}V@(_l;&^~ox1cZB+*`m1vM3{=Y?n0^&||l!6c)U%xA3}nA8ukWY@$moanohl ztQp0sU~0B3J6~qo@=*m1Z#S2i0ACg+kngRl;4QRj1ZIny8$FnE=p{$owmGlVyp+Ai zH%b3uR099$)Qj1v^qlk2KI~FCVpb4t9m%D=#&5cwhzeOF^Q%O&(a~{}ZMc+m&fP>0 zu_0ropvhim%`9YjG1|p#dbFbHKosoa`fQ}d(qeaU<{UHZRyF;^Y0_sGhJB~rm>7qw zmPIv29%WNO62+ngA-WZF6*XYNz;?6%LaNNJ($p-m`?BPr6`bRA2GeA+_bJb(Ryjv` z<$0&^u|DCP4P3UiPMPPrli29Dj_D2WTvVKSf*{QeQ8Cxu>o5 zeBN5rCxWBCk3(KY4jG4l5K^nmEU*^q{3M#W;#AZvFe}F6OU}y-`D$eQ2*!mjXtE@yod}Q$`D~4^6)V5j zCanucWuY$5Q%ttV;yWJB(`%{9D#_cP%j@0IMbH$VZY;ldS3CJZX6`Y^>f%pX*TY*6 zA@aq}n~TvemmPyHE3J>b9zHaki+e{^9M2zZ$pV=XrPxab@U>Vv}j5?i+6 z37|83_7hNo{lc2oi7Zt8HNwb_l|(BfLmq_GWa3&iVKE)Naqq~+n^$aL(P1JD| zA8x_-w)`K+C~VickBYH2P(nZS&hEtb^hl>Q=ZgOj^KD`LbmK z8N*>An?R*gSn^Cv=u4CpQ36Q_)mAac$pMGVSPmu@r?YljwzD-gF|Zemtj-99$eFcL zo)|89s7$Nv0YrcTz*uDX6+csiog^_>sHE|D26iU{$4^kmje?SVJNiUnUo@3)<}kQA!N#%LnGt{MGMW%x&WOlO&<LaIvz>QuR9#OjnRN6ZuO^b#kVZHZDg3vO>of+3wC&l8+esD`7)fyT0O9Ys#8 zgG`;&TY&IVhfES1f)iHDFknoU9A``^1+;GF1ei8C6I!~GXN&hbX7%&>pL>Q`**d_u zKIPE#vfJs!Afk;##zVjk4D=2`B=z)3Hqt!aSF`i5REHO&`IMOj+j|^%#<*P zb_uG8XqsHMugl3_2OgF`F6Qr84WjD007G8AcMh2vIw{-Nt0iyQ54XJ?)$8Zp>*mU7 zm#iKDG134G-f+!3BI5BA*q%R<#1g)M42T>M)@j8+h?#B9$<3ZHPnAzI-0eV>*=JAd z2z|6!7^y^45*eF8XAf5cuR)gv>JqsA9JbP9gJvbY%O^Xr>BVU!O;BC(=3|e+;6^Oa z1`4?v;Ew}Z(}KT9u16(LOiXe9e)~>!+SKFjsv)8;vnZ6t!weVp4X~lGICk1nI5lhr zxD=YZ22!d`@zQoN?RWo3Gj&U^CwOM|N8;vbJ!#u8hBmSc%#nx+)VF9_7C&OA!OKD z<8~l3)z`X=XRtcBtisorfx8ZFK1HUvIkL3Va#N1eK8IAT$9-!+97Bef z9#RRV=?Rb{;(IPKG;mzog(s+Uz_k#gT_h9Q`1DIh=v)(!T7{EV$eP+6nFq_z0lT*) z)s=?+;`N(rnr`^%Ci7YJ>&Yhf{pvLUn$;T{Jplvyp}lM8C!t5L&M1R&P=6pI>6$kiLhE2R)AXT-BXvZlbB`>;5OVlndMtiH0ogO0rkp|)kns|qTH<8s1GQ}%hO!pjjpJS)F6FUPmI`y$$A9K-WYr zbC4SN=sE;{^#z`fcFHSjrey?~9(Q=N$!rO_4$U-RqGwnkeYe0XL)G@zPNngPto=Dn zPl4z}km~a^Y?0v*xI@%sERT<0qVQ6OHQvu4WKFZjiVG+27IeqDcWB{t_h#FRq@op1 zwYULX`pj+YJnVpHk~Gt0q&zO6nvssvN(l1I1-Ho%=b;MG;#13!{$MKl;8CFCYH2eF zdih(bQP&|$mY^W$g;)nZ9yP_cGe$!S^|^)w8-K{*R+W?`b5rVg#ww0-UCF+SpNf{f zr}9=Yt=XvwO&Pj}a;esEMWJ=Pi8lv6*3wnhuTvFR^`Ny)dM$#$?8yJlU%9!Tn8WDE zGj^tSmvKuVD>$_-QN*t%glD7xtdbE2e*P^{8Kc&-_Yl<{7{T(^11&pn(!O&0C!Xq0 z=nClEFOSUv{9C&Ca}wK&R79!qz&1ktinNTJ>(WeAuos3U^R;Nf(pMD&fd-M0O}RmYQLiz6@?B_jP#BF0T6yLPHl=e4kdugRTU0+&T)$Efs^ks3#d$W+fV*PgpH zzT@u4J_Q94?`fdEumsZG0IP*e>Co=W_-5Xtj_qUDOF}=syr30KmNW35M_x>|l9I(y z?fJD03c_^1qfbN7+IoqjLi1o)t^IWnh#Rt@yA%y>DF?FBDj%nwK|q=a%R)K%2HA}G zx#KuJ``G&0Dxz*!X3z%XqMp(6*v?Kn@I6$!^($RrhacxN0~_~jLSDodulMp&z$JIW z-K(wB>*#~%n!ePa+QPcY`3Z(^6|?kJcJT1j?D_REMF&7EHN;`BIqk#fdmS72#I}j+ zYMxJ4Y%v(R5iN5*m~6Iy{$l1jLG93(tOZZJ%wxe^dHKHMhJ7FCW4#+OxFe>zt_dQ0 z?#1opyA0>raI~$u*4|^*wE6WHP|5?P|5M=IWqT-*=5JvZqq zOJxmjblUIhkw@QPXKzk@Za{U+*&6I2H+2nSa~VYWOmP zz<|B&Z@ENUyV?D)(_*XA+kL;+`{{c8cju(BClU|r(`{)10RV6TkU)QPPX6w}|Er7g zPj4RRGsyP2`hWJLDslRcAXCs)a8KZxCmpx-SEzVLDt|4_CmKAg=%~b2Zv|Cy8$^1<7Rg)}VaIBj*K5#s zT^>m43~;ac*IUeAp>?gBSIthofjx<#vfmLYcA$&*jf)GRUvEN2mO-*oX943rXnCVI zem{2(r?>JV;?#6RoJ>PRHMs${OX@XYAHBv+%&!lDRUC#(~i-5WbK6=Yd%u1s` z^m*94CHRkQG^gy6Knno?z!3ugXrC+o#zszN#@5CRe;b+p=I3f?#^SJ{`iSoHtKH?8 zm^jpC6lhUh*mQ1equ-nuWnppT+>E)na0rQ&@!SLifrdfExg7uz#R&l448)c%MNG!_ zJxY-u41J~AE`YxHw()$MeK7k2mmpWl;UGFP&5vb>vqXI7rluWUU_1+)6Y6c|ebK!7 zCxBiLSwIM7$#o@++jh(Ay&31aBTO#JFG=>I&AQH zLmfV&8~wvb(PgJiC;rzgPD1~BB~RP>K1WcQWQiZg-(G^oe8YDw^kmk;6{2CGqTy0< zJPs`Rh+(q?7hDgyfOz>uFb04?9f&AiV=6zgUZ-&$gu=q0*AupsK8_sP1?ujbabZk@ z^SEz1rEBMEfrQTw$h9A+@67>Ovqv&4^u|@I7MW%Haqvp2EHdtg}^QzXr4{}fh#_%&;W1}Kv(LT*z$h2X}t=e>E+r#e^oE4u;9HPjhSu%Nvtt$aHIp+64A^t?A+tu0!FVDk`Vv>c@ z;wB7+I&xTh;FSf}S$v30ZQ<;S(G%yw$++t#8iu(3GFX1X-CC?t3hI7)Hycav{`@>I z8_WN^dsBGT2Lw-|AKwXN3wi_+0?io&5ZQgu;pCKrOt%)I!MdZJLBx{I4lYeGtlyt*TLNkDT@%SU zt7&b5x|I>(Vg>FYyMSV3oP|2?qvkgLVK|YYr%8{YbfX?bw`itZf~<2{8qKD)1WO)$ zSGBhYYf#xC=#b99Uq_i$6>a*Xr=Xl`R@He*8P8F9bWKD@2(OV&`yM23+7Q2*tj6oO zu`ehqj7<TgAYFEL$-Eb<@68Ickzv+Nkhi<`Ky(U*}2aJcu26YDa$h~vWIEvK!K_Lyz&{1`bp~+&8-8l9513R8_PH5Eh90A3EA{tBb}+2 zr__cSn~!vxKdEX`56lCFskWq$iy5O1kLtO-#(OTUwJqipOV&!~PkUf>D@hv?al{NB z``Y)Hl?9Q>y-n#IBtJ5j5}4^n;zY5eWR1bY>IGmCaVPZ{ z-uy|)9C+Q$bd()>90n@C$@C_7N1?;8VxW<1)?`g4shR2`R&hCziRTLUe@Tl+;|^Jn ztBxt{!qKCLR)t7QF7UJ*&h|>q6*-v9y}$}4jn?xiPHJ=qU%d#BF(=44y{wt?=}A{F z%eo&}y=)9#5~i|L*&;mKXrhQqb)8IAvqtIdr=HyI9It5=cTrv)irj%Dv)CMlwTP$> z-f&qeatTKhG;b$nt)vg1?16VFRM|$%98h?A>{%^o3}wC@ZP3z=w+bR{D5WYDm2%9T z*URRBnw1f6DV4@19B0x1;A)K}nX}0J9=4AkifIH}I#PzzsJ4JUb_#2B8y;&W7sXLFD&*J?Bsd0CI`pFg(Trp-Q^myYN`)Elj$(Y?$$V%Nu?2`9QSg ztJBI{Y?FB?4evl->Gi$-b+*GVRw<_Od&u$?#8(L?y4$7tGOT7C-0{>~NGXJ}iCy-k zBiiWBXdk7*lSG10!4et{(BF1k#llmzibS@EF(NZ!IR^I*qJCYzqnHNL#YaRq9D|vX z*a}QY>1o)QeCJ1)+-v8M!%oIzl21r)rI_&aefdFfJYV0$1yB;7CgF(;^K@he%p+qU`(I!93-o1}4*;g*rLiP~4&vG?|07 z7IOR#R+5WB_p#L>Ypog)6-NaNocYusLHGhCuRr=CgVQpE1Af*qyUipDKfE1db?-X6T~-IgI3KZxn2CI^NL(|C+xmwEP<@}(nZD@ zO;`e+H%`>t5EKGCGu1W1-_1rIfHpoT10H+#v{3sieX1&Zd+aQ3lAUMbXy_vNC@Vxq z7i@#IuU3#F!jEgCq@`$dT!2e=*N`)J4Tic7`Rzp|;`RHelm#BiOZMV8O5-?qIZwbj z?%Mej18#%+8ku{8gW{%3JWHeBg07I{8#O4wc|yb(>?Pa%;LX@wG_XzL*ebTUfRvI5 zW+NQ4A*dj5rx6KK=*lta3Pd9AvJ`)wQ?&@#H%-vDEUvLC0c7KhG3Q`r0nIQ4$^I-n zbb??Vfy^YkNKJ%I*3RV)^S)hqVt8(TiwYY5@bRjY`v*}YT&sJ+v(R6Baen?pROARH z`YLh`v}bosEF2<@6oV6DF78t(tY{ap}-ajWLYkIek9dI;m0OTU)BLiup^@3hV~1L_%0iS&cK#iEORq z(+&6JIW5nMj-lL^g_UxeS^9aq=f{N|5=ml9$%(zuw-h6(8aTl*Xl3QWMkkaho^Kq% z@UU#GUHZ?MO$?_dTW2FG95zmmV8$kucj4E+`b4P7QP812X7e)R)E$C?cb) z{AP&rr}=@8wim`6`_tBtyf#mB!!wA>fRztB(t!mS<{>xg^T0QQc>1G=(kz}wYABB( zdqM-|*N|J9P0Sc9yp1fKM%uW(F{1Q#AO4PSEPi%vPdiPL&pYs#U9>s*wM;rw762~a z@3kO=|1*HGpSY6+h0W^F9#@6}<3^+~=3HyBCA6>Im*@qTDnK*aF&cZ-wtslq-OGoK zKxXjtfiVi5W3ck)-4P>v>fNvbb1p;a-N%OH*>4-I-w6N7N8~SIM?U@Z56LkA0OWrf z_cqSf2F4Db^5+lnGnG2|nZZI0c>;Td4|s&4Q%}Lu&+3<2K&6Th^cSCJqnmF*)B#Pn zEuM5w=My5Z)X5J`qTHNciaVlhLL$p?a<# z563}ud~IZ>JO>KkhYe)6@M5C=MqY_dc?K3xrBNi#zkuLFe<=#RS!B+?&?cSnK++t7 zVu@fUj|e|f90zOpoJ2EJ=S3HZ1He%G5t()DfiNY1&dB+rmX|r8ETnH_eK?59fSAN7 z>q|u1Tk)Ydp6}vN=29Yc4}AutP$wJA^fpn$qLMiVO{bY^Fn>goQIKUNc0y1?_`P79Q1{2Z7ee-aD=^tC{&_VZY&dED~mf(Nkr$ zoHFY(1|YyaB^--wnt-r7|Mg&f5?<4V;9lz%kLx8*{M8+ohVs zLADwT`Dj&ErI&PzDI-DXdSf2F)EZik@11}ubFN1t<2vZmYb~|??Ycrnp}`Ldro)#r-G} z`j8YdCeHev&CA1o(L(vK(T5Bqo3pR$VX7?7#v&}<7#)%r>XR+MTp4{mnd~8)8C_9O z)O0sjku!xUnP-?^G}KZ*8Nqa*)Y4>69cjM}Xgo);q{bjC7UsBNsEhxy_+`{I{xWP%cF+;;1kBfTdVJP!4*a`r`PzZ&m}9peVbZz z%kgEU&Z`n!_*F%X>+0gs?r90%z9yrRa#57CAt)}4%aKKon7Wc%;+GWN$dP47&DhAV z@JNZ51|~asxOg@k>q~IqR211e{qa6uEJEfIt643_J3}(`OT~t#R6_D&iXk&+0fkAt**bbCvizKXH4cKgSF6b$HmGOY-R0KiKL0Pwls?_R&7le?Ai-;9!T?M;Wx zZ^+&|74Hy9IW7da+G6nu)DjX2)yrVZIG4jD(Zm&Xj$QFr&3B=mJf`g1B%MK4bg~TLaVu%o%&T)G?36 zbTsQxXpPQ8<^f-EHNrOf6KK7fn7-J|#aQW&+&E>Ys`{H_9yLPMvOtD)O+dO z75yzw@WRoo4IlZ!D18XQWWf)0`c3^gMRuK;3g(5acY0d&PWrulW}yKxXGRTa=X1gjZi)Ba`8P^802g9p5bvT4yga)3vCF;*Dsx zzM6G=Lbk?cO5J__#>gT^uFd&OxwP)(VM(~znOE$Q?InHE-rhBBIDuOGln8F(4r&0r ztGg3fOs+3YDs4RfcMg!k4~@a*wO=J3?RxrET*D<~81ff(PK2IuL(F0L(Xtf`xv2?~ zEwn6)VZd{~mTTU9X^<|&_uHqCw2!x^(bsJF+sOu_FF6*HR=;ld*kc>DgxBx77Zn?C zVrCDX>``x)UiG;mNq%oemFhy{SGRn4RO7B&K{gsw^C66o9Epe{b-$tC21j)o*iMj^ z<`xMO`*ugEM$_DVsOW`;w2;4Hncg0v;Mxe4T^16?6p85LS+g8F9IP$Z%E7_8EYI1g z!r@(2b&V_#JekzHuB7U}6UK&B7E&Un@7P>6S{$3@bc!1Ew9IEBk46mtv&cl_)$k_g% zwAMWV4HU8#ePR%bzITB=Q}8lBhaBU(A_&+bKg;JE6p%=k3L<7RVG`rHFz~57r0C2? z*$R6WGvNc1xv-Jxya$5Tw>BxIuvSyN&}~asRdMp#{QJvM?O$;f6;`&SiY#z8>NEHb zEoop472B|u1S~Dtle8Z2msB(6Y{<)9I_+Uq#-pbVAAU9Y^5K;uBnhg~qNH`$wY@`p z5#|k9dEKSsrk5#+4f0LU<%wojY7I*$8^0|KjeQX`p?0}uV3@I32a(;bDZXSUJ1GeF zC^NjdS_Lobs$|NCH+h05VJ%m=WwKBxi=6tnP)K9F(GKR*R(2NrUzRR*Dn zoOcDCMTH9C$U#pMt-6LpP}`FyV91}O z6LRFMg)gnL*mPKnP{a3R}lAz>CnedgAbc+3^b zR}U0SA=)L=RPlvWD&;J*4T{h>nu{pQ%94{h!S?{Ap+=l`!Usu7SUtfAOWxYrc|bnp z=TnU}i=u46{pEo5fDqqgLfDTOLx;@>uNN8ql=^k=+018s6>!(ajt$$vDEJl) z6{xq2^+)i`5icYBcyrdbu|l^mwOr5yC75s>I5e?3EH(I@=1e-%q${+s+!_PyqMLN8 zjfZTL_M(z&$Ks-r#fxl{?7UsZFNTFAQJcR?XKrw3IBf0;Hrndf*+nbpGPUfsjzugL zpy&tWbm;ufofe}udota&9x>6{zRE`xQ*{ zPm@WkT0e$9SCrnxykDl)NR{$!#yV`u1zyT2*KVn8=ZdsVHH_xn^bh(^aCG<&C6dl4 zg>TraZ;vRq3g^*#{dQRX9TXe={jON@SRK-N8r2V>QzIZ_qHg-gS~BhsZj)!b1+;NS zU-Q11uHW2l4c#f3zA{r`=oAvOH5hC1c~1X3dNrLR=a4ni26GU}7J53}SI$1`n>A)0 zcq6;-O?;P}GKH_d75wIoW6%fIqUVlN;wq_ezv?@YO-Iiq^KuBOVsArI@?|r+8Eng$ zg>1|DD1A-WFMq_SzyXqE6TU9^42mei<#&~be9jE^g%x8H>ye>LG0?4aQ+GGb#C^Ek^2|CX(m@rY)fD z6`Z5SlI-R-K{e;?NF56&-vn+>gZfc^h6u5ohujuor_!;>Uoa?f0H;`JwHy|Ger{HX zo=njwA2F7+sjy#HKv{0HDi62#*ggODd8PlSX|0weVdq(t29%N9PdZByZ1kEAil1~c z%0B5xD;+cxlYbIRNc`udMe!%8_CGfHugSmdG%o&${M+Q;eg+?OV%jd6oU3C>D$w@Z z{`W=$m4@F86u%OVyT%e~d7#Y@9>ATG-efH&b;YfkQS+a@sYaxFfVMrfs1|Jf*!<2y z2?{*Ysm*CUk<*q3r%aah9otn}%V1ksl>;*^heH8A&27mR`U6Aq@5G`YtT_`HBA*Ml$* z*3C8R!aa&oQGEgoRwgN5xS1-Z?=>@RddQt6L%0^d{Umlge@YQKKAdqi$=vE~nc2!X zvdI3@{?edhN}ohs`{vAx8=GWXMo*TQ&1YnhN;jR)eG}rMQxweRFc*)Osbr zo^QtS&RojQMqp``2>awL!-@im8S~gLDyp)kgqKlIv$#`PuQH>lUtX9 z2ReaQL){fbu5GLA6dS>nxasMe8^GxnnzE``T-w81J6{i|2URbrDOyUE^a(s75)ise zhh9HuwmW-#78glkvhnpVHw$jU4z31Ck|cC=&reQ4JfPOd2^dKv4nPW3FG0R;LS)hB z8PzZ5*?CcaSaStwIh!BBKh_(sujGw#$Hp=rZ*Yp6JU$ zlfUv9V>X)6fyxu$^UeJz4z*n@; zm{X*=#2eki1V{F$dqes%c3;~V{8kE;E8!j19SU&Rm(6#R>Gd%3avo z!X2Wc&AcKz$O%)`(D0pc>ukQNhh%%+e9)LEdFZx*F;ZOngKpE9m@t*bjBA z-f5Lw3!(%%?KQ`GHd2GhC1PC!&CZ%NBK7%UHVm3k;i@!`-KRn#2Ye_0$>G7UFbI|i zUnu9fRQkB26Y9js1STZ162?b~;+xXMJV{=9WSKBAM$`V@AbK6n{vDa{nw~bwFJuKn zQNL)GhilF(UZXKH4Xaz(;h0+TO5#+4*p&38212M){3FtOgvl%Q4Njb#wR~Q>l4M3w zj8)+5sYC6?k?%r$cpYkYO=6aj$_srI;U-CDf7a_x7gy4any8(xH-G;|F@Y8st+SvS zol@DJec)`;-1(zQeehv_D-(2?n=(nuzd2$ZHBZh!Ce`tsNM_et#pDOfYEyk9V&8kd zxPVLMbB+8yac`}_YWCRl3r#L(52Nw)#8M=r6?0*$f|&wQGt}*vlnKvl&EtjT8Afkt za`DvX>BKN=G`9J|6Zg?k_bnT|Hl!jxriZ$o)48!unV1`|-6SdzDU2f<8?>1EsAO&+Uj51y<-RyWWy;r4BA z7dPD$tjOcJmL87@_NNo%{qy4u;_W_)ST(J0XSF@_6+Wtvvdlm2K8UW$6A6NR$K48+ zN<+3AX?1i3z4uazV5j1(J>!IY7Hy2p&y9*a3h7VIY|kjX13z*#z`=Z$&N{qhAuNg4 z_v>qAo~oG~9_VFO0X07J91<$2uX6GZ1)6My%3*m4TJ>PlYyRR!&VxrIVJf*1xxYW_ z0{(m93HkR|G272l61vZ{2I@a!2d>5jivN<;$XeXC86ZRj?7oqChK6_+bFoPpvZV5F=y-{0%F%TJWpM zYJ5R13pcldQ`QICBG6C`29poxGE!#R_xh~sg7eYrnXnP9WA$+@cPjLXT+Y+5QJ9iA z+fMTP&8AZqcH*bPR+(W~TFyn?M%9=F0^<<3sA?)y2LP)Dpb4aza8OQU$60)%2 zxLSE>OJ>Fj8F|9H$%e5Q&%wns{g8~`Y@)=c!x$UJ_tZINPKNf>1MfV?Spn-MD8v^8 zcXoj=wsnM!>ho}}=kkXJ;bdU``w3~0Hba7eYSxVTrOHDS8h# zi2UN`F87@Hdz?|D`iJNX0hoF*@^n%(t}>(;p@pkv;!14t4w8|DzLK!6Y)XoKtDN=z z%28Rb&@{3EzGA64P0b~~r};T7?f0b7Y|m3=$a!Q#FsZNswN@Bjcj>x{Ll;@{TcTv( z&(ibQTB<|*r?Y78BUy_-j&7^QNIXUo_kN@hFFv8(w2BY6YsZUrGi70wj^kKF$@`b9 z4wo~X6oo8dv8*1Bz2q3TS~8t{z|r~aZ}xYi?L{XpbZ}*%Hq^foa8c$;RMKGCoUxp9 z3Y6X|qzZCjK;xbm~-?0>7&J_Tx4g0$>s&sE5k*soA((~hR>=ZX#) z;3gO;Ax6-BbY$Dfl_L55>hqn%7R%8gnXU8Z8_OTk4L7aS0d#5gv3B*I?&}9 zB)9CDK^&xZV@-M@<@&-dyJMXE{F80s?&f>zDd4mccK)gh^hYMbDPiQrOE+Yc$KW}0 zJ)8{H1}BQ0c_BA!ngHp7lL%@7a!h6on2-`xQcv-IPw~cj5fVbqU|>`;CszES`#xf| zBN=wqWZj~KHWoYNiwNHL3nK&-Wwx>qxU;9&)6x6W=5`B8=L%${KrJ6Y|GQKrx!;bG@eA z2Pb`tV2+#*2t28TmoBBF@55&@Fq-Ngi99x8eAAC5tuz6UUFznR)~fCV-}$G=No5NT znWGLE+jE9n&5?`c@6~PHmwXYG-oSoWuR%3^!}DGH^&eFnC_-SH>nE#@f3hm#zp|>n zo!uYu^M5(@lTH8NRE0^I&w9!(k{bm1%j!j7<;a#AIhrB=)Fru@ltyt{+|35K0^ivT z0m%JtGM$azZ>EOo+^?J-L-;5yS6-|%4zaM!X^b~irNjB)(B z2gUDpJ}DfCLkfoa*%dvn&5UjonGLCkjgzso;!3RW6UXGIhWM8H%SL{}kdm`}Y1&`-&=mH`+nDjpvfK22a8AiJY16$RmmpJHte7<3maKPF#WSl?m zglg?R6BJgfU8Pil5XU{5`CY-yK(jwXVqbn>H!61PVfLyJ1n473--?S2=Dy)q5if?l z@no0OhG&fzxEL$G%C*bvIMTf?N)^MwLZox3;RswLq+pnDgCvK^-o%bpH;2@ zv8eU0B>q~e^Ct;lynklM{>8-oEBvpy_CMi%ME`*QTju?*_`jy){=}z~{d4>OO3?ik z{8yX&Pw+C^Kfr&n(Em!|uSVma6kIs|LE+y_$iL$MUAzB@{;VwK0s#J-uKz3i-zDz9 g!rOTM1^y5DD<=u|$zA{e?B^5clS7UF=x+!7fBZGwTmS$7 literal 0 HcmV?d00001 diff --git a/docs/_originals/STATE VARIABLES AND DESCRIPTIONS.docx b/docs/_originals/STATE VARIABLES AND DESCRIPTIONS.docx new file mode 100644 index 0000000000000000000000000000000000000000..f1dd71dda16cec47e15e1d4045ef1d4715533c1d GIT binary patch literal 14711 zcmeHuWmFx@w(i1RgS)$XfZ*-~3GTXZ*C4^&CAhmokl^m_PH;kS_qX;w_uMV#y!Xbq zfA8rrR*mki{=QyaJ*(!|vt}vDLO@~wpaHM|0Du&*SukU*1qJ|+Kmh>n0I=ZNqIR~< zrnb)dsvh>HPP$C)Hr6D0kl-{q0C3Rt|JnW*w?ISUsBI4ms`y>fBT8J8n$cli869|p zKr-XUBN!YnaP^n?!M4|qci_ruU~%x)WR&c88|>->0n;mK)^KRw+$fK+KP3An=vi{p zFE8#g`kLTU{YYfl5FY08v*u`P$Ccv(Vu_-v5V;<=llx068Q}#J4%c9o`8$FG8`aj86P8;5)}vWp-E^r1^GTQ+n;ap+ zq5ah-n|lZV;Oz|pp!An6Nfd|IbOy3B1yGMe0Ch=yM^kGjW~SfD|8&Lw#r^M3k6sbq z4eVt>6gmrd37BqIUg^fkS70`tTE$t0fz_6ld$+m-Tzq}uUs?j!Ju;LWotaIT@^s3O zaM?=KJ;zH{Lke$)TX@jx)qZMo2P6fx6|%Z7*l#1I@86oejF3yyjs!$#VunxRLC4*P zrjB>L+oKb^-77}0B%__2Gp4A|&vH;(yi4_A&-uzazW|id_JS$XF@Yu6p;3Y0neI+nKC2Jr~)4EylwiYXMSgKe^?L$TrOM~^OLuk z4!YLsLHItdAlDhGW`q6@JNyh?;VY11`q%#9%>c(E0`gwzLI407s8QVP98H)_?2KJ( zKz{2thxJQm-FB4+tAp5J)1ReA2*!er?^W7}1DB_97V@xBVn?1CLMxAf45O5kmM^Q^ zBg7-&bD&3}NBoD7_-7UBsCYBiJ(BiN3Ylkj_l~Px^6AfSqc#jfk(Rwl{8gMA^Hzb< z`cOIwF;;Ix*(Zbxp|z^esx-sVRtRRm&Wz`s;=3!`oM#TR8FatcB0k0E9W4`^nH&Bc zNrs|*-LcP=k?<#c`u$n(qNnV3RnA){i})^X$rgL;#s+NyN$f!2`wU-gWX36H`h zy$7`U zrA+HCe2#^|D&|yV2lG^&5#!gC2)Qq{uxFSG~LmOdkmLUM%?!F;mcHPi=MijB`$ zvh~%NkkFuNTZMl0hudS`!8NKIq^)d+)akP#pqeFinnTel9EOj2!&&L4GnsU_xQ4A* z`>_}h`@m|*M4l!@5%Y4|uSzFR4Nd`mN4e$S$Li+`82F3;!iCs!$Ps3 zV1UM>+zlQBw`Sq;uIvcvUa9^4;ap7gBj+MK?VQoE@GFW|Yt0s7M^^yJL3hpP@78!n ze0VSn1*J8sZW31V3gK}B0TakyMriqY@(n8FPCq|tTq$gLJ=oaYTxS|r|B&OqYqDFr zXf3&_`p`mfHz4Xb|KvE$_rlXg(XI%=hNE}esS`PXoh_)l-OF_xA68r0sov_ba_ZtL z>T6&`M*vjK*QGE}r7{%J(bC{E3_*wYQ7X(YKSq&bJHZ0Se{8k8&qd6#w7>4Gk}g4+ z3Ns5n!Y$8??euvIxK^pG1sHvKPD4ueY}md`uaBFOGjihH^v)_ApK~&rs@uy{ntD2XerVAr#2*Uk zX>v^_y}QRU9vMpaeU)oQB#|}kfIV^!SEL>PqU$#JC6u4^(-3LqX}e!~Mo`a@NN$Y} zjAUTAG2Z)-43m0yS`!^w!=na~Qp+*tF-nFRv#%!N24gqK2#|04g*2V+QUL zRChqYLSo>EA1o1DS6m^RO7Z+DCv>W?9{W2Qt3x_;N~})S&mVfy3V79Hha1%yzj8=J zh5(1@4q`OlC&9fn-R~p^Pux{YR+;oZULx#|k9(47L2Ai=rFgf`@QvoI%S4*)eMPbR znCk~;Yl~fa8ev}(cB(RC9tEoSZ?simLKmSX3;;S3=L*EZ^GxP??xhkFj*z2AZWMJ- zrbK)^w$>|zbR?OzUz50)TxH0V5M1*d_IAT8a9bzk4#n{&lPd(@4GQ!Qx`A%Y zw+Op#k@@P3^7n7 z6>uS3p?fz#`7Y^NEODary>?&)-`-~4JyMiV?c%4I0*5-~la_bDVg7BOTLD{3#6Gu4 z_WH;*<^g_JQxNS0CS~EL>Zkw(r>Xb6o>9}dH^dw$v99T9KUrQmjfARQ2^58edXSVq z+7I(%2A>|zbv$L$Wjsp82GC(dM_iY5FW#Q3EwCv&w)zpk^~5WcyGu_-kmPdb>r7b( z*xvAyUVY(F#w+8IU#jGTXvz`knxP~?2}301@KG<^%Z{p_>^GJ075JQ)2zQeKnz zb6*l5}(7_G5mYunVGhg;3E=l6#j?#rN-f5koNs+)3s}YRDw~zu)7K`jGuJp{sg0!OwY(*Xh z-?9g-JtrX8*Y&GtC+C~SrJt8vs|H|ZomZRE2qF`+sW3@e!`SGR%3Ji5=b-Z#|UDaEYn~!|3#I98h#!)yv11ML3WN}L1D+1&8i7xvUoI`6@d2PE*-aH>zy5_ znIBlYRvP$;g0cd0GJ|V%bzwfF(GQ6z=h86uA{yV)U6j(J3ZvwYuA$Gi%)i=SFG_9wP|7F`Bw0lcSor@=DI-$pIN6a7?| z?K{w+wVd`Za2E+^i1ojbaHUxHRib?4;;TydG`5;))=7S){#M>K?E7y8$AU?{@-;|k zu!7_|0RR^4cfs)wRsLt$@lS;g2KrbA@%-=JD&j{$3KjIR81x#D`k9gMvy#ZJwG8R% z!V5s0NU($fZv6U3XSI~{@sz>$bH}Pwr%6Aq)yeK~x5zoK;+!Ez)WgVXuSGidQljcp zVN|P6R>y>NIB^ErdV1DbQ$PjTxf_46Jf4qJtRdeLO?U}7Oa*denWJI?_BjUBp>6bB zA{>(r+}IRwm9kj+tJG25Za71Mi1);ec4-@10o-;FyaFnug7$BbV@EtP8id*=Pzfxu zVzCF}>ayWe#1Y19#YzliUHSc`U4~iZow{{dvrMmz!~TB2~hF@g)#46eiYv2aGgU2>hZargScR zG^XoTj%ue*ly*H2{zPKs{xWlC@_>LiTh4JODk9a7y^p6zdh?>H1zBh~1DXf!Y2szp zvho*Hqv399x8HuD=l= zmMgab3f|z9+XaVujKR32vkhIELlDWT z2&cnG5(KyBxODSD5n6BdCL*Pgr!Cq*nioIqs-3hS=KOtc=^%-K-rK|c>G=7;|vN*sq-B~B%+((ll5kbD<@X{{JqW@MHZ)=(NG!3rfwQ3`&U*E9GeT7eOdA(qax(W%)Spq z_)q0?o*2U96{^{*J1*mhZ!Zb#RHj6)2)Ng4Y;3h}#;X}3MhrDbsVbq}{*3D~XuU7m zXf7EIOCxkmEGQ=nNH>{z)C0rpbUANTmvJ}!3CtZ02F%4PwGjFR6Qwegt@HAjwoOI2 z%2->UIty@n)f@wN8IAn))Hpt2j=y!}mGVx0av4)2bW$5!64w(UtY_4{hR7K=CaR>Y z^4_oS3d{)Q6o%2k{-BffVn7GuB8h+*lR6{Cb+w16Gn8WsA<@68Ax4cRx5t*HN4nec zGd3X6QIqG$u-ukYSp9+&>5|&LtY=1%vk-u>>d>SXIZ7sPl7BLBi)N9lcPH|a>LMyM zEPxU=V?-4e93*DWevgRmX`a%PXKpyH_LE-ouxX9{(h*$g1F9V-y9C>si4@F;;@9Va z)|AsDI^(p}TgKI6+NzWt%K$OjH97P`mdM?`T0ZaLj#C?5;FL?P#ok{JHSO^^0nB=Qf8Ka3B=K81=yv~%;*<#)AQ{yoC zf@hQ}ql??{4Vd6R!K5bTd0F*mdM9Oz?~G=j;094d8Tb??)_XuNo_tZTBu+azts3*` z_^Mfwaow|cS|2ngMr)GS7koj|3KD-0fpx=Je zW6=gFjl7eytYv+nV8NPWU8{-HVh*}ey*Isq-;MuzGvQhc!>e-4Uj@gwZo>B|XYkJF z4b@JdMkjr?S>dKQ>^s&%r|wU!lEvFWh-;9=_d5ZKs{)sNo~x=WDg{;XbO^%@DMrXYg&4O?J01aw&UU zF@v1vzq(h<&6#{TNC2P#@lR18CsSuoWkE%!7M-aUWhn%qJxH$S^VI z*ASS&?ZnD-476+xHa26Lc4X}eILcUz^2nUdgc9$5{Jh)TI8zaCfM(|e50xq8&-N-@ zaQXQ}#|$U=Q)I3H+?13;5>Ib$;Xq1&^M(hzO(M-KQTg+EK1r%4VPvXTRK*Ok(U>Ju z5PA?7Qz;F6TEgiM{$1_uMkd)f?hMrxiEB#3*nkpMX{)`d`gJ^&MA1{A&b z5J1_f>pkyw3KhNZ;F%>yK0&}&@MZW42C$v@5=zB{a>a5A!4SmBG#TJzzKgG4pd2aHmTGucZ{jtR0fkKO|hCat(IZG*f7W{UwYNRk2L~$44#PfOtae%o z!l(?`lWG(Do*Wi^saQLVr-6&QRv;Cl#PAW#6rT~uvO>CaFebcD8Ben)W(!P&SP@ax zg5UpDb5C&%zETjVz2>o0v|P<)0|6Za@38bBt)hz{CubH_U?)hnV~`&*%(C0$4~d8< z&FaB{xp@dd-W2;B>_fST`MN|S4>sMnkUg~J1s6La_KHa0!9TZ~OtLQY)km4d3%x0F z!HTXh_6`%;_PNfWfhIH%fYICt{isBH+c@C{X_z|ONn@KoBxr#6$@vnt!TUR!7J`pk ziEPQuWM;u$t6%}Mw~fIbmVV%rqzVp4y_(~!8L+`_T24Jd9KEwhdVASh4*G}xfl<5Q|}SRMB2ngn)CH~DlT$3iWF8e|GTY6vQ2Nx z;9=ujZf>2rnL$E?F=&)Fr`bH(;l2qGUlra%@!BHuABRj3+iXYD zS)g)`Q8VtAGDWH|Tzau98*@)>#WSYVt7k5?6xpEoJH3g7;}^i5I!|y~>b|w>1Uke* zmOC_fVn^}g6HSi&9~c~9Zh8c$~IU?A*~F?o~r;4O{Pg?lnDC? z?23C*?Mqeb4AX}%Nk*)lf;u(NhTps~%_1o2cPumd_GW)vOi$l;b?xdZ)h#n1KcqA0 zFuH5eJ@sZ#gR{y;c(gIlH4HLY#Ap&RUNP*7lOlV@S+qe#%;K4`fD1+NjMbB+CkciI zuzvWc)Z=Ym;KLZt*#(EZg#(BbeMJg!0J0zl6-K?2#!J-{;Z}*iL|TWt==jY&7SCJ`+`Uj+9-i_7TgGwR3npPxGVi zhN-0{WQ=(Q?9RQy^(T(+q2ffaQUvch@+sp3r^;pXmbcPjdDr7Z0^(%Ld$`uz~59Z34n;hp=Ib3|YE~$?#7Eu{a}iz>btnI+Y6_3JP>7Pd93Et89kw#AEiVvo~PxaZwUnkT*Unn zMjs{dp>q$Y2)&Y1kr;)UoV{^)xR^T2`6+jOB>CI<*!WukypJrC%Sss%+x&UAA>)8KT^?l4JO=_J z(H)+KzySv-sHhz!aJ<1EhZY1O#Q6>cw&7j0^;3I6$@M6N8ynHBPXs?gTAvcPKm{VG z;M;ooaTsfP8yr_I>t6Mlorzvo){MS2*Y+AS>nhIAtq!@3y5Fzc(hCv{DJ7*6ySeZG381 zDK^7c{j2UMj;42Wbi}JMrSO+gwRn573Pld4qMFA8X!s&uV2;6~`ENT$1`ZOOV$e|* z1&Dalez+WY4zsV)oVK77YoHU&xDBs6uGlGI@E5lg##8OCZb>GWcrs@`YXf(sWh1u| zY@D-O!F#_1%tt*)%2&o~Zdr|2TgLK=x1zT*)X9~{kCP&Xv|KZ)9#IaV@sgT>{A3>U z?qcBO7mu>P@>8is;a0rTy!Tx>8S%x-V|l}FlPT#xso&n!d;@Isdk9knm}!8c zyiyd`$18*nHJzHiMOW57jsp4U;#?<%(62x0*%!j~o@FQVV_PnZ+7-BI#+$_O=ZUs4 zUdcVBF+LcJOH&Vb>M|TugsN3FfK9)s>aTxB^EMgXfN@T!;VJxaa#9Wzk>FXQ zs@Z_0oFlTD``fwuIG+2p>2@l=eCyw!GIJ>O#y96X9x|j_$UJ?DXu`xI;{ezJv4g$ z9td^!xk1@OHu#tvisJLvq(L-XT=>XvI4BA60Py^6A^$k^sW)Uogo-yCUM!6_FBcA+ zX^bxL{7d$kS;1*FB8141NerB%Y+4pNK@|g4A1?2A=gV?(Uyc-5u_%%zHDjHr(;9Xo zOq1)M!(cCMdd_f#{Z;eVcbDY^;1UWSscgZeH1ic;saNr$!*@6D6DzFHBkJ@aF_n`k zG$mBEwX^LL_x9VZTF2%RNZMQN6KY~7>nXNdc2d_G$@DwsV@$2x^j-2*malj_vQxTG z+Ny3>S$6U>lht}U3>#a!i&%-%B~9?g1ukjy7|Wu2LTCqiPX|Wwxg*O5ZM7m7*~5@V z6QYxA#xHC~Zx}p!9cQM|8$DL0KOQ;v*2$yTX}nGy!X|LNl{)cl`mB@rYq0F^s(lLeK{`#|hCp993t`P_QJ@FNyO! zysmo{q};aBU?m^bUKJ21)UOba%%JqtL&UY`PgTQ&|6LUftEUQq<6B0W$PFTm0mf41 zmj=WBgEVwYoYU{37*E6l#JWYri`e)-z=SK8p=ni9o)QSjq7P5oBYkZ(S+39 zOg6SW+)1a=Bw=6Ta3l*qmp;lC5+hpyhriaAhNIV(MzG9b`Qy9!R}mL-gVF(0S%u$@ z>F1lROOt>)jk`s7DU6)TQKQLeCATOOwxB2dzg2^<@~U_Iq>*GnirzqPM*0qCk0v@O(1WphyN9GV716<_v;A{`fssveh{ zRqZn@YA;r4of!8u3nUNLw}s{ducoKBEG}<%Kc1Ni=-qZbTqaoPS0*5QA=WD?ym1>Z zy38~(f((A_HQQ%5FP8ZB)yHb~X0gC_Sjl|F;$?{7seO;!$#F-!Ucq+reqt?n?~%{R z@y7Hevqh<_?R2qq+N8o;^rV8U>j6yVQNKEwyAU>K)D6$@Mf3Ylqxu(3-u8({gN&Ff z0=~?_KoY!z_orL@R+>LwxWpdDPE9+~n`Ya~hR!ov7N=ruT2u5EXWN4n?%0~VrkWSe z`5dZ&LxiW_M#FA@&<&dHH(vP5eXA-ikIbktIz7vENSa1)OHx@?DXT&GAU+(jp;V)q~wC>F%eLg;RU%(dq|1nhsCT-o7KGA~N9}q=d5`{4y}#3BMZiSH;ZdbWJ#< zw_@hRH{D2jv|nm(gYO=y5#H=*_Cu>PpYhc#?tNdd_d4;m4^;U-?BwEDW2Ir&^Zm5g zhmgI&|1x)w)cCpk0+R|RriceR)XA+Oac?zQq3qJus$cPwUuM?)^0yJoycSGBfr6QO zqC)Mt4^bVgNR*BG7ZeXe*Bi?-?N&YJABl~Qx1`$roUEQyePw$rv&$op75sX~Cl32v z2dDH?B5!6{Ccw)pD!37wJUPnGq}-fW?A1bZTax&!@9gs3zpu;Iv*JJ=`_*H1;}LFR zHqoWH_A|I)Jo;v0$d@u%ey90Bl{bg6|2-?X!#DUTkuDDLxGXQ?2Ps-_5vt7Od3Msp zs`X7N7TNMl&>5$Z)f3z@tC?gPPL9Aec`1rK7x2;2g2CRI{cAg?kt=w zoq@cEve;5G&Pl`K!-1jbDmY%bGxxL7Q-ws>aK&O2sr6g>BG{7|TW3XLpY(MS+o;QgN&xW7fQWTXL1UQAE z0$aA*ZWRuTct6*q%<6Y@xjf;)v@m+*JF_-E-Lca-qLxg`WnRj{0Lgo^y z>owNTIMp`ZebmjU0@FF0=9W=Uc~nw%EYs%9R}0OF*Quo(U-FkWap~P#2vzS4&wd3> z{{3s*l4|2o$__L=%m|8IV*E3B;AU#1@~6;c#_YOn4+#cf>xt4UB-pEvms8f5Qxhv? zok6zo1E8mr61*5p$3;=FWPaY=*i8j_>T2(tTmST%Oh-3w7!`HCp$s|;K@dlJhWFGZBEE=|zUL?3v}EZRF2+(too@c9ep)c!WWlMW zthu|TqYE|>j^ieQdrb% zF)lBgosaLMbH*FyELdL^HmeWMJX(6{Ms3D<-mk&TiO>O^ea&GV4_d6UY@VagL4=}M zyH={})rKQn{zLcRH1lfwfaFTG*q%zco_-lT9-rQaz9Klo&B#F;%K(vnl3y!iZTb~$ zbC)pc7TF97$P7`vazS1#~fh9aO@B7xz)cmH!mvt<0gD|?#sqnoLQ@<=%{Z4)^ z&C;Zxp?Uftig9IAo6LUJsc>m<1YP#M_(HCDjXPj;Eyeze>ZUTImC=Jg0w~bk?;hY8 z*%FjD8n1F&aU{)VD*D+v)n2SJXPXnTVINB?UtSqs9@j5jGd!9a?h`qcrmjClu|xpV zNe|Mj8-`L9e>Z9THbhMpj8ruMe}w4@XEh70b%Ztq`-&$$t~UbiU^DG2AbgfV>^s5Z zIf}l3p|D{DkjQpP`Il7~C8qyR_F9aq&~mt1J_C{2JKBVCcAF32+DC3QmbX_W4WuwX zq)t^OP7TDtex2D0zM_e^!hLTlM3MOcaj;VL=9o{VBE~z_v;u@>s|*DL`RDE6L7e^{ zn_`aB$aEY8IkIzWGr+0IKKo706mTEsuy+LZ(Q7b44&U1)GvnPIo0Hq)qv21J_RNEz z72M^CZrd-r;XV(nYkb;icN`{p>`yyvN)`(ew#wtEF(H`C4nfk}=G1G^|Cy)8Js=;Q z+LgI86v4e~N=$V`@bDw?>E!V#i5$h(tzc*ER7%7BdMp>K;3WoY6Q<_r-)3yP!iL|w zf%^0d$ZXI+2_m4Z5G6-DdnaaNJICKG29&q`pR5p2Uy6+HRsiKK2cJo`i6*h@rpY6g zd{+SPgNj8(^luL8Tdm`?OiWE`|6tkbqWY_AJX-M0^_3#s=a_88@2ZUBT@N%|SXbyr zy86`E#bsS@X|k9#DZNB!Diee(xvSX(xh2&^cH}0 zu(~aM8*)pZ$-ebe2IU`iEKP6fxfrOa1pw!A41FawiHY^n$_GZ~^x#N5sKmqJ5r)`3 zVMTX41wN6~d^n9qMSvlYO%Ze&C)Cdrzf*XiJb+F?YOP+Js5aD2Qh3an83m{6Mkr+1sj+@!kpI&+zCQSH#@gJom28M6HK}pol-@2seRY{| zIAr*o-;9AsZ){0zWWX}sdrtfI5#@_#Q`Z|N^JBP||3b-Y$ha@4$^X>@X(i^m{AR7g zAZtbav$Y!9+y6Ga{l{2A%?8>sK8}Kn6}6500!8_BPTK#=)B-FfDRNr@G>`TKRjs}C zsB8J{nI<>tm*%+H(+W3!c2=D;&rF+X7}Ie!W^?hZ+_*;dBHjJ!`SoGbtRNaW#s<#j zu{)egD<5x2<_+F!Wy7J+ofqLgbroT6hU)=D=pJF7kcheb{j)5 z=k>?dw20$pa4JuXf*%R>YBd;|Gv=R4`@9|8~n?%gTKT7nl|_c7yzIE%^Ll`k_i9K^!HS< zKe)6&3n2b&V%gs*{yts)2Sp3ce^LB-^8D}czfXDn0p}q6C;Y!B!2S;YyX5@??7;Y6 z;J*przcc(@ll{Sf4ia&{H^5&M+TZbib PV+Battery Simulink” + +To be continued: + +* Fix the aforementioned issue 4d. +* Test and see if these values make sense. Compare the 2 versions for both. +* Discuss if this is a good standard for all parts. \ No newline at end of file diff --git a/superseded/README.md b/superseded/README.md new file mode 100644 index 0000000..7af86d3 --- /dev/null +++ b/superseded/README.md @@ -0,0 +1,188 @@ +# Superseded documents + +Nothing here is current. Every file in this folder has been replaced, duplicated, or has +expired — but is kept because deleting project history is worse than storing a few kilobytes. + +**If you are looking for current documentation, go to [`docs/`](../docs/README.md).** + +Each entry below records *why* it was retired and *what replaced it*. If you disagree with a +call, the evidence is stated — argue with the evidence. + +--- + +## Exact duplicates + +Two files, byte-identical to a file still in `docs/`. Both are ClickUp bulk exports made on +2026-07-25 where the same page was exported twice, seconds apart. + +| File | Identical to | MD5 | +|---|---|---| +| `Cost Analysis Excel File-20260725175434.md` | [`docs/05-business-economics/cost-analysis.md`](../docs/05-business-economics/cost-analysis.md) | `2cbbb87f383126cd2f27bee20cc1f636` | +| `Social Cost-Benefit Analysis-20260725174919.md` | [`docs/05-business-economics/social-cost-benefit-analysis.md`](../docs/05-business-economics/social-cost-benefit-analysis.md) | `fe37dd0ba965306ae4b6623d0e808178` | + +**Evidence:** identical MD5. The retained copy is the earlier export of each pair (…5431 and +…4855 respectively); the choice between two identical files is arbitrary. + +--- + +## Older revisions + +### `BIDCM-UCSD hybrid hospital energy flow and balances (older revision).docx` + +Was: `Shift Matlab Drive/Shift Matlab Drive/Energy_Managment/BIDCM-UCSD hybrid hospital energy flow and balances.docx` + +**Superseded by:** the copy in +`Energy_Managment/Beth Israel Deaconess Medical Center/`, reported at +[`docs/03-energy-management/bidmc-ucsd-energy-flow-and-balances.md`](../docs/03-energy-management/bidmc-ucsd-energy-flow-and-balances.md). + +**Evidence:** the two files differ by exactly one addition. The newer revision appends the +**SoC Violation Rate** KPI, its formula, and its 0% target: + +``` ++ - SoC Violation Rate: ++ - Aiming for 0% , so that the battery never went dangerously low (risking losing from ++ Tier 1 load ) or overcharged (risking hardware damage) +``` + +Everything else is identical. This is a strict superset relationship — nothing is lost. + +### `PV+Battery.md` + +Was: `PV+Battery.md` at the repository root. + +**Superseded by:** [`docs/04-simulations/pv-battery-simulink.md`](../docs/04-simulations/pv-battery-simulink.md). + +**Evidence:** this file was a plain-markdown transcription of +`Simulations/PV+Battery Simulink/PV+Battery.docx` — same five sections, same wording, same +"To be continued" list. The new report covers the same ground *and* transcribes +`PVBatteryRead.mlx` and `Constants.mlx`, cross-checks the constants against the project +specification, and diagnoses the time-dependency bug. The `.docx` original stays where it is. + +### `Shift input data (duplicate copy).docx` + +Was: `Shift Matlab Drive/Shift Matlab Drive/Simulations/Old Simulations/Shift input data.docx` + +**Evidence:** byte-identical (MD5 `b4e1cea6…`) to +`Simulations/Shift input data.docx`, which remains in place and is reported at +[`docs/04-simulations/shift-input-data.md`](../docs/04-simulations/shift-input-data.md). This +was the copy inside `Old Simulations/`. + +--- + +## Time-expired + +### `MAY MONTH SIMULATION PLANS-20260725175516.md` + +A status-and-plan snapshot for **May 2026**. Today is 2026-07-25. + +**Why retired:** it is a dated plan whose horizon has passed, and its status claims are stale +by construction — *"Current progress is around 75% done"*, *"Grid is not ready thats all"*, +*"Step 2 — Define Inputs and Outputs - (Completed)"*. + +**Where its content lives now:** + +| Content | Current home | +|---|---| +| Component list and I/O definitions | [`docs/02-specifications/simulator-io-interface.md`](../docs/02-specifications/simulator-io-interface.md) | +| Model integration status | [`docs/04-simulations/simulink-model-inventory.md`](../docs/04-simulations/simulink-model-inventory.md) | +| Hospital data research | [`docs/06-data/dataset-inventory.md`](../docs/06-data/dataset-inventory.md) | + +**Kept because** it is the only record of the digital-twin-paper rationale for the +component-based modelling approach, and of the outreach effort (*"3 replies received"*) to +people with digital-twin and microgrid experience. That is project history worth not losing. + +--- + +## Stock templates and empty files + +### `demo-repository/` + +GitHub's stock organisation demo template. Contains `index.html`, `package.json`, and two +sample workflows (`auto-assign.yml`, `proof-html.yml`). + +**Evidence:** the README is unedited GitHub boilerplate — + +> *"This code repository (or "repo") is designed to demonstrate the best GitHub has to offer +> with the least amount of noise."* + +No SHIFT-specific content of any kind. The workflow badges point at +`github.com/Team-SHIFT-Space/demo-repository`, not at anything this project builds. + +### `github-profile-photos-temp.md` + +Was: `.github/profile/photos/temp.md` — a **zero-byte** file whose only purpose was to let git +track the otherwise-empty `photos/` directory before the PNGs were added. The directory now has +three images, so the placeholder is redundant. + +--- + +## What was *not* retired, and why + +Several things look retirable and are deliberately kept in place. Recording the reasoning here +so it does not have to be re-derived. + +### `Simulations/Old Frameworks/` and `Simulations/Old Simulations/` + +Despite the names, these hold **unique Simulink revisions** that exist nowhere else: + +| File | Revision | Unique? | +|---|---|---| +| `Old Frameworks/Copy_of_Initial_Simulation_Framework.slx` | 2.2 | ✅ only copy | +| `Old Frameworks/EL20N_Electrolyser_Model.slx` | 1.3 | ✅ only copy | +| `Old Frameworks/electrolyserNEW.slx` | 1.1 | ✅ only copy | +| `Old Frameworks/FC_DigitalTwin_MathModel.slx` | 1.1 | ✅ only copy of rev 1.1 | +| `Old Simulations/Initial_Simulation_Framework.slx.autosave` | 1.2 | ✅ only trace of rev 1.2 | + +Moving binary Simulink models around risks breaking model references in ways that are invisible +until someone opens MATLAB. They stay put; the lineage is documented instead at +[`docs/04-simulations/simulink-model-inventory.md`](../docs/04-simulations/simulink-model-inventory.md). + +### `Simulations/Big Ugly Folder/` + +21 of its 22 files are byte-identical duplicates of the two "Ready Made" folders — but its +`Initial_Simulation_Framework.slx` (revision 1.3, 1.03 MB, MD5 `46010d0d`) is **unique**. +Deleting the folder would lose it. + +### `Exisiting EST Model/` + +Vendored third-party code, MIT-licensed, © 2023 Energy Storage and Transport, from +`gitlab.tue.nl`. Its internal duplicates and its ~100 MATLAB Project bookkeeping XMLs are +upstream's structure, not a defect here. Nothing inside it was touched. See +[`docs/04-simulations/existing-est-model.md`](../docs/04-simulations/existing-est-model.md). + +### `website/images/` + +Superficially a superseded predecessor of `website/public/images/` — several files are the same +size (`sim.png` / `cluster-sim.png` at 2.30 MB, `business.png` / `cluster-business.png` at +2.08 MB). But the Astro build only serves `public/`, and confirming that nothing references the +legacy folder requires a build check that has not been run. Left alone pending that check. + +### `RL_ML/Empty.mlx`, `Energy_Managment/Emptier.mlx`, `Business_Economics/Emptiest.mlx` + +Each contains a single string literal (`'Test'`, `'Exam'`, `'Attempt'`). They are **directory +placeholders** — MATLAB Drive does not sync empty folders. Deleting them drops the three +cluster directories. Documented at +[`docs/04-simulations/matlab-live-scripts.md`](../docs/04-simulations/matlab-live-scripts.md). + +--- + +## Not in this folder: recruitment notes + +`Interview Questions-20260725174912.md` contains interview notes on **named candidates** — +ages, nationalities, course loads, and hiring assessments. It is **excluded from version +control entirely** via `.gitignore` rather than committed here, because parking personal data +in `superseded/` still publishes it. + +The file remains on local disk. The generic question template — the same document without the +candidate notes — is committed at +[`docs/07-team-and-operations/interview-questions.md`](../docs/07-team-and-operations/interview-questions.md). + +--- + +## Restoring something + +```bash +git mv superseded/ +``` + +Everything here is in git history; nothing has been deleted. diff --git a/Shift Matlab Drive/Shift Matlab Drive/Simulations/Old Simulations/Shift input data.docx b/superseded/Shift input data (duplicate copy).docx similarity index 100% rename from Shift Matlab Drive/Shift Matlab Drive/Simulations/Old Simulations/Shift input data.docx rename to superseded/Shift input data (duplicate copy).docx diff --git a/superseded/Social Cost-Benefit Analysis-20260725174919.md b/superseded/Social Cost-Benefit Analysis-20260725174919.md new file mode 100644 index 0000000..f4b358e --- /dev/null +++ b/superseded/Social Cost-Benefit Analysis-20260725174919.md @@ -0,0 +1,86 @@ +# Social Cost-Benefit Analysis + +A robust SCBA addresses several fundamental questions: +* **What is the purpose of the proposed intervention?** Clarifying the objective helps set the stage for a targeted analysis. +* **What are the available alternatives?** This relates to the concept of _opportunity cost_, whereby resources used for one project could have been allocated to another. An analysis of alternatives includes the _base case_ or _zero alternative_: what happens if no intervention is made. +* **Who are the stakeholders?** Identifying all relevant stakeholders is crucial, as the distribution of benefits and costs may vary significantly among groups. Excluding stakeholders can lead to biased or incomplete analyses. +* **What are the costs and benefits over time?** All future costs and benefits must be discounted to their present value to allow meaningful comparison (see next module). This includes both direct financial effects and indirect or social impacts, such as improved air quality or reduced travel time. +* **What are the present values of these costs and benefits?** Discounting future impacts to present value is essential for comparing long-term projects fairly. +* **What is the net present value (NPV) of each alternative?** The NPV helps determine whether the benefits exceed the costs over the life of the project (see next module). +* **What recommendations can be derived from the analysis?** This includes determining whether the intervention creates a net social benefit and whether it is preferable to other alternatives. +# 3.3 Using Excel for Discounting +While the above process can be completed manually, spreadsheet software such as Microsoft Excel provides built-in functions to streamline the calculation. This becomes especially useful when analyzing long-term projects, some of which may span 50 years or more, where manual calculations would be impractical and error-prone. +We will illustrate the use of Excel for computing the NPV with the following example: +Imagine a small wind farm is going to be constructed. An initial investment of 10 million euros is needed. After the construction period, it will be operated for 15 years. The income from electricity production is 3 million euros per year. Assume that the discount rate is 5 percent. What is the NPV? +To compute the NPV: +1. Enter all costs and benefits into a spreadsheet, organized by year. +2. Apply the discount factor for each year using the formula 1\\(1+r)t +3. Multiply each year’s net benefit (benefit – cost) by its corresponding discount factor to obtain the present value. +4. Sum all present values to obtain the total NPV. +You can also use the NPV() command, i.e., = NPV(discount rate, series of Benefit/Cost that require discounting). The NPV() function automates the discounting of future values, though it assumes the initial investment occurs at the beginning of the time horizon and may need to be adjusted depending on project structure. +**Steps to Calculate NPV in Excel** +1. _Set Up Your Data Table_ +Create a spreadsheet like this: + +| A | B | C | +| ---| ---| --- | +| Year | Benefits | Costs | +| 0 | | 10.000.000 | +| 1 | 3.000.000 | | +| 2 | 3.000.000 | | +| ... | ... | | +| 15 | 3.000.000 | | + +Note: Row 3 will be Year 0, Row 4 Year 1, and so on. +1. _Use the NPV Function in Excel_ +In Excel, the formula to calculate NPV is: +\=NPV(discount\_rate, value1, \[value2\], ...) +Note: the NPV function assumes cash flows start in period 1, so the initial investment in period 0 must be added separately. +**In our case:** +* Discount rate is in cell G3 \*\*\*\*(5%) +* Cash flows from years 1 to 15 are in cells B3:B17 +* Initial investment is in cell C2 \*\*\*\*(10.000.000) +Then, the full Excel formula is: +\=NPV(G3, B3:B17) - C2 +This will return the Net Present Value of the project: €21.138.974,11 (see Figure 3.1). +_Figure 3.1 Calculation of NPV in Excel_ +_Explanation_ +* NPV(G3, B3:B17) calculates the present value of the future income (€3 million per year for 15 years). +* C2 subtracts the initial investment (€–10 million in Year 0). +* Since Year 0's cash flow is not discounted, it must be added separately to the result of NPV(). +To get the column for PV (D) you put the formula for PV in Year 1 in cell D3: +\= B3 / (1 + $G$3)^A3 +$G$3 locks the discount rate cell so it doesn’t shift as you drag the formula down. A3 and B3 reference the year and cash flow dynamically. To drag down the formula you click on the cell (D3) with the formula. This will highlight the cell and show a small square in the bottom-right corner (called the "fill handle"). Hover over the bottom-right corner of the cell (the small square). Your cursor will change to a small black cross (✛). Click and drag down the fill handle as far as needed (i.e., down to row 17 for 15 years). Excel will copy the formula, automatically updating relative references (like A2 → A3, A4, etc.). +In this example, the project results in a positive NPV, indicating it is financially viable under the given assumptions. +**Costs** +* **CAPEX**: €2.5M (PV, electrolyzer, storage, fuel cell, battery). +* **OPEX**: €150k/year (maintenance, replacements, AI operation). +* **Training costs**: Staff to manage AI system. +**Benefits** +* **Financial**: Gas savings (€50k/year), electricity cost reductions (€100k/year), potential grid participation revenue (€50k/year). +* **Environmental**: 2 million kg CO₂ avoided over 15 years. +* **Social**: Improved healthcare reliability, job creation, innovation leadership. +* **Resilience**: Island-mode operation during outages → critical in healthcare. + +| Category | Description | Estimated Benefit (€ / Qualitative) | +| ---| ---| --- | +| AI Model Development (RL & ML) | Develop and train intelligent algorithms to optimize hospital energy use | Reduces overall energy costs by ~10–15% annually (~€5,000 savings/year) | +| Data Acquisition & Integration | Collect and clean hospital or synthetic data for model training | Improved decision-making accuracy; forms dataset for future expansion | +| Software Infrastructure & Tools | Cloud computing and simulation environments | Enables scalable AI testing at low ongoing cost | +| Workshops & Training | Training staff or students to understand and use the AI tools | Builds in-house knowledge and reduces dependency on external support | +| Program Coordination & Management | Planning, communication, and reporting | Ensures project delivery on time and within scope | +| Public Relations & Outreach | Materials to communicate project impact | Enhances hospital image, potential for green funding or publicity value (~€2,000) | +| Testing & Validation | System testing in a simulated or limited real setting | Validates feasibility, increasing future funding chances (~€5,000+ potential grants) | +| Contingency & Maintenance | Minor software updates and troubleshooting | Extends system usability and ensures long-term reliability | + +**RISKS** + +| Risk | Description | Mitigation / Solution | +| ---| ---| --- | +| System Reliability | Failures in AI control, hydrogen storage, or power conversion could disrupt hospital energy supply. | Use redundant AI controllers and backup systems (battery or diesel). Implement real-time monitoring, predictive maintenance, and fail-safe protocols. | +| Data Quality & Availability | Incomplete or poor-quality hospital energy data reduces AI accuracy and decision reliability. | Establish continuous data validation, standardized data collection, and backup data storage. Use synthetic or historical datasets to train and test models. | +| Regulatory & Safety Compliance | Strict EU and Dutch regulations on hydrogen safety and AI autonomy in healthcare. | Engage early with regulatory bodies, follow ISO and IEC hydrogen standards, and obtain required certifications. Conduct regular safety audits and staff training. | +| Environmental & Resource Risks | High water use for electrolysis or unsustainable material sourcing. | Implement water recycling for electrolysis, prioritize certified green materials, and monitor life-cycle environmental impact. | + +# Untitled + diff --git a/demo-repository/.github/workflows/auto-assign.yml b/superseded/demo-repository/.github/workflows/auto-assign.yml similarity index 100% rename from demo-repository/.github/workflows/auto-assign.yml rename to superseded/demo-repository/.github/workflows/auto-assign.yml diff --git a/demo-repository/.github/workflows/proof-html.yml b/superseded/demo-repository/.github/workflows/proof-html.yml similarity index 100% rename from demo-repository/.github/workflows/proof-html.yml rename to superseded/demo-repository/.github/workflows/proof-html.yml diff --git a/demo-repository/README.md b/superseded/demo-repository/README.md similarity index 100% rename from demo-repository/README.md rename to superseded/demo-repository/README.md diff --git a/demo-repository/index.html b/superseded/demo-repository/index.html similarity index 100% rename from demo-repository/index.html rename to superseded/demo-repository/index.html diff --git a/demo-repository/package.json b/superseded/demo-repository/package.json similarity index 100% rename from demo-repository/package.json rename to superseded/demo-repository/package.json diff --git a/.github/profile/photos/temp.md b/superseded/github-profile-photos-temp.md similarity index 100% rename from .github/profile/photos/temp.md rename to superseded/github-profile-photos-temp.md