A benefit of having notifyIdle would be that it could also handle the case of vehicles being delayed on initial insertion. But it is a complicated thing to do because those vehicles may not have decided yet on which lane to start so you cannot give the right MoveReminder to them beforehand. Also it is not clear whether this case should be handled identically to ending parking. So if you found a method without MoveReminders just go ahead and we are looking forward to the pull request :-)
Best regards, Michael Am 26.02.20 um 21:50 schrieb The div: > Thanks again jakob, I guess you don't sleep ;) > > After sleeping on it I realised I didn't need to kludge the > movereminders - just iterate over the lane movereminders - seems fine. > > I just need to cross check the computed emissions are equal across all > the outputs. > > Cheers > Div > > > > > > > -------- Original Message -------- > On 26 Feb 2020, 08:09, Jakob Erdmann < namdre.s...@gmail.com> wrote: > > > Thanks for the thoughtful discussion, > > - Adding MSMoveReminder::notifyIdle sounds reasonable but l'll have > to discuss this with @behrisch who designed the MoveReminder > architecture and may have further ideas about it. > - I would call the new method MSVehicle::workOnIdleReminders (I > analogy to workOnMoveReminders) because it might be used for other > things besides emissions (https://github.com/eclipse/sumo/issues/2233) > - I think it would be ok to let parking vehicles keep their > moveReminders and let MeanData handle notifyIdle. This would be > consistent with vehicles that stop directly on the road. > - You do not need to wory about performance impact from emission > coloring because the overhead of that check is minimial in > comparisson to the emission calculation. The simulation runs in it's > own thread anyway. However, I would separate the GUI stuff out into > a separate pull request > - having NOTIFICATION_PARKING_REROUTE as the last part of the enum > does not hurt because it is never a reason for leaveLane. (though it > should probably be moved within the enum for consistency) > > best regards, > Jakob > > Am Di., 25. Feb. 2020 um 22:53 Uhr schrieb The div <d...@thoda.uk > <mailto:d...@thoda.uk>>: > > Hi again, > On a first look at the other kind of emission outputs: > > trip information - I tried the following approach and it seems > to behave: > a) added > MSDevice_Emissions::notifyIdle(SUMOTrafficObject& veh) + > (virtual method in MSMoveReminders) which calls > myEmissions.addScaled > b) added MSVehicle::addIdleEmissions() which iterates > over the move reminders invoking notifyIdle > c) invoke MSVehicle::addIdleEmissions() from > MSVehicleTransfer::checkInsertions when the insertion fails > > Color vehicles by emission: > The current code does not recognise that the vehicle is not on > the net - so a parked or stopped vehicle never has zero emissions > - can be corrected by changing the rellevant cases in > GUIVehicle::getColorValue to the equivalent of: > case 14: > if ( isOnRoad() || isTryingToEnterNet() ) > return getCO2Emissions(); > else > return 0.; > > but I might be nervous about a performance impact for large > simulations? > > > Edge/Lane emission aggregations > I can't see a clean way to do these - the parked vehicle has > lost the MSMeanData_Emissions::MSLaneMeanDataValues MSMoveReminder > adding this back then handling lane re-entry would be a > horrible kludge. > > Arguably the Edge/Lane emissions should not have the parking > related emissions anyway - it feels like the correct approach > would be to add a specific MSMoveReminder for parking emissions > - then add it when the vehicle is parked and remove when > re-entering the lane? > > > Any thoughts welcome! > > fyi: > Whilst looking at this I noted that the definition of enum > Notification in MSMoveReminder.h has > NOTIFICATION_PARKING_REROUTE appended to the enum. > however the enum has a comment, ("All notifications below must > result in the vehicle not being on the net..."), that suggests > NOTIFICATION_PARKING_REROUTE is in the wrong place? > > cheers > div > -------- Original Message -------- >> On 23 Feb 2020, 21:14, Jakob Erdmann < namdre.s...@gmail.com >> <mailto:namdre.s...@gmail.com>> wrote: >> >> >> The approach sounds reasonable. However, it won't cover >> all kinds of emission outputs: >> https://sumo.dlr.de/docs/Models/Emissions.html#outputs >> >> cheers, >> Jakob >> > > _______________________________________________ > sumo-dev mailing list > sumo-dev@eclipse.org <mailto: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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
