| Re: [sumo-user] Is it OK to calibrate SUMO by modifying edge speed in a simplified network? |
Good morning!Perhaps, in this case, since the network will not be used in a future scenario, adjusting edge speed is a good technique, and since a model for emissions is being calibrated that strongly depends on the speed being close to reality, it could be a good solution.The important thing in this situation is the interpretation of the other indicator outputs so that you can analyze more carefully indicators that are a relationship between a potential edge speed and the speed that occurs in practice, such as: relative speed, time loss... and you would have to research what others. For these two, for example, relative speed will give you approximately 100% and time loss will return close to 0, since the vehicles are traveling at the target edge speed.Density will not be an affected parameter; it would only be in a future scenario that you implement some improvement.Since you are also working in an urban area, and in that case there may be factors affecting the free-flow speed (not being limited by the flow), this could be a good argument for adjusting edge speed, based on the fact that adding other interferences to the simulation would be technically unfeasible.This is my view as a user; we can wait to see what the SUMO developers, who have more experience and knowledge of the software, would recommend.Sds,Pedro OliveiraEm qua, 3 de dez de 2025 06:16, Gabriel García Casa <gabrielgarciacasa@xxxxxxxxx> escreveu: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!GabrielEl 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 OliveiraEm 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