Choosing a surrogate-model architecture to predict steady-state thermal fields from CAD geometry — FNO vs PINN vs GNN?

This is specialized enough that I’d strongly recommend asking in the Hugging Science Discord as well. I’m not a thermal/CAE practitioner myself, so please treat the notes below as a public-literature map rather than field-tested engineering advice.

---

Short answer

I would not frame this mainly as vanilla FNO vs vanilla PINN vs vanilla GNN.

For CAD/thermal surrogates, the first decision is usually the representation :

• CAD B-rep?
• surface mesh?
• volume FEM/CFD mesh?
• STL / point cloud?
• SDF / voxel grid?
• structured chip/package power map?

Given your description — steady-state temperature fields from parameterized geometry plus boundary conditions, with expensive CFD/thermal solves and concern about hotspots / extrapolation — my practical starting point would be:

1. If you already have FEM/CFD meshes: start with a mesh-GNN / MeshGraphNet / X-MeshGraphNet / graph neural operator baseline.
2. If you want FNO-like operator learning on irregular CAD geometries: look at Geo-FNO , GINO , and related geometry-aware neural operators.
3. If the problem is closer to 3D-IC / chip/package / power-map thermal analysis: look at DeepOHeat / DeepONet / FNO-style thermal operator learning.
4. I would not use a vanilla PINN as the primary engineering surrogate by default. I would use PINN/PINO-style physics residuals, weak-form losses, calibration, or solver refinement as auxiliary pieces.

A simple first recommendation:

Build a strong mesh-GNN or graph neural operator baseline first, compare it against a geometry-aware neural operator such as GINO/Geo-FNO/DoMINO, and treat PINN-style physics as a regularizer or refinement stage rather than the main model.

Why this is not just “FNO vs PINN vs GNN”

The architecture choice depends heavily on how geometry enters the model.

Input representation	Natural model family	Why it matters
Volume FEM/CFD mesh	MeshGraphNet, X-MeshGraphNet, graph neural operator	Preserves unstructured simulation topology directly.
Surface mesh / STL / point cloud	X-MeshGraphNet, DoMINO, GINO, point-cloud operator models	Useful if you want to avoid full meshing at inference time.
Irregular domain but FNO-like operator desired	Geo-FNO, GINO	Standard FNO is tied to regular grids; geometry-aware variants try to recover FNO efficiency on irregular geometry.
Voxel / SDF grid	3D CNN, U-Net, FNO, ViT-style surrogates	Can work well if resolution and memory are manageable.
3D-IC / chip/package power maps	DeepOHeat, DeepONet, FNO variants	The inputs are often more structured: layers, power maps, boundary conditions, materials.
Native CAD B-rep	BRepNet / UV-Net-style geometry encoder + downstream surrogate	CAD geometry may be better represented before converting to mesh/point cloud, depending on workflow.

So I would start with:

representation → data strategy → architecture → validation metrics

rather than architecture alone.

Architecture map

