Open Tasks to be Completed

[ciaradunks]

Below is a list of tasks to be completed, but the list will be updated/adapted on a regular basis.

General

• Add oemof-industry to the requirements (talk to PF/Hendrik about this)
• Decide on structure for csvs in elements (e.g. see if there is a way to group together certain csvs into one source csv) to provide a clear structure for components
  WARNING: danger of diverting too much from oemof-tabular structure, and could get messy with e.g. different source components requiring very different input parameters, but there could be a way around this

Pre-processing

• Write a function that automatically creates the datapackage.json file from CSV inputs after setting up CSV files (ask PF if he has already done this)
• This is done in oemof-tabular already - modify to work in oemof-tabular-plugins
• It uses building.infer_metadata() in scripts/infer. When automatically created, the type of some parameters in the json file is automatically set to integer - this might cause problems
• Decide how to resolve this (either ensure values are of correct type e.g. int or try and change the type for some params)
• Check pre-processing for the addition of CAPEX, OPEX fix and lifetime parameters and determine if they need to be also included in 'custom_attributes' of output parameters column (might be important for GUI?)
• Write function that automatically creates the datapackage.json file from an oemof-model
  e.g. so someone using the MVS can transfer their models over to oemof-tabular
• Check how capacity_minimum is implemented and then use it for planned capacities
  e.g. if 50 MW PV is planned, then set capacity_minimum to 50 and capacity_maximum to 50 to see if this works and then still can include investment costs

Components

• PV panel:
  At the moment, PV panel is its own facade and additional parameters specific for the panel type
• Either the facade has to be adapted later so that pv_panel component can be in conversion.csv (to avoid many csv files) and only the pv_panel type needs to be specified and other params come from specification sheet
• or a function is written for graphical user interface to automatically fill in the PV panel parameters based on a pv panel specification file and the facade is untouched
• Decide what is best to do based on clarity and staying in-line with oemof-tabular!
• Multi-input multi-output transformer:
• Thoroughly check that the mimo transformer is defined correctly in the examples
• The component has been based on this: https://calliope.readthedocs.io/en/v0.6.8/user/advanced_constraints.html#the-conversion-plus-tech
• There are lots of variations to this component, could be useful for future component building
• Battery component:
• Check that this works as expected for storage capacity costs
• Solution: see https://github.com/oemof/oemof-tabular/blob/dev/src/oemof/tabular/_facade.py_

Post-processing

• Adapt the results in post-processing to be generated from a tidy dataframe, see discussion: Formatting of the oemof-solph results #10

Documentation

• Add explanation in README file for the installation and usage of OTP e.g. how to use the examples
• Documentation for oemof-tabular-plugins
• Documentation for multiple input multiple output (MIMO) transformer: https://github.com/sedos-project/oemof.industry/blob/main/oemof_industry/mimo_converter.py

Tests

• Pre-processing tests:
• Pre-processing costs
• Pre-processing custom attributes
• Post-processing tests: TO BE COMPLETED
• Examples:
• Make sure that all examples run through successfully with each new PR merged into production (talk to PF)