Applied Mathematics Is Bad Mathematics

Why We Keep Pretending Applied Math Solves Things

I spent about seven years as a numerical analyst at a firm that built simulation tools for industrial clients. We modeled heat transfer in turbine blades, fluid dynamics in fuel injectors, stress distributions in bridge components. The sales team loved to sell it as "applied mathematics." The engineers who actually used the software knew better. They called it what it was: expensive guessing with graphs. The gap between pure math and applied math is not a gap at all. It is a wall, and most people who talk about applied mathematics being bad at mathematics are pointing at exactly where that wall gets built. You can write a beautiful proof about existence and uniqueness for a nonlinear PDE, and then spend three months watching your finite element solver blow up because someone rounded a boundary condition to two decimal places.

The Applied Mathematics Is Bad Mathematics Problem

Here is the core issue, stated without ornament: applied mathematics routinely discards the very thing that makes mathematics rigorous — exactness — and replaces it with approximations whose error budgets are unclear, unchecked, and almost never communicated to the people making decisions based on the output. Pure math asks whether something exists. Applied math asks whether the answer is close enough to matter, and then forgets to ask how close is close enough. I remember a specific project around 2019 where we were modeling thermal fatigue in a welded joint. The governing equations were well-posed. The mesh was refined. The material properties came from the manufacturer's datasheet, which listed values at three temperatures: 20°C, 500°C, and 800°C. Everything else was linear interpolation. The client wanted a lifecycle estimate. I gave them a number. Two years later, a failure report came back from a site operating at 650°C under cyclic loading, and the discrepancy between our prediction and actual failure was a factor of four. The error was not in the math. The error was in the chain of assumptions that preceded the math, each one presented as settled fact. Linear interpolation across a phase-transition region in the thermal conductivity curve. Isothermal boundary conditions on a surface that was actually experiencing convective cooling with a time-varying coefficient. Neglecting the residual stress from the welding process itself, which shifts the fatigue curve on the Goodman diagram by enough to move a component from safe to in roughly 10,000 cycles.

I should have flagged every single one of those assumptions with an error bound. I did not. The model output looked clean. Clean outputs are seductive. They make decision-makers feel like they are acting on knowledge rather than speculation dressed in numbers.

What Actually Goes Wrong

The discipline of applied mathematics has a structure problem. It sits between mathematics and engineering, and it borrows rigor from one and pragmatism from the other, but it rarely achieves full rigor from either side. The result is a body of work where derivations are sketched, assumptions are hidden in footnotes, and validation is often limited to comparison with other published results rather than ground-truth measurement. Consider discretization error. Every numerical method introduces it. Finite difference, finite volume, spectral element — they all approximate derivatives with algebraic expressions. The truncation error is usually known theoretically, but in practice the asymptotic regime where the theory applies may be far from the grid resolution you can actually afford. I have seen codes run on meshes that were coarse by an order of magnitude relative to the gradient length scales in the solution, and the users had no idea because the residual norms looked small. Small residuals do not mean small errors in the quantity you actually care about. They mean the discrete operator is being satisfied, which is a different question entirely. Then there is conditioning. A problem can be perfectly well-posed in the continuous sense and completely unstable when discretized. The classic example is the heat equation with a negative diffusion coefficient, which is ill-posed, but even within physically valid parameter ranges, advection-dominated problems develop boundary layers that standard Galerkin methods smear unless you add stabilization. Streamline-upwind/Petrov-Galerkin formulations exist for this reason, but they introduce artificial viscosity that is difficult to quantify and easy to misuse. I ran into this on a combustion simulation where the Peclet number exceeded 1000 in certain zones. The default solver produced smooth-looking velocity fields. The temperature field was completely wrong because the artificial diffusion was smearing the flame front across five cells instead of resolving it in one.

Parameter uncertainty is another area where applied mathematics routinely underestimates its own ignorance. Sensitivity analysis is often performed as a post-hoc exercise rather than an integral part of the modeling workflow. Global sensitivity methods like Sobol indices exist and are straightforward to implement if you have the computational budget. Most projects do not. Instead, you get one-at-a-time parameter sweeps that miss interaction effects and give a false sense of control over the model's behavior.

How to Do Better, Or At Least Less Worse

I am not arguing for abandoning applied mathematics. The alternative is usually hand calculation or no calculation at all, and both are worse for most real problems. The argument is for treating applied mathematics as what it is: a controlled approximation framework, not a truth engine. The difference matters in how you set up a problem, how you validate it, and how you communicate its limitations. Start with verification before you ever think about validation. Verification answers the question: are we solving the equations correctly? Validation answers: are we solving the correct equations? Most applied work stops at verification or skips it entirely. Grid convergence studies are the minimum viable verification. Run the same problem on three successively refined meshes and check whether your quantity of interest is converging at the theoretical rate. If it is not, something is wrong — either the discretization is not in the asymptotic regime, or the model has a singularity or discontinuity that the method cannot handle without special treatment. This usually takes less than a day for a well-behaved problem and ten minutes to set up if you have automation in place. Quantify error bounds wherever possible. You do not need a full a priori error analysis for every project. But for the critical outputs, estimate the magnitude of the dominant error sources: discretization, iterative solver tolerance, rounding, parameter uncertainty, model-form error. Add them in quadrature if they are independent. The result is a single number that tells you whether your answer is meaningful to three significant figures or barely meaningful to one. I started doing this religiously after the turbine incident, and it changed how my team approached every subsequent project. We stopped presenting results as point values and started presenting them as intervals. It slowed down the workflow by maybe twenty percent and made the reports significantly more useful.

