Re: [sumo-dev] emissions whilst trying to exit from parking

[Michael Behrisch]

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

Re: [sumo-dev] emissions whilst trying to exit from parking

[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 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 :
>
>> 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::getColorValueto 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.hhas  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

Re: [sumo-dev] emissions whilst trying to exit from parking

[Jakob Erdmann]

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 :

> 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::getColorValueto 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.hhas  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

Re: [sumo-dev] emissions whilst trying to exit from parking

[The div]

Oops - thanks, I'll look wider!

 Original Message 
On 23 Feb 2020, 21:14, Jakob Erdmann 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
>
> Am So., 23. Feb. 2020 um 20:41 Uhr schrieb The div :
>
>> Hi,
>> I'm playing with multiple aspects of vehicle behaviour associated with 
>> parking.
>>
>> It appears that when the parking/stopping period has ended and the vehicle 
>> is trying to re-enter the net - ie engine is running - emissions are not 
>> computed until the vehicle is actually on the road.
>> In my models this is significant because vehicles are often blocked from 
>> entering the lane, by other vehicles, for many sim steps - equivalent to 
>> 5-10mins real time.
>>
>> I don't pretend to understand the emission model yet, however I have been 
>> looking at what seems a relatively simple way to get these emission values 
>> output - this is what i did:
>> 1) add a new flag  - 'myTryingToEnter' to SUMOVehicle/MSVehicle etc.  
>> paralleling the 'myAmOnNet' flag with associated get/set functions. (This 
>> could equally be an 'engineStarted' flag if there was a more generic use 
>> case.)
>> 2) change MSVehicleTransfer::checkInsertions   line 127  to set this 
>> flag, before the insertion check,  and clear the flag, in the block after 
>> insertion success.
>> 3)  changeMSEmissionExport::write   line 51if (veh->isOnRoad()) 
>> { to something like   if (veh->isOnRoad()  || 
>> veh->isTryingToEnterRoad() ) {
>>
>> This seems to give me (idling) emission outputs with no obvious side effects 
>> wrt my results or the test sets.
>>
>> My questions are
>> a) Is this a sensible approach or is it likely to break something I don't 
>> understand
>> b) If not please could you give me any pointers to implementing this 
>> functionality.
>>
>> cheers
>> div
>>
>> ___
>> 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

Re: [sumo-dev] emissions whilst trying to exit from parking

[Jakob Erdmann]

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

Am So., 23. Feb. 2020 um 20:41 Uhr schrieb The div :

> Hi,
> I'm playing with multiple aspects of vehicle behaviour associated with
> parking.
>
> It appears that when the parking/stopping period has ended and the vehicle
> is trying to re-enter the net - ie engine is running - emissions are not
> computed until the vehicle is actually on the road.
> In my models this is significant because vehicles are often blocked from
> entering the lane, by other vehicles, for many sim steps - equivalent to
> 5-10mins real time.
>
> I don't pretend to understand the emission model yet, however I have been
> looking at what seems a relatively simple way to get these emission values
> output - this is what i did:
> 1) add a new flag  - 'myTryingToEnter' to SUMOVehicle/MSVehicle etc.
> paralleling the 'myAmOnNet' flag with associated get/set functions. (This
> could equally be an 'engineStarted' flag if there was a more generic use
> case.)
> 2) change MSVehicleTransfer::checkInsertions   line 127  to set this
> flag, before the insertion check,  and clear the flag, in the block after
> insertion success.
> 3)  changeMSEmissionExport::write   line 51if
> (veh->isOnRoad()) { to something like   if
> (veh->isOnRoad()  || veh->isTryingToEnterRoad() ) {
>
> This seems to give me (idling) emission outputs with no obvious side
> effects wrt my results or the test sets.
>
> My questions are
> a) Is this a sensible approach or is it likely to break something I don't
> understand
> b) If not please could you give me any pointers to implementing this
> functionality.
>
> cheers
> div
>
>
>
>
>
> ___
> 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