---
title: 'BuilDa: Synthetic Thermal Data Framework'
url: https://www.emergentmind.com/topics/builda
type: topic
---

# BuilDa: Synthetic Thermal Data Framework

Searching arXiv for the specified BuilDa papers and related context.
BuilDa is a thermal building data generation framework for producing synthetic data of adequate quality and quantity for transfer learning and broader machine-learning research on building thermal dynamics. It is centered on a single-zone Modelica model, exported as a Functional Mock-up Unit and simulated in Python, with the stated aim of removing the need for profound building simulation knowledge while still supporting large-scale, parameterized data generation [2508.12703]. The framework is presented as a response to two constraints identified in the literature: public thermal-building datasets are insufficient in both quality and quantity for transfer-learning studies, and existing data-generation approaches typically require expert knowledge in building simulation [2508.12703]. A later description broadens the framing from transfer learning to large-scale machine-learning research and reports a transfer-learning study involving the fine-tuning of 486 data-driven models [2512.00483].

## 1. Definition and system architecture

BuilDa consists of two tightly integrated layers. The first is a single-zone, building-physics model encoded in Modelica, based on the Modelica Buildings library and VDI6007-1 methods. This base model represents the zone air node, its envelope components including walls, roof, floor, and windows, interior mass such as furniture, ventilation, solar gains, and an ideal heating/cooling source [2508.12703]. The second is a Python-based orchestration and data-generation engine that converts user-friendly configuration files in YAML or JSON into FMU parameter sets via a converter layer, instantiates and runs the exported FMU in parallel using FMPy and the FMI 2.0.4 standard, and collects simulation outputs such as zone temperature and HVAC power as time-series CSV files [2508.12703].

The later account preserves this architecture but adds several implementation details. The Modelica building is described as being based on a Buildings library example and extended with an ideal HVAC source, a heat-pump COP curve, internal or external proportional or two-point controllers, window-opening and ventilation models per VDI 2078, and runtime retrofit logic for changing envelope parameters mid-simulation [2512.00483]. The Python layer is described as wrapping the FMU co-simulation loop into a higher-level API that reads user configuration, runs the converter layer, parameterizes the FMU, collects outputs, writes CSV files, and can apply retrofit changes at pre-specified timestamps [2512.00483].

This separation between a physics-based base model and a Python orchestration layer is central to the framework’s stated purpose. The Modelica/FMU level preserves a physically grounded thermal model, while the Python layer exposes high-level configuration and large-scale execution. This suggests a deliberate division between model fidelity and experimental throughput.

## 2. Thermal-dynamics formulation

At the core of BuilDa is a single-zone nodal RC network. One description gives the core energy balance on the uniform air node as

$$
C_z \frac{dT_z}{dt}
=
\sum_i U_i A_i \bigl(T_{out,i}(t)-T_z\bigr)
+ Q_{vent}(t)
+ Q_{int}(t)
+ Q_{sol}(t)
+ Q_{src}(t),
$$

where \(C_z\) is the thermal capacitance of the zone air plus interior mass; \(U_i\) and \(A_i\) are the heat-transfer coefficient and area of each envelope component; \(Q_{vent}\) captures ventilation and infiltration; \(Q_{int}\) covers occupants and plug loads; \(Q_{sol}\) accounts for solar radiation through glazing; and \(Q_{src}\) is the heating/cooling source split into convective and radiative fractions [2508.12703]. Ventilation is further specified as

$$
Q_{vent} = \rho \, c_p \, \dot m_{air}(t)\,(T_{amb}(t)-T_z),
$$

with \(\dot m_{air}\) computed from ACH or infiltration or window opening following VDI 2078 [2508.12703].

A complementary formulation presents the simplified single-zone balance as

$$
C_{\rm zone}\,\frac{dT_{\rm in}}{dt}
=
UA\,(T_{\rm out}-T_{\rm in})
+ Q_{\rm int}(t)
+ Q_{\rm sol}(t)
+ Q_{\rm HVAC}(t)
+ Q_{\rm vent}(t),
$$

where \(Q_{\rm vent}(t)=\dot m_{\rm vent}c_p(T_{\rm out}-T_{\rm in})\) and the variables denote indoor temperature, outdoor temperature, internal gains, solar gains, HVAC power, and ventilation or infiltration heat flow [2512.00483].

