agentsoz/bdi-abm-integration

Undesired routing through fire in Anglesea12kTestSample

dhixsingh opened this issue · 5 comments

dhixsingh commented

In commit d9c23da, 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:

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

Lines 197 to 206 in d48f0bf

static void penaltyMethod2(Geometry fire, Geometry buffer, double bufferWidth,
Map<Id<Link>, Double> penaltyFactorsOfLinks, Scenario scenario ) {
// Starting thoughts:
// * Could make everything very expensive in buffer + fire, they find the fastest path out. This may, however,
// be through the fire.
// * Could make everything very expensive in fire, and factor of 10 less expensive in buffer. Then they would
// find fastest way out of fire, then fastest way out of buffer.
// * Problem is that fastest way out of buffer may entail getting or remaining close to the fire.
//
// What about

Might need help from @kainagel here.

kainagel commented
kainagel commented
dhixsingh commented

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

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

@kainagel fyi have pushed a fix for this in a4dd0b3. 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:

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

Lines 119 to 125 in a4dd0b3

// Setting 'lastUpdateTimeInMinutes = time' below will mean that only the new fire shapes since the
// last update will be sent. However, this can cause problems for the model if the fire shapes are
// discontiguous. See https://github.com/agentsoz/bdi-abm-integration/issues/36.
// So instead, we send all the shapes up until now. This ensures that the state of the fire
// in the model will always be a union of all shapes from the start of fire.
// To send all shapes, just disable the lastUpdateTimeInMinutes update below
// lastUpdateTimeInMinutes = time;

/cc @osbornejr