Digital Twin of the Thermal-Conductivity Apparatus

1. Summary

What to build this week: a calibrated physics model of the commercial thermal-conductivity apparatus, connected live to the apparatus's data, estimating thermal conductivity k, interface (contact) resistance and heat-loss coefficient online, with a dashboard and a "virtual experiment" mode. That is a digital shadow with an honest predictive model. Closing the loop (the twin choosing the next set-point or stopping a run) is a day-5 stretch goal if the instrument accepts commands; otherwise it becomes the first task of week 2.

Why the timeline changed: version 1 assumed the team would build a hobby rig from scratch. The apparatus is real lab equipment, so the mechanical build disappears and the critical path becomes (a) getting data out of the instrument and (b) understanding its physics well enough to calibrate a model. Both fit in a week for six people, provided the instrument's data is reachable (see Section 4.2 on what to check on day 1).

What "truly replicates real life" means operationally: the model's predictions at sensors it was not fitted to fall inside the model's own stated uncertainty, on runs it has never seen, for the operating range you declare. Nothing more, nothing less. Industrial twins that work (Rolls-Royce engines, Aarhus incubator, Willcox's UAV) all share three traits: a fit-for-purpose model, few physically meaningful tunable parameters, and continual verification, validation and uncertainty quantification (VVUQ). Copy that discipline.

Three capabilities the twin must offer, and how each is implemented:

The honest caveat on one week: steady-state thermal runs take 30 minutes to 2 hours each. You can build and wire the whole twin in a week, but a proper validation (≥3 materials × ≥2 thicknesses) is roughly 15 hours of instrument time and will run in the background into week 2. Plan for that from day 1 by queuing instrument time.

2. Context and assumptions

2.1 Team

Everyone is willing to work across the pipeline, so pair people across disciplines on each module (a CS engineer with a chemical engineer on the estimator, the energy engineer with a CS engineer on the model). The point of this first week is to make the whole team fluent in every layer before the reactor work, where the chemical engineers' knowledge becomes the critical path.

2.2 Facilities and inputs

• Apparatus: a commercial thermal-conductivity instrument (model to be confirmed). Until the model is known, this document treats it as a steady-state source/sample/sink stack (ASTM E1225 or D5470 style). Section 4.2 lists what to check once the model is known; several choices below depend on it.
• Makerspace: full access (3D printers, bench tools). Used this week only for fixtures, sensor mounts and sample preparation, not for building the instrument.
• Workstation: a strong machine for model training. This week it runs Bayesian calibration (MCMC) and sensitivity sweeps; later it trains surrogates and reactor models. Treat it as a shared server: one user account per person, a shared conda/uv environment, jobs run through tmux or a simple queue.
• Database: a PostgreSQL database of catalysis data for many reactions will be provided; details unknown. Recommendation: use PostgreSQL (with the TimescaleDB extension if allowed) as the twin's own data store from day 1 so the two live side by side. Section 7 covers what to ask about the catalysis database.
• Use modes: the apparatus serves both teaching labs and research experiments. The twin therefore needs a "lab mode" (guided run, live comparison with theory, auto-generated report) and a "research mode" (full parameter estimation, experiment design, raw-data access). Both are the same code with different configuration.

2.3 Scope of this week versus later

3. The physics, in terms a CS engineer can act on

3.1 Fourier's law and the resistance analogy

Fourier's law: heat flux q″ = −k dT/dx, with k in W/(m·K). Treat temperature difference as voltage, heat rate Q (W) as current, and thermal resistance R = L/(kA) (K/W) as electrical resistance. At steady state the stack is a series circuit:

Q = ΔT_total / ( R_c,hot + L/(k·A) + R_c,cold )

If Q is known and the drop across the sample ΔT_s is measured, then k = Q·L/(A·ΔT_s). Most commercial instruments do exactly this, either measuring Q directly (heater power, with guards to stop losses) or comparatively, by placing reference bars of known k_ref in series with the sample so that the same Q flows through both: k_s = k_ref(ΔT_ref/L_ref)(L_s/ΔT_s). With a reference bar above and below the sample, the mismatch between the two flux estimates is a live measure of heat loss — use it as a health signal.

3.2 The transient model (what the twin actually integrates)

ρc ∂T/∂t = ∂/∂x ( k ∂T/∂x ) − (hP/A)(T − T_ambient)

• Diffusivity α = k/(ρc) sets the time scale τ ≈ L²/α. A 10 mm polymer disc (α ≈ 1×10⁻⁷ m²/s) has τ ≈ 1000 s; add the metal blocks' thermal mass and steady state takes tens of minutes to ~2 h. This wait is why transient estimation is worth doing: the twin can report k with error bars long before the instrument's own steady-state readout.
• Boundary conditions: Dirichlet (fixed T, e.g. a controlled block), Neumann (fixed flux: constant-power heater, or zero flux for perfect insulation), Robin/convective (−k∂T/∂x = h(T − T_∞) for a fan-cooled sink and for lateral losses).
• Contact resistance: a temperature jump ΔT = Q·R_c at each interface, modelled as an interface conductance. It is usually the dominant error and changes with grease, clamping pressure and surface flatness.
• Lumped capacitance: if the Biot number hL_c/k_block < 0.1, a metal block is effectively isothermal and obeys m c dT/dt = Q_in − Q_out. This turns the stack into a small RC network, the same structure the Aarhus incubator twin uses, and it is fast enough to run inside a Kalman filter.

3.3 Identifiability — decide this before fitting anything

At steady state with one sample thickness, k and R_c are confounded: you only observe their series sum. Three ways to separate them: sensors on or inside the sample faces; testing 2–4 thicknesses and regressing total resistance against L (slope 1/(kA), intercept = contact term; this is the ASTM D5470 logic); or transient data. Likewise h_loss and the true delivered power are confounded unless reference bars (or a guard) are present. Before writing the estimator, compute Beck-style scaled sensitivity coefficients θ ∂T/∂θ for each sensor the instrument exposes; if two parameters have proportional curves, they are not separately identifiable with that sensor set and you must change the experiment (power steps, multiple thicknesses) rather than the code.

3.4 Which standard method the instrument follows

ASTM E1225 defines a homogeneous specimen as one whose apparent conductivity does not vary with thickness or cross-section by more than ±5 %. That is a ready-made validation test. Your twin will be "E1225-inspired", not compliant; say so in reports.

3.5 Numerical approaches

4. Working with real lab equipment

4.1 Why this changes the plan

A commercial instrument gives you traceable geometry, a built-in heater controller, calibrated sensors and (usually) its own steady-state readout. It takes away freedom: you may not be able to add sensors where identifiability wants them, change the excitation profile, or command the heater from your code. The twin's job therefore shifts from "measure k" (the instrument already does that) to: estimate k earlier and with uncertainty, track drift of contact resistance and losses across runs, detect faults, simulate experiments that have not been run, and propose the next run.

4.2 Day-1 checklist once the model number is known

4.3 Adding sensors to a commercial instrument (only if needed)

If the instrument exposes too few channels for identifiability, add external sensors at accessible points (outer insulation surface, coolant inlet/outlet, ambient, and if the vendor allows, sample faces). Use NTC thermistors with an ADS1115, or PT100/PT1000 with MAX31865, on an ESP32 or Raspberry Pi, emitting JSON at 1 Hz. Inter-calibrate all added sensors against the instrument's own sensors by soaking them together at three temperatures; only relative offsets matter for ΔT. Print mounts in PETG/ASA/PC, not PLA, near warm surfaces. Keep added wiring away from the heater and outside the guard; otherwise you perturb the measurement you are twinning.

4.4 Lab mode and research mode

Lab-mode runs are not throwaway: hundreds of student runs on reference samples are exactly the dataset you need to learn instrument drift, operator effects and sensor ageing, and to validate the model across time.

5. Twin architecture

5.1 Layers

5.2 Where this sits in the reference architectures

Grieves (2002/2014)

Physical product, virtual product, and the data connections between them. Your "connections" are the MQTT bus and the database.

NASA, Glaessgen & Stargel (2012)

A probabilistic, as-built simulation using the best physical models and sensor updates to mirror its twin. The twin is of this instrument with its contact resistances, not a generic one.

Kritzinger et al. (2018)

Digital model (manual data flow) → digital shadow (automatic physical→digital) → digital twin (automatic both ways). Target: shadow by day 4; twin by day 5 or week 2 depending on instrument control. Report your level honestly.

Tao et al. five dimensions

Physical entity, virtual entity, services, data, connections. Name your services explicitly in the code (services/early_k.py, services/forecast.py, services/anomaly.py, services/virtual_experiment.py, services/next_run.py).

ISO 23247 (2021)

The instrument is an "observable manufacturing element"; ingest is the device-communication entity; model + estimator form the digital-twin entity; the dashboard is the user entity. Use its vocabulary in the architecture diagram.

NASEM (2023)

A twin is dynamically updated, predictive, informs decisions, and the virtual–physical interaction is bidirectional. The model must be fit for purpose; VVUQ is continual. This report's capability table (Section 1) is written to that definition.

Digital Twin Consortium Capabilities Periodic Table

A checklist, not an architecture. Tick: data acquisition and integrity, streaming, real-time monitoring, prediction, simulation, alerts, orchestration (later).

5.3 Synchronisation (the inverse problem)

1. Steady-state algebra: detect steady state (|dT/dt| < 0.01 K/min on all channels for 10 min, via rolling regression slope), then apply the instrument's own formula. This reproduces the vendor readout and is your sanity check.
2. Batch nonlinear least squares with scipy.optimize.least_squares (residuals T_meas − T_model(θ); loss="soft_l1", bounds, x_scale). Covariance ≈ s²(JᵀJ)⁻¹ gives error bars from day one.
3. Recursive estimation: linear Kalman filter on the temperature field (the method-of-lines model is linear in T, so the KF is exact) with θ fixed between refits; normalised innovations are the fault detector (the Aarhus tutorial uses this to detect a lid opening). Week 2: unscented KF on the augmented state [T, k, R_c, h] with random-walk parameters, via FilterPy.
4. Bayesian calibration (workstation): emcee or PyMC with physical priors (e.g. PMMA k ∈ [0.15, 0.25]; log-normal R_c), ArviZ diagnostics; add a Kennedy–O'Hagan Gaussian-process discrepancy term if residuals show structure. This is the Kapteyn–Willcox view in miniature: each asset keeps a unique digital state on a shared model, updated by Bayesian inference.
5. Sensitivity and UQ: SALib (Sobol/Morris) to rank which uncertain inputs dominate k; Monte Carlo propagation of sensor accuracy.

5.4 Validation criteria (write these down before running)

• Solver verification: finite difference matches the analytical slab solution within 0.5 %; energy conservation to 1e-8; Crank–Nicolson shows second-order convergence.
• Model validation: on held-out runs, ≥90 % of sensor readings fall inside the model's 2σ band; k from the twin agrees with the certified reference within its stated uncertainty; the ±5 % thickness-independence test passes.
• Twin metrics: time for the twin's k estimate to converge versus time for the instrument to reach steady state; forecast error of time-to-steady-state; anomaly false-alarm rate; end-to-end latency from reading to dashboard.
• Re-validate after any change to the instrument, sample mounting procedure or sensor set.

5.5 Virtual experiments

Expose a function simulate_run(material, thickness, T_hot, T_cold, duration, theta_samples) that integrates the model forward from either the current filtered state or a cold start, for each of N posterior samples of θ, and returns median and 5–95 % bands for every virtual sensor, time-to-steady-state and the expected ΔT across the sample. Two uses: (a) teaching — students predict before they measure; (b) research — screening whether a proposed sample/temperature combination will give a resolvable ΔT at all (Section 3 example: an aluminium disc 5 mm thick gives ΔT ≈ 0.02 K, which no instrument resolves well). Keep virtual runs in the same database with origin=simulated so they are never confused with measurements.

5.6 Optimisation

• Stop-early rule: end a run when the posterior standard deviation of k is below a target (e.g. 3 %) — this is the most immediately valuable decision the twin can make and needs no instrument control, only a recommendation.
• Set-point selection: choose T_hot, T_cold and thickness sequence to maximise expected information about θ (D-optimal design: maximise det(JᵀJ) over candidate runs using the current model). Implement with the Jacobians you already compute for least squares.
• Bayesian optimisation (BoTorch or scikit-optimize) when the objective is expensive, e.g. minimising total instrument time to characterise a material set. This is the self-driving-lab pattern (Burger et al., 2020) in miniature and is the template for the reactor work.

6. The one-week plan

Assumes instrument data is reachable by day 2 and the team can commit roughly 25–30 hours each this week. Instrument time is the scarce resource: book it in blocks from day 1 and run reference samples continuously in the background.

6.1 Day by day

6.2 Hard gates

• End of day 2: a measured run exists in the database and the model reproduces the analytical solution. If the instrument interface is blocked, switch immediately to CSV-export file watching and do not wait for a vendor reply.
• End of day 4: the digital shadow runs for one uninterrupted hour without crashing. Nothing else is added until this holds.
• End of day 5: a written list of what is validated, what is not, and what the twin's declared operating range is.

6.3 Repository layout

thermal-twin/
├── pyproject.toml            # pinned dependencies; package "thermotwin"
├── configs/                  # instrument_<model>.yaml, materials.yaml, estimator.yaml, modes/lab.yaml, modes/research.yaml
├── firmware/esp32/           # only if extra sensors are added
├── hardware/                 # fixtures, sensor mounts (STEP + source), photos
├── db/                       # schema.sql, migrations/ (alembic), seeds/
├── src/thermotwin/
│   ├── interfaces.py         # Asset / Model / Estimator / Store / KnowledgeBase protocols
│   ├── physics/              # analytical.py, lumped.py, fd1d.py, fem2d.py, materials.py
│   ├── estimation/           # steady.py, least_squares.py, kalman.py, bayes.py, sensitivity.py
│   ├── io/                   # instrument_<model>.py, csv_watcher.py, serial_reader.py, mqtt_bridge.py, schema.py, storage_pg.py, replay.py
│   ├── services/             # early_k.py, forecast.py, anomaly.py, virtual_experiment.py, next_run.py, report.py
│   └── twin/                 # state.py, runner.py, decisions.py, safety.py
├── dashboard/                # app.py, pages/lab.py, pages/research.py
├── notebooks/                # exploration only; never imported
├── data/                     # raw/ (immutable), processed/; DVC or git-lfs
├── tests/                    # unit, property (hypothesis), replay regression, @pytest.mark.instrument
├── docs/                     # MkDocs: architecture, derivations, SOPs, data dictionary, assumptions log
└── .github/workflows/ci.yml  # ruff, mypy, pytest

interfaces.py is the investment that pays off in the reactor phase: FD1DConductionModel and a future PackedBedReactorModel both expose step(state, u, theta, dt), observe(state), params() and param_priors(), so every estimator, service and dashboard page is reused unchanged.

6.4 Exactly what Python is used for, per module

6.5 Database schema (PostgreSQL, same server as the catalysis data if permitted)

instruments(id, model, serial_no, geometry_json, calibration_cert, installed_on)
runs(id, instrument_id, mode, operator, sample_id, thickness_m, clamp_force_n, started_at, ended_at,
     config_hash, git_commit, origin)                 -- origin: measured | simulated | replay
samples(id, material, supplier, lot, nominal_k, notes)
telemetry(time, run_id, channel, value, unit)         -- hypertable (TimescaleDB) or partitioned by run
estimates(time, run_id, estimator, param, mean, sd)   -- k, R_c_hot, R_c_cold, h_loss, rho_c
posteriors(run_id, method, param, sample_idx, value)  -- MCMC draws
events(time, run_id, kind, payload_json)              -- steady_state, anomaly, recommendation, command
materials(name, k, rho, c, T_ref, k_dTdx, source)     -- material library (also loaded into configs)

Keep telemetry long-format (one row per channel per timestamp) so new instruments add channels without schema changes. Never store derived quantities in the telemetry table; they go in estimates with the estimator version.

6.6 Working practices

• Trunk-based Git; short branches; one reviewer per pull request from a different discipline; green CI before merge.
• pre-commit with ruff and mypy; pinned dependencies; one shared environment on the workstation.
• Immutable raw data; every artefact records the git commit and config hash that produced it.
• A 15-minute stand-up at the instrument each morning; the person who ran the overnight reference run reports first.
• One person owns documentation each day; the assumptions log is updated whenever a model-form decision is made.

6.7 Pitfalls

7. PostgreSQL and the catalysis database

7.1 Questions to ask whoever provides it

• Schema and documentation: tables, keys, units, provenance columns. Is it a dump of a known public database (Catalysis-Hub, CatApp-like, NIST SRD 17-like, a literature kinetics compilation) or in-house data?
• What kind of quantities: DFT adsorption/reaction energies (Catalysis-Hub style, ~100,000 entries of electronic-structure energies), measured kinetic parameters (Arrhenius A, E_a, reaction orders, with conditions), or turnover frequencies under stated conditions? These need different models.
• Validity ranges: temperature, pressure, catalyst composition, facet/support. Parameters outside their range are priors with wide variance, not facts.
• Access: read-only role? Can you add schemas (e.g. twin.*) to the same server, or must the twin's data live elsewhere?
• Size and update cadence; whether there is an API or only SQL.

7.2 How the twin will use it

Through a read-only KnowledgeBase adapter (io/catalysis_db.py) that converts records into ParameterPrior objects with value, uncertainty, units, provenance (table, record id, DOI) and validity range. The reactor model's param_priors() returns these; the same estimators that today update k from live data will then update kinetic parameters, with the database as prior and the experiment as evidence. Build the adapter against a tiny mock table this week (two rows is enough) so the interface exists before the real data arrives.

7.3 Modelling path toward the reactor twin

1. Isothermal CSTR with power-law kinetics (an ODE as simple as lumped.py).
2. Non-isothermal packed bed: species balances plus an energy balance that is the heat equation of Section 3 with a reaction source term; reuses fd1d.py directly.
3. Microkinetics (Cantera surface kinetics) seeded from database energies.
4. Hybrid physics + ML residual models trained across the database on the workstation.
5. Autonomous experiment loop: the next-run service becomes Bayesian experimental design over kinetic parameters.

8. Toolkit decisions

Standards to cite: ASTM E1225, D5470, C177/ISO 8302, C518/ISO 8301, E1461, ISO 22007-2; GUM (JCGM 100:2008) for uncertainty; ISO 23247-1…4:2021; ISO/IEC 30173:2023; ISO/IEC 30141; FMI; AAS (IEC 63278); OPC UA; MQTT (OASIS). Check IEEE 2888 working-group status before citing it.

9. Lessons from past digital twins

On industrial numbers: figures such as GE's "1.2 million digital twins" or Rolls-Royce's "400 unplanned maintenance events prevented annually" come from the companies or their vendors. Cite them as claims. The National Academies (2023) note that enthusiasm for digital twins currently outweighs evidence of their success.

Prioritised lessons: (1) start from the decision the twin informs; (2) few, physical, continuously updated parameters; (3) estimation beats adding sensors; (4) VVUQ and data quality are continual, not a phase; (5) design for reuse; (6) plan a real, small virtual→physical loop so the project does not stall at the shadow stage.

10. Sources

10.1 Referenced in this report

Digital-twin foundations and reviews

• Grieves, M. (2014). Digital Twin: Manufacturing Excellence through Virtual Factory Replication (white paper); Grieves & Vickers (2017), Springer chapter.
• Glaessgen, E. & Stargel, D. (2012). The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles. AIAA 2012-1818. ntrs.nasa.gov
• Kritzinger, W. et al. (2018). Digital Twin in manufacturing: a categorical literature review. IFAC-PapersOnLine 51(11):1016–1022. doi:10.1016/j.ifacol.2018.08.474
• Tao, F., Zhang, H., Liu, A. & Nee, A.Y.C. (2019). Digital Twin in Industry: State-of-the-Art. IEEE Trans. Ind. Informatics 15(4):2405–2415. doi:10.1109/TII.2018.2873186
• Tao, F., Zhang, M. & Nee, A.Y.C. (2019). Five-Dimension Digital Twin Modeling. In Digital Twin Driven Smart Manufacturing, pp. 63–81.
• Fuller, A. et al. (2020). Digital Twin: Enabling Technologies, Challenges and Open Research. IEEE Access 8:108952–108971. doi:10.1109/ACCESS.2020.2998358
• Jones, D. et al. (2020). Characterising the Digital Twin. CIRP J. Manuf. Sci. Technol. 29A:36–52. doi:10.1016/j.cirpj.2020.02.002
• Rasheed, A., San, O. & Kvamsdal, T. (2020). Digital Twin: Values, Challenges and Enablers. IEEE Access 8:21980–22012. doi:10.1109/ACCESS.2020.2970143
• Wright, L. & Davidson, S. (2020). How to tell the difference between a model and a digital twin. Adv. Model. Simul. Eng. Sci. 7:13. doi:10.1186/s40323-020-00147-4
• VanDerHorn, E. & Mahadevan, S. (2021). Digital Twin: Generalization, characterization and implementation. Decision Support Systems 145:113524. doi:10.1016/j.dss.2021.113524
• Niederer, S.A., Sacks, M.S., Girolami, M. & Willcox, K. (2021). Scaling digital twins from the artisanal to the industrial. Nature Comput. Sci. 1:313–320. doi:10.1038/s43588-021-00072-5
• Kapteyn, M.G., Pretorius, J.V.R. & Willcox, K.E. (2021). A probabilistic graphical model foundation for enabling predictive digital twins at scale. Nature Comput. Sci. 1:337–347. doi:10.1038/s43588-021-00069-0
• National Academies (2023). Foundational Research Gaps and Future Directions for Digital Twins. doi:10.17226/26894. Highlights PDF
• AIAA/AIA (2020). Digital Twin: Definition & Value. Digital Twin Consortium, Capabilities Periodic Table.

Thermal and laboratory twins; estimation

• Feng, H. et al. (2021). The Incubator Case Study for Digital Twin Engineering. arXiv:2102.10390. Code: github.com/INTO-CPS-Association/example_digital-twin_incubator
• Feng, H., Gomes, C. & Larsen, P.G. (2023). Model-Based Monitoring and State Estimation for Digital Twins: The Kalman Filter. arXiv:2305.00252
• Gomes, C. et al. (2025). Digital Twin Tutorial: The Incubator Case Study. LNCS. doi:10.1007/978-981-96-4656-2_3
• Gil, S. et al. (2024). Survey on open-source digital twin frameworks. Software: Practice and Experience. doi:10.1002/spe.3305
• Lang, S. et al. (2024). Kalman filter-driven state observer for thermal error compensation in machine tool digital twins. Manufacturing Letters 41:208–218. doi:10.1016/j.mfglet.2024.09.025
• Kuprat, J. et al. (2024). Thermal Digital Twin of Power Electronics Modules for Online Thermal Parameter Identification. IEEE JESTPE. doi:10.1109/JESTPE.2023.3328219
• Zhang, X. et al. (2023). Rapid online solution of inverse heat transfer problem by ANN-based extended Kalman smoothing. arXiv:2304.00021
• Oka, Y. & Ohno, M. (2020). Parameter estimation for heat transfer analysis during casting processes based on ensemble Kalman filter. Int. J. Heat Mass Transfer 149:119232; companion Natsume et al. (2020) 150:119222.

Industry and process

• Spatenka, S. et al. (2019). From Laboratory to Industrial Operation: Model-Based Digital Design and Optimization of Fixed-Bed Catalytic Reactors. Ind. Eng. Chem. Res. 58(28):12571–12585. doi:10.1021/acs.iecr.9b01314 (vendor-authored, gPROMS).
• Digital Twin Approach toward the Design, Optimization, and Control of a Catalytic System for High-Purity Hydrogen Production from Biogas. Ind. Eng. Chem. Res. 64(45):21588.
• Digital Twin of an Argon-Hydrogen Plasma Reactor. arXiv:2609.15250 (preprint, not peer-reviewed).
• Chen, Y. et al. (2020). Digital Twins in Pharmaceutical and Biopharmaceutical Manufacturing: A Literature Review. Processes 8(9):1088. doi:10.3390/pr8091088
• Rolls-Royce (2019) company stories on IntelligentEngine; Microsoft customer story on Rolls-Royce; Windpower Monthly on GE's Digital Wind Farm; Emerj on GE (secondary sources; treat as claims).

Self-driving labs and catalysis data

• Burger, B. et al. (2020). A mobile robotic chemist. Nature 583:237–241. doi:10.1038/s41586-020-2442-2
• Abolhasani, M. & Kumacheva, E. (2023). The rise of self-driving labs in chemical and materials sciences. Nature Synthesis 2:483–492.
• Coley, C.W., Eyke, N.S. & Jensen, K.F. (2020). Autonomous Discovery in the Chemical Sciences, Parts I and II. Angew. Chem.
• Winther, K.T. et al. (2019). Catalysis-Hub.org. Scientific Data 6:75. doi:10.1038/s41597-019-0081-y
• Hummelshøj, J.S. et al. (2012). CatApp. Angew. Chem. 51:272–274.
• NIST Chemical Kinetics Database, SRD 17: kinetics.nist.gov (gas-phase only).

Standards and measurement

• ASTM E1225-20 (store.astm.org); ASTM D5470, C177, C518, E1461; ISO 8301, 8302, 22007-2.
• ISO 23247-1…4:2021; ISO/IEC 30173:2023; ISO/IEC 30141. NIST AMS 400-2 use cases (free): tsapps.nist.gov
• JCGM 100:2008, Guide to the Expression of Uncertainty in Measurement.
• Zhao, D. et al. (2016). Measurement Techniques for Thermal Conductivity and Interfacial Thermal Conductance. arXiv:1605.08469

10.2 Recommended further reading

Heat transfer

• Bergman, Lavine, Incropera & DeWitt, Fundamentals of Heat and Mass Transfer, 8th ed., Wiley 2017 (chapters 1–5).
• Çengel & Ghajar, Heat and Mass Transfer, 6th ed., McGraw-Hill 2020.
• Lienhard & Lienhard, A Heat Transfer Textbook (free PDF, ahtt.mit.edu).

Numerical methods

• LeVeque, Finite Difference Methods for Ordinary and Partial Differential Equations, SIAM 2007 (chapter 9).
• Patankar, Numerical Heat Transfer and Fluid Flow, 1980.
• Versteeg & Malalasekera, An Introduction to Computational Fluid Dynamics: The Finite Volume Method, 2nd ed., 2007.

Inverse problems, estimation and UQ

• Özişik & Orlande, Inverse Heat Transfer, 2nd ed., CRC 2021.
• Beck, Blackwell & St. Clair, Inverse Heat Conduction, Wiley 1985; Beck & Arnold, Parameter Estimation in Engineering and Science, 1977.
• Kaipio & Somersalo, Statistical and Computational Inverse Problems, 2005.
• Simon, Optimal State Estimation, 2006.
• Labbe, Kalman and Bayesian Filters in Python: github.com/rlabbe
• Kennedy & O'Hagan (2001), Bayesian calibration of computer models. J. R. Stat. Soc. B 63:425–464.
• Saltelli et al., Global Sensitivity Analysis: The Primer, 2008.
• Chaloner & Verdinelli (1995), Bayesian experimental design: a review. Statistical Science 10:273–304.

Reaction engineering (for the next phase)

• Fogler, Elements of Chemical Reaction Engineering, 6th ed.
• Froment, Bischoff & De Wilde, Chemical Reactor Analysis and Design, 3rd ed.
• Cantera documentation (surface kinetics): cantera.org

Library documentation

• SciPy (solve_ivp, least_squares, solve_banded); FiPy; scikit-fem; FEniCSx tutorial (jsdokken.com/dolfinx-tutorial).
• FilterPy; PyMC; emcee; ArviZ; SALib; BoTorch; GPyTorch; DeepXDE.
• pyserial; pymodbus; python-opcua / asyncua; paho-mqtt; Mosquitto; watchdog.
• SQLAlchemy 2; psycopg 3; TimescaleDB; Grafana; Streamlit; Plotly.
• FMPy; pythonfmu; OpenModelica; Eclipse BaSyx; DTDL specification.

Courses

• Willcox group, predictive digital twins: kiwi.oden.utexas.edu
• MIT OCW 2.51 (Intermediate Heat and Mass Transfer); 18.085/18.086 (Computational Science and Engineering); 10.37 (Chemical and Biological Reaction Engineering).
• Aarhus University, Centre for Digital Twin Technology publications.

11. Caveats

• Industrial claims (GE, Rolls-Royce, PSE/Siemens, Microsoft) are company or vendor sources, not independent studies. Academic cases are mostly single-laboratory demonstrations.
• Material property values, diffusion-time estimates and sensor accuracies quoted here are textbook or datasheet figures, not measurements of your samples or instrument. Your calibrated reference runs supersede them.
• Only the scope statements of the paywalled ASTM/ISO standards were checked; read the full texts through the library before claiming any conformance.
• Everything in Section 4 is provisional until the instrument model is known. Expect to revise the observation model, the identifiability analysis and the day-1 checklist at that point.
• Library maintenance status (e.g. FilterPy) and cloud-service availability change; verify before pinning.
• The one-week timeline covers building the twin; validation runs will continue into week 2 because of steady-state wait times.

12. Change log