Within each solid element, BuilDa uses a three-node RC discretization. One description writes this as

$$
C_j \frac{dT_j}{dt}
=
\frac{T_{j-1}-T_j}{R_{j-1,j}}
+
\frac{T_{j+1}-T_j}{R_{j,j+1}},
$$

with \(R=1/(U\cdot A)\) and \(C=c\rho A d\) for each sublayer [2508.12703]. Another description states that each wall, along with floor, roof, and interior walls, is discretized into three RC segments per VDI 6007-1, and expresses segment dynamics as

$$
C_i\,\frac{dT_i}{dt}
=
\sum_{j\in\mathcal{N}(i)} H_{ij}(T_j-T_i)
+\Phi_{\mathrm{rad},i}
+\Phi_{\mathrm{conv},i},
$$

with \(H_i=1/R_i\) and segment-to-zone convective and radiative fractions specified in the configuration [2512.00483].

These formulations place BuilDa within the established lineage of reduced-order building thermal models. The emphasis is not on replacing detailed simulation with a learned surrogate, but on using a validated RC model as a synthetic data source for downstream ML and TL workflows.

## 3. Modelica-to-FMU-to-Python workflow

The operational workflow begins in a Modelica environment such as Dymola or OpenModelica. The single-zone model is assembled with parameterization over U-values, C-values, geometry, window properties, ventilation specifications, and controller logic, and then exported as an FMU using FMI 2.0 co-simulation [2508.12703]. The later description explicitly identifies co-simulation FMU v2.0.4 as the export target [2512.00483].

In Python, BuilDa relies on FMPy. The described workflow includes reading a high-level YAML or JSON configuration, converting user configuration into FMU parameters through the converter layer, instantiating the FMU, setting experiment start and stop times, applying parameter values, entering and exiting initialization mode, stepping through time, reading outputs such as zone temperature and source power, and writing results to CSV [2508.12703]. Parallel execution is handled through `multiprocessing.Pool`; the later account notes that `concurrent.futures.ProcessPoolExecutor` can also be used [2512.00483].

The configuration schema is divided into simulation settings, building properties, controller settings, input schedules, and sampling definitions. The `sim` block includes `start`, `stop`, and `step`, with an example of a year-long simulation from \(0\) to \(365 \times 24 \times 3600\) s at a step size of \(300\) s [2508.12703]. The `building` block includes dimensions such as `zone_length`, `width`, `height`, `n_floors`, envelope coefficients such as `U_wall`, `U_roof`, `U_floor`, `U_win`, thermal capacities such as `C_wall`, and window orientation fractions [2508.12703]. The later formulation names static parameters such as `zone_length`, `zone_width`, `n_floors`, `floor_height`, `UExt`, `UInt`, `UFloor`, `URoof`, `UWin`, `heatCapacity_wall`, `heatCapacity_floor`, `heatCapacity_roof`, `fAWin_{south,west,north,east}`, `airChangeRate`, `heatRecoveryRate`, `relative_heatPump_efficiency`, and `heatingCurve_steepness`, and also mentions predefined construction profiles such as “Concrete + ETICS” [2512.00483].

The input schedules comprise weather files in MOS format, occupancy or internal-gains profiles, window-opening profiles, and control strategy [2508.12703; 2512.00483]. Weather can use any EPW-to-MOS file, with examples including Munich, Prague, and London [2508.12703]. The later description specifies built-in archetypes for internal gain and window opening, including `CHR07_Single_with_work` and `CHR01_Couple_both_at_Work` [2512.00483].

The converter layer is described as automatically computing dependent quantities such as room volume or maximum heating power [2508.12703], and more specifically as resolving zone area from dimensions, RC distributions, nominal HVAC power via DIN 18599-2, and link-resolver functions [2512.00483]. This component is important because it mediates between user-friendly high-level specifications and the lower-level parameter set expected by the FMU.

## 4. Parameterization, sampling, and generated datasets

