EIDM slowToStartTerm/patchSpeedBeforeLCEIDM may be ignored, when calculated in finalizeSpeed

[Domsall]

The following line is responsable for ignoring the output of finalizeSpeed, when the vehicle wants to drive over a junction:

https://github.com/eclipse/sumo/blob/ea11ca980bb42de0756fde918afc9f27cc26083e/src/microsim/MSVehicle.cpp#L4128

The output of finalizeSpeed is purposely overwritten, when vSafeMin is higher. This does not perform well with intended acceleration slow-down such as slowToStartTerm.

@namdre: Do you have a suggestion how to change/where to put slowToStartTerm and patchSpeedBeforeLCEIDM, so that they are always included in the calculation?! Can the above mentioned line and Code logics be somehow changed?

[namdre]

A solution might be to override MSCFModel::maxNextSpeed so it accounts for EIDM slow-to-start acceleration and then take this into account at https://github.com/eclipse/sumo/blob/9f2f3224cc7d3bcf1c3c693cf89d310c28499ab6/src/microsim/MSVehicle.cpp#L3351-L3355

[Domsall]

Is it possible to add a new MSCF-function for this? If I understand it correctly, it would be something like: MIN2((double) DIST2SPEED(vSafeMinDist + POSITION_EPS), dpi.myVLinkPass, maxNextSpeedDriveDynamics);

I tried to add a EIDM::maxNextSpeed, but came across a few issues. Especially startupDelay does not work correctly again (dpi.myVLinkPass and const double maxV = cfModel.maxNextSpeed(myState.mySpeed, this); are then very small when starting up). The issue is somewhat similar to EIDM::minNextSpeed :)

[namdre]

After thinking about this some more:

The code path, with vSafeMin is only triggered in a critical situation: The vehicle has committed to passing an unprioritized intersection and is too fast to brake. This is a somewhat dangerous situation and so the junction model purposefully overrules normal carFollowModel behavior (i.e. dawdling).

Arguably we might wish to influence the junction model and permit dangerous dawdling behavior but the basic idea of one model overruling another is fine.