Write new test for congestion

[dhixsingh]

Requires some discussion around what it means to be in congestion, i.e., how the congestion event is generated.

Then:

• Calculate when an agent is in congestion and generate the BDI percept
• Handle the congestion percept on the BDI side and replan like we do for when blocked.

/cc @kainagel

[kainagel]

Look at * EvacAgentTracker, which generates the event (i.e. defines the conditions of "congested") * EventsMonitorRegistry, which catches the event and then interacts with the BDI system On 18. Jan 2018, at 17:11, Dhirendra Singh <notifications@github.com<mailto:notifications@github.com>> wrote: Requires some discussion around what it means to be in congestion, i.e., how the congestion event<https://github.com/agentsoz/bdi-abm-integration/blob/a167cf42751ae2f6250331b0d99ad8e7cdf50e70/integrations/bdi-matsim/src/main/java/io/github/agentsoz/bdimatsim/AgentInCongestionEvent.java#L31> is generated. Then: * Calculate when an agent is in congestion and generate the BDI percept * Handle the congestion percept on the BDI side and replan like we do for when blocked<https://github.com/agentsoz/bdi-abm-integration/blob/c0a4941a227be26122a5c45e47eb7cfb5995d5f8/examples/bushfire/src/main/java/io/github/agentsoz/ees/agents/Resident.java#L97>. /cc @kainagel<https://github.com/kainagel> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#8>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIXvscxrkY4U_KPO27TSu0bMBkIb14Vxks5tLuCggaJpZM4Rib12>. www.vsp.tu-berlin.de<http://www.vsp.tu-berlin.de> +49 30 314 23308 (phone) +49 30 314 26269 (fax) TU Berlin Sekr. SG 12, Salzufer 17-19, 10587 Berlin

[dhixsingh]

Since a154c29 there is now some logic that determines if an agent is in congestion. The idea is something like this:

• An agent senses if it is in congestion periodically, with the interval between each sensing being at least T seconds. The intuition is that people do not compute precisely whether they are or are not in traffic congestion to the second, but rather evaluate the situation now and then, and conclude one way or the other.
• For all the road network links traversed in time duration T, the agent knows the exact distance covered and the free speed on those links, and therefore knows an estimate t' of how long it should take it to cover that distance if there was zero congestion.
• If the actual time taken to cover the distance is found to be t such that the delay t-t' is greater than some threshold k, then we declare that the agent is in congestion.
• The parameters T and k=wT are set to default values T=600 and w=0.2, and so the default rule translates to something like, if the delay in travelling some known distance over 10 mins is greater than 20% of the expected time if one was travelling at free speed (i.e., 20% of 10 mins = 2 mins) , then the agent will sense that it is in congestion.
• The parameters can be overridden by using the command line argument --x-congestion-config T:w, for instance --x-congestion-config 300:0.1 would set the monitoring interval T to 5 mins, and the delay threshold to 10% of T.

The relevant code is here:

bdi-abm-integration/integrations/bdi-matsim/src/main/java/io/github/agentsoz/bdimatsim/EvacAgentTracker.java

