User-defined scalars, arrays, derived types and procedures

In addition to global, customer and surrogate properties, the analyst can also create additional variables by explicitly declaring them at network object and model levels. In future versions of NMOD, it will also be possible to declare variables at network level; the scope of variables declared at network level will be all network objects contained in the network in which they are declared (recall that a model can be made up of many networks).

During model translation, NETrans creates one subroutine for every network object in the model, which has at least one active property definition. If every property of a network object has default values, NETrans does not create a subroutine for that object, since default behavior of every network object is part of NMOD's design. NETrans also creates property sections in every network object subroutine to reflect all of that object's relevant property logic.

The scope of a user-defined variable (scalar/array/structure) declared in a network object is just that object. Variables should be declared in a network object right below the beginning boundary of an object's code block. To see how this is done, go to object 5 in Figure 14 (PrimerSigNET.TXT) window and look at the three records underneath the top code block delimiter record of [5]. Click here if PrimerSigNET.TXT window is not already open.

The object has four user-defined variables, viz. intIndx, intCol, bigCustomer and logBranch. Description(s) to the left of double colons (::) are attributes/properties of the variables to the right of ::. The SAVE attribute of bigCustomer ensures that its value is preserved between calls to that subroutine.

As mentioned above, the scope of all user-defined variables in {Object.5} is the subroutine created for {Object.5}. This means two things. Those four variables are accessible to all property blocks of this object; and, they are not accessible to any other network object in the model. As you can see, there are explicit definitions for three properties of n[5], viz. Merging property, Trans property and SignalTarget property. All four variables mentioned above are accessible to all three code blocks in [5].

bigCustomer is a good example of a variable used in multiple properties of an object. When NMOD executes the Trans property of [5] for a customer, the value of bigCustomer is set equal to the value of the customer's ID. If bigCustomer did not have a SAVE attribute, one cannot count on that value being preserved once execution of [5]'s Trans property is complete.

Since, according to our network logic, a new customer will not enter our system until an existing customer has departed, we can be sure that the value of bigCustomer set in the Trans property will be the same when the event related to [5] is complete and NMOD calls this object again to execute [5]'s SignalTarget property where bigCustomer is used for the upper limit of a DO loop. 

Since the node we are examining is on the 1st page/network of the model and it is the 5th object on the page, NETrans names the subroutine it creates for the object Obj_1_5. Let us take a peek at this routine (even if you are not familiar with Fortran 95). You will hardly ever do this while routinely modeling with NMOD.

Click here to open the PrimerSigF95.TXT window.

Page down to locate SUBROUTINE Obj_1_5(bigSur,bigTkn,bigSeq...

Notice that NETrans has also inserted the name of the network and the object (CostPerPiece.[5]CostPerPiece) above the subroutine name. Under the subroutine name there are default declaration statements which are delineated at the bottom [of those statements] by a record with several dashes. NETrans has inserted right underneath that record of dashes, indented by several spaces, all variables we declared in the NET file for [5].

All user-defined variables and common procedures to be made available to all network objects in the model must be defined outside the NET file. The facility to accomplish this is the ADD file of a model. It is explained in the next section.

Model level variables need to be declared in the ADD file of a model. In the current version of our example problem, let us say that we need to declare a model level character array (strResults) to hold each x-y pair of the cost-per-piece curve as they are computed during each customer loop. Click here to open the PrimerSigADD.TXT window to see how the array is declared.

Notice the declaration

0:20 in the DIMENSION attribute of the two-dimensional array strResults indicates that the rows in the array extend from 0 to 20. The 2 following the comma indicates that the column dimension extends from 1 (by default) to 2. Lower and upper limits of a dimension can be any integer, and an array may have up to 7 dimensions.

The 25 in the CHARACTER attribute indicates that strResults is an array of 25-character strings.

In addition to model level variable declarations, ADD file of a model also houses model level procedures. To illustrate this, we created a just-to-show procedure (FUNCTION dblfSignalDelay) for fetching the Duration of [5]-to-[2] signal traversals. You may have already noticed this function when you examined the ADD file as suggested earlier. Procedures so included in the ADD file will be available to all network objects in a model.

Contents of a model's ADD file and DefNet Module (discussed in the next chapter) go into a model's F95 source file for creating Model.EXE, a model's executable (PrimerSig.EXE in the case of our example).

Close PrimerSigADD.TXT window.