NMOD Primer Ch 1

A model is an abstraction of reality. Engineering models and business decision models are usually formulated in terms of mathematics and/or logic.

A quantitative model designed just to describe a real-world situation is called a descriptive or what-if model. Descriptive models are typically used to determine the consequences of manipulating variables and/or relationships between variables of a situation in some way.

A model designed to prescribe a solution to a real-world problem is called a normative or prescriptive model. Normative models are used to determine how the variables in the situation should be manipulated to achieve desired consequences.

Thus, variables in descriptive models are manipulated to assess the consequences; and variables in normative models are solved for to find out how they should be manipulated to produce desired consequences. We sometimes refer to prescriptive/normative models as reverse-what-if, if-what or what-should models.

Whether or not a model of interest is descriptive or prescriptive, using a model to find answers to a problem involves performing a set of computations in some ordered sequence.

Note: In a sense, what-should models are also what-if models, except that using insightful mathematics and logic in what-should models we are able reduce the effort required to find the answers we are truly looking for, and in many cases solve problems considered unsolvable. Regardless, a quantitative model in general is an abstract representation of certain parallel and sequential computational processes. We will expand on this a little more in Chapter 5.

Take, for example, a simple problem of calculating the cost per piece of operating a machine which can be set to run at a range of speeds (in terms of number of pieces or widgets per hour). Human labor is required to operate this machine, so that

Let us say that the machine cost per hour is a function of the speed at which the machine is operated so that the hourly cost of operating the machine increases nonlinearly with production rate, due to wear and tear, power consumption, etc., as shown below:

Note: ** is an operator for raising the operand left of it (PiecesPerHour in this case) to the power of the operand to the right of it (WearExponent). ORMSware operator set is comprised of all operators available in ANSI Fortran 95 and extensions of operators developed for ORMSware Suite.

To use the above model for calculating cost per piece, we have to execute a series of steps in a certain sequence such as the one shown to the right of Figure 1 below:

Get values of WearCoeff and WearExponent
Get PiecesPerHour
Calculate MachineCostPerHour using second equation above
Get LaborCostPerHour
Calculate CostPerPiece using first equation above

Note: It is certainly possible to condense or expand these steps, but the fact still remains that producing results from this or any other model is a process involving a sequence of steps (i.e. a "program").

Figure 1

Compared to the 5-step instruction set above, the calculation process becomes more readily apparent when looking at the same steps depicted in the form of a network in Figure 1. It is immediately apparent from the network that the order of steps 1 and 2 are interchangeable, as are the order of steps 3 and 4. The dependency relationships between variables are also instantly apparent in a network-structured formulation.

Based on this simple network diagram alone, it is not hard to imagine that if we were dealing with a complex model, its network diagram will be far more lucid than its instruction set.

In a general sense, any model can be expressed in terms of nodes (boxes) and arcs (arrows) in a logical network.

Notes

Nodes are also known as vertices, junctions, etc. and arcs are also known as links, edges, etc., but we will always use the terms nodes and arcs in all documents related to ORMSware networks.

Some modeling tools restrict orientation of network flows from left to right and top to bottom, with arcs leading out of nodes originating only from right or bottom sides of nodes and arcs leading into nodes terminating only at left or top sides of nodes. While such restrictions can be helpful in quickly grasping simple models, they can easily become counterproductive when models are large and/or complex. Our experience shows that letting a network start at any location on a page, flow in any direction, end at any location on the page, and enter and exit nodes at any side is the best policy for avoiding clutter.

Some readers may wonder at this point if showing the sequence of calculations in network form isn't the same as putting together flowcharts programmers and process designers routinely use. The best answer to that at this point of our discussion is simply a short answer.

You will understand why as we get deeper into this primer. There is a point in this primer when we ask you to reflect on the differences. The exercise will be a no-brainer.

The next question might be whether modeling with NMOD can be classified as programming. The answer is that it falls somewhere between spreadsheet modeling and programming, but it gives you more modeling power and implementation speed than spreadsheet or a higher order language can.

NMOD is not as easy as spreadsheets when a project involves just simple models. However, when it comes to complex and/or large scale modeling too difficult to handle with spreadsheets, we can use NMOD to absorb many of the structural issues associated with developing a program from scratch by leveraging NMOD's modeling paradigm.

Going through this primer, you will find that NMOD helps analysts focus the lion share of their efforts on the modeling aspects of solving problems, freeing them from many of the traditional programming issues involved in implementing models. We will elaborate on this as our example model evolves through this primer.

Be forewarned that we are not going to execute and look at the results of the model presented above until Chapter 13 (Events, execution feedback, and model debugging). Chapters 2 thru 12 are devoted to explaining NMOD concepts and principles. Without understanding them, it may be difficult understand Chapter 13 and beyond. If things start to get too abstract as you go through this primer, we highly recommend that you jump to the tutorial and go as far as you can before coming back here to pick up more concepts.

Chapter 21 (Expressing spreadsheets in terms of logical networks) may be understandable to many people without having gone through the chapters before that. We have tried to keep it as light as possible considering the curiosity of most clients of modeling practitioners and the likelihood that they would want to jump to it to satisfy their curiosity.

Models and logical networks