A Simple Discrete-Event Simulation: Part 68

Last time I got the system to handle multiple types of entities and today I updated the reporting capability so it generates results for the system as a whole and for each type of entity that we might want to report on. Entities can be differentiated by many properties singly or in combination. I therefore found it necessary to structure the solution so the hand-coding required to ensure all the correct statistical accumulators get updated is concentrated into as few, easily identifiable places as possible.

The existing code that managed the various accumulators was easily modified to update an accumulator array of choice instead of just the single global one. The recordGroupStats function shown below used to write directly to the statsArray accumulator directly, but here we’ve modified it to write to an accumulator of choice by specifying target accumulator array in the whichStatsArray parameter. We then created a “wrapper” function that called the original function so it’s applied to each desired accumulator. The invocations of the original function were easy to find in the code and update to their wrapped version with a slight change of parameters.

Note that the wrapper function must refer to the relevant entity so its type and classification can be determined. This determination can be done using any combination of an entity’s properties, although this example shows a very simple division based on a single property. It’s also possible to collect the statistics in numerous different ways. In this case we broke things down by an entity’s residency but in the future we’ll also break it down by processing speed, when we segregate those entities within the simulation.

Initialization of the statistical accumulator arrays was rolled up into a function so the reset mechanism could easily make a single call instead of having to duplicate the code in two places. We can define accumulators for as many entity subtypes as we’d like.

There were a few places where I had to something slightly more complex, like ensure a counter referred to by all the accumulators was only updated once, but the main work was straightforward.

The output of the report is simply repeated once for all entities and again for each entity type or subtype the programmer wanted. I added a text title for each set of accumulated data to identify its entity subtype and corrected a bug I noticed where the Max and Min values in each row weren’t being calculated correctly.

I’ve tried to build the reporting mechanism in the most general and modular way possible but there’s only so far this can be taken. The instrumentation needed to collect different kinds of data will necessarily vary based on what we might want to know. In the end all we can do is keep the code as clean as possible and understand it well.