Modeling The Physical World

By Oscar Gordon

Also, for the handful of you reading this who are more intimately familiar with the nuts and bolts of what I’m laying out here, keep in mind this is primarily for the uninitiated. Yes, I know my explanation for X is simplistic and/or incomplete, but do we really have time for a week long discussion as to why?

The goal of this post is to explore the complexities involved in building models. Since modeling the physical world is my bailiwick, I’ll be using that as my basis, but the complexities I hope to expose exist in any modeling paradigm, be in physical, economic, social, or anywhere in-between.

First, what is modeling? Modeling is, at its root, any attempt to build a representative system of something that you can then control and experiment with. Model train hobbyists build models of trains and explore the complexities of railway infrastructure (and claim to have fun at the same time; to each his own, I guess). Airplane designers build model airplanes and fly them or stick them in wind tunnels to explore their designs. Car makers, shipyards, civil engineers, etc. all build physical models to help explore systems. But physical models such as these have drawbacks, such as they are expensive to build, and somewhat limited in the information they can provide due to the limits of technology.

Luckily, we clever monkeys developed math and the scientific method, and we’ve spent centuries paying attention to how the world works. This means we can build mathematical models that (usually) do a respectable job simulating complex systems. We really have two ways to mathematically model the physical world; statistically and numerically. Statistical models are built upon observed data and are most useful when the system can not (yet) be represented with concise equations or systems of equations (usually due to an incomplete understanding of the system due to an inability to observe the system in detail). Statistical Mechanics is one example. Numerical methods are more analytical, in that there are specific equations that can be solved, or approximated, to reach a solution. Computational Fluid Dynamics (CFD) is an example of a numerical approach.

We’ve been using both for a long time, with varying degrees of success and predictive capability. However, when Isaac Newton put together Calculus in order to kick Robert Hooke in the metaphorical and intellectual ‘nads, he opened up a whole new capability to more accurately model our world. This is not to say we weren’t already doing it, since the likes of Boyle, Maxwell, Weber, Halley, Hooke, Newton, and their peers who came before had all developed equations to model specific physical situations, but what we could do was very limited. For instance, Hooke’s Law is fundamental to all students of mechanics, and is expressed simply as:

Hooke’s Law is a first order linear approximation of the behavior of springs (or any spring like material), but prior to Newton’s Philosophiæ Naturalis Principia Mathematica, and the works of minds like Leibniz, no one had the mathematical tools to really explore further. Hooke’s law provided solid predictive ability, right up to the point that the material left the linear elastic displacement range. Once it became non-linear, Hooke’s law stopped being able to predict behavior. Thanks to Newton, et. al., we were better able to develop nonlinear models and now we can model the material through all behavior domains.

Another example is Bernoulli’s Equation, shown here:

This is also a linear approximation of what would later become the Navier-Stokes equations, shown here in the general form*:

(*I’ll discuss this later)

The Navier-Stokes equations model the movement of a particle of fluid through a fluid system, and like many other equations that model physical systems, are very complex. Currently they exist without a closed form solution (a way to solve the equations analytically), and the development of such a solution is one way to win the Millennium Prize (recently a solution was presented, but it has yet to be translated, vetted, and shown to work for all conditions). The only way to approximate a solution is with numerical modeling and a lot of computing power. Thankfully, computing power gets cheaper and more abundant every day.

So, armed with mathematical models of physical systems, we can build the complex models representing these systems inside a computer, which is currently orders of magnitude cheaper, faster, more flexible, and more informative that the old physical models (we still build the physical models, but only as a final check). Simple enough, right? Go to school, understand the math, build the models, compute, solve, cover yourself in money, fame, and glory! WooHoo!

Yeah, you already know the answer to that. Complex systems are complex. Modeling them involves not just understanding how to work with statistics, calculus, linear algebra, and differential equations, it also requires the modeler to have a detailed, almost intimate understanding of everything happening in, and to, the system. Being good at this requires not just math skills, but expert programming skills in a variety of languages, a solid knowledge of the physics and chemistry involved, plus the mind of an investigator and troubleshooter. In short, it takes a team with a lot of skills overlap and cross-training to develop complex systems models correctly.

