01 / MOTIVATIONWhy combine physics and learning
Two ways of modelling the world have always been in tension, and PINNs sit deliberately in the gap between them.
Physics-based models (the differential equations of mechanics, heat, fluids, electromagnetism) are trustworthy and extrapolate well, because they encode causal structure. But they need a mesh, a solver, boundary conditions you actually know, and material parameters you often do not. Solving them on complex domains can be slow, and inverse problems (inferring an unknown parameter from sparse measurements) are painful.
Pure machine learning models are flexible and fast at inference, and they happily ingest messy real data. But they are data-hungry, they extrapolate badly, and they will cheerfully predict things that violate conservation of energy or mass, because nothing in their training told them not to.
A PINN keeps the network's flexibility while bolting the physics back on. Instead of trusting the model to infer the physics from enough examples, you tell it the governing equation directly and penalise any output that breaks it. The payoff is the headline feature of the whole field: PINNs can produce sensible solutions from small, sparse, or noisy data, precisely the regime where ordinary deep learning falls apart.
02 / THE CENTRAL IDEAA network that is the solution
Start with the thing we usually want: the solution of a differential equation. Say we are looking for a field u(x, t), the temperature along a rod, the displacement of a beam, the velocity of a flow. A classical solver computes u at a finite set of grid points. A PINN does something different: it makes the neural network be the solution.
uθ(x, t) ← NeuralNet( inputs = [x, t] , weights = θ )
So the inputs are spatial and temporal coordinates, not features in the usual ML sense, and the single output is the value of the field at that coordinate. The weights θ are what we train. Because a neural network with smooth activations (such as tanh) is itself a smooth, differentiable function, we can do something a lookup table of grid values could never do: we can take its exact derivatives with respect to its own inputs, analytically, at any point we like. That single fact is the whole trick.
03 / THE ENGINEAutomatic differentiation, not finite differences
To check whether the network obeys a differential equation, we need its derivatives: ∂u/∂t, ∂²u/∂x², and so on. PINNs get these from automatic differentiation (autodiff), the same machinery that already computes gradients for training. This is not a numerical approximation like a finite difference; it applies the chain rule exactly through the network's own operations, so the derivatives are accurate to machine precision and free of grid-spacing error.
Concretely, the same computational graph that lets us differentiate the loss with respect to the weights also lets us differentiate the output with respect to the inputs. Need a second derivative for a diffusion term? Differentiate twice. Need a mixed partial? Autodiff handles it. This is why a PINN can encode almost any PDE you can write down, without ever discretising the operator by hand.
residual(x,t) = ∂uθ/∂t − α · ∂²uθ/∂x²
# every derivative above comes straight from autodiff on the net
If the network exactly solved the heat equation, this residual would be zero at every point. It will not be, at first. Driving that residual toward zero is what training does.
04 / THE COMPOSITE LOSSThree jobs, one objective
Here is the heart of the method. A PINN minimises a weighted sum of loss terms, each enforcing a different requirement. For a typical forward problem there are three.
# 1. match any measurements you have
Ldata = mean[ ( uθ(xi,ti) − umeasured,i )² ]
# 2. obey the PDE at scattered "collocation" points
Lphysics = mean[ residual(xc,tc)² ]
# 3. respect boundary and initial conditions
Lbc/ic = mean[ ( uθ(boundary) − known )² ]
Three ideas deserve to be named clearly:
- Collocation points. The points where we enforce the physics. Crucially, they need no labels. We just sample coordinates across the domain and demand that the residual be small there. This is why PINNs are so frugal with data: the physics term supplies “free” supervision everywhere.
- The loss weights λ. They balance the terms. Getting them wrong is the single most common reason a PINN fails to train (more on this in section 09).
- Soft constraints. Boundary conditions added as a loss term are “soft”: encouraged, not guaranteed. There is a stronger alternative, baking them into the architecture so they hold exactly, which we revisit later.
05 / ARCHITECTUREThe whole pipeline, end to end
Putting the pieces together, here is what one forward pass and one training step look like. Notice that the network on the left is completely ordinary; everything distinctive happens in how the loss is built on the right.
06 / SEE IT LEARNA real PINN, trained in your browser
Everything above is concrete enough to run live. Below is an actual neural network (a small tanh network, trained by gradient descent right here in JavaScript, no pre-baked animation) learning the decay problem
You are given only a few noisy measurements, and only in the first half of the time window. Toggle the physics term on and off and watch what happens past the last data point. With data alone, the network has no reason to behave sensibly where there is no data. With the physics residual switched on, the same network extrapolates correctly across the whole window, because the equation constrains it everywhere.
Decay PINN sandbox
07 / WORKED EXAMPLEThe damped oscillator, by hand
The decay demo is first order. Most real systems are at least second order, so consider a damped, driven mass-spring system, a stand-in for a great deal of vibration and structural dynamics work:
To turn this into a PINN you do exactly three things:
- Define the network uθ(t), input time, output displacement.
- Form the residual using autodiff for the first and second derivatives:
r(t) = m·∂²uθ/∂t² + c·∂uθ/∂t + k·uθ − F(t)
- Assemble the loss: penalise r(t)² at collocation times, plus the initial conditions u(0) and u′(0), plus any sensor data you happen to have.
That is the entire recipe, and it generalises directly to partial differential equations. The canonical PINN test case, used in the original 1999-era-style benchmark and ever since, is the one-dimensional Burgers equation, a fluid model that develops a sharp shock:
Here the inputs are (x, t), the nonlinearity u·∂u/∂x is no obstacle at all (autodiff does not care whether terms are linear), and the network learns the moving shock from the equation plus the initial and boundary conditions, with little or no interior data. This single example, from Raissi and colleagues, is what put PINNs on the map.
08 / TWO MODESForward problems and inverse problems
PINNs come into their own across two distinct kinds of question, and the second is arguably where they beat classical solvers most clearly.
Forward problem
You know the equation and its coefficients, and you want the solution. The PINN plays the role of a mesh-free solver. Honest assessment: for clean, well-posed problems on simple domains, a mature classical solver is usually faster and more accurate. PINNs get interesting when the geometry is nasty, the dimension is high, or you want a single smooth model you can differentiate later.
Inverse problem
You have sparse, noisy measurements and you do not know some coefficient in the equation, a diffusivity, a damping constant, a reaction rate, a material property. Here is the elegant part: you simply promote that unknown to a trainable parameter and let the optimiser fit it alongside the network weights.
minimiseθ, α [ Ldata(θ) + Lphysics(θ, α) ]
# the physics term is what makes α identifiable from sparse data
The data anchors the solution to reality; the physics term ties the solution to the equation; and the only way to satisfy both at once is to land on the true coefficient. This unified treatment of forward and inverse problems, in one framework with one loss, is the reason PINNs drew so much attention. It is also the mode most relevant to health monitoring and diagnostics, where the “unknown parameter” is often the very thing you are trying to estimate, such as a degrading stiffness or a growing fault coefficient.
09 / PRACTICAL NOTESWhat actually goes wrong, and how to fix it
PINNs are easy to write and surprisingly hard to train well. Most of the field's research effort goes into the failure modes below. Knowing them saves weeks.
Unbalanced loss terms
If L_physics and L_data differ by orders of magnitude, the optimiser ignores the smaller one and the model collapses to a useless solution. Fixes: tune the weights λ, or better, use adaptive weighting schemes that rebalance them automatically during training (learning-rate annealing, gradient-norm balancing, or self-adaptive per-point weights).
Spectral bias
Networks learn smooth, low-frequency functions far more readily than sharp, high-frequency ones. So PINNs struggle with steep gradients, boundary layers, and oscillatory solutions. Fixes: Fourier feature embeddings of the inputs, sinusoidal activations, or domain decomposition.
Stiff and multi-scale problems
For convection-dominated or stiff systems, the loss landscape becomes brutally ill-conditioned and naive training simply fails. This is a documented, characterised failure mode, not user error. Fixes that help: curriculum / causal training (learn early times before late times, so the solution propagates forward the way the physics does), and domain decomposition (a separate network per subregion).
Soft constraints leak
Boundary and initial conditions added as loss terms are only approximately satisfied. When they must hold exactly, use a hard-constraint ansatz: structure the output so the conditions are true by construction, for example uθ(x,t) = g(x,t) + B(x,t)·NN(x,t) where g matches the boundary and B vanishes on it. This removes a whole loss term and usually trains better.
| Knob | Sensible default | When to change it |
|---|---|---|
| Activation | tanh | switch to sin / Fourier features for high frequency |
| Width / depth | ~4–8 layers, 20–128 wide | deeper for harder PDEs, not always better |
| Optimiser | Adam, then L-BFGS to polish | L-BFGS finishes the last digits of accuracy |
| Collocation | uniform or Latin hypercube | residual-adaptive resampling near sharp features |
| Loss weights | start equal, then adapt | almost always needs adaptive balancing |
| Inputs | normalise to O(1) | non-negotiable for stable training |
10 / THE FAMILY TREEVariants you will hear about
“PINN” is now an umbrella. A quick orientation so the acronyms stop being scary:
XPINNcPINN Domain decomposition. Split the domain into pieces, put a separate network on each, and stitch them with interface conditions. cPINNs enforce conservation across interfaces; XPINNs generalise this in space and time. Good for large or multi-scale domains and easy to parallelise.
vPINN / hp-VPINN Use the equation's weak (variational) form instead of the strong residual, which can lower the derivative order the network must produce and handle discontinuities more gracefully.
B-PINN Bayesian PINNs. Put distributions over the weights so you get uncertainty estimates, which is essential when the downstream decision is safety-critical.
Self-adaptive Per-point trainable loss weights that automatically pour attention onto the hardest regions (such as a shock), one of the more effective fixes for the balancing problem.
DeepONetFNO A different philosophy worth knowing. Instead of learning one solution, operator learning learns the whole solution operator, the map from inputs (a forcing function, a boundary profile, parameters) to solutions. Train once, then infer new solutions almost instantly, no retraining per case. DeepONet and Fourier Neural Operators are the headline methods, and physics-informed variants of both exist. If you need many solutions across varying conditions (a fleet, a sweep, a digital twin queried repeatedly), operator learning is often the better tool than a plain PINN.
11 / IN PRACTICEWhere it earns its keep
PINNs have landed in fluid dynamics (reconstructing flow fields from sparse velocimetry), heat transfer, solid mechanics, subsurface flow, power systems, biomedical modelling, and increasingly in prognostics and health management. That last one is worth drawing out, because it is exactly the sweet spot the method was built for.
Why PHM and vehicle health monitoring fit so well
- Sparse, noisy field data. You rarely have dense labelled measurements from a degrading component; you have a handful of noisy sensor channels. That is the regime where the physics term does the heavy lifting.
- Inverse parameter estimation. Estimating a hidden state, a damping coefficient drifting with wear, a thermal resistance rising as a joint degrades, a capacity fading in a cell, is exactly the inverse-problem mode of section 08.
- Physics you already trust. Equivalent-circuit models, lumped thermal networks, fatigue and crack-growth laws, and electrochemical models are known and partial. A PINN lets you fuse that trusted structure with whatever data the asset actually produces, rather than discarding either.
- Extrapolation toward end-of-life. Remaining-useful-life estimation is an extrapolation question, and physics-constrained models extrapolate far more defensibly than data-only ones, which matters when the decision is whether to keep operating.
The honest framing: a PINN is not a silver bullet for diagnostics, but it is a principled way to inject domain physics into a learned model so that estimates stay physically plausible when data runs thin, which is precisely when health-monitoring decisions are hardest and most consequential.
12 / REFERENCESWhere to go next
- Raissi, M., Perdikaris, P., & Karniadakis, G. E. (2019). Physics-informed neural networks: A deep learning framework for solving forward and inverse problems involving nonlinear partial differential equations. Journal of Computational Physics, 378, 686–707. (the founding paper)
- Karniadakis, G. E., Kevrekidis, I. G., Lu, L., Perdikaris, P., Wang, S., & Yang, L. (2021). Physics-informed machine learning. Nature Reviews Physics, 3, 422–440. (the standard review)
- Cuomo, S., et al. (2022). Scientific machine learning through physics-informed neural networks: Where we are and what's next. Journal of Scientific Computing, 92(88). (broad, practical survey)
- Wang, S., Teng, Y., & Perdikaris, P. (2021). Understanding and mitigating gradient flow pathologies in physics-informed neural networks. SIAM Journal on Scientific Computing, 43(5), A3055–A3081. (loss balancing)
- Krishnapriyan, A., Gholami, A., Zhe, S., Kirby, R., & Mahoney, M. W. (2021). Characterizing possible failure modes in physics-informed neural networks. Advances in Neural Information Processing Systems (NeurIPS). (why training fails)
- Wang, S., Sankaran, S., Wang, H., & Perdikaris, P. (2023). An expert's guide to training physics-informed neural networks. arXiv:2308.08468. (hard-won training advice)
- Lu, L., Meng, X., Mao, Z., & Karniadakis, G. E. (2021). DeepXDE: A deep learning library for solving differential equations. SIAM Review, 63(1), 208–228. (the go-to software library)
- Lu, L., Jin, P., Pang, G., Zhang, Z., & Karniadakis, G. E. (2021). Learning nonlinear operators via DeepONet. Nature Machine Intelligence, 3, 218–229. (operator learning)
- Jagtap, A. D., & Karniadakis, G. E. (2020). Extended physics-informed neural networks (XPINNs). Communications in Computational Physics, 28(5), 2002–2041. (domain decomposition)