edrt: results are not deterministic

[sebhoerl]

While writing additional unit tests for #2826 (prebooking in combination with edrt), I noticed that the output of edrt is not deterministic. In particular, events appear at random times during the iteration:

Here I was writing out the events of 10 runs of the RunEDrtScenarioIT, every time it has a different hash:

md5sum *
a9f047a4f63a71698a256c4c85c46bc8  events_0000.xml
525fdffcf9fdd148e65db5c9517c9749  events_0001.xml
d61901df6ca0d13f28f806521b779205  events_0002.xml
8202a42c67aa41f130e9ed5a91b2fedc  events_0003.xml
8de07129df24b47b8628736d463df501  events_0004.xml
fc260ed09667c25520fa6da808d2cbc7  events_0005.xml
2a1c9de1b973b7b8bde61da21300b769  events_0006.xml
79af77419d846a9fd21fba1bdb3015c1  events_0007.xml
927b83a35028ec1d5706a942314214d9  events_0008.xml
7f96411df0357fb6e05e2cb45ba20960  events_0009.xml
2800fcba68ade3881ba6ba89c71a56bc  events_0010.xml

Different from #2826 I couldn't yet find a case where it actually changes something in the dispatching decisions.

[sebhoerl]

Potential fix is in #2925. When I run the RunEDrtScenarioIT in a loop, I get the following now:

md5sum *
d8aa9c92ecdb7ba56f14255a46d441eb  events_0000.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0001.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0002.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0003.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0004.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0005.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0006.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0007.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0008.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0009.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0010.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0011.xml.gz
1e151ba46007a3aa7cb5068ca76c3286  events_0012.xml.gz

So the behaviour is deterministic, because now all the discharging events come at the end of the simulation. Interestingly, the first run is different from the other ones. The difference is one single Stuck event that comes one second later in the following simulations. I also tested this with the standard DrtControlerCreator and it is the same behavior, so it doesn't seem to be related to the present issue.

Just to give you an idea what is my set-up here:

[michalmac]

The difference is one single Stuck event that comes one second later in the following simulations.

Interesting! Is this PersonStuckEvent related to a rejected DRT request? I can then have a look at it.

[sebhoerl]

Yes, probably caused by a rejection.

[michalmac]

@sebhoerl This issue has been (probably) fixed with #2935 and #2939.