Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[sumo-dev] Mesoscopic changes

Dear all,

we are slowly finalising the electric/trolleybus extension of microscopic and mesoscopic mode. So far it works for us, but before we offer the code as a pull request, there is still a long way to go as the code -- even if compiling and running okay -- probably contains portions that are not appropriately placed in the source/library tree, and, frankly, also a lot of ugly hacks. Hence, I would like to discuss some potential problems before we make the code available.

What I am not sure about includes (the list is probably fairly incomplete):

(1) we keep using  an instance of MSDevice (i.e. a micro-simulation device `MSDevice_ElecHybrid`) in mesoscopic mode, introducing checks to `notifyEnter()` and `notifyLeave()` methods to determine the type of simulation that is currently running (via `MSGlobals::gUseMesoSim`). Is this the way to go?

(2) the energy consumption of the trolleybus is at this moment identical with that of an electric vehicle, i.e. we use the `PollutantInterface` to give us an instance of `HelpersEnergy` class to compute the energy consumed on microscopic and mesoscopic segment. As a result, the `HelpersEnergy::compute()` methods needs to know about the type of simulation as well, but this makes the class dependent on `mesolib` target, requiring executables besides `sumo` and `sumo-gui` to link to `mesolib` as well. This is most likely something that we should avoid (I suppose for example that when calling e.g. `duarouter`, the value of `MSGlobals::gUseMesoSim` is not guaranteed to be initialised).

(3) the overhead line (trolley/catenary) object is derived from `MSChargingStation` which in turn inherits from `MSStoppingPlace`. As there are no required stops to charge a trolleybus, my idea would be to put an intermediate class between `Named` and `MSStoppingPlace` that would provide only the lookup interface (we need to look up the correct overhead line when a vehicle enters an edge/lane) and would not contain the stopping place functionality which is not needed.

(4) currently the statistics of particular overhead line sections and associated substations (power stations, voltage changers) is being output using additional code that lives in MSNet class (similarly to `MSNet::writeChargingStationOutput()`). Is this the correct place?

(5) both original electric vehicles and our trolleybus would continue to move even if their battery is completely discharged and there is no overhead line to recharge it from. At the moment we explicitly set the speed of the vehicle to zero in microsimulation, overriding the value computed by the car-following model. Is it an acceptable hack or is there a more systematic way to introduce this scenario (this is namely more likely to happen in case of electric vehicle).

By the way, the current status page of mesoscopic mode in SUMO (http://sumo.dlr.de/wiki/Simulation/Meso) is probably outdated (if I understood the release notes correctly, at least public transport is now supported in mesoscopic mode), but I failed to locate the mesoscopic emission routines when looking at calls to `PollutantInterface` so that I can get a clue how to update the code in `HelpersEnergy`. Does SUMO currently support computing emissions in mesoscopic mode?

If it helps, I can describe the changes more in details (list the new classes, changes to existing classes, etc.).

Thanks a lot.


-- 
  Jan Přikryl
  prikryl@xxxxxxxxxx


Back to the top