Feature: STEBBS profiles for Heating and Cooling setpoints, Appliance, Occupants and Hot Water

[dayantur]

This PR implements STEBBS profiles of heating and cooling setpoints, appliance use, occupants, and hot water, and wires them through the full SuPy / Fortran SUEWS code.

Key changes

• Added a new dedicated profile class (TenMinuteProfile (144×2)) for higher‑resolution profiles
• Extended ArchetypeProperties and StebbsProperties so that Heating and cooling setpoints, occupants, appliance use, and hot water flow can be specified as profiles in YAML
• Updated to_df_state/from_df_state logic accordingly
• Extended the STEBBS Fortran code to accept Heating and cooling setpoint, cccupants, appliance, and Hot water flow profiles

Tests & fixtures

• Updated YAML fixtures (e.g. sample and benchmark configs) to be compatible with profile‑based setpoints.
• Adjusted STEBBS hot water volume tests to reflect the new intended behaviour

[github-actions]

Preview Deployed

Content	Preview URL
Site	https://suews.io/preview/pr-1038/
Docs	https://suews.io/preview/pr-1038/docs/

Note

This preview is ephemeral. It will be lost when:

• Another PR with site/ or docs/ changes is pushed
• Changes are merged to master
• A manual workflow dispatch runs

To restore, push any commit to this PR.

[dayantur]

hi @sunt05 and @suegrimmond - I and @yiqing1021 have been working on this for a month now. Despire being aware that best practice would be to work on small set of commits for a PR,in this specific case we preferred to have all of these changes together for continuity.

Happy to receive feedback and answer questions about what we have done so far. :)

[sunt05]

@dayantur I've been reviewing this PR and spotted a potential indexing issue that I'd like you to double-check.

In src/suews/src/suews_phys_stebbs.f95 line 834:

idx = imin / 10 + 1 !for 10 minutes resolution

The profile arrays are declared as DIMENSION(0:143, 2) — zero-indexed with valid indices 0–143.

But this calculation produces indices 1–144:

• At 00:00 (imin=0): idx=1, but should be 0
• At 23:50 (imin=1430): idx=144, but max valid index is 143

This would mean the first time bin is never used, and there's a potential out-of-bounds access at end of day.

Should this be idx = imin / 10 instead (without the + 1)?

Could you verify whether this is intentional or needs correcting?

[dayantur]

@dayantur I've been reviewing this PR and spotted a potential indexing issue that I'd like you to double-check.

In src/suews/src/suews_phys_stebbs.f95 line 834:

idx = imin / 10 + 1 !for 10 minutes resolution

The profile arrays are declared as DIMENSION(0:143, 2) — zero-indexed with valid indices 0–143.

But this calculation produces indices 1–144:

• At 00:00 (imin=0): idx=1, but should be 0
• At 23:50 (imin=1430): idx=144, but max valid index is 143

This would mean the first time bin is never used, and there's a potential out-of-bounds access at end of day.

Should this be idx = imin / 10 instead (without the + 1)?

Could you verify whether this is intentional or needs correcting?

Hi @sunt05 - this looks like a potential bug! Thanks for spotting this. @yiqing1021 what do you think?

[yiqing1021]

Hi @sunt05 , Thanks for spotting this bug. Yes, I agree we should remove +1.

[yiqing1021]

@dayantur I've been reviewing this PR and spotted a potential indexing issue that I'd like you to double-check.
In src/suews/src/suews_phys_stebbs.f95 line 834:

idx = imin / 10 + 1 !for 10 minutes resolution

The profile arrays are declared as DIMENSION(0:143, 2) — zero-indexed with valid indices 0–143.
But this calculation produces indices 1–144:

• At 00:00 (imin=0): idx=1, but should be 0
• At 23:50 (imin=1430): idx=144, but max valid index is 143

This would mean the first time bin is never used, and there's a potential out-of-bounds access at end of day.
Should this be idx = imin / 10 instead (without the + 1)?
Could you verify whether this is intentional or needs correcting?

Hi @sunt05 - this looks like a potential bug! Thanks for spotting this. @yiqing1021 what do you think?

Yes I argree Ting's point and have pushed the change

[sunt05]

Thank you both @dayantur @yiqing1021 for the prompt fix - please resolve the conflict and and I'll then take another look later.

[dayantur]

hi @sunt05 - conflict should be now resolved!