Traditional finite element analysis has served engineers well for decades. But it comes with a fundamental constraint: every new geometry, every new load case, every design iteration requires starting the solve from scratch. For a complex assembly, a single FEA run can take hours. Multiply that by dozens of design variants and the engineering bottleneck becomes clear.

phinen takes a different approach. By combining ML surrogate models — specifically NVIDIA's MeshGraphNet architecture — with physics-informed constraints, we deliver full-field simulation results in under a second for most structural geometries. Here's exactly how it works.

The Core Idea: Graph Neural Networks on 3D Meshes

The fundamental insight behind MeshGraphNet is that a finite element mesh is, structurally, a graph. Each mesh node is a vertex in the graph. Each edge connecting adjacent nodes carries information about their geometric relationship — distance, angle, shared face area. The boundary conditions and material properties are features on the nodes and edges.

MeshGraphNet, introduced by Pfaff et al. at DeepMind and now a core component of NVIDIA PhysicsNeMo, is a graph neural network that takes this mesh graph as input and directly predicts the physical field quantities at every node — von Mises stress, displacement, temperature, or velocity — in a single forward pass.

Compared to a full FEM solver which iteratively builds and inverts a large stiffness matrix, the inference pass through a trained MeshGraphNet takes milliseconds, not hours.

What the Training Process Looks Like

The surrogate doesn't learn from scratch for each new geometry. Instead, it is pre-trained on a large dataset of (geometry, boundary conditions) → (field solution) pairs, where the field solutions are computed by FEniCSx, our high-fidelity FEM solver.

For structural FEA, the training dataset includes:

• Geometry diversity: brackets, enclosures, plates, shells, beams, and organic shapes
• Material diversity: steel, aluminium alloys, titanium, polymer composites, and cast iron
• Loading diversity: point loads, distributed pressure, thermal expansion, gravity
• Boundary condition diversity: fixed faces, pinned joints, sliding constraints, symmetry

After training on over 80,000 FEA reference solutions, the model learns to generalise its field predictions to geometries and loading conditions it has never seen before — not by memorising, but by learning the underlying structural mechanics relationships encoded in the graph topology.

The Accuracy Question

The most common scepticism we hear is: how accurate is "good enough"? Our benchmarks across a held-out test set of 5,000 structural problems show a mean absolute error of 2.1% relative to FEniCSx ground truth on von Mises stress, and 1.8% on peak displacement.

The 6% of cases where accuracy degrades typically involve highly irregular geometries with sharp re-entrant features, contact between multiple bodies, or loading conditions far outside the training distribution. This is precisely where the confidence gate kicks in.

The Confidence Gate: When to Trust, When to Escalate

The confidence gate is phinen's quality assurance layer. After every ML inference, the gate evaluates the result against three physics-based checks: energy balance consistency, boundary condition satisfaction, and a residual norm computed against the governing PDE.

If the result passes all three checks with scores above threshold, the ML result is delivered directly. If any check fails, the system automatically escalates the run to FEniCSx, which performs a full high-fidelity FEM solve at the cost of 30–120 seconds of additional compute.

In practice, approximately 94% of runs are served by the ML surrogate and pass the confidence gate. The remaining 6% are escalated to FEniCSx and delivered with a "Validated" badge in the result.

The Speed Numbers

On a standard structural bracket analysis (bracket.stl, 12,840 faces, aluminium 6061, 1000 N load):

• FEniCSx (full FEM): 18–45 seconds depending on mesh refinement
• MeshGraphNet (ML surrogate): 0.31 seconds
• Speed ratio: 58–145× faster

For larger, more complex geometries, the advantage grows further because FEM solver time scales super-linearly with mesh size, while MeshGraphNet inference time grows only modestly.

What This Means for Design Workflows

When simulation time drops from hours to seconds, the workflow changes fundamentally. Instead of "run FEA to validate a design decision", engineers can run FEA to explore — testing 20 geometry variants, iterating boundary conditions in real time, and catching failure modes before a single physical prototype is made.

This is the shift phinen is built to enable: not just faster simulation, but simulation as an active part of the design loop — not a validation step at the end of it.

This is a walkthrough of a real thermal analysis workflow on a power electronics enclosure. The goal: identify hotspots, predict the risk of thermal failure, and propose a geometry modification — all before ordering a single prototype.

The Problem

A compact electronics enclosure housing a DC-DC converter and gate driver circuitry. At full load, the converter dissipates approximately 25W across three components mounted on an aluminium baseplate. The design team needed to verify that the peak component junction temperature stays below 85°C at a 40°C ambient — a standard operating condition for industrial-grade electronics.

Traditional options: wait 3 days for a CFD specialist to mesh and run a full thermal simulation, or prototype and measure. phinen offered a third path.

The Setup

The enclosure geometry was exported from SolidWorks as an STL file (approximately 28,000 faces) and uploaded directly to fea.phinen.com. The thermal setup was configured via the LLM chat interface:

The LLM advisor parsed the description, confirmed the setup, and asked one clarifying question: "Should I apply radiation from the external faces as well? Typical emissivity for anodised aluminium is 0.85." We confirmed, and the simulation ran in 78 seconds (escalated to FEniCSx due to the combined convection + radiation boundary conditions).

The Results

The temperature field prediction showed a peak temperature of 91.3°C at the gate driver — 6.3°C above the 85°C target. phinen's AI report flagged this immediately:

• Hotspot location: Gate driver body, specifically the top face (maximum distance from the cooled base)
• Root cause identified: The gate driver sits on a raised plastic standoff, creating a thermal resistance between the component and the aluminium baseplate
• Suggested fix: Replace the standoff with a thermally conductive interface pad (k ≥ 3 W/mK) and add a small aluminium heat spreader above the component

The Iteration

The team modified the geometry in SolidWorks — adding the heat spreader in approximately 20 minutes — re-exported the STL, and re-ran the simulation. The second run completed in 1.4 seconds (ML surrogate, confidence 96%). Peak temperature: 79.8°C. Margin: 5.2°C below the target.

Total time from first simulation to design sign-off: 94 minutes, including the CAD modification. The alternative — a full CFD simulation — would have taken 3–5 days from design to result.

What Made the Difference

Three things made this workflow fast:

• No meshing. The geometry went directly from STL to simulation. No specialist needed to set up a mesh, define refinement zones, or manage solver settings.
• LLM-guided setup. The thermal boundary conditions were specified in plain English in under 3 minutes. The LLM advisor caught the radiation term the team had initially forgotten to specify.
• Instant iteration. The second run took 1.4 seconds. Iteration speed at that pace fundamentally changes how engineering decisions get made — from "let's validate this and see" to "let's run 10 variants and find the optimum".

Broader Applications

This workflow applies directly beyond electronics enclosures. The same thermal simulation capability — heat sources, convection boundaries, radiation, conduction through complex geometries — is applicable to battery pack thermal management, HVAC system design, data centre cooling, medical device thermal validation, and industrial furnace design. If your product dissipates heat and has a temperature constraint, phinen can help you meet it faster.

The engineering simulation industry is undergoing a quiet revolution. Over the past three years, physics-informed neural networks — PINNs — have moved from academic curiosity to a credible alternative to classical numerical solvers for a growing class of problems. But the transition is neither complete nor straightforward. Here's where PINNs stand in 2026, what they can and cannot do, and why we believe they are a foundational piece of the next generation of engineering tools.

What PINNs Actually Are

A conventional neural network learns a mapping from inputs to outputs purely from data. A physics-informed neural network does something subtly different: it incorporates the governing equations — conservation of mass, momentum, energy, or the elasticity equations — directly into its loss function.

Concretely, for a structural elasticity problem, the PINN's loss function includes not just the mismatch between predicted and reference displacements, but also the residual of the governing PDE — the Navier equations of linear elasticity — evaluated at a set of collocation points inside the domain and on the boundaries.

This means the network is being trained to satisfy physics, not just to fit data. The result: predictions that are inherently consistent with the governing equations, even at points far from the training samples.

The Promise

The theoretical advantages of PINNs over classical FEM are significant:

• Mesh-free. PINNs don't require a mesh. They operate on collocation points sampled from the geometry, eliminating the meshing bottleneck entirely.
• Continuous fields. The output is a continuous function of spatial coordinates — you can query the predicted field at any point, not just at mesh nodes.
• Inverse problems. PINNs can solve inverse problems — inferring material properties or boundary conditions from observed field measurements — naturally and elegantly. This is extremely hard with classical FEM.
• Multi-physics coupling. Coupling multiple physics domains in a PINN is often simpler than in FEM, because the coupling conditions become additional terms in the loss function rather than complex numerical interface conditions.

The Reality in 2026

Despite the promise, PINNs are not yet a drop-in replacement for FEM in production engineering workflows. The honest limitations:

• Training time is long. Training a PINN from scratch for a single geometry and set of boundary conditions can take minutes to hours — far slower than a direct FEM solve. The advantage only materialises when the same geometry is queried many times with varying parameters, or when mesh generation is extremely expensive.
• Spectral bias. PINNs have difficulty representing high-frequency spatial variations in field quantities — a known failure mode for problems with sharp stress gradients, thin boundary layers, or high wavenumber oscillations.
• Convergence can be fragile. PINN training can fail to converge or converge to local minima, particularly for problems with strong nonlinearity or complex multi-physics coupling. Diagnosis requires expertise.
• No error certificates. Unlike FEM, which has well-developed a posteriori error estimators, PINNs do not provide formal error bounds. The confidence gate in phinen addresses this partially by cross-checking PINN outputs against physics-based residuals.

Where We Are in the Adoption Curve

In our view, PINNs in 2026 are at a similar maturity level to finite element methods in the early 1980s: demonstrably useful for a class of well-defined problems, with clear limitations that active research is addressing, and with industrial adoption just beginning in the most forward-thinking organisations.

The domains where PINNs are winning fastest are those where classical numerical methods face fundamental difficulties: complex geometries that are expensive to mesh, inverse problems, real-time control applications where online retraining is viable, and digital twin scenarios where sensor data and simulation need to be fused continuously.

phinen's Approach: PINNs as One Layer in a Validated Stack

We do not believe PINNs alone are sufficient for production engineering simulation today. What we do believe is that PINNs — combined with graph neural network surrogates (MeshGraphNet), confidence-gated escalation to validated FEM solvers (FEniCSx), and LLM-guided setup — form a powerful and practically deployable simulation stack.

In phinen, PINNs serve two roles:

• As a physics-consistent prior that regularises the ML surrogate's predictions toward physically plausible solutions — reducing the frequency of confidence gate escalations.
• As the primary solver for inverse problems — inferring material properties or loads from measurement data — where FEM-based approaches are cumbersome.

The simulation specialist is not going away. But the simulation bottleneck is. That is what phinen is built to eliminate.