Re: [sumo-dev] Mesoscopic changes
Hello Jan, (2) there already exists infrastructure within Sumo to compute emissions for mesosim using the default compute() interface (admittedly, this is very hard to figure out from the code alone). This is done by implementing the method MSMoveReminder::notifyMoveInternal >From this method you have access to the time, meanSpeed and distance travelled on the current segment and this is triggered whenever leaving a segment. You can take a a look at MSMeanData_Emissions::notifyMoveInternal. Here the compute() method is called only once for a representative second and the value is scaled using time spend on the segment. You are free to call the compute() method multiple times to achieve more sophisticated interpolations. (3) state-based coloring is indeed easier to achieve with a custom class And I think it's ok to inherit from MSChargingStation even if the stopping place functionality is never used. Regarding the scope of the battery device: I think it would make sense to generalize this to encompass different modes of electrical energy storage. The code for tracking energy use and storage state is well-seperated anyway. best regards, Jakob Am Do., 29. Nov. 2018 um 17:31 Uhr schrieb Jan Přikryl : > 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 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. > > > > > > 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
Re: [sumo-dev] Mesoscopic changes
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 > 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. > > > 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 > :>> Dear all, >> >> we are
Re: [sumo-dev] Mesoscopic changes
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 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. (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 : > 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`.
