90de1fc976
An LPG-boiler dwelling on the Summary → from_elmhurst_site_notes path mapped to main_fuel_type=26 (mains gas), making it indistinguishable from a mains-gas boiler downstream — wrong Table 12/32 cost / CO2 / PE (bottled LPG is ~10.30 p/kWh vs mains gas 3.48), and it defeats any "non-gas → gas only with a mains-gas connection" gate (an LPG dwelling looks already-gas). Root cause: the recommendation worksheets lodge the boiler carrier as §15.0 "Water Heating Fuel Type: Bottled gas" (§14.0 carries only SAP code 115, a Table 4b gas-family row, + "Main gas: Yes" in §14.2 — a mains-gas CONNECTION, not the heating fuel). "Bottled gas" was absent from `_ELMHURST_MAIN_FUEL_TO_SAP10`, so the §15.0 fuel resolved to None and `_elmhurst_gas_boiler_main_fuel` fell through priority-1 to the mains-gas meter flag → 26. Map "Bottled gas" → 3 (bottled LPG MAIN heating): code 3 routes via `API_FUEL_TO_TABLE_32`/`API_FUEL_TO_TABLE_12` → Table-code 3 (10.30 / 9.46 p/kWh). NOT the legacy "LPG bottled": 5 entry — API code 5 = anthracite, and `canonical_fuel_code` resolves the same-valued Table-32 code 5 to anthracite (3.64 p/kWh), so a 5 here mis-prices the dwelling as cheap solid fuel (verified: a 5 mapping moved SAP the WRONG way, 42.33 → 45.11; code 3 moves it to -6.40 vs the worksheet's -6.6499). Also add 3 to `_GAS_LPG_MAIN_FUEL_CODES` so the §15.0-lodged bottled-LPG water fuel is adopted as the boiler's space-heating carrier (priority 1) instead of the meter flag. Effect: main_fuel_type=3 (bottled LPG) and water_heating_fuel=3 (was None). Mains-gas certs still → 26 (full regression suite green bar the 3 pre-existing unrelated fails); the MissingMainFuelType tripwire still fires for genuinely-undeterminable carriers. Spec: SAP 10.2 Table 12 / RdSAP 10 Table 32 (PDF p.95) — bottled LPG main heating fuel code 3. 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 | ||
| 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 | ||
| 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