What Modeling Really Is (and Isn’t)

Choosing states, laws, and solvers — and knowing where the map ends.

By Haitao Xu · Draft for web.

1. Models Are Not Miniature Realities

We sometimes slip into talking as if a “good model” is a small copy of the real world. Add enough terms, enough parameters, enough detail, and the model becomes “realistic”. This is comforting — and wrong.

A model is not a shrunken universe. It is a carefully constructed machine for answering a particular class of questions. Outside that question class, it is allowed to be blind, wrong, or silent. In fact, it must be; otherwise we have not really made a model, only a vague wish for omniscience.

The first responsibility of a modeler is therefore not to capture everything, but to decide:

• Which states are necessary and sufficient to describe the problem,
• Which laws those states must obey, and
• What kind of solver we will accept as an answer mechanism.

2. Modeling as State Choice

In the Rᵀ–L–S language, the first move is always a choice of state. For a mechanical system, we might choose positions and velocities; for a tire, we might choose deformation gradients, internal variables for viscoelasticity, and temperature.

This choice is never neutral. It already contains a worldview:

• If we ignore temperature, we are saying: “For the questions I care about, temperature does not matter.”
• If we smear cord behavior into an effective isotropic stiffness, we are saying: “I do not need to know what happens between cords, only how the laminate behaves as a whole.”
• If we keep only steady-state rolling and discard transients, we are saying: “I will not ask this model about startup and shutdown.”

Good modeling begins by making these statements explicit instead of pretending that “the model” is just there, pre-packaged. Every state choice is a cut through reality; clarity about the cut is more important than elegance of the equations that follow.

3. Laws vs. Fitting

Once states are chosen, we introduce laws: balance of momentum, constitutive relations, energy inequalities, evolution equations. This is the L layer in the Rᵀ–L–S picture.

At this point, it is tempting to mix two very different activities:

• Writing down structure-preserving laws that express symmetry, conservation, and thermodynamic admissibility.
• Fitting flexible function approximators (neural networks, polynomials, splines) to data within that structure.

The first activity is modeling; the second is parameter estimation or system identification. Both are necessary, but they are not the same.

When we forget this distinction, we start to expect that a good-enough fit is automatically a good model. It isn’t. A model must decide what is allowed and what is impossible before any data arrives. Data then tells us where we are in that admissible space, not what the space itself should have been.

4. Solvers Are Not Oracles

With states and laws in place, we still need a way to obtain answers. That is the S layer: numerical solvers, optimization routines, time steppers, neural operators, and so on.

It is tempting to treat solvers as oracles: press “Run”, wait, and accept whatever comes out. But solvers are just algorithms with failure modes. A model is only meaningful if the solver’s behavior is structurally compatible with the laws and states we chose.

Some examples:

• A time integrator that does not respect energy or dissipation constraints may converge numerically while violating thermodynamics.
• A contact algorithm that permits interpenetration at the discrete level is modeling a different physical system, whether we admit it or not.
• A neural network that fits boundary data but does not enforce internal balance laws is not solving a PDE; it is interpolating measurements.

A responsible modeler asks not only “Did it converge?” but also “Is this class of solver admissible for the laws I claimed to enforce?”

5. What Modeling Is Not

Against this background, it becomes easier to say what modeling isn’t:

• It is not dumping all available variables into a black-box fitter and hoping generalization will happen by magic.
• It is not decorating a report with colorful contour plots after the core design decisions are already locked in.
• It is not hiding arbitrary assumptions in default settings and calibration spreadsheets.
• It is not a competition to see who can run the largest or most complex model.

All of these can appear in competent engineering projects, but none of them define modeling. They are, at best, side effects.

6. Modeling as Structured Forgetting

A more honest description is that modeling is a disciplined form of forgetting.

We forget microscopic details when we use continuum mechanics. We forget acoustic waves when we study quasi-static deformation. We forget every loading scenario except those that matter for the design question at hand.

The art lies in forgetting the right things for the right reasons:

• State choices that match the scale and questions of interest,
• Laws that encode the non-negotiable parts of physics,
• Solvers that fail loudly when we step outside the model’s domain.

When done well, this kind of selective forgetting makes problems clearer, not fuzzier. It allows us to see structure we would otherwise miss: stiffness architectures, admissible operating envelopes, and the relationship between geometry, material, and performance.

7. A Simple Checklist

In practice, a working model can be tested against a few simple questions:

1. States: Can I write down, in one paragraph, what is included in the state and what is deliberately omitted?
2. Laws: Do I know which equations express physics (balance, thermodynamics) and which are empirical closures?
3. Solvers: Do I know what kind of failure should happen when the model is used outside its domain?
4. Questions: Can I list the questions this model is allowed to answer — and those it is not?

If the answer to these is “yes”, we are modeling. If not, we are probably just computing.

8. Closing Thoughts

What modeling really is, in the end, is a way of thinking. Equations, simulations, and data are important, but they sit downstream of a few structural decisions about state, law, and solver.

Remembering this does not make the work easier. It does, however, make it more honest. It turns models from collections of tricks into explicit, examinable structures — structures that can be tested, improved, and, when necessary, replaced.

That is the real power of modeling: not to mimic reality, but to expose, in a controlled and limited way, the parts of reality that matter for the decisions we face.