Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Is it OK to calibrate SUMO by modifying edge speed in a simplified network?

Good afternoon Pedro, thank you very much for the detailed reply. 

Let me add a bit more context about my use case, because it may affect whether adjusting edge.speed is acceptable or not.

My final objective is emission prediction, where accuracy depends strongly on mean speed per edge, acceleration / stop-and-go patterns and time-loss reproduction. Even adjusting tau, sigma and speedFactor globally, the gap remains substantial in many urban edges, that's why we treated adjustments to edge.speed as an operational tool to close the calibration loop, ensuring that observed free-flow speeds are matched when behavioural parameters alone cannot achieve this because of the simplified model (default traffic lights, no behavioural heterogeneity, default vType, etc.). Also taking into account that the comparison between real and simulated traffic counts obtained is pretty accurate (92.7%) with flowrouter.

I understand your point about future scenarios, however, I do not plan to evaluate infrastructure upgrades, only emission baselines and short-term predictions. So I am trying to judge whether modifying edge.speed is an acceptable pragmatic solution in this context or something SUMO experts would still discourage, even for emission-focused applications.

For even further context, I am sharing the results of matching speeds before and after applying the algorithm. Before the algorithm (only blue dots), you can see the comparison between real speed (X axis) and simulated speed (Y axis), where the simulation shows a clear trend to real speed limits (20-30-50 km/h). After applying the algorithm, the accuracy for both the detectors used for calibration (blue dots) and the detectors used for validation (red dots) increases a lot.

Would you still recommend avoiding modifications to edge.speed, even if driver-parameter calibration alone cannot fully reproduce the observed speeds?  

Thanks again for your guidance!

Gabriel





El mar, 2 dic 2025 a las 18:30, Pedro Oliveira (<pedro.engenhariae@xxxxxxxxx>) escribió:
Good afternoon!

 Well, in the analyses I conduct and what I see others developing, the road speed should be the regulated speed because the parameters derive from it, such as: density, relative speed, time loss, etc. 
Obviously, in some cases, such as very steep inclines, sharp curves, speed bumps, where it is easier to reduce the speed than to modify the geometry, I set a lower value that is more compatible with reality.
 Many analysts prefer that road speeds be the regulated speed. I would work by interfering less with the network and modeling the drivers more, but this is not a general rule.
I believe that for future uses of the network, it could be a problem if you calibrate the path with a very low speed; you won't be able to verify the speed gain in improved scenarios.

Sds,

Pedro Oliveira 

Em ter, 2 de dez de 2025 13:56, Gabriel García Casa via sumo-user <sumo-user@xxxxxxxxxxx> escreveu:
Good afternoon everyone,

I'm calibrating an only cars and highways SUMO model. The only modifications done are in terms of connections, number of lanes and geometry of edges, everything else is default from osmWebWizard.

I use loop detector traffic and speed counts and run an algorithm that follows an iterative process:

- Build routes with flowrouter + implausibleRoutes + flowrouter with the implausibleRoutes restrictions, taking into account real traffic counts.

- Simulate and compare real vs simulated edge speeds (e1Detector)

- Compute a factor between vreal and vsimulated

- Modify parameter 'speed' on detector edges, then propagate to neighbors

- Optionally, if specified by the user, the algorithm runs a grid-search on global driver parameters (tau, sigma, speedFactor, speedDev)
  
Given the simplification of the model: 

My questions:

 - Is it methodologically acceptable to calibrate by modifying edge speed (interpreted as “effective” free-flow speed), or is this discouraged in SUMO?

-   Is it better to keep speed limits fixed and calibrate only driver parameters?

- Any known pitfalls of adjusting speed this way for later use of the network?

Any short guidance or pointers to examples / best practices would be very helpful.

Thanks in advance,

Gabriel  






  


_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Attachment: Speed_After_Algorithm.png
Description: PNG image

Attachment: Speed_Before_Algorithm.png
Description: PNG image


Back to the top