Model family	When I would try it	Strengths	Main cautions	Useful links
MeshGraphNet / mesh GNN	You already have unstructured FEM/CFD meshes.	Natural fit for mesh-based simulation data; handles irregular topology better than regular-grid CNN/FNO baselines.	Vanilla message passing can struggle with long-range diffusion, very large 3D meshes, and mesh-resolution shift.	MeshGraphNets paper, MeshGraphNets project page
X-MeshGraphNet / scalable graph models	Large 3D geometry, STL/point-cloud workflows, or when inference-time meshing is expensive.	Addresses scalability, partitioning, long-range interactions, and graph construction from tessellated geometry.	Still needs careful validation on thermal quantities, not just generic CFD metrics.	X-MeshGraphNet, PhysicsNeMo MeshGraphNet tutorial
Geo-FNO	You like the FNO idea but your domain is not a simple rectangular grid.	Deforms irregular physical domains into a latent uniform grid where FFT/FNO can be applied. Accepts point clouds, meshes, and design parameters.	More complex than vanilla FNO; implementation/data pipeline may be less straightforward.	Geo-FNO JMLR, Geo-FNO arXiv
GINO	Large 3D PDEs with varying geometries, SDF/point-cloud inputs, irregular grids.	Combines graph neural operators with Fourier neural operators; useful bridge between irregular geometry and FNO-like efficiency.	Mostly demonstrated on CFD/aerodynamics-style settings; thermal validation still needs task-specific checking.	GINO arXiv, GINO OpenReview
DoMINO / point-cloud CAE models	CAD/STL/point-cloud industrial simulation surrogate workflows.	Designed around local, multi-scale point-cloud geometry modeling for industrial CAE-style tasks.	Public examples are often CFD/aero-heavy rather than exactly electronics thermal.	PhysicsNeMo DoMINO example, PhysicsNeMo
DeepOHeat / DeepONet thermal operators	3D-IC, chip/package, structured thermal maps, power maps, heat-transfer coefficients.	Very relevant if your geometry is closer to layered electronics / power-map thermal analysis than arbitrary mechanical CAD.	Less obviously suited to arbitrary CAD unless your representation can be made structured.	DeepOHeat, DeepOHeat GitHub, DeepOHeat-v1
PINO / physics-informed neural operator	You have some data but want PDE constraints, higher-resolution residuals, or physics regularization.	Better framing than pure PINN for learning families of PDE solutions.	Still requires careful residual weighting, boundary-condition handling, and validation.	PINO
Vanilla PINN	Inverse problems, sparse sensor reconstruction, parameter identification, or small single-instance problems.	Can encode governing equations directly.	Usually not my first choice for broad CAD-to-field surrogate learning across many geometries. Training stability and loss balancing can be painful.	PINN stiff-PDE instability discussion
B-rep geometry encoders	Your real input is native CAD, not meshes.	Avoids losing CAD topology by prematurely converting to point clouds or meshes.	Usually only one piece of the pipeline; you still need a thermal field predictor downstream.	BRepNet, BRepNet GitHub

My practical baseline suggestion

If I had to design a first study, I would probably do this:

Phase 1 — Make the data split honest

Before comparing architectures, define validation splits that mimic the failure modes you actually care about.

Do not rely only on random train/test splits.

Use something like:

Split type	What it tests
Random split	Basic interpolation sanity check. Useful, but not enough.
Geometry-family holdout	Can the model generalize to unseen shape families?
Boundary-condition holdout	Does it extrapolate to new convection coefficients, inlet/outlet conditions, ambient temperatures, etc.?
Material-property holdout	Does it handle new conductivity / heat capacity / anisotropy regimes?
Heat-source-layout holdout	Does it generalize to new source positions, densities, or power maps?
Mesh-resolution shift	Does it depend too much on the training mesh resolution?
Design-ranking split	Does the surrogate preserve the ranking of candidate designs?

For this point, SIMSHIFT is especially relevant because it is explicitly about distribution shifts in industrial neural surrogates and includes a heatsink design task. I would also keep REALM in mind as a warning that simplified surrogate benchmarks can overstate real-world robustness.

Phase 2 — Build a mesh-based baseline

If you already have simulation meshes, I would start with a mesh-GNN baseline:

• node features: coordinates, material properties, source terms, boundary-condition flags, maybe distance-to-boundary / SDF-like features
• edge features: relative displacement, distance, possibly face/element connectivity features
• outputs: temperature field, maybe heat flux or derived quantities
• model: MeshGraphNet or an X-MeshGraphNet-style multi-scale variant

Why this first?

Because your problem sounds closer to field prediction over an unstructured computational domain than to image-to-image prediction.

Useful starting points:

• MeshGraphNets: Learning Mesh-Based Simulation with Graph Networks
• X-MeshGraphNet: Scalable Multi-Scale Graph Neural Networks for Physics Simulation
• PhysicsNeMo MeshGraphNet tutorial
• PhysicsNeMo GitHub

Phase 3 — Compare against geometry-aware neural operators

I would not compare against only vanilla FNO. I would compare against geometry-aware operator models:

• Geo-FNO
• GINO
• DoMINO / PhysicsNeMo
• possibly DeepONet-style variants if your input can be represented as functions over coordinates

The key point:

