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>:
> 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> 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
> 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