So lets take a look at how a model is developed. For example, let’s model Tod’s golf swing (Tod does play golf, right? If not, this will be his hypothetical golf swing). In the interest of world peace and to combat global… something, it is imperative that we be able to understand and model Tod’s work with a driver. To that end, we’ve invited Tod to an ultra modern driving range (one of those ones that is inside a giant, inflatable building), where we can acquire relevant data.

Tod is fitted with a motion capture suit, given a motion capture club, and buckets of brightly colored golf balls. The driving range is surrounded by an array of cameras that will track the flight, impact location, and final resting place of each colored ball. Tod has a number of high speed cameras watching him (this is for combating global peace… or something, so spare no expense! – besides, digital high speed cameras are relatively cheap these days). In short, each swing will be recorded in detail. Tod will then spend the day swinging that club as many times as he can stand.

All of this data will serve two purposes. The first will be to aid in the development of the complete model. The second will be to validate the model.

Building the Model:

Since the model we want to build is a motion problem of an object on a (generally) ballistic trajectory, we will start with the ballistics equations. The ballistics equations are all derived from Newton’s First Law, which is expressed with the force equation:

This site at NASA does a nice job explaining the derivation of the ballistics equations from Newton’s First Law. This wiki page has the generalized equations (the NASA site is for vertical launch only). The equation we are going to use first is the distance traveled equation:

This will tell us how far the ball travels from the tee, assuming we were hitting the ball in a vacuum. We do have to take air resistance into account, and the wiki page shows a derivation that would be fine if we just needed a rough estimate of the effects of drag on the ball. However, golf balls, thanks to their dimples, don’t follow that derivation very well. Still, for the moment, the distance traveled equation is a good place to start. We’ll also need the Height at X and Velocity at X equations later on, but for now let’s move on.

As you can see when you look at the distance traveled equation, you have three unknowns, initial velocity, angle of launch, and initial height. Initial height is easy; if the driving range is flat, it’s the height of the tee; if there is a hill or valley, we can estimate about where on the hill or in the valley it will hit and adjust the initial height accordingly. Initial velocity and angle of launch, however, depend on Tod.

But, before we get to Tod’s swing, we have to understand the material mechanics of the ball itself. A golf ball certainly feels solid and firm to the touch, but it’s actually quite deformable, and as such we’ll need an equation that describes how the ball will deform at impact with the club head, and how much energy it will expend as it returns to it’s original shape. This will affect the initial velocity of the ball. If the ball did not deform, would could just use the momentum equation and me done with it.

So the mass and velocity of the first object will equal the mass and velocity of the second, or the slow moving heavy driver head will make sure the lightweight golf ball is gonna leave at a pretty good clip. Of course, this equation assumes that objects 1 and 2 are perfectly elastic, i.e. they do not deform, or if they do, the deformation energy is perfectly returned. If there is any deformation, part of the transferred kinetic energy will be consumed as the material deforms and returns to it’s original shape (and expended as heat – yes, hitting a golf ball warms it up a smidge). So golf balls have an elasticity value (e) that is less than 1 and (usually) determined experimentally. Factoring e into the momentum equation, and doing a bit of algebra to solve for the final velocity, we get this.

So we treat the mass of the golf ball as a bit less than it is in order to accommodate the energy lost due to deformation.

Now we can get to Tod’s swing. I honestly don’t know if there is an existing equation or model for a golf swing, but for the sake of this discussion, let’s say there isn’t. How do we model the swing? Well, we are taking tons of HD video of Tod swinging his club, so we can use that video to develop a statistical model of the swing. Why a statistical model? Because despite claims to the contrary, Tod is neither a literal, nor a metaphorical machine, so his swing will vary each time. Even pro golfers have measurable variation in their swings, although less so than others. That said, we don’t have to look at the whole swing, just the last bit, where he hits the ball. We need the speed of the club at impact, the angle of impact to the head, and how long the ball stays in contact with the club. If we use the video to get all this information for each swing, we can develop a statistical model of the swing that, in combination with the elastic model of the ball, will allow us to formulate a useful range of potential initial velocities and launch angles.

