Usecase 7: Electric vehicles

[jnnr]

This usecase tests the flexibility option of electric vehicles.

TODO

• [x] Create Bev-facade
• [x] Pass efficiency
• [x] Pass tests
• [x] Update Bev's attributes in component_atts
• [x] Adapt update function
• [x] Run the model
• [x] Get complete results: I am not sure about what the scalars 'shifting' should mean. Will ask first. update: Got replaced by "Charging".
• [x] Check results: Looks good. Only larger difference is in the marginal_cost: They are set on the vehicle-to-grid flow, not on the battery output flow. To set it in the latter way would require quite a lot of more work. Battery outflow comprises both the flow to drive power as well as the flow back to the grid. As the drive power is fixed exogenously, the part of the cost that really influences the results is similar (apart from the fact that there is an efficiency on vehicle-to-grid), so the main influence is in reporting. Will discuss this with the partners.

[jnnr]

The usecase runs. Mapping results from oemoflex_scalars to the results template does not work yet - the numbers do not find their way into their place. This is because when filtering for the requested value, a series with an index is returned and not a float.

https://github.com/modex-flexmex/oemo-flex/blob/de08222b1cfd8eab3551eebaa86d6d180080ca4e/oemoflex/postprocessing.py#L547-L551

I could not find out yet why this happens. This leads the script to fail transfering the data just a few lines below.

https://github.com/modex-flexmex/oemo-flex/blob/de08222b1cfd8eab3551eebaa86d6d180080ca4e/oemoflex/postprocessing.py#L560

Update: It was caused by duplicate entries in the multiindex. Marginal costs were listed in the attributes, but they were not processed anywhere. This lead to get_varom_cost yielding empty data, all with the same index. I removed the marginal_cost in 0e21c7b , which fixed the problem.

[unndreay]

Updated some files after changes on usecase 3 that affect this usecase here, too.

Since this usecase still needs some coding, here are the parts which may need a change if sequences from the Sink ('drive_power') subnode have to be processed.

1. Sink must be overwirtten just like Source and Transformer to let it have the carrier and tech property. Use the Source/inflow subnode as a template: https://github.com/modex-flexmex/oemo-flex/blob/991a08dd9a83ca29321d84c7178836fd78d01833/oemoflex/facades.py#L7-L19 and hand over the property values in init() https://github.com/modex-flexmex/oemo-flex/blob/991a08dd9a83ca29321d84c7178836fd78d01833/oemoflex/facades.py#L488-L489

2. The drive_power subnode has to be kept in mind similar to... https://github.com/modex-flexmex/oemo-flex/blob/991a08dd9a83ca29321d84c7178836fd78d01833/oemoflex/postprocessing.py#L275-L276 ...and later, all nodes must be checked against it: https://github.com/modex-flexmex/oemo-flex/blob/991a08dd9a83ca29321d84c7178836fd78d01833/oemoflex/postprocessing.py#L312-L313

3. An exception has to be added to the exclusion of bus subnodes: https://github.com/modex-flexmex/oemo-flex/blob/991a08dd9a83ca29321d84c7178836fd78d01833/oemoflex/postprocessing.py#L323-L324

4. Finally, the if conditions to rename the node at https://github.com/modex-flexmex/oemo-flex/blob/991a08dd9a83ca29321d84c7178836fd78d01833/oemoflex/postprocessing.py#L330-L338 have to be extended with:

            or isinstance(component, Source) and name[1] == 'drive_power'

[jnnr]

... if sequences from the Sink ('drive_power') subnode have to be processed.

They are fixed, so no new information on the drive power is created by running the model. So we will leave that out.