Events Step by Step
Experimentation
A Look at the Results
A DESMO-J experiment automatically produces a number of pre-formatted files, the most important of which will probably be the report. For validation and/or calibration of a model, the error, debug and trace logs come in handy. It is always a good idea to first have a look into the error file, just to ensure that no DESMO-J rule violations occurred like trying to remove an entity from an empty queue.
EventExampleExperiment - errors & warnings
model | time | error | content |
As you can see, there are no errors or warnings reported by DESMO-J. Note that this does not mean that
- Your simulation is free of errors, especially logical errors.
- Your model is representing the real system in a realistic way.
Therefore you have to validate your model before you can assume that its results can be transferred onto the real system. And don't forget that a single simulation run will not offer reliable results, since they are the outcome of a stochastical process. However, we will not discuss these issues here any further. We just assume our model is correct (bearing in mind that we have to compare it to observations we make on a real system).
Let's have a look at the report. You will find the resulting report file in the directory from which you started your simulation run. It's called EventsExampleExperiment_report.html and you can simply open it in a browser.
The report starts with the model description, followed by the report of the used queues:
EventsExampleExperiment ReportModel Event-Oriented Simple Van Carrier Model
Description |
|
This model describes a queueing system located at a container terminal. Trucks will arrive and require the loading of a container. A van carrier (VC) is on duty and will head off to find the required container in the storage. It will then load the container onto the truck. Afterwards, the truck leaves the terminal. In case the VC is busy, the truck waits for its turn on the parking-lot. If the VC is idle, it waits on its own parking spot for the truck to come. Report drawn at 1500.0. Last reset at 0.0. |
Queues
Title | Qorder | (Re)set | Obs | QLimit | Qmax | Qnow | Qavg. | Zeros | avg.Wait | refus. |
| Truck Queue | FIFO | 0.0 | 304 | unlimit. | 171 | 169 | 93.19876 | 1 | 289.90371 | 0 |
| idle VC Queue | FIFO | 0.0 | 1 | unlimit. | 1 | 0 | 0.0 | 1 | 0.0 | 0 |
These results show that there were 304 trucks serviced (Obs = trucks leaving the queue) during our simulation period and only one of it (Zeros =1) went into the queue and got serviced right away. This was most likely the very first truck to arrive at the terminal.
At the moment the report was drawn there were 169 trucks waiting in the queue, with a maximum queue length of 171 trucks. The average waiting time for a truck was 289.90371 minutes (more than 4 hours) before it got serviced. The truck queue was on an average 93 trucks long (on an average there were 93 trucks waiting in line to be serviced). Well, being a the driver of a container truck certainly doesn't seem to be much fun... ;-)
The van carrier on the other hand is working continually without a break. It has only once entered the idle queue waiting for trucks to arrive, right at the beginning of the simulation.
The report finishes with the distributions used in the model:
Distributions
Title | (Re)set | Obs | Type | Parameter 1 | Parameter 2 | Seed |
| ServiceTimeStream | 0.0 | 304 | Cont Uniform | 3.0 | 7.0 | 71529105 |
| TruckArrivalTimeStream | 0.0 | 473 | Cont Exponential | 3.0 | 91080577 |
As you can see there were 304 samples drawn from the ServiceTimeStream (Obs). This number corresponds with the 304 trucks we observed having left the truck queue. If you add these 304 trucks and the 169 trucks currently waiting for service, you will end up with the 473 samples drawn from the TruckArrivalStream.