IFC-to-Energy Simulation Pipeline for the NBLA Platform
March 26, 2026
Press → to begin
IFC-to-Energy simulation pipeline integrated into the NBLA platform
Branch: feature/energy-analysis
A standalone Energy Converter service that takes IFC building models, preprocesses them, runs a full annual EnergyPlus simulation, and writes the results back into the NBLA platform — enriching both the IFC files and the MongoDB database.
Generates missing IfcSpace and IfcRelSpaceBoundary elements from raw IFC files
Full annual heating and cooling simulation with configurable thermal zones
Results and enriched IFC files pushed back to the main platform and stored in MongoDB
End-to-end flow from IFC upload to enriched results in the database
User selects an IFC from the project, sends it to the Energy Converter API with an EPW weather file
Converter generates missing IfcSpace and space boundary elements automatically
Select storeys, edit heating/cooling setpoints, lighting power, occupancy schedules
Full annual simulation in background (~1–5 min) with real-time log streaming to the frontend
Writes Pset_EnergyAnalysis properties into both preprocessed and original IFC files
Enriched IFC uploaded to project via Main API → results stored in MongoDB metadata.energyAnalysis
The Energy Converter runs as a standalone container and pushes results back through the Main API
When an IFC file lacks IfcRelSpaceBoundary, the system detects and generates them automatically
Geometric interfaces between thermal zones and building elements (walls, slabs, windows). They define the surfaces through which heat transfer occurs — required for zone-based energy simulation.
2a: Connects a space to a specific building element (wall, slab, window). Two opposing boundaries per interior partition.
2b: Virtual surfaces that close geometric gaps where 2a boundaries don't fully enclose a space.
• Fix non-coplanar opening boundaries
• Correct surface normal orientations
• Split non-convex boundaries (EnergyPlus requirement)
• OpenCascade Boolean subtraction for gap detection
Most IFC files from BIM tools (Revit, ArchiCAD) lack space boundaries. Without them, energy simulation is impossible. This auto-generation step makes any IFC file simulation-ready.
The full chain from simulation output to persisted database document and back to the UI
libs/schema/src/main/ifc.validation.ts
microservices/main/src/models/ifc.model.ts
Python main_v2.py → _push_results_to_nbla()
IFC document fetched via Main API → metadata.energyAnalysis → displayed as KPI cards (heating kWh, cooling kWh, total, zone count)
Key fix: markModified('metadata') is required because Mongoose doesn't auto-detect changes to nested Mixed-type objects
Key files modified in the feature/energy-analysis branch
New compose file for the Energy Converter container — pulls from Docker Hub, joins NBLA Docker network, configures env vars for Main API push-back
Added enrichedOriginalIfcId optional field to the energyAnalysis schema — tracks the enriched original IFC document
Fixed Mongoose persistence — added markModified('metadata') to ensure nested energy analysis fields are saved correctly
Modified _push_results_to_nbla to upload both the preprocessed IFC and the enriched original IFC back to the NBLA project storage
Nginx vhost for energy.nbla.ca — proxies HTTPS to the Energy Converter on port 8000
Added NBLA_ENERGY_IMAGE, container name, port variables. Updated script to include energy service in the build/start loop
Energy results are persisted inside the IFC document's metadata
New field: enrichedOriginalIfcId — added in this PR to track the enriched version of the original IFC, separate from the preprocessed version
Heating kWh, cooling kWh, total energy, zone count — shown as KPI cards in the UI
Two ObjectIds pointing to enriched IFC files stored as project documents in Storage
markModified('metadata') ensures Mongoose detects changes to the nested energy object and persists them
Every other NBLA service builds from source with docker compose build. The Energy Converter is different:
~15 minutes to compile — EnergyPlus, micromamba, Python scientific stack, runtime patches
Source lives in a separate repo — team members shouldn't need to clone or build it
Everyone runs the exact same image — no "works on my machine" issues with build patches
Registry: hub.docker.com/r/intentolabs/energy-services · Visibility: Private · Owner: intentolabs
The intentolabs account owns the private image. Here's how to add a new person:
We do not share the intentolabs Docker Hub password or access tokens with team members.
Each person uses their own Docker Hub account to pull the image. They only get Read access as a collaborator.
This way, access can be revoked individually if someone leaves the team.
Read — can pull the image (team members)
Admin — can pull and push (builders only)
Once the admin has added you as a collaborator, follow these steps:
Sign up at hub.docker.com (free) and send your username to the admin
Go to hub.docker.com/settings/security
→ New Access Token → name it (e.g. nbla-energy) → Read-only
The admin adds your username as a collaborator on the private repo with Read access
Everything a new team member needs to get up and running
Docker Desktop · Git · Docker Hub account with collaborator access to intentolabs/energy-services
Add *.nbla.ca entries to your system hosts file and trust the root CA certificate. See README for full list.
March 26, 2026