GCFMModel::forcePedPed() ep12 cannot be computed.

[gjaeger]

JuPedSim - JPScore

[2020-07-01 20:37:00.502] [info] Commit id v0.8.4-991-g9749a79
[2020-07-01 20:37:00.502] [info] Commit date Thu Jun 18 22:03:54 2020
[2020-07-01 20:37:00.502] [info] Build from branch master
[2020-07-01 20:37:00.502] [info] Build with g++(8.3.0)

Describe the bug

I get this error message

[error] GCFMModel::forcePedPed() ep12 cannot be computed.

when using the GCFM model to simulate a fundamental diagram of a corridor with the following settings:

<operational_models>
  <model operational_model_id="1" description="gcfm">
    <model_parameters>
      <solver>euler</solver>
      <stepsize>0.01</stepsize>
      <exit_crossing_strategy>3</exit_crossing_strategy>
      <linkedcells enabled="true" cell_size="2.2"/>
      <force_ped  nu="0.6"
                  dist_max="3"
                  disteff_max="2"
                  interpolation_width="0.1"/>
      <force_wall nu="0.2"
                  dist_max="3"
                  disteff_max="2"
                  interpolation_width="0.1"/>
    </model_parameters>

    <agent_parameters agent_parameter_id="1">
      <v0 mu="1.3" sigma="0.00" />     <!-- desired speed -->
      <bmin mu="0.25" sigma="0.001" />  <!-- minimal length of the shoulder semi-axis -->
      <bmax mu="0.20" sigma="0.001" />  <!-- maximal length of the shoulder semi-axis -->
      <amin mu="0.18" sigma="0.001" />  <!-- minimal length of the movement semi-axis -->
      <atau mu="0.50" sigma="0.001" />   <!-- speed-dependency of movement semi-axis -->
      <tau  mu="0.50" sigma="0.001" />    <!-- reaction time -->
    </agent_parameters>
  </model>
</operational_models>

The calculation is not aborted and continues. The fundamental diagram resulting from the simulations is completely unrealistic. Already at a density of $1 m^{-2}$, agent stop moving.

[chraibi]

This is rather a warning and not an error and means that the distance between two different agents is very small so that the inverse of the distance can not be calculated (division by zero). Since this behavior (overlapping) is typical for force-based models (like GCFM), there is elegant solution, unless we introduce some collision mechanisms or add contact forces.

The calculation is not aborted and continues.

According to this line

LOG_ERROR("GCFMModel::forcePedPed() ep12 cannot be computed.");
return F_rep; // FIXME: should never happen

continuing the simulation is with purpose. Abording would be too annoying. However, if this happens very often in a single simulation, then the results won't make any sense (for instance high flows at bottlenecks) and parameters should be changed accordingly to mitigate overlappings.

Already at a density of $1 m^{-2}$, agents stop moving.

could happen, when agents do not have any space left. See for example these screenshots:

• Time 0 s

• Time 6 s

As you can see, only the agents with enough space in the front can move. The rest will have to be patient.

I would recommend using a smaller time step (e.g. 0.001s), then an acceleration model needs more accuracy than a velocity model. We already use the very simple and inaccurate Euler method. Therefore, bigger time steps lead to more errors.

[gjaeger]

This is rather a warning and not an error and means that the distance between two different agents is very small so that the inverse of the distance can not be calculated (division by zero).

After the message, I assumed an error. If it's a warning, shouldn't we change the output?

Thank you for your comments. These are helpful background information.

I would recommend using a smaller time step (e.g. 0.001s), then an acceleration model needs more accuracy than a velocity model. We already use the very simple and inaccurate Euler method. Therefore, bigger time steps lead to more errors.

The manual explains that for force-based models the time step should be between $10^{-2} s$ and $10^{-3} s$. I used the time step of $10^{-2} s$. What is the best way to find a suitable time step?