agentsoz / bdi-abm-integration

BDI ABM Integration
GNU Lesser General Public License v3.0
8 stars 13 forks source link

Undesired routing through fire in Anglesea12kTestSample #36

Closed dhixsingh closed 6 years ago

dhixsingh commented 6 years ago

In commit d9c23dafe13ac340cfc5ea6c17033d8c5e38ac62, for test Anglesea12kTestSample, we see some unexpected re-routing through the fire. This is a 12k population test running at a 4% sample and capacity reduced accordingly.

The modelled situation is that there is a complete blockage due to an accident at 1630hrs on the way out to Torquay (both ways are blocked, outbound only is shown in orange highlight below):

anglesea12ktestsample-blockedlink

There is heavy congestion on the roads. Each vehicle arriving at the blockage re-routes (using the global information router that also knows about congestion). Vehicles arriving at the blockage after 2100hrs however, choose to re-route through the fire (see figure below, white dot is the destination in Torquay, clock not shown but time is around 2200hrs). Somehow the penalty function mixed with travel time penalty (congestion) in MATSim yields a least cost path through the fire. I tried playing around with the penalty function but even conceptually can't work out where the issue is ever though I understand how penalties are being calculated.

anglesea12ktestsample-routing-through-fire

The penalty function in question is this: https://github.com/agentsoz/bdi-abm-integration/blob/d48f0bf6ee4da698d29670664b2577c4a047f1be/integrations/bdi-matsim/src/main/java/io/github/agentsoz/bdimatsim/Utils.java#L197-L206

Might need help from @kainagel here.

kainagel commented 6 years ago

Dear Dhirendra,

I can't really tell without running (and debugging) it.

The first thing to check (= print out) the penalty factors of the links along the faulty route (i.e. get their IDs manually from via, and have the penalty values printout just after penaltyMethod2 was called).

The basis are "node heights". Start with

} else if (buffer.contains(fromPoint)) {

 final double heightAtFromNode = Math.pow(bufferWidth-fromPoint.distance(fire),2.) ;
 final double heightAtToNode = Math.pow( bufferWidth - point.distance(fire),2.) ;
 if ( heightAtToNode>heightAtFromNode) {
      penaltyFactorsOfLinks.put( link.getId(), heightAtToNode-heightAtFromNode ) ;
 }

Here both fromNode and toNode of the link are in the buffer area (around the fire). The "heights" are such that they are zero at the outer edge of the buffer, and "bufferWidth^2" at the inner edge of the buffer. Penalty factor is the difference between those two heights when going towards the fire; otherwise, there is no penalty factor.

In the fire has penalty factory "bufferWidth^2". Compared to the height differences in the buffer area, this should be quite a lot more, so they should take the fastest path out of the fire.

(You are not using a very small buffer width, are you?)


Otherwise, you would need to put it into some testcase and tell me how to run it.

Best wishes

Kai

On 19. Jun 2018, at 04:42, Dhirendra Singh notifications@github.com<mailto:notifications@github.com> wrote:

In commit d9c23dahttps://github.com/agentsoz/bdi-abm-integration/commit/d9c23dafe13ac340cfc5ea6c17033d8c5e38ac62, for test Anglesea12kTestSamplehttps://github.com/agentsoz/bdi-abm-integration/blob/d9c23dafe13ac340cfc5ea6c17033d8c5e38ac62/examples/bushfire/src/test/java/io/github/agentsoz/ees/Anglesea12kTestSample.java, we see some unexpected re-routing through the fire. This is a 12k population test running at a 4% sample and capacity reduced accordingly.

The modelled situation is that there is a complete blockage due to an accident at 1630hrs on the way out to Torquay (both ways are blocked, outbound only is shown in orange highlight below):

[anglesea12ktestsample-blockedlink]https://user-images.githubusercontent.com/7893676/41572565-ca051a66-73bb-11e8-89fa-e53df7e0c0ab.png

There is heavy congestion on the roads. Each vehicle arriving at the blockage re-routes (using the global information router that also knows about congestion). Vehicles arriving at the blockage after 2100hrs however, choose to re-route through the fire (see figure below, white dot is the destination in Torquay, clock not shown but time is around 2200hrs). Somehow the penalty function mixed with travel time penalty (congestion) in MATSim yields a least cost path through the fire. I tried playing around with the penalty function but even conceptually can't work out where the issue is ever though I understand how penalties are being calculated.

[anglesea12ktestsample-routing-through-fire]https://user-images.githubusercontent.com/7893676/41572830-1a6d617e-73bd-11e8-8c76-d15181712782.png

The penalty function in question is this: https://github.com/agentsoz/bdi-abm-integration/blob/d48f0bf6ee4da698d29670664b2577c4a047f1be/integrations/bdi-matsim/src/main/java/io/github/agentsoz/bdimatsim/Utils.java#L197-L206

Might need help from @kainagelhttps://github.com/kainagel here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/agentsoz/bdi-abm-integration/issues/36, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIXvsaVDtRsanCfGAk47zRWmdbncYwZFks5t-GUggaJpZM4Uswp3.

==============================================================

Use MATSim through an IDE (e.g. eclipse or intellij):

Use MATSim as a standalone executable:

See


www.vsp.tu-berlin.dehttp://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

kainagel commented 6 years ago

Upload got stuck because I am in the train; here is at least the text:

I am fairly sure now that the problem is in the data, not in the code. You start seeing it when you set the time-dep display in VIA to "3600" instead of "until next start time":

image

Then you see that after 21:00 the fire has jumped to a small patch further to the north-east:

image

This is presumably due to disconnected polygons in the json: ![Uploading image.png…]() I tried to compensate in the matsim code by using multipolygons, but that does not fix it (I am leaving in the code nevertheless). If you look into the json, you see that there is some hickup with the times: ![Uploading image.png…]() My guess is that matsim is receiving the polygon that is marked under MINUTES with 830.40200. I can't tell from the code since that info seems to be gone, but MATSimModel is certainly getting fewer coordinates than an hour earlier. Removing those shorter entries from the json file fixes the jumping fire. I can't tell about the blockage since that older commit uses different path conventions, editing the json file takes time, and I don't want to do it again. :-)

dhixsingh commented 6 years ago

Oh yes right, that makes sense @kainagel. I should have picked that up but that visual threw me. Thanks so much. I can take it from here.

dhixsingh commented 6 years ago

To clarify that point re the jumping fire, I've attached a few snapshots of the fire through from 8pm-11pm. The reason why vehicles are driving as they are in the original image is because presumably at 9pm there is no fire in that region as can be seen below. Will discuss this with Surf Coast Shire working group.

fire8pm fire9pm fire10pm fire11pm

dhixsingh commented 6 years ago

@kainagel fyi have pushed a fix for this in a4dd0b3688670df9f778010ee76d462d242754c2. Instead of dealing with it in MATSimModel, I've updated the PhoenixFireModel to instead send all fire shapes prior to a given time. That way the union is always the full fire shape and nothing is lost in case we see these discontiguous shapes in the fire shapefile.

Relevant code is here: https://github.com/agentsoz/bdi-abm-integration/blob/a4dd0b3688670df9f778010ee76d462d242754c2/examples/bushfire/src/main/java/io/github/agentsoz/ees/PhoenixFireModule.java#L119-L125

/cc @osbornejr