Dear Jan, (1) Yes. We do the same thing (e.g MSDevice_Tripinfo::notifyEnter) (2) I don't understand why the type of simulation needs to be known within HelpersEnergy:compute(). Can you elaborate? (3) If all you need is a lookup from lanes to an ID there may be better ways to approach this. You could define polygons with <param> elements to identify them as overhead lines for a particular lane, then create a static map between lanes and lines from the polygon data (and get a slick colored visualization on top) e.g. <poly id="caternay_123" color="red" width="0.1"> <param key="lanes" value="lane1 lane2 lane3"/> <poly>
(4) The code that triggers the output for each object can go into MSNet but anything on top of that I would put into a separate class (5) Vehicle stopping on the road due to empty batteries should still be an exceptional case and I would make any custom behavior in this situation optional. Instead of setting the speed to 0 I would use either of the following two approaches a) adding a stop for some a fixed duration (similar to --collision.stoptime) b) using veh->getInfluencer().setSpeedTimeLine(speedTimeLine) to let the vehicle stop for a specified duration (see libsumo/Vehicle::slowDown) Regarding the error mesoscopic model documentation, you are correct. I've removed public transport from the list of limitations. It would help if you could describe how your extension differs from the existing electrical vehicle model. In particular I would like to figure out whether it would make sense to generalize the existing battery device rather than adding another device. Tracking of substations / energy network usage might be a reason but there may be better places than a vehicle device to do so. best regards, Jakob Am Fr., 9. Nov. 2018 um 13:47 Uhr schrieb Jan Přikryl <prik...@fd.cvut.cz>: > 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 > prik...@fd.cvut.cz > _______________________________________________ > sumo-dev mailing list > sumo-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-dev >
_______________________________________________ sumo-dev mailing list sumo-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-dev
