NMOD Primer Ch 18

Figure 16a

Figure 16a is an overview of Model.EXE showing how a model's networks formulated by the analyst form a Client Module that requests services from the NMOD engine which runs surrogates through the model's networks and carries out the computations.

Figure 16b below shows how a what-if model can be turned into an optimization model using non-naive search procedures which probe the what-if model several times (i.e. repeatedly execute the model) to find optimum solutions.

We looked in DefNet.F95 file briefly in Chapter 16 (Using Microsoft Excel for inputs) to see the table arrays deduced from Excel tables by the NETrans translator program. Click Figure 17a to open PrimerSigDefNetF95.TXT window so that we can take a closer look at the rest of the contents of this file and their relationship to a model.

In addtion to the Table declaration(s) deduced... section, DefNet Module also contains NMOD functions available to users (see the statement USE NmodExposures), and derived-type definitions of Global, Customer and Surrogate properties NETrans program finds in a model (see derived types UserDefGlbProps, UserDefCstProps, and UserDefSurProps). In the absence of an IDE, DefNet Module is one of the places analysts visit during model debugging, to look for inadvertent misspellings of property references in models.

Notice the items after the exclamation on lines defining global, customer and surrogate properties. An exclamation mark, by the way, tells the compiler that everything to the right of it are to be ignored. What NETrans has listed to the right of exclamation marks are the properties it found in PrimerSig's NET and ADD files. Declarations to the left of those properties in ORMSware notation form are their corresponding names when prefixed with 3-character Hungarian notations and converted to names acceptable to the compiler used by NMOD.

Notice that in the [derived] TYPE declarations of Global, Customer and Surrogate properties, the property names are listed in alphabetical order (ignore the prefixes of the properties, such as &S, #B, etc.). NETrans lists them in this order so that it is easy to find common mistakes such as inadvertently defining the same property name with different data types (e.g. @S.CostPerHour and @D.CostPerHour).

While it is certainly permissible to have two distinct property names this way, often something like this is a mistake that creeps in as a model evolves. To aid in the process of tracking down use of variables, you have already seen the use of reference checks in Chapter 12 (Working with Visio interface and NET file).

Figure 17a

Now let us Find END MODULE DefNet in PrimerSigDefNetF95.TXT window. In addition to NMOD exposures, table array declarations, and definitions of derived-type structures for Global, Customer and Surrogate properties, the source file DefNet.F95 also contains globally accessible routines NETrans creates to perform various housekeeping functions to support the above properties created by the user. You can see these below DefNet Module.

Towards the bottom of the file you will also notice SUBROUTINE SyncCheck. NETrans creates this subroutine during model translation to ensure that the user compiles and links a model's newly translated F95 file (PrimerSig.F95 in this case) before attempting to execute the model's EXE file (PrimerSig.EXE in this case).

In Figure 17b, Model in Model.F95 refers to the name of the model. For the example we have been discussing, the value or Model is PrimerSig. Model.F95 file contains direct or nested references to all files that make up the executable of a model (i.e. Model.EXE).

Click Figure 17b to open PrimerSigF95.TXT window for a closer look.

Top of Model.F95 (i.e. PrimerSig.F95) houses the Main program for driving the NMOD engine that serves model logic (in networks). This program is inserted in PrimerSig.F95 file during model translation by the NETrans program. We will explain this further in the next section.

NETrans puts the DefNet Module, contents of ADD file and network object subroutines created for a model into a Module. This module is called the Client Module of a model (see Figure 17a above).

Variables declared at the top of the Client Module (through ADD file) are available to all network objects in the model through "host association." Client Module is a host that CONTAINs all model-level variables and procedures created by the user. Thus, one network object in a model can communicate with any other network object in that model through its Client Module host association using user-defined model level variables.

Figure 17b

The analyst can create a PGM file (see Figure 18 at left) to override the default Main program created by NETrans (see Figure 17b above) to drive the NMOD engine. When NETrans translates a model, it looks to see if a PGM file for the model already exists. If it does, NETrans uses that file to create the program to drive the NMOD engine.

Currently, the only time an analyst would create PGM file for a model would be to use NMOD-supplied search procedures. Search procedures help us use a what-if model to find optimal value of one design/control variable at a time, or to find the value of a variable that produces a desired result from the model (i.e. goal-seeking).

Example Problem 3 (Capacity Planning model) posted at this site uses Goalseeking to find optimal tax returns processing capacity of an IRS Regional Center (Goalseeking could be used for optimization in this case, because of the way the analytical what-if model was formulated). That model's PGM file content is as shown below:

PROGRAM problem3
USE Optimization
CALL InitOptimization
!CALL TrivialSearch(WithPath("Tables.HTM"))
CALL GoalSeek("Tables.HTM")
END PROGRAM problem3

Example Problem 5 (Fleet Flow model) posted at this site uses Fibonacci search to find optimal fleet size of a trucking operation dedicated to a corporate client. That model's PGM file content is as shown below:

PROGRAM problem5
USE Optimization
CALL InitOptimization
CALL Fibonacci(WithPath("Tables.HTM"))
!CALL TrivialSearch("Tables.HTM")
END PROGRAM problem5

Figure 18

In the CALLs shown above, Tables.HTM happens to the spreadsheet containing parameters of the search.

As you can see, the code above corresponds to the top part of Figure 18. The optimization procedure it calls (in this case the Fibonacci search) in turn calls NmodServer procedure in NmodEngine Module iteratively as shown in Figure 19 below.

NMOD's Optimization Module contains various search procedures for using what-if/descriptive models to determine values of independent variables that produce optimal or desired results.

NMOD currently has only simple one-dimensional search procedures such as Golden Section and Fibonacci searches, Goalseeking, etc. Sophisticated search procedures will be added once we reach a critical mass of NMOD users.

Close PrimerSigF95.TXT window.

Figure 19

Modules and global procedures that make up Model.EXE