Scenario Manager in Vissim and Viswalk – Part II.3

Pedestrians, Fundamentals, Evaluations, Tipps and Tricks

If you have read the previous articles on Scenario Management: one of the key features for traffic simulation, Scenario Manager in Vissim and Viswalk – Part II.1 with its in-depth discussion of the role of modifications, and the introduction to scenario management from a Viswalk perspective in Scenario Manager in Vissim and Viswalk – Part II.2 you have an understanding of the scenario manager with which are now ready to get more specific. This means, we will take a look at those columns in the project structure dialog, which are typically skipped in the first pass of learning scenario management in Vissim.

Project Structure Dialog Elements: Load Index, Exclusions, and Dependencies

List of Modifications in Project Explorer

Having understood the role of Modifications in general and the Load Index in particular, we can make use of it in the small example project of Rimea test case 12 – the example project from Part II.2.

Careful readers may have noticed that the Modifications seemingly are shown in wrong order in the Project Explorer:

The load index specifies the sequence in which the modifications are loaded, and later loading may overwrite earlier settings. By default, the Load Index matches the number. This default setting had to be changed here since the destination area needs to be moved to the right when the bottleneck is long, even if the destination is near. This translation must be overwritten in a later step if the destination is far. If one would – on the contrary – first move the destination area to the far position it would be placed next to the end of the bottleneck with the modification that elongates the bottleneck. Hence the relevance and effect of the load index in this case.

Exclusions

It is an obvious fact: it is not possible that all pedestrians of a scenario are younger than 30 and older than 50 years old at the same time. It does not make sense to include modifications 4 and 5 both in one scenario. However, it is technically possible, and if you would do so, the one with the higher load index would define the outcome. But why would one do something, which does not really make sense? There is a realistic chance, that it is a plain mistake, if someone does something like this. Therefore, it is possible to tell that a modification is excluded from being combined with some other modification as it is shown in the project structure dialog for modifications 4 and 5 in Figure 3. If you try, you will receive an error message. For projects as simple as this one, this may seem like over-engineering, however, when modifications and scenarios are more complex or in collaborations within teams the exclusions option can prove helpful.

Dependencies: Modifications of Modifications and merging Modifications into the Base Network

The motivation to merge a modification to the base network may be to reduce the number of modifications in the project. While this may be regarded as being merely a comfort aspect, more important is that by default any new modification is be based upon the base network, i.e. it is defined by adding changes to the base network. If it is intended to change a certain object as part of a modification which is not included in the base network but has been created as part of another modification in first instance, this is – by default – not possible by means of further modifications.

Once modelled as part of modification 1 the new staircase cannot be modified in further modifications to investigate variants, since by default any newly created modification once opened will show the base network for editing.

Rimea test case 8 with external stairs added.

As an example, a use case might be that updated fire safety regulations require that an additional, external staircase be built for a building. We are using another test case (no. 8) from Rimea here as shown to demonstrate this.

Modification 2 depends on Modification 1.

And second, when modification 2 is selected for a scenario, modification 1 is automatically selected as well. One may argue that the second variant of the additional staircase is so much different from the first variant of the staircase that one could simply model it from scratch working the base network.

Assigning Modification 2 to a Scenario automatically adds Modification 1 since Modification 2 depends on Modification 1.

However, if modification 2 is defined to depend on modification 1. then two things happen: first, when opening modification 2 for editing the base network plus modification 1 will be shown.

Modified routes to assign chambers to staircases.

This can be quite helpful since in this way modelling work which has already been done as part of Modification 1 for scenario 2 and which is as well needed in Scenario 3 can be re-used and does not have to be done a second time. Here it is changes for the routes which are concerned. Instead, a Scenario with an alternative staircase can quickly be defined (Figure 25).

However, this overlooks that there can be further changes in modification 1 which can be reused independent of the changes in modification 2. In this example project it is the added intermediate points for the routes (Figure 24).

At this point, it may have become obvious: while it is not possible to merge modifications formally to the base network, it is possible to achieve the effect with the help of the “Depends On” column for modifications in the project explorer by making all other modifications depend on that Modifications which one would want to merge to the base network.

You can find this Scenario Management project for download here.