Lines 117 to 125 in a154c29

	// If it has been long enough since the BDI agent last evaluated if it is in congestion
	if (vehicleData.getTimeSinceStart() > evacConfig.getCongestionEvaluationInterval()) {
	// Calculate delay against the estimated travel time for this interval (could be over several links)
	double totalDelayInThisInterval = event.getTime() - vehicleData.getEstArrivalTimeAtCurrentLinkEnd();
	// If the delay is greater than the agent's tolerance threshold, then the agent will
	// now realise (or "believe" in the BDI sense) that it is in congestion
	if(totalDelayInThisInterval > evacConfig.getCongestionEvaluationInterval() * evacConfig.getCongestionToleranceThreshold()) {
	// ding ding!
	this.events.processEvent( new AgentInCongestionEvent(event.getTime(), vehicleId, null, event.getLinkId()));

This now means that the AgentInCongestion MATSim event is now generated. The next (easier) part still to do is to then handle this and ship off a congestion percept to the BDI counterpart to do something with.

/cc @osbornejr

[dhixsingh]

Commit d5aea6f adds the ability for Resident agents to react to congestion. Current behaviour is to react in the same way as they do for blockages, i.e., by replanning to find a better route to the destination.

Relevant code is here:

bdi-abm-integration/examples/bushfire/src/main/java/io/github/agentsoz/ees/agents/Resident.java

Lines 97 to 113 in d5aea6f

	} else if (perceptID.equals(PerceptList.BLOCKED) || perceptID.equals(PerceptList.CONGESTION)) {
	// Something went wrong while driving and the road is blocked or congested
	String status = perceptID.equals(PerceptList.BLOCKED) ? "is blocked" : "is in traffic congestion";
	failedAttempts++;
	writer.println(prefix + status + " at link " + parameters);
	writer.println(prefix + "is currently near coordinates " +
	getQueryPerceptInterface().queryPercept(String.valueOf(getId()), PerceptList.REQUEST_LOCATION, parameters));
	if (failedAttempts < MAX_FAILED_ATTEMPTS) {
	writer.println(prefix
	+ "will reevaluate route to destination (attempt "+(failedAttempts+1)
	+ " of " + MAX_FAILED_ATTEMPTS
	+ ")");
	post(new RespondToFireAlert("RespondToFireAlert"));
	} else {
	writer.println(prefix + "is giving up after " + failedAttempts + " failed attempts to evacuate");
	}
	} else if (perceptID.equals(PerceptList.FIRE_ALERT)) {

Have added test Castlemaine2000Test where 2000 vehicles leave Camp Reserve in Castlemaine towards Harcourt. Test is ignored at the moment as it is not ready yet.

/cc @osbornejr

[dhixsingh]

@kainagel the new test Castlemaine2000Test that I mention above fails with the following error. Any ideas? It's not doing anything special, just has 2000 vehicles leaving Castlemaine for Harcourt.

java.lang.RuntimeException: java.lang.IndexOutOfBoundsException: toIndex = 154

	at io.github.agentsoz.ees.Main.main(Main.java:496)
	at io.github.agentsoz.ees.Castlemaine2000Test.testCastlemaine2000(Castlemaine2000Test.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:53)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.IndexOutOfBoundsException: toIndex = 154
	at java.util.ArrayList.subListRangeCheck(ArrayList.java:1012)
	at java.util.ArrayList.subList(ArrayList.java:1004)
	at java.util.Collections$UnmodifiableRandomAccessList.subList(Collections.java:1400)
	at org.matsim.withinday.utils.EditRoutes.spliceNewPathIntoOldRoute(EditRoutes.java:280)
	at org.matsim.withinday.utils.EditTrips.replaceRemainderOfCurrentRoute(EditTrips.java:210)
	at org.matsim.withinday.utils.EditTrips.replanCurrentLegWithNetworkRoute(EditTrips.java:129)
	at org.matsim.withinday.utils.EditTrips.replanCurrentTripFromLeg(EditTrips.java:105)
	at org.matsim.withinday.utils.EditTrips.replanCurrentTrip(EditTrips.java:95)
	at org.matsim.withinday.utils.EditPlans.addActivityAtEnd(EditPlans.java:55)
	at io.github.agentsoz.bdimatsim.DRIVETODefaultActionHandler.handle(DRIVETODefaultActionHandler.java:103)
	at io.github.agentsoz.nonmatsim.ActionHandler.processAction(ActionHandler.java:75)
	at io.github.agentsoz.nonmatsim.PAAgentManager.initiateNewAction(PAAgentManager.java:139)
	at io.github.agentsoz.nonmatsim.PAAgentManager.updateActions(PAAgentManager.java:112)
	at io.github.agentsoz.bdimatsim.MATSimModel.runUntil(MATSimModel.java:347)
	at io.github.agentsoz.ees.Main.start(Main.java:177)
	at io.github.agentsoz.ees.Main.main(Main.java:492)
	... 24 more

[dhixsingh]

Commit a6411d4 now has what seems to be a reasonable setting for congestion - agents reevaluate the situation every 3 mins and will replan if then are delayed by more than 25% or 45 secs.

bdi-abm-integration/examples/bushfire/src/test/java/io/github/agentsoz/ees/Castlemaine2000Test.java

Line 45 in a6411d4

"--x-congestion-config", "180:0.25"

Here is what the unfolding evacuation looks like with vehicles departing Camp Reserve in various directions due to congestion, towards Harcourt in the northeast:

Note that the checks are not enabled yet in the test, as the results seem to be non-deterministic.

/cc @osbornejr

[dhixsingh]

As of 6a015b5 the test is called 'Castlemaine1000Test.java', as the test actually has 1000 vehicles.

Note that the test results are non-deterministic. Will raise a separate issue for this.