It won’t tell us exactly how Tod will hit the ball every time, but it will tell us what the chances are that Tod will hit a ball in a certain way during any given swing. Unless, of course, Tod has a couple of pints of Deschutes during lunch, which could add a fun wrinkle to the model.

So, we’ve figured out how the ball is to be hit, and we have a rough idea as to the path the ball will take, so what’s next? Well, landing and roll out. If the ball is somewhat deformable and elastic, the fairway or green is even more so. They are also rough (fairways more than greens, obviously). The elasticity of the ground will affect how much bounce the ball will have when it lands, and the characteristic of the grass will affect how long the ball will roll once it stops bouncing (coefficient of friction is factored into the equation of motion as an opposing force to the motion). This is pretty much the same equations we used up above, but on the other end of the ballistic equations.

We use the statistical model of Tods swing to inform (i.e. give us the unknowns) of the elastic momentum equation, which gives us the initial values for the ballistic equation. The ballistic equation then provides the values we’ll use to fill in the unknowns for the landing bounce and roll out, with each bounce being another ballistic calculation.

Remember how I said that golf balls are dimpled, and that matters? There was a reason I picked golf, and that is because golf balls don’t conform exactly to the ballistic equations, certainly not the way a heavy artillery shell, or even a rifle bullet would. Those dimples affect how a golf ball flies, and while the ballistic equations are a good approximation, an accurate flight path would need to be informed by the local weather.

Thus, once we have the initial velocity, angle, and any spin values of the ball as it leaves the face of Tod’s club, we can either develop another statistical model of the flight path, or we can use a numerical method, such as CFD, to determine the flight path, especially if we have weather data (although that isn’t necessary, since we can create whatever weather we want in the simulation). First, however, let me get back to the CFD model and the equations at the heart of it. Earlier, I showed the general form of the Navier Stokes equations. That single expression doesn’t really show just how complex the system is. Here they are in an expanded form:

Navier Stokes is a system of five partial differential equations that computes rates of change for multiple unknowns across four dimensions (three spatial, one temporal). For those who didn’t get that far in math, here is what the notations mean:

So as time advances, the density of the fluid may change as well. If the fluid is water, this term is likely constant, since the density of water, absent other fluids or a change in temperature near a phase transition, will remain constant. Air, on the other hand, can change it’s density quite a bit, so this term is in flux. The various velocity and shear stress (turbulence) terms are all very much in flux almost all the time, and across the whole temporal and spatial domain. As you can imagine, with so many terms changing across such a wide set of dimensions, solving this is not a trivial task. So how do we solve it?

Well, first off, we don’t solve it, per se, we compute an approximate solution. To do that, we employ a technique called discretization. The specifics of how things are discretized can vary depending on the scheme, or the approach to the solution, but the basic idea is to break the problem up into teeny, tiny pieces and solve for it on each piece. If our piece is the 250 meters of the drive, a whole lot of change can happen from start to finish, but if our piece is a space about 1 cm across, that’s a different story. The change there will be very small, and, more importantly, very predictable. Thus:

Where the denominator equals 1 cm, and the numerator will equal some very small change that we can compute based upon our known conditions of how aerodynamic drag affects a golf ball, plus whatever effect the weather might be having. The computed change is then applied to the value of u and the next centimeter of space is computed using the new value of u. This is then done for each term that is changing, for each little piece of space. The actual math, at this point, is not difficult. It’s a bit of a grind, but it’s basic algebra at this point. Which is why computers have been such a boon, because while it would take a person all day to do the math for this problem, a computer can do it in seconds, or even very small fractions of a second.

