5d556faf86
`u_roof` only implemented the joist column, so roofs lodged insulated at rafters (`roof_insulation_location == 1`) were mis-billed at the joist U on both the API and Summary paths — under-stating loss, over-rating SAP. RdSAP 10 §5.11.2 Table 16 (spec p.42-43) gives a distinct "insulation at rafters" column (2): the rafter cavity is shallower than a loft void, so the same depth yields a higher U (200 mm: rafters 0.29 vs joists 0.21). §5.11 Table 18 (p.45) likewise carries a rafters column (2) for unknown / as-built thickness (footnote (1): "The value from the table applies for unknown and as built") — band A-D = 2.30, E = 1.50, F = 0.68, diverging from the joist column's 100 mm-equivalent 0.40 default (footnote (4)). - add `_ROOF_RAFTERS_BY_THICKNESS` (Table 16 col 2) + `_ROOF_RAFTERS_BY_AGE` (Table 18 col 2) to rdsap_uvalues; `u_roof` selects them via a new `insulation_at_rafters` flag (ignored for flat / sloping-ceiling roofs). - `heat_transmission` derives the flag PER BUILDING PART from `roof_insulation_location` (gov-API int 1 / Summary "R Rafters"), which also fixes the multi-part dedup-roof-join problem: each part's own location now drives its U, replacing the unattributable joined `epc.roofs[]` description. Worksheet-validated to 1e-4: simulated case 41 (4-bp — Ext1 rafters 200mm → 0.29, Ext3 rafters As-Built band F → 0.68; roof total 24.8350) and case 42 (6 variants — rafters 50mm → 0.88, rafters unknown band C → 2.30, joists/none unchanged). Case 40 stays exact (roof 35.340, total 441.1606); worksheet harness 47/47. Corpus within-0.5 66.9% → 66.5% (gates 0.65/1.08 hold) — a spec-correct shift, NOT a regression: all 15 corpus rafter certs carry redacted (None) thickness yet lodge roof EER 2-4 (insulated), so the open API blanked a specified thickness and the spec's unknown-rafter 2.30 default correctly over-states them. Recovery needs a roof-EER→thickness inference on the API path (follow-up), not a change to the U-table. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .devcontainer | ||
| .github/workflows | ||
| .idea | ||
| .vscode | ||
| applications | ||
| asset_list | ||
| backend | ||
| backlog | ||
| datatypes | ||
| deployment/terraform | ||
| docs | ||
| domain | ||
| epr_data_exports | ||
| etl | ||
| harness | ||
| infrastructure | ||
| model_data/requirements | ||
| orchestration | ||
| recommendations | ||
| repositories | ||
| sap worksheets | ||
| scripts | ||
| sfr/principal_pitch | ||
| survey_report | ||
| tests | ||
| utilities | ||
| utils | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| __init__.py | ||
| ara_backend_design.md | ||
| BaseUtility.py | ||
| CLAUDE.md | ||
| conftest.py | ||
| CONTEXT.md | ||
| devcontainer.sh | ||
| Dockerfile.test | ||
| Dockerfile.test.dockerignore | ||
| Makefile | ||
| MEMORY.md | ||
| next_claude_prompt.txt | ||
| package-lock.json | ||
| package.json | ||
| pyproject.toml | ||
| pyrightconfig.json | ||
| pytest.ini | ||
| README.md | ||
| run_lambda_local.sh | ||
| serverless.yml | ||
| test.requirements.txt | ||
| tox.ini | ||
| UBIQUITOUS_LANGUAGE.md | ||
Model Repository
This repository contains the code pertaining to the development of the data science and machine learning products being utilised by Hestia.
The different folders in this repository relate to services that can be used independently, or can be imported and used as part of a larger application
Getting Started
Prerequisites
Dev Container Setup
This repo uses a Docker Compose-based dev container. The model-backend service joins a shared-dev Docker network so it can communicate with other local services (e.g. a frontend container) running on your machine.
VS Code users: The initializeCommand in devcontainer.json creates the shared-dev network automatically before the container starts. No manual step required — just open the repo and select Reopen in Container.
Non-VS Code / CI workflows: Run the following once before starting the container:
make dev-setup
This is idempotent and safe to re-run if the network already exists.
Folders
backend/
This folder contains the code for the fastapi backend service, which provides an interface to much of the functionality in this repository, for the frontend
model_data/
This folder contains related to the reading and preparation of assessment model data, including pulling out epc attributes
Testing
All tests can be run, against the configuration in pytest.ini running
pytest
This will run the complete panel of tests and report on coverage in the locations specified by the pytest.ini file.
To run tests in a specific service, e.g. inside of model_data, simply run
pytest --cov-config=model_data/.coveragerc --cov=model_data
This will produce the test results and coverage reports