# The Modeling Cycle (Part 1) Here we discuss the modeling process and begin to get our ideas off the ground. The two figures are adapted from [GAIMME](https://www.siam.org/publications/reports/guidelines-for-assessment-and-instruction-in-mathematical-modeling-education/), the *Guidelines for Assessment and Instruction in Mathematical Modeling Education* (SIAM and [COMAP](https://comap.org/membership/member-resources/item/introducing-gaimme-time)), which is a standard reference on how modeling is taught and assessed. ## Part 1. The ladder, and what a model review is GAIMME's Figure 1.1 shows how a textbook turns a mathematics problem into a modeling problem. Start with a math problem, add labels and it becomes a word problem, add meaning, and it becomes an application problem, add interpretation, and it becomes a modeling problem. ![[modeling-ladder.svg]] You have been standing at the right end of this ladder since your brainstorm. Your questions arrived as modeling problems, statements about the world with no symbols in them, and the work of the two response forms has been the search for the mathematics underneath. That search is the ladder run backward. Strip the interpretation from your question and ask what application it is. Strip the meaning and ask what word problem is left. Strip the labels and ask what mathematics remains. A student who can write "underneath my question about accents is a problem about estimating the spectrum of a recorded signal" has found the symbols. A student who can write "underneath my question about copper prices is a process that returns to a mean after being pushed" has found them too. A student who cannot yet write the sentence has found out exactly where the work is, which is also the point, and is worth saying on the form. The ladder also gives the semester's two projects a definition each, in one sentence. A **model review** climbs the ladder from left to right on someone else's mathematics. You take a model that already exists, with its symbols already attached, and you add the labels, the meaning, and the interpretation until you can explain to another person what it says about the world and where it stops being true. A **modeling project** runs the cycle on your own problem. You start at the right end of the ladder with a question of your own, run it backward to find the mathematics, and then go around the cycle with it, lap by lap, until December. The two are not separate skills. The review teaches you what a finished lap looks like from the outside, and the project asks you to produce one from the inside. They do not have to be separate projects either. You may run them independently, a review of one model and a modeling project on an unrelated question, which is the choice for breadth. Or you may join them, reviewing the model that your own project is built on, which is the choice for depth. Joining them makes sense when the project will require digging out the origin story of its mathematics, where the model came from, what it was first built to do, and what it assumed when it was built. Independent makes sense when you want to see two different kinds of mathematics attached to two different parts of the world. Neither is the better choice. Say which you are doing on the next form, and know that you can change your mind once around the first lap. What a lap is, and what going around the cycle asks of you, is Part 2. ## Part 2. The cycle, one arrow at a time The ladder said where the mathematics comes from. The cycle says what you do with it once you have it. [GAIMME](https://www.siam.org/publications/reports/guidelines-for-assessment-and-instruction-in-mathematical-modeling-education/) draws the whole cycle at once, six circles and a sequence of steps with multiple interconnecting arrows. The point is a good one, but it tends to support the two interpretations: 1. The modeling process is a checklist, six boxes to fill in order, 2. Steps often interconnect and processes are repeated. These are both true statements but, as I found, make the modeling process intimidating and confusing when students end up in-between non-sequential states where diagnosing difficulties and moving forward tend to be the hardest. The following is their diagram with the arrows removed. ![[modeling-cycle-frame0.svg]] The starting point is clear. You identified something you'd like to understand and, on the second form, you specified it, ranked it against its neighbors, and guessed at the mathematics. Once this is done, that circle is generally done, unless something is discovered that makes us consider a near-complete reevaluation of context, which would be a big discovery, i.e., we set up a mass-spring experiment and found that it didn't obey our equation, and now we have to go back to our derivation to determine if we really understood what was going on. While this would be an outstanding exercise in discovery, we are hoping this doesn't happen in the context of a class project. That said, here is the first arrow. ![[modeling-cycle-frame1.svg]] **Identify to Assume.** Notice that it only points one way. You do not get to go back and re-identify the problem until you have assumed something about it, and this is the step that needs to happen sooner rather than later. It is, in my opinion, the first critical step. Making assumptions means writing down what you will ignore, what you will treat as constant, what you will treat as known, and which quantities you will give a symbol to. There is a trap here. The goal is to "do the math," and often you are balancing trying to encode everything you are sensing about the context with the mathematics, but this will likely create a model whose mathematics is poorly scoped and unworkable at first pass. To resolve this, we need to keep things simple, and you should know that almost everyone finds that the assumptions they have to make at this stage to achieve workable mathematics lead to great simplifications, embarrassing ones. That is fine. Here, it's best to keep statistician [George Box's](https://en.wikipedia.org/wiki/All_models_are_wrong) quote, "All models are wrong, but some are useful," in mind and seek the wrong model with doable mathematics to get the cycle moving. The goal here is to establish a pipeline of mathematics tied to the context that gets you to the point where you can perform analysis, because it's the analysis that is the teacher. ![[modeling-cycle-frame2.svg]] **Assume to Do the Math, and back.** This is the first double-headed arrow. You take your crude assumptions and do whatever mathematics they permit, and the mathematics immediately tells you which assumptions it cannot live with. A variable you forgot to define. A quantity with no units. Two assumptions that contradict each other once written as equations. You go back, fix the assumption, and come forward again. This small loop can run several times in an afternoon, and it is where the correspondence problem gets worked out. Context plus symbols equals model, and the symbols push back. ![[modeling-cycle-frame3.svg]] **Do the Math to Analyze and Assess, and back.** Now there is a solution, a number or a curve or a picture, and you ask whether it is any good. Does it have the right sign and size? Does it behave sensibly when a parameter is pushed to edge cases? Does it match the one piece of data you can find? This is the bend in the road. Everything before it is preparation, and everything after it is only possible because there is something to be circumspect about. In my experience, getting around this bend is the most important step in the whole cycle, and the students who get stuck are the ones who stay in the middle of the graph, polishing assumptions, thinking about what-ifs, struggling with the math and its analysis. While all of this push-and-pull is central to the modeling process, the best way to avoid the quagmire in the center of the [GAIMME](https://www.siam.org/publications/reports/guidelines-for-assessment-and-instruction-in-mathematical-modeling-education/) chart is to keep the first lap as simple as possible and iterate the built pipeline from an established working start. ![[modeling-cycle-frame4.svg]] **The return arrows.** Only now can they be drawn. Analyze to Iterate, Iterate back to Assume, Iterate back to Identify, and the diagonal between Assume and Analyze. These are the arrows that make it modeling rather than calculation. Having assessed a solution, you now know which assumption to revisit first, and you may find that the problem you actually solved is not the problem you set out to solve. Invariably it isn't. That is fine, and it is important. The question drifts once symbols are attached to it, and noticing the drift, naming it, and deciding whether to follow it or correct it is the real achievement. It is the sign that you have modeled something. A lap around the cycle is Identify, Assume, Math, Assess, and one return arrow. The goal of the first check-in is to see how this one lap handled and how it informs the overall project and the pipeline's scope. ![[modeling-cycle-frame5.svg]] **Iterate to Implement and Report.** The last arrow, and the only one that leaves the cycle. It gets drawn in December. Between now and then you will go around the loop two or three more times, and each lap should be smaller and sharper than the last. Here is the whole thing, for reference. Look at it after you have been around once and it will read differently than it does today. ![[modeling-cycle-full.svg]] That is the map. Part 1 told you where to find the mathematics under your question, and Part 2 told you what to do with it once you have it. The forms and checkpoints that follow are laps around this figure, nothing more.