The Three Categories Most People Actually Use
You set up a physical model first — a wind tunnel, a scaled structure, a beaker with controlled variables. Then you write equations for what you expect the data to show. Then, somewhere in between, you draw a diagram that explains to your lab partner why the results are wrong. Those are the three types of models in science, and they do completely different jobs. I spent three years running computational fluid dynamics simulations on turbomachinery blades before I learned that my mesh resolution was garbage at the boundary layer. The math was correct. The code was validated. The model failed because I hadn't accounted for surface roughness at the micron scale. This happened to me in 2019 on a project for a regional aerospace contractor, and it cost us about six weeks of rework. The workaround was running a quick physical test with a laser profilometer on the actual blade surface, measuring the roughness height, and feeding that back into the simulation as a boundary condition. Takes maybe four hours if you know what you're doing.
3 Types Of Models In Science
Physical models are what you can touch. A quarter-scale bridge in a shaking table. A DNA double helix made of plastic. A climate chamber for testing material degradation. They exist in real space and real time, which means they obey real physics — including the physics you didn't plan for. I once watched a student build a perfectly reasoned hydraulic model of a storm drain system, then realize too late that the pipe diameter he chose couldn't actually produce the Reynolds number he needed. The model was physically real but dynamically irrelevant. That's the thing nobody tells you about physical models: similarity isn't automatic. You have to prove it, usually with dimensionless numbers, or the whole thing is just an expensive toy. Mathematical and computational models are the workhorses. Differential equations, finite element analysis, Monte Carlo simulations, agent-based models — these let you explore scenarios that would be impossible or unethical to build in reality. The danger here is the opposite of the physical model problem. Your equation might be perfectly elegant and completely detached from measurable reality. I had a colleague who built a population dynamics model for a local fishery that predicted stable equilibrium under all conditions. The model was internally consistent, but it ignored nutrient cycling entirely. When real-world data came in, the prediction was off by an order of magnitude. The fix wasn't to tweak parameters — it was to recognize that the model structure itself was missing a feedback loop. You can run a sensitivity analysis across every parameter and still miss the fact that the wrong variables are in the equation at all. Conceptual models are the sketches on the whiteboard. Box-and-arrow diagrams, mental maps, causal chain descriptions. They're not formalized enough to run on a computer, but they're usually the first thing you build when you're trying to figure out what question to ask. I use them constantly at the start of any new project. The tendency is to treat them as temporary — something to discard once you get to the real modeling. That's a mistake. A good conceptual model often reveals more than you'll ever get from a complex simulation, because it forces you to be explicit about your assumptions. The problem is that they don't scale. Once your system has more than roughly a dozen interacting components, the whiteboard diagram becomes unreadable, and you have no choice but to commit to a mathematical or computational form. At that point, you've already made implicit commitments that the conceptual model left vague.
The real trick is knowing which type to reach for at which stage, and when to switch between them. Physical models are expensive and slow but catch things equations miss. Computational models are flexible but can validate themselves into error. Conceptual models are cheap and fast but break down under complexity. In practice, most research I've seen moves through all three in sequence, and the people who skip a step tend to produce results that look solid until someone actually tries to use them. If you're just starting out, don't worry about building the most sophisticated model. Build the simplest one that could possibly fail in an interesting way. Then break it on purpose. I usually start with a hand calculation or a napkin sketch before I open any software. It takes ten minutes and has saved me from more embarrassments than I'm willing to admit.
Get the Full Details