The capability of computers to do these kinds of repetitive tasks at such incredible speed opened up a whole world of simulations. Whereas previously, we’d only compute the path of the ball and treat the weather as merely inputs along that path, now we can overlay a mesh across the whole of the driving range, and factor in not just wind, but varying air densities and humidities, as well as thermal anomalies (such as the ball passing over a section of asphalt on a hot day and experiencing the thermal updraft that results) and whatever else we can dream up. The solutions are computed at points along the mesh (which points are used is something else that varies based upon the scheme in use). Of course, meshing a whole domain like that has all sorts of other issues, such as resolving the spatial and temporal changes, as well as requiring multiple passes, or iterations, of the problem domain in order to reduce the errors that the various schemes experience. However, the ability to expand the domain opens up whole new avenues for exploration.

No longer are we limited to modeling the flow around the cross section of a wing and extrapolating from that the performance of the whole wing. Now we can model the wing itself, with all the control surfaces and the wing-body interface, and using a Design of Experiments approach, rapidly explore how changes in various design parameters alters the performance, and even automatically optimize the design by allowing the computer to seek out performance targets. It really is an exciting time to be an engineer.

But, back to the golf ball. We have the swing, the impact, the flight path, and the terminal performance. All put together, that is the mathematical model of Tod’s golf game. Now, we test the model against real world data!

If the model is accurate and robust, we should be able to predict where Tod’s golf ball will go within a certain probability envelope. So what happens if our model falls outside of that envelope? What then? This is where the investigator/troubleshooter skills come into play. It could be a mathematical error (usually easy to spot and fix), or an incorrect assumption (less easy to spot and fix since this can have a large helping of human foible attached to it), or an erroneous input (less easy to spot, very easy to fix), or the original data is bad (hoo boy…). If Tod did have a couple of Black Buttes at lunch on the day of data collection, and no one noticed and wrote it down, then there could be an hour or two worth of data that is inaccurate, especially if he is stone cold sober on the day of validation.

Which finally brings us to error bars. Error bars are a modelers way of saying, “we are sure of our results, but only this sure”. They are a simple thing, one that you’ll find in some form or another in every research paper that plots data, something that is critical and incredibly informative with regard to the quality of information being presented, and usually the first thing to vanish from media reports of scientific research results (to my great annoyance). If the researchers didn’t know Tod was buzzed after lunch, their error bars would expand considerably, as opposed to if they did know, and could adjust the data, or just exclude that data from the set (with an attached explanation of why the data was excluded, e.g. Tod was soused). Finally, error bars, even large error bars, do not suggest that the research was bad, or done incorrectly, or that the conclusions are necessarily wrong, it only speaks to the quality of the data (which can often be low through no fault of the researchers) or the accuracy of the applied model. Usually what large error bars mean is that the research will need to be repeated or replicated once a way to get better data is determined.

So, that is the basics of what goes into a mathematical model. As you can see, even simple models can be very complex, and complex models can be a nightmare to develop and untangle. So next time you see a report on the results of a mathematical model (or a computer model), you’ll hopefully have a better understanding of what potentially went into it. And if you see modeling data plotted without error bars or some notation regarding the error of the data, keep your hand on your wallet, because someone is trying to sell you something.

Rules For Modeling

1) The model is wrong (for certain values of wrong). This is usually the hardest thing for new engineers, and most everyone else, to understand and accept. When you put in a lot of effort creating a model, and the computer spits out an answer that looks correct at first glance, it can be difficult to check that enthusiasm for a more pragmatic response.
2) You have to know, in detail, why the model is wrong. If you can’t explain why the model is wrong, you don’t understand the physics involved.  Assumptions abound during the construction of a model, and being able to explain the assumptions made & how those assumptions can cause trouble is part of the process.
3) You have to know precisely how wrong the model is. If you don’t know your error bars, then you don’t understand your model.  It’s not enough to just know the assumptions & their limitations, you also have to have a good idea how badly those assumptions can throw off the answer.

If you want more like this, let me know. I can talk about modeling all day long.

{Feature Image from the CD-Adepco Image Gallery

Golf Ball image from Titleist Golf Ball Education}