Valuation (Simulation)

Determining whether a simulation model is an accurate representation of a real world system is called validation. Some degree of validation must take place throughout the simulation study. However, validation during the modeling of the system and when simulation results become available is particularly important. Here, we wish to emphasize that decision makers must be involved in modeling so that both the actual validity and the perceived validity of the model will be improved. A modeler may not have the insights into the nuances of the mechanics of a system that a manager who is intimately involved with the system will have. Determining whether the parameters, the random variables and their respective probability distributions, and the data collected on system performance are accurate representations of the system is essential for maintaining model validity.

Programming and Verification:

A computer program must be constructed for the simulation model as most real world simulations require the use of a computer. A modeler can select either a general purpose computing language, such as FORTRAN or PASCAL, or a specially designed simulation language, such as GASP, GPSS, or SIMSCRIPT. These simulation languages often reduce programming time and effort considerably. For example, the capability to generate random variables from a specified distribution is essential for all simulation models. For some specific applications, such as project planning, packaged simulation programs exist that reduce or eliminate the burden of programming. One such package is the Factory Modeling System (FMS) for the logical design of a factory.

Debugging a computer program to ensure that the model performs as intended is called verification. It is useful to debug the program in simple modules or subprograms. A trace, in which the state of the simulated system is printed out after the occurrence of each event, also helps in identifying problems. The simulation model can also be run under simplifying assumptions for which the output can be hand computed.

Once a computer program is debugged, pilot runs of the model are made to ensure that the results do indeed make sense. Appropriate modifications in the model and in the computer program are made based on the results of these areas.

Experimental Design and Simulation Runs:

The number of possible combinations grows rapidly with the number of factors as well as with the number of factor levels. Fractional factorial designs reduce the number of combinations so that the cost of simulation is not prohibitive.

Once the alternative system designs are selected by appropriate experimental design methods, several other decisions must be made. For each system design to be simulated, starting conditions for the simulation run, the length of the simulation run, and the number of independent simulation runs must also be determined. Starting conditions should be representative of the real system. A job shop that initializes a simulation with no jobs on any machine may produce artificially low values for queues since heavily utilized machines often have jobs in queue from the previous day. The simulation may, of course, be run for a few time periods with starting conditions of no jobs in the system with the data for these warm up periods then disregarded. The length of the simulation run and the number of independent replications of the simulation are determined by cost considerations and the degree of output precision desired.

Simulation runs are made to provide data ion system performance. In making production simulation runs, it is desirable to proceed slowly and to examine the output as it becomes available. Modification of the experimental design may be appropriate in order to improve the efficiency and precision of the results. For example, if the specified levels of factor do not seem to have much influence on system performance or if the levels of some other factor seem to have particularly significant influence, then it may be desirable to eliminate the first factor from the experimental design and to explore instead system performance under more detailed levels of the second factor.

“What? Gaming in the workplace? No way!” This is something that we hear from Corporate
Closely tied to the question of how much capacity should be provided to meet forecasted
The notion of focus naturally, almost inevitably from the concept of fit. Just as a
At its heart a capacity strategy suggests how the amount and timing of capacity changes
However, as with most strategic decisions, the issue is more complex than it first appears.