Dear Jakob,
sorry for the delay, a colleague of mine who did many of the microscopic
changes for the trolleybus + overhead line mode was away and I did not
want to provide only part of the information. So:
On Sun, 11 Nov 2018, at 1:17 PM, Jakob Erdmann wrote:
> (2) I don't understand why the type of simulation needs to be known
> within HelpersEnergy:compute(). Can you elaborate?
The reason is the difference in microscopic and mesoscopic state of the
vehicle. The energy computation in microscopic mode can be handled in
`notifyMove()`, but in the case of macroscopic simulation, we compute
the energy consumption in `notifyLeave()`. In order do estimate the
energy needed for moving from the beginning to the end of the mesoscopic
segment, we need to know the speed at the beginning of the segment and
the distance travelled. In microscopic mode we have macros
`ACCEL2SPEED()` and `SPEED2DIST()` to help us in this regard, but these
macros rely on microscopic DELTA_T, which is not available in
macroscopic simulation.
So, basically, my update does the following (HelpersEnergy.cpp,
line cca 60):
// In mesoscopic mode, last speed is given. In microsopic mode, last
speed may be derived // from the acceleration and simulation step length.
const double lastV = MSGlobals::gUseMesoSim ?
param->find(SUMO_ATTR_ARRIVALSPEED)->second : v -
ACCEL2SPEED(a); const double mass =
param->find(SUMO_ATTR_VEHICLEMASS)->second;
// In mesoscopic mode, travelled distance is given by the segment
length. In microsopic // mode, travelled distance may be derived from
the speed and
simulation step length. const double dist = MSGlobals::gUseMesoSim ?
param->find(SUMO_ATTR_LENGTH)->second : SPEED2DIST(v);
hence, I am introducing two new parameters and pass them via
`params` map.
Now when I think of it, I could get rid of the `MSGlobals::gUseMesoSim`
check by checking for presence of e.g.`SUMO_ATTR_ARRIVALSPEED` in
`params` (which is available only in mesoscopic mode) or even by
introducing another parameter like `SUMO_MESOSIM` (this is IMO cleaner).
This way the dependence on MSGlobals will go away.
> (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>
I will look into this, at the moment we have a custom code to draw the
overhead line (new GUITrolley GL object. so that we can change the
colour when charging, and display its parameters), which is, I believe
an extended replica of GUIChargingStation, therefore the reference to
MSStoppingPlace.
> (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
We have just replicated the code that is in
MSNet::writeChargingStationOutput(), and every object (converter
station, overhead line, ...) has its own method that accepts an
OutputDevice instance and writes its data there. It seems that we follow
your recommendation in this case.
> (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)
I will look into this as well.
> Regarding the error mesoscopic model documentation, you are correct.
> I've removed public transport from the list of limitations.
Thanks.
> 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.
We have tried to summarise the changes introduced so far and from my
point of view it would probably make sense to have just a single
electric platform -- i.e. to merge our code into the battery device,
probably creating something else as the resulting device may be a
combination of a fuel cell, supercapacitor, and so on. The summary
(working document, not very polished) can be downloaded from
https://www.dropbox.com/s/9kwbx9ezfvscdib/SUMO%20-%20battery%20vs%20elecHybrid%20devices.pdf?dl=0
(it has more than 1 megabyte, I do not want to attach it).
Thanks for the feedback!
Jan
> 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
