Feat: Varied heating/cooling schedule approaches in STEBBS#1261
Merged
Feat: Varied heating/cooling schedule approaches in STEBBS#1261
Conversation
… and required params in config.py
…into YL/STEBBS_schedule
…into YL/STEBBS_schedule
… when setpointmethod == 2
…WR = 0 and WWR = 1
…into YL/STEBBS_schedule
CI Build PlanChanged FilesFortran source (4 files)
Rust bridge (6 files)
Python source (11 files)
Tests (16 files)
Documentation (10 files)
Build Configuration
Rationale
Updated by CI on each push. See path-filters.yml for category definitions. |
Preview Deployed
Note This preview is ephemeral. It will be lost when:
To restore, push any commit to this PR. |
…into YL/STEBBS_schedule
…odel_option_setpointmethod_2_invalid_slice_keys accordingly
Author
sunt05
previously approved these changes
Mar 31, 2026
sunt05
left a comment
sunt05
left a comment
There was a problem hiding this comment.
Thanks @yiqing1021 for addressing all the previous review comments — the physics logic looks solid now. The CASE 0/1/2 branching, WWR guards, and 1..144 profile validation are all in good shape.
I'll push a small follow-up commit to tidy up a few minor items (typo, indentation, stray profiles.yml at repo root) and then merge.
…ev artefact - Fix typo 'setpoinbts' -> 'setpoints' in suews_phys_stebbs.f95 - Add INTENT(IN) to wall_surface_active/window_surface_active in tstep - Fix Python indentation in config.py and phase_b.py - Correct old_value description in ScientificAdjustment - Remove stray profiles.yml from repo root Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
sunt05
added a commit
that referenced
this pull request
Mar 31, 2026
Resolve merge conflicts between forcing-height validation (this branch) and setpointmethod validation (master, PR #1261). Both features are independent additions to physics_rules.py and CHANGELOG.md. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
sunt05
added a commit
that referenced
this pull request
Apr 19, 2026
Registers the first real cross-release upgrade handler alongside the
identity placeholder in `src/supy/util/converter/yaml_upgrade.py`. The
handler migrates YAMLs produced by release `2026.1.28` (and its
`.dev0` sibling) into the current `2025.12` schema:
* relocates each site's profile-shaped
`HeatingSetpointTemperature` / `CoolingSetpointTemperature`
building-archetype fields into the post-#1261
`*Profile` siblings, and seeds the scalar form expected by the
current validator from the first working-day value;
* sets `model.physics.setpointmethod = 2` (SCHEDULED) so the
migrated run honours the supplied hourly schedule by default.
Adds a retrofit schema label `2026.1` for the pre-#1261 shape and
maps the affected package tags through `_PACKAGE_TO_SCHEMA`. The
`_HANDLERS` registry now carries the real `(2026.1, 2025.12)`
transition.
Tests:
* `test/fixtures/release_configs/2026.1.28.yml` - vendored verbatim
from tag `2026.1.28` via `git show
2026.1.28:src/supy/sample_data/sample_config.yml`, per the
policy in the sibling README.
* `test_release_compat.py` is split on upgrade-need: current-schema
fixtures still parse directly; pre-drift fixtures (auto-detected
from `_PACKAGE_TO_SCHEMA`) must upgrade and then parse via the
same pipeline a user would invoke.
* `test_yaml_upgrade.py` gains targeted regressions for the new
handler: it renames the two profile fields, preserves their
contents, stamps `schema_version`, and defaults
`setpointmethod` to SCHEDULED.
Refs #1301, #1304. Post-#1306 follow-up: turns the upgrade CLI from
scaffold into a path that actually unblocks existing user YAMLs.
This was referenced Apr 19, 2026
sunt05
added a commit
that referenced
this pull request
Apr 20, 2026
CURRENT_SCHEMA_VERSION stayed at "2025.12" through several breaking changes (#879 STEBBS clean-up, #1240 DeepSoilTemperature rename, #1242 DHW volume-bound removal, #1261 setpoint split). The YAML-upgrade dispatch had no real schema versions to key on, get_schema_compatibility_message returned inverted verdicts, and StebbsProperties' default extra="ignore" silently swallowed removed fields. Phase A - retrospective bump: - CURRENT_SCHEMA_VERSION -> 2026.4 - SCHEMA_VERSIONS populated with 2025.12 / 2026.1 / 2026.4 entries - COMPATIBLE_VERSIONS lineage extended monotonically - sample_config.yml schema_version synced to 2026.4 Phase B - YAML upgrade tooling on real schema versions: - _PACKAGE_TO_SCHEMA maps release tags to real schema versions; synthetic labels retired, _HANDLERS dispatch keys monotonic - New _migrate_2025_12_to_2026_1 absorbs the #879 clean-up (Wallx1/Roofx1 -> *OuterCapFrac rename, IndoorAirStartTemperature / OutdoorAirStartTemperature -> Initial* rename, drop DHWVesselEmissivity plus runtime-state fields with logged reasons) - _migrate_2026_1_to_current extended for #1240 / #1242 / #1261 - TestNoSilentFieldDrops asserts each source STEBBS key either survives or appears in a rename/drop/split log line Phase C - guardrails: - New rule .claude/rules/python/schema-versioning.md - CI gate .github/workflows/schema-version-audit.yml + backing script scripts/lint/check_schema_version_bump.py; bypass via schema-audit-ok label - pytest test_schema_version_sync.py asserts sample_config carries CURRENT_SCHEMA_VERSION on every PR - prep-release skill gained a schema-audit step; audit-pr skill acknowledges the CI gate
sunt05
added a commit
that referenced
this pull request
Apr 20, 2026
Closes the remaining gaps in the retrospective schema-version work: - docs: rewrite schema_versioning.rst onto the actual CalVer lineage (2025.12 / 2026.1 / 2026.4) and the migration-registry compatibility model; add a 'YAML Schema Migrations' section to transition_guide.rst walking users through the 2026.1 (#879) and 2026.4 (#1240/#1242/#1261) upgrades; refresh schema-developer.rst and schema_cli.rst; note the migration chain in version-history/v2026.4.3.rst - audit: extend check_schema_version_bump.py to require a matching doc edit when CURRENT_SCHEMA_VERSION moves; broaden the workflow path filter to pick up schema doc changes; add regression tests for the merge-base + repo-root semantics - hardening: narrow the lazy-import in SchemaMigrator to ImportError only (so genuine registration bugs surface), guard the CalVer fallback path against synthetic hops without a registered handler (was silently no-op'ing), and cache the migration-pair registry used by is_schema_compatible - rule + audit-pr skill: Step 6 of schema-versioning.md lists the exact RST files that must move with every bump; audit-pr checklist + steps mirror the rule so review catches silent-docs PRs before CI does
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR extends STEBBS with configurable heating and cooling setpoint profiles, and improves robustness of wall and window surface-temperature calculations for the extreme
WWRcases (0and1).Description
This PR adds new STEBBS inputs for scheduled heating/cooling setpoints, wires the new model option through the data model and runtime path, and avoids unnecessary wall or window calculations when the corresponding surface does not exist.
1.1 New Input
HeatingSetpointTemperatureProfileUser-defined ten-minute heating setpoint profile.
CoolingSetpointTemperatureProfileUser-defined ten-minute cooling setpoint profile.
setpointmethodModel option controlling how space heating and cooling setpoints are determined in STEBBS.
0: ConstantUse fixed
HeatingSetpointTemperatureandCoolingSetpointTemperaturethroughout the day.1: DependentUse user-provided setpoint temperatures with metabolism-dependent variation.
2: ScheduledUse user-provided diurnal profiles from
HeatingSetpointTemperatureProfileandCoolingSetpointTemperatureProfile.1.2 New Function / New Features
HeatingSetpointTemperatureProfileandCoolingSetpointTemperatureProfilewhensetpointmethod = 2.WWR-based guards for surface-temperature calculations:WWR = 0: skip window calculationsWWR = 1: skip wall calculations0 < WWR < 1: calculate both wall and window temperatures1.3 Validation logics