BuilDa exposes approximately 40 parameters [2508.12703]. Building-envelope ranges based on German TABULA data include U-values for walls, roof, and floor between \(0.1\) and \(1.4\ \mathrm{W/m^2K}\), windows between \(0.7\) and \(4.3\ \mathrm{W/m^2K}\), heat capacities between \(50\) and \(660\ \mathrm{kJ/m^2K}\), zone area between \(60\) and \(120\ \mathrm{m^2}\), a roof or floor area ratio factor, and window-to-wall fractions per orientation [2508.12703]. Input and control options include four base day types for occupancy and internal gains—workday, Saturday, Sunday, and holiday—with per-5-minute window-opening logic, as well as either a P-controller with configurable \(k_p\) and day or night setpoints or external hysteresis or controller scripts [2508.12703].

Variability can be introduced through discrete value sets, min/max/step ranges, or probability distributions. The later paper states that currently uniform distributions are supported and that normal and log-normal are planned [2512.00483]. BuilDa can form the Cartesian product of parameter sets or draw random samples if distributions are used [2512.00483]. One account also mentions support for cartesian product, Latin Hypercube, or Monte-Carlo sampling [2508.12703].

The framework recommends different strategies for different experimental goals. For detailed sensitivity studies, a full cartesian product over 3–5 values per key parameter is suggested; for broader coverage, Latin Hypercube sampling over continuous ranges is suggested; and for “divide-and-conquer” TL source selection, families grouped by one parameter at a time are suggested [2508.12703]. These recommendations imply that BuilDa is designed not merely for brute-force generation, but for controlled exploration of source-target relationships in transfer learning.

The large-scale generation workflow is described as a sequence: define parameter variation sets in configuration files; resolve dependencies through the converter layer; build a variation list of length \(N\); dispatch FMU runs in parallel across CPU cores; write time series to `output_<idx>.csv`; write metadata to `output_<idx>_meta.json`; and compile a master index file listing all runs and associated paths [2512.00483]. Time-series CSV files can contain columns such as `[time, T_in, T_out, Q_HVAC, Q_int, windowOpen, …]`, while metadata JSON records static and input parameters [2512.00483].

A concise comparison of reported dataset constructions is useful here.

| Aspect | Reported instance |
|---|---|
| Source simulations | 27 source buildings in one TL example [2508.12703]; 243 source-building simulations in another demonstration [2512.00483] |
| Target buildings | 1 target in the 27-source example [2508.12703]; 2 targets, high- and low-inertia, in the later study [2512.00483] |
| Temporal resolution | \(300\) s example configuration [2508.12703]; \(900\) s and about \(35{,}040\) lines per annual run in the 243-source demonstration [2512.00483] |

The difference between the 27-source and 243-source demonstrations is not a contradiction so much as a change in experimental scale. A plausible implication is that BuilDa is intended to support both compact proof-of-concept transfer-learning studies and larger factorial designs.

## 5. Transfer-learning workflow and empirical findings

BuilDa is explicitly motivated by transfer learning. One documented workflow begins by generating one year of data for \(N\) source buildings, with an example of \(N=27\) using all combinations of low, medium, and high U-value, C-value, and floor area [2508.12703]. A target building is then selected, with an example given as \(U=0.15\ \mathrm{W/m^2K}\), \(C=430\ \mathrm{kJ/m^2K}\), and area \(=110\ \mathrm{m^2}\), and one year of target data is generated [2508.12703]. The target data are split into the first 30 days for fine-tuning and the remaining 335 days for testing [2508.12703]. For each source building, a data-driven forecasting model, exemplified as an LSTM plus FC model predicting the next 4 timesteps from past \(M\) steps of \([T_{out}, G_{dir}, G_{diff}, T_{in}, Q_{src}]\), is pretrained, hyperparameter search is performed on a source validation split, and the pretrained source model is fine-tuned on the 30-day target training data with low learning rate and optional freezing of lower layers [2508.12703].

Best practices reported for this process include reporting both RMSE and MAE on the test set, early stopping based on validation MAE, low-learning-rate fine-tuning such as \(10^{-4}\), short schedules of 5–10 epochs, and smaller batch size [2508.12703]. Comparison to a train-from-scratch model trained on the same 30-day target data is explicitly recommended [2508.12703]. The use case cited is indoor-air-temperature forecasting for MPC or fault detection [2508.12703].

The later study expands the design. It uses 243 source buildings and 2 target buildings at parameter edges, defines the task as one-hour-ahead indoor temperature forecasting with an LSTM(+FC) model, pretrains 243 distinct source models with per-model hyperparameter tuning on source data, fine-tunes each pretrained model on limited target data consisting of 30 days per season, and evaluates on the remaining part of each season, reporting test RMSE [2512.00483]. It also trains target models from scratch using the same 30 days and their own hyperparameter tuning [2512.00483].

Reported results from the smaller transfer-learning demonstration are specific. The scratch model achieved RMSE \(=1.03\ \mathrm{K}\) and MAE \(=0.74\ \mathrm{K}\). The best fine-tuned source, `sr3_acc`, described as having the closest parameters, achieved RMSE \(=0.05\ \mathrm{K}\). The worst fine-tuned source, `sr27_ccc`, described as the farthest, achieved RMSE \(=0.16\ \mathrm{K}\). The stated trend is that fine-tuning always outperforms scratch, and that source buildings with U-values nearer the target yield lower errors [2508.12703].

The larger study reports that scratch baselines are RMSE \(\approx 0.97\ ^\circ\mathrm{C}\) for the high-inertia target and \(1.08\ ^\circ\mathrm{C}\) for the low-inertia target, while fine-tuned models reach median RMSE \(<0.1\ ^\circ\mathrm{C}\) for high inertia and \(<0.15\ ^\circ\mathrm{C}\) for low inertia [2512.00483]. Violin plots are reported to show that for the high-inertia target, wall U-value closeness dominates TL success and other parameters are minor, whereas for the low-inertia target, wall U and window U both strongly affect fine-tuning RMSE [2512.00483]. Heatmaps are reported to show two-way parameter interactions, with best source-to-target fits when wall U matches and, for low inertia, window U also matches [2512.00483].

These findings support a specific interpretation of source selection in building TL: thermal similarity, particularly as mediated by envelope parameters, is not incidental but predictive of transfer performance. The papers do not present this as a universal criterion, but they do report it as a clear empirical trend in the studied settings.

## 6. Validation, performance, and scope

BuilDa’s thermal model was validated against ANSI/ASHRAE 140-2004 test cases TC600 and TC900 for annual heating and cooling, and TC600FF and TC900FF for minimum, maximum, and mean temperatures, with all tests passing within IEA tolerances or established software reference bands [2508.12703; 2512.00483]. This validation is significant because the framework’s downstream ML utility depends on the physical plausibility of the generated data.

Performance measurements are reported for year-long batch generation. On an Intel i7-6600U with 4 cores and 20 GB RAM, 100 one-year simulations at \(300\) s resolution ran in approximately 12.5 minutes with the internal P-controller, corresponding to about 7.5 s per simulation, and approximately 48 minutes with an external two-point controller, corresponding to about 29 s per simulation [2508.12703]. The later paper describes parallel dispatch over all CPU cores but does not restate those exact timings [2512.00483].

The generated datasets are not limited to raw indoor temperature traces. Reported outputs include zone temperature, HVAC power, internal gains, window-opening state, and outdoor temperature [2508.12703; 2512.00483]. Example statistical analysis from the later study notes that daily mean indoor temperature spans \(12\,^\circ\mathrm{C}\) to \(28\,^\circ\mathrm{C}\) across five random variations, that 90th-percentile indoor temperatures rise with better insulation while energy demand drops, and that retrofits involving wall and window U-value reductions at day 2 or 4 reduce heating load by about 30% [2512.00483].

The framework is described as open-source on GitHub and designed to be extended, with examples including multi-zone extensions, RL Gym interfaces, and RL gym wrappers [2508.12703; 2512.00483]. Since the reported implementation is single-zone, any multi-zone interpretation remains prospective rather than demonstrated in the cited material. What is established is that BuilDa combines a validated RC-based Modelica model, a converter layer that hides much of the low-level modeling complexity, and a Python driver for parallel synthetic-data generation at scales suitable for transfer-learning experiments [2508.12703].

A recurring misconception in this area is that synthetic building datasets are useful only for pretraining generic models and not for analyzing source-target relations. The BuilDa studies argue otherwise by explicitly structuring source families, preserving metadata, and analyzing parameter proximity effects on fine-tuning outcomes [2508.12703; 2512.00483]. Another possible misconception is that usability must come at the expense of physical validity; the framework’s combination of FMU-based simulation and ASHRAE 140 validation is presented precisely to counter that dichotomy.

Source: https://www.emergentmind.com/topics/builda