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 <noreply@anthropic.com>
11 KiB
Generation Profiles Workbook
Markdown report of a non-markdown source document.
Source Shift Matlab Drive/.../Simulations/Current Framework/Profiles SHIFT(Generators Factors + Battery).xlsxDuplicate Shift Matlab Drive/.../Simulations/PV+Battery Simulink/Profiles SHIFT(Generators Factors + Battery).xlsx— byte-identical, MD5cb529138Format 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:
- Sheet
Profiles SHIFT(Generators Facto...— a 24-hour campus-scale generation and battery dispatch profile, plus the results analysis from a PowerWorld run. - Sheet
Fake Simulink Data— a small placeholder dataset and the constant block thatPVBatteryRead.mlxparses 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 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, 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 — 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 byE_rated"Disharge_max— "If NOT in %, divide byQ_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². 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) |
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 — the consumer of sheet 2
- PowerWorld Microgrid Model — the source of sheet 1's results
- Simulator I/O Interface — the parameter spec these constants should match