Vanilla FNO is attractive because it captures global structure efficiently, but its usual FFT formulation is most natural on regular grids. For irregular CAD geometry, use a geometry-aware variant or a hybrid graph/Fourier operator.

Geo-FNO is a direct response to the regular-grid limitation: it learns a deformation from the irregular physical domain into a latent uniform grid. GINO is another useful framing: use graph neural operators to move between irregular grids and regular latent grids, where FNO-like layers can operate efficiently.

Phase 4 — Treat PINN-style physics as auxiliary

I would not make a vanilla PINN the main baseline for this problem unless there is a specific reason.

For many design variants, repeatedly training or optimizing a PINN per geometry can become expensive and fragile. Hotspots, sharp gradients, stiff-like behavior, boundary loss balancing, and irregular geometry can make training difficult.

But physics-informed components are still useful:

Use of physics	Practical form
Regularization	PDE residual loss, boundary-condition loss, flux consistency
Higher-resolution correction	PINO-style loss at a finer resolution than training data
Trust check	energy/flux residual as a diagnostic
Post-processing	solver refinement or projection step
Active learning	use residual or uncertainty to choose the next expensive simulation

PINO is a better conceptual fit than a pure PINN if the goal is to learn a solution operator across a family of geometries / BCs / source terms.

Phase 5 — If the domain is 3D-IC / package thermal, check DeepOHeat

If your “electronics” problem is closer to chip/package thermal analysis than arbitrary CAD bodies, I would look carefully at the DeepOHeat line of work.

• DeepOHeat learns mappings from configurations such as boundary conditions, power maps, and heat-transfer coefficients to temperature fields in 3D-IC design.
• DeepOHeat-v1 adds emphasis on multi-scale thermal patterns, confidence scoring, and finite-difference/GMRES refinement.

That line of work is useful because it treats thermal simulation as an operator learning problem rather than just a generic regression problem.

Metrics I would not skip

For early design screening, field MSE alone is probably not enough.

I would track:

Metric	Why
Mean / relative field error	Basic global accuracy.
Max temperature error	Often more important than average error in thermal design.
Hotspot location error	A field can look good globally but miss the failure-relevant location.
Top-k hotspot recall	Useful if you screen for dangerous regions.
Thermal resistance error	More design-relevant than raw field error in many workflows.
Boundary flux / energy residual	Helps detect physically inconsistent predictions.
Design ranking consistency	If the surrogate is used for screening, preserving candidate ranking may matter more than absolute field accuracy.
OOD confidence / abstention rate	A surrogate should know when not to be trusted.
Solver-refinement improvement	If you use a hybrid ML+solver workflow, measure how much correction is needed.

The “where does accuracy actually break?” question should be answered by these slices, not just by one average error number.

Data strategy may matter as much as model class

Because full thermal solves are expensive, I would not only compare neural architectures. I would also design the data-generation loop.

Possible additions:

Strategy	Why it helps
Multi-fidelity data	Use cheaper approximate solves plus a smaller number of high-fidelity solves.
Active learning	Spend expensive simulations where uncertainty or expected design value is highest.
Geometry-aware sampling	Ensure training shapes cover topology/size/aspect-ratio regimes, not just random parameter values.
Boundary-condition sampling	Sample BCs/source terms deliberately instead of treating them as afterthoughts.
Uncertainty estimation	Needed for screening, especially under geometry shift.
Solver fallback / refinement	Use ML as a fast initializer or screening model, not necessarily as the final authority.

A slightly simpler model with a better data strategy can beat a more sophisticated model trained on a weak random split.

Suggested experiment matrix

A practical comparison could look like this:

Track	Candidate	Purpose
Baseline 0	Classical surrogate: Gaussian process / random forest / gradient boosting on engineered geometry descriptors	Check whether deep learning is actually needed for your current design family.
Baseline 1	3D CNN / U-Net on voxel or SDF grid	Simple structured-grid baseline.
Baseline 2	MeshGraphNet	Main unstructured-mesh baseline.
Baseline 3	X-MeshGraphNet / multi-scale GNN	Large 3D / long-range / meshing-at-inference baseline.
Operator 1	Geo-FNO	FNO-like model adapted to irregular geometry.
Operator 2	GINO	Hybrid graph/Fourier neural operator for varying geometries.
Operator 3	DeepOHeat / DeepONet-style model	Especially if the problem resembles chip/package thermal maps.
Physics hybrid	PINO-style loss or weak-form residual added to the best supervised model	Test whether physics improves sample efficiency and OOD behavior.
Trust layer	ensemble / confidence score / residual check / solver refinement	Test operational reliability.

I would avoid spending too much time tuning every model before the validation protocol is stable. The first goal should be to find which representation and split actually expose the failure modes.

What I would ask in the Hugging Science Discord

If you ask there, I would include very concrete details. For example:

Detail	Why people will ask
Is the geometry native CAD B-rep, STL, surface mesh, or volume mesh?	Determines representation and architecture.
Are the outputs on volume nodes, surface nodes, voxels, or probe points?	Determines model output format.
Is it conduction only, conjugate heat transfer, or CFD-coupled?	Changes physics and loss design.
Are BCs simple scalars or spatial fields?	Determines whether operator learning is needed.
How many high-fidelity solves can you afford?	Determines whether deep models are realistic.
Are materials fixed or variable?	Important for OOD splits.
What is the design objective?	Max temperature, hotspot position, thermal resistance, ranking, etc.
How far outside training geometry should the model work?	Determines whether extrapolation is realistic.
Do you need real-time prediction or just cheaper batch screening?	Changes acceptable model complexity.

A compact prompt might be:

I am building a surrogate for steady-state thermal fields in electronics/battery design. Inputs are parameterized CAD geometry plus boundary conditions; labels are expensive CFD/thermal solves. Outputs are full temperature fields and hotspot-related quantities. I’m trying to choose between mesh-GNNs, geometry-aware neural operators, and PINN/PINO-style physics constraints. I would especially appreciate advice on representation choice, OOD geometry validation, and whether mesh-based GNNs or neural operators are more robust for this type of thermal problem.

Resource list

Mesh / graph simulation

• MeshGraphNets: Learning Mesh-Based Simulation with Graph Networks
• MeshGraphNets project page
• X-MeshGraphNet: Scalable Multi-Scale Graph Neural Networks for Physics Simulation
• PhysicsNeMo MeshGraphNet tutorial
• NVIDIA PhysicsNeMo GitHub

Geometry-aware neural operators

• Geo-FNO: Fourier Neural Operator with Learned Deformations for PDEs on General Geometries
• Geo-FNO arXiv
• GINO: Geometry-Informed Neural Operator for Large-Scale 3D PDEs
• GINO OpenReview
• DoMINO / PhysicsNeMo external aerodynamics example

Thermal / electronics operator learning

• DeepOHeat: Operator Learning-based Ultra-fast Thermal Simulation in 3D-IC Design
• DeepOHeat GitHub
• DeepOHeat-v1: Efficient Operator Learning for Fast and Trustworthy Thermal Simulation and Optimization in 3D-IC Design

Physics-informed operator learning

• PINO: Physics-Informed Neural Operator for Learning Partial Differential Equations

CAD representation

• BRepNet: A topological message passing system for solid models
• BRepNet GitHub

Validation / distribution shift

• SIMSHIFT: A Benchmark for Adapting Neural Surrogates to Distribution Shifts
• REALM benchmark

Bottom line

My best reading from the public literature is:

• If you have unstructured simulation meshes: start with MeshGraphNet / X-MeshGraphNet / graph neural operators.
• If you want FNO-like speed on irregular geometry: use Geo-FNO / GINO / DoMINO , not vanilla FNO.
• If the target is 3D-IC / chip-package thermal: check DeepOHeat / DeepONet / FNO-style thermal operator learning.
• If labels are scarce: focus on multi-fidelity data, active learning, physics-informed losses, and uncertainty.
• If reliability matters: prioritize OOD splits, hotspot metrics, confidence estimates, and solver refinement.
• If using PINNs: use them mainly as auxiliary physics constraints, inverse-calibration tools, or refinement mechanisms , not as the default standalone surrogate.