One model, all physics

I trained one neural network to do the job usually split across a dozen specialised solvers, and it works well enough to be useful and not well enough to trust blindly. Both halves of that sentence matter.

The project is called NEMO, short for Neural Engine for Multi-physics Operators. The idea is simple to say and hard to build: instead of one network per physics (one for stress, one for heat, one for electromagnetics), you give ONE model a discrete “physics mode” id, a material vector, and boundary conditions, and let it read the physics off the input rather than off its architecture. The physics lives in the data, not in separate networks.

Under the hood it’s a shared latent space with two heads. Head A predicts shape (a signed distance field). Head B predicts the field you actually care about, von Mises stress, temperature, whatever the mode calls for. The model currently spans tens of physics modes in its registry, backed by 42 solver-generators that have run real MOOSE solves, not synthetic approximations. MOOSE, the open-source finite element engine, is the teacher. The surrogate is the product; the solver is where its homework gets checked.

Does it actually know material from geometry, or is it just memorising shapes?

I ran the test that would embarrass the model if the answer was “memorising.” Same 24 geometries, twice: once with the correct material assigned, once with materials shuffled at random. If the network were ignoring material, the two runs should score about the same.

They didn’t. True material gave a von Mises relative error of 0.1215. Shuffled material gave 0.6630. That’s a 5.46x gap, and the correct material won on 19 of 24 shapes. The model is reading the material vector, not just the shape.

I want to be precise about what that test proves and what it doesn’t. It’s a material-disjoint test on a fixed set of geometries. It says the model notices material. It says nothing about how the model behaves on geometry it has never seen, and that’s a separate, harder question with its own separate, less flattering numbers (more on that below).

Multi-physics without a bigger network

When two physics couple, say thermal expansion feeding into stress, the system doesn’t reach for a second model. It runs the same ONE model twice, in an in-core fixed-point loop: solve thermal, feed the result into mechanical, solve mechanical, feed back, repeat until it settles. We measure the contraction rate of that loop, rho. Rho under 1 means the loop is provably converging. Rho at or above 1 means the loop is diverging, and the system escalates honestly instead of returning a number it can’t stand behind. The same solver code that runs the coupling loop in production also runs inside the test gate, so there’s no separate “demo path” that behaves differently from what ships.

Now the caveat, because this is the part that actually matters

On a geometry-disjoint holdout (families of shapes the model never trained on, 320 real bracket-and-load cases from actual SimJEB parts, checked against real Altair/OptiStruct finite element results, not against itself), the best variant of the model gets a local-peak relative error of 0.36 and mislocates the peak stress by 0.19. Our own internal gate, the bar we set before we’d call something production-ready, is 0.15 error and 0.05 location. The model misses its own bar by roughly 2.4x on error and 3.8x on location.

Worse, in 57% to 93% of cases (depending on the model variant) it under-predicts the peak stress. That’s the dangerous direction: a model that tells you the part is safer than it is. We know why, mostly: it’s a spectral bias problem, the smooth decoder architecturally struggles to reproduce sharp peaks, and the fix is architectural (a Fourier or FNO-style head, geometric equivariance), not “more training data.”

So: this is not a certification-grade stress predictor on unseen geometry, and I’m not going to write a post that implies otherwise. It’s a fast, physics-aware first pass that notices material, couples physics through a real mathematical fixed point, and honestly tells you when a loop won’t converge. Whether it’s ready for your specific use case depends entirely on what error you can tolerate and whether you’re willing to gate the output through a real solver before you act on it, which is the subject of the next post.

What would make this useful to you: a fast first estimate you verify, or nothing short of certified accuracy on day one?