BuilDa: Synthetic Thermal Data Framework

• BuilDa is a thermal data generation framework using a validated single-zone Modelica model to simulate building thermal dynamics.
• It integrates a physics-based FMU with a Python orchestration layer, allowing large-scale, flexible, and parameterized synthetic data creation.
• The framework is validated against ASHRAE standards and demonstrates improved transfer-learning performance by matching building envelope parameters.

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 (Krug et al., 18 Aug 2025). 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 (Krug et al., 18 Aug 2025). 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 (Krug et al., 29 Nov 2025).

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 (Krug et al., 18 Aug 2025). 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 (Krug et al., 18 Aug 2025).

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 (Krug et al., 29 Nov 2025). 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 (Krug et al., 29 Nov 2025).

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 (Krug et al., 18 Aug 2025). 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 (Krug et al., 18 Aug 2025).

A complementary formulation presents the simplified single-zone balance as

$C_z$0

where $C_z$1 and the variables denote indoor temperature, outdoor temperature, internal gains, solar gains, HVAC power, and ventilation or infiltration heat flow (Krug et al., 29 Nov 2025).

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

$C_z$2

with $C_z$3 and $C_z$4 for each sublayer (Krug et al., 18 Aug 2025). 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_z$5

with $C_z$6 and segment-to-zone convective and radiative fractions specified in the configuration (Krug et al., 29 Nov 2025).

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 (Krug et al., 18 Aug 2025). The later description explicitly identifies co-simulation FMU v2.0.4 as the export target (Krug et al., 29 Nov 2025).

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 (Krug et al., 18 Aug 2025). Parallel execution is handled through multiprocessing.Pool; the later account notes that concurrent.futures.ProcessPoolExecutor can also be used (Krug et al., 29 Nov 2025).

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 $C_z$7 to $C_z$8 s at a step size of $C_z$9 s (Krug et al., 18 Aug 2025). 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 (Krug et al., 18 Aug 2025). 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” (Krug et al., 29 Nov 2025).

The input schedules comprise weather files in MOS format, occupancy or internal-gains profiles, window-opening profiles, and control strategy (Krug et al., 18 Aug 2025, Krug et al., 29 Nov 2025). Weather can use any EPW-to-MOS file, with examples including Munich, Prague, and London (Krug et al., 18 Aug 2025). The later description specifies built-in archetypes for internal gain and window opening, including CHR07_Single_with_work and CHR01_Couple_both_at_Work (Krug et al., 29 Nov 2025).

The converter layer is described as automatically computing dependent quantities such as room volume or maximum heating power (Krug et al., 18 Aug 2025), and more specifically as resolving zone area from dimensions, RC distributions, nominal HVAC power via DIN 18599-2, and link-resolver functions (Krug et al., 29 Nov 2025). 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 (Krug et al., 18 Aug 2025). Building-envelope ranges based on German TABULA data include U-values for walls, roof, and floor between $U_i$0 and $U_i$1, windows between $U_i$2 and $U_i$3, heat capacities between $U_i$4 and $U_i$5, zone area between $U_i$6 and $U_i$7, a roof or floor area ratio factor, and window-to-wall fractions per orientation (Krug et al., 18 Aug 2025). 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 $U_i$8 and day or night setpoints or external hysteresis or controller scripts (Krug et al., 18 Aug 2025).

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 (Krug et al., 29 Nov 2025). BuilDa can form the Cartesian product of parameter sets or draw random samples if distributions are used (Krug et al., 29 Nov 2025). One account also mentions support for cartesian product, Latin Hypercube, or Monte-Carlo sampling (Krug et al., 18 Aug 2025).

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 (Krug et al., 18 Aug 2025). 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 $U_i$9; 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 (Krug et al., 29 Nov 2025). 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 (Krug et al., 29 Nov 2025).

A concise comparison of reported dataset constructions is useful here.

Aspect	Reported instance
Source simulations	27 source buildings in one TL example (Krug et al., 18 Aug 2025); 243 source-building simulations in another demonstration (Krug et al., 29 Nov 2025)
Target buildings	1 target in the 27-source example (Krug et al., 18 Aug 2025); 2 targets, high- and low-inertia, in the later study (Krug et al., 29 Nov 2025)
Temporal resolution	$A_i$0 s example configuration (Krug et al., 18 Aug 2025); $A_i$1 s and about $A_i$2 lines per annual run in the 243-source demonstration (Krug et al., 29 Nov 2025)

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 $A_i$3 source buildings, with an example of $A_i$4 using all combinations of low, medium, and high U-value, C-value, and floor area (Krug et al., 18 Aug 2025). A target building is then selected, with an example given as $A_i$5, $A_i$6, and area $A_i$7, and one year of target data is generated (Krug et al., 18 Aug 2025). The target data are split into the first 30 days for fine-tuning and the remaining 335 days for testing (Krug et al., 18 Aug 2025). For each source building, a data-driven forecasting model, exemplified as an LSTM plus FC model predicting the next 4 timesteps from past $A_i$8 steps of $A_i$9, 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 (Krug et al., 18 Aug 2025).

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 $Q_{vent}$0, short schedules of 5–10 epochs, and smaller batch size (Krug et al., 18 Aug 2025). Comparison to a train-from-scratch model trained on the same 30-day target data is explicitly recommended (Krug et al., 18 Aug 2025). The use case cited is indoor-air-temperature forecasting for MPC or fault detection (Krug et al., 18 Aug 2025).

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 (Krug et al., 29 Nov 2025). It also trains target models from scratch using the same 30 days and their own hyperparameter tuning (Krug et al., 29 Nov 2025).

Reported results from the smaller transfer-learning demonstration are specific. The scratch model achieved RMSE $Q_{vent}$1 and MAE $Q_{vent}$2. The best fine-tuned source, sr3_acc, described as having the closest parameters, achieved RMSE $Q_{vent}$3. The worst fine-tuned source, sr27_ccc, described as the farthest, achieved RMSE $Q_{vent}$4. The stated trend is that fine-tuning always outperforms scratch, and that source buildings with U-values nearer the target yield lower errors (Krug et al., 18 Aug 2025).

The larger study reports that scratch baselines are RMSE $Q_{vent}$5 for the high-inertia target and $Q_{vent}$6 for the low-inertia target, while fine-tuned models reach median RMSE $Q_{vent}$7 for high inertia and $Q_{vent}$8 for low inertia (Krug et al., 29 Nov 2025). 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 (Krug et al., 29 Nov 2025). 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 (Krug et al., 29 Nov 2025).

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 (Krug et al., 18 Aug 2025, Krug et al., 29 Nov 2025). 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 $Q_{vent}$9 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 (Krug et al., 18 Aug 2025). The later paper describes parallel dispatch over all CPU cores but does not restate those exact timings (Krug et al., 29 Nov 2025).

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 (Krug et al., 18 Aug 2025, Krug et al., 29 Nov 2025). Example statistical analysis from the later study notes that daily mean indoor temperature spans $Q_{int}$0 to $Q_{int}$1 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% (Krug et al., 29 Nov 2025).

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 (Krug et al., 18 Aug 2025, Krug et al., 29 Nov 2025). 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 (Krug et al., 18 Aug 2025).

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 (Krug et al., 18 Aug 2025, Krug et al., 29 Nov 2025). 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.