Use benchmark problems. Every subfield has them. The lid-driven cavity flow for CFD. The heat equation with an analytic solution on a unit square for thermal codes. The Taylor-Green vortex for turbulence modeling. If your code cannot reproduce these benchmarks to within expected tolerance, nothing else you do with it is trustworthy. This sounds obvious. It is surprising how often it is skipped. Document assumptions explicitly. Not in a section called "Limitations" at the end of a report where nobody reads it. In the model setup, as part of the input file or the script that generates it. Every assumption should be traceable to a citation, a measurement, or a stated judgment call. When I cannot find a justification for a boundary condition or a material property, I flag it and assign it a worst-case range rather than pretending a single value is sufficient.

When Applied Mathematics Fails Completely

There are problems where the applied mathematics approach cannot salvage the situation, no matter how carefully you do the numerics. The first class is chaotic systems. The Lorenz attractor is the textbook example, but chaos appears in many engineering contexts — turbulent flows, orbital mechanics with three or more bodies, chemical reactions with feedback loops. In these cases, long-term prediction is impossible regardless of numerical precision because initial condition errors grow exponentially. The Lyapunov time for atmospheric flow is roughly two weeks. Nothing about better discretization changes that. What changes is whether you recognize the limit and switch from deterministic forecasting to ensemble-based probabilistic prediction. The second class is problems with multiscale coupling where the scales interact in ways that cannot be separated. Climate models struggle with this. So do multiscale materials models. The standard approach is homogenization or scale separation, which works when there is a clear gap between scales. When the gap is not clean, the effective parameters you derive are scale-dependent and their dependence is often unknown. I worked on a composite material problem where the fiber diameter was on the order of the matrix grain size. Classical homogenization broke down because there was no representative volume element. We ended up switching to direct numerical simulation with explicit resolution of both scales, which was computationally expensive but at least honest about what it was doing. The third class is inverse problems. Given observations, infer the parameters or forces that produced them. These are often ill-posed in the sense of Hadamard — solutions may not exist, may not be unique, or may not depend continuously on the data. Tikhonov regularization stabilizes them, but the regularization parameter is a tuning knob that involves a judgment call, and different choices lead to qualitatively different solutions. Medical imaging, geophysics, and nondestructive evaluation are full of these problems. The applied mathematics literature often presents regularized solutions as if they are the answer rather than acknowledging they are one possible answer among many consistent with the data and the prior assumptions encoded in the regularization.

A Quick Reference for Common Pitfalls

Convergence without accuracy. A solver converging to a solution does not mean the solution is correct. Check against known benchmarks or analytic limits. Overconfidence in output precision. Presenting six significant figures from a model with poorly constrained inputs is misleading. Three is usually generous. One is often more honest. Neglecting model-form error. No model is the truth. The question is whether the simplifications are acceptable for the intended use case, and that requires explicit reasoning, not silence.

Ignoring numerical dissipation and dispersion. Every numerical method adds some artificial diffusion or alters wave speeds. In long-time integration or wave propagation problems, these effects accumulate. Monitor them. Skipping code validation on simplified geometries. Before running a full 3D simulation of a complex component, verify the code on a 2D or 1D version where you know the answer. If it fails there, it will fail in 3D too, just more expensively.

On Terminology and the State of the Field

The phrase "Applied Mathematics Is Bad Mathematics" circulates in certain corners of the mathematics community, usually as a provocation rather than a careful argument. It is not entirely wrong, and it is not entirely right. It misses the fact that much of applied mathematics is not mathematics in the proof-driven sense but is instead computational science, which has its own standards and its own epistemology. The error is not in doing applied mathematics. The error is in pretending it is pure mathematics with extra steps, or in using its outputs without acknowledging the approximation chain that produced them. The field has improved in some ways. Open-source frameworks like FEniCS, deal.II, and PETSc have made verification more accessible. Code certification and standardized benchmark suites are becoming more common. Journals increasingly require data and code availability. But the incentive structure still favors novel applications over careful validation, and a result is easier to publish than a careful error analysis. My recommendation, if you are going to use applied mathematics as a tool, is to treat it like any other engineering tool: understand its limitations, calibrate it against known cases, and never trust it more than you trust the weakest assumption in the chain. The tools are powerful. They are not magical. The people who use them best are the ones who are most aware of how easily they can go wrong.

I still run grid convergence studies on everything. I still present intervals instead of point estimates when the error budget allows. I still flag assumptions that I cannot justify. The work takes longer, and the results are less dramatic, but they are more likely to survive contact with reality.