rl-institut / fleema Goto Github PK

The decision making for buses is based on a master's thesis. The proposed algorithms need to be analyzed and converted into code

• Read master thesis
• Flow chart (miro)
• implement

As we want to simulate vehicles per time step, there is likely crossover between the two tools.

• Get simbev and checkout the remote branch feature-41-restructure-simbev or look it up in github
• Look at the Car and CarType classes to check for useful code
• Check other classes for useful functions
• Implement found code in the advantage tool

The planned class structure from the meeting on April 27th 2022 needs to be implemented so that we can start working on the functions. This includes the classes Simulation, Vehicle, and Location and their respective init functions.

Tasks:

• Research docstring conventions
• Decide on convention that fits our needs (typing, readthedocs, ...)
• Write docstrings for existing classes and functions

Currently result files are always created. There should be a run option to create no vehicle outputs, which can improve calculation speed and doesn't clog up the project folder when running pytest

Current charging point choice method doesn't check if the charging event actually contributes to goals in a meaningful way (end of day soc, minimum soc, ...)

Instead of putting the first and last drive to a location in the schedule set a start/end location that the vehicle has to reach by the end of the day. This allows for more flexible charging. It should be an optional parameter.

Write tests that cover all properties and functions of the Location class.

• Define all properties of the class via Miro
• Implement tests that define the functionality of the class
• Implement the class itself

• #49
• Parse temperature series
• Use temperature in driving simulation
• implement changes in simulation and simulation_type

mypy is used to check the code for type hints and enforces good typing practices. To not break the automated tests (again), this will be implemented on it's own branch first until all current mypy issues are resolved

Rounding should only happen at the export stage, not during the calculation.

• remove rounding in the output update function in the vehicle class
• add rounding in the export function

Currently cost is being calculated with a fixed price of 30 ct/kWh. The max cost for charging evaluation is set at 1€. These should be changed to use the actual cost time series and the highest price in the series for the charging evaluation.

• Read cost time series
• Get max values of series for evaluation
• Calculate power cost from time series

Track the interpolated specific consumption in kWh/km in the vehicle drive events and add them to the output csv as an extra column

The current charging_points.json in each scenario contains plug types and charging points using those types. They information for actual plug type (Schuke, Type2, etc) is missing here, and makes it difficult to match vehicles to the proper charging power that's available for them.

This issue should only be tackled once #35 is completed. All scenarios that are not public_transport_base need to be restructured and updated according to changes made in #35, #21 and #22. This includes new input files, changes of the scenario.cfg and structural changes of the directories

Having to copy every single file for a new scenario is not efficient. I suggest a split between data and settings. An example tree could look as follows

• advantage-tool
  • scenario_data
    • bad_birnbach
      • charging_points.json
      • schedule.csv
      • ...
    • bad_birnbach_future
      • ...
  • scenario_settings
    • base_scenario
      • scenario.cfg
      • weights.csv

The name of the scenario_data folder will be set in the scenario.cfg and all data files will be pulled from there. This means that there needs to be a standardized name for every input file.
Optionally we could allow the override of specific file paths. Example:

scenario_data = bad_birnbach
charging_points = bad_birnbach_future

OR

charging_points = scenario_data/bad_birnbach_future/charging_points.json

So either it points to another scenario and takes the specific file from there, or set the path directly. One of those options should be chosen and implemented.

When starting the program, provide a flag option to use an absolute path for finding the scenario config file. This allows separately storing

Plotly is a big package that slows down automatic tests due to installation time.

• Define different levels of installation (refer to "dev" installation option in setup.cfg)
• Implement new installation levels
• Plotly should be an optional requirement

Last update was in #35
This time we want to change the format a little, by including a configs folder inside of the scenario_data subdirectories.

Find a good option to not serve specific ride request when they are deemed impossible. This should include an output noting the missed rides.

ReadTheDocs integration should only be set up once the project goes public, but the docs can already be built. We use .rst files instead of .md, which can easily be used for docs creation. See other projects like TracBEV and SMOOTH for inspiration.

If given a schedule, we can interpolate distances between all points (assuming a straight line grid with only one possible way to get between stations). Distances that can't be calculated could either be left empty or get a high or negative number (up for discussion). This could be a good start to make inputting your own data easier. The incline matrix could be left empty (all 0), but creating the rows and columns can be automated.

In some cases the starting SoC in the first time step isn't being adjusted properly. Also events with event time 0 appear sometimes

possible plots we could have as outputs:

• SoC of vehicles over a day
• grid timeseries
• energy from grid vs from pv
• create flag in config
• docstrings

These could be done with matplotlib or using plotly (html output)

change temperature.csv with 4 columns "hour", "median", "lowest" and "highest" to 2 columns with "hour" and "t_amb"

• check if one charging station is used by multiple people
• check for total connection and charging points
• integrate them into the same scenario
• write new function to get proper results from multi vehicle scenario

In case we don't get access to the API license for missions, for use in our own projects and as a necessary component of the open source version of this tool, a driving simulation is needed.

The driving tool gets initialized with all relevant Locations, distances, maximum average speeds and other parameters. It will take a current location, destination, consumption, max speed, consumption, ... as inputs and return the time taken and the necessary energy for the trip

• read consumption data into simulation (from_config)
• find consumption value through inputs (driving simulation)
• interpolate average speed in config
• create data format for Locations and read it in from_config
• find all values from matrix for drive from location A to B and output consumption

spiceev is currently being called with dummy data. To change this, data in spiceev_interface.py and scenario_info (for relevant classes) needs to be updated. Additional tests to check for correct formatting and successful execution of the Scenario should also be implemented

• change data in spiceev_interface.py, get_spice_ev_scenario_dict()
• update scenario_info property of each relevant class
• create additional tests

• add cost time series
• parse pv and costs
• use current price and production in evaluation function

Event csv should get the following new columns:

• distance
• energy from PV
• energy from grid
• energy cost in €
• co2 emissions in g

Log file (JSON) should contain:

• rejected ride requests
• total emissions
• total cost
• total distance
• total charged energy
• self-sufficiency (pv energy / total energy)

See SimBEV outputs

When no vehicle is being charged the simulation crashes when calculaing self_sufficiency:

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Program Files\JetBrains\PyCharm Community Edition 2020.2.3\plugins\python-ce\helpers\pydev\_pydev_bundle\pydev_umd.py", line 211, in runfile
    runpy._run_module_as_main(module_name)
  File "...\.conda\envs\Advantage_Tool_env\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "...\.conda\envs\Advantage_Tool_env\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "...\PythonProjects\advantage-tool\src\advantage\__main__.py", line 26, in <module>
    main()
  File "...\PythonProjects\advantage-tool\src\advantage\__main__.py", line 21, in main
    simulation.run()
  File "...\PythonProjects\advantage-tool\src\advantage\simulation.py", line 271, in run
    sim.run()
  File "...\PythonProjects\advantage-tool\src\advantage\simulation_types\schedule.py", line 259, in run
    self.simulation.observer.export_log(self.simulation.save_directory)
  File "...\PythonProjects\advantage-tool\src\advantage\simulation_state.py", line 74, in export_log
    self.calculate_key_log_parameters()
  File "...\PythonProjects\advantage-tool\src\advantage\simulation_state.py", line 64, in calculate_key_log_parameters
    self.accumulated_results["energy_from_feed_in"]
KeyError: 'energy_from_feed_in'

Example: \319_szenario_data\Sz_1\01_depot_paper\configs\ohne_prio.cfg

Level of load is a factor from 0-1. Max level of load depends on vehicle type (set when calculating demand table).

• Level of load in schedule?
• check level of load when getting demand (track in drive event?)
• check if interpolation works
• testing

SpiceEV names were changed in rl-institut/spice_ev#160

feedInPower is now localGenerationPower
extLoads are fixedLoads

• replace old names with new ones
• check if functionality is unchanged
• get current users to update SpiceEV in their environments

Multiple parameters are currently hard coded and should be added to the config. This includes the simulation type and the desired end of day soc

Vehicle and Location are currently set up as dataclasses, which only make sense for static objects. If the Simulation class tracks locations and vehicle SoC, this could be kept. Otherwise these should be changed. Dataclasses could be useful for a VehicleType or Charger class

It would be important to be able to see what input was used to generate output. The easiest solution would be to copy the input files to the output folder in a subdirectory called "input". Files that should be included are at least:

• config
• charging_points.json
• vehicle_types.json
  I think bigger files tht are not supposed to change frequently are not as relevant and can be left out to minimize size of each output folder created.

Charger should be a data class. The constructor and additional properties need to be tested and implemented.

• Define all properties of the class via Miro
• Implement tests that define the functionality of the class
• Implement the class itself

One example simulation worked fine without PV weight in the config (set as 0) but failed to complete once it was set higher.

Create an enum to replace the currently used status strings of "parking", "driving", and "charging".

• Create enum
• Replace usage of strings in the code with the enum

Take inspiration from SimBEV

• build dummy files for config
• test config parser

Writing test before implementing the actual code allows for simple and clean development of functions. Tests have to be created based on planned functionality of the software.

• pull locations from distance matrix instead of schedule

Develop tests that define functions and behaviors of the Simulation class.

• Define all properties of the class via Miro
• Implement tests that define the functionality of the class
• Implement the class itself