• For stacking/unstacking to be reversible, the columns have been sorted. This is not ideal. The index order could be retained when unstacking. However, if some other step is performed with the stacked data, that information would be lost.
• This has consequences even here!:

  oemoflex/oemoflex/model/model_structure.py

  Lines 313 to 316 in 3431118

  	# sort the columns for comparability
  	component_df = pd.DataFrame(comp_data).set_index("name")
  	component_df = component_df[sorted(component_df.columns)]

• There is no guarantee that the index of the dataframes is always the same. When load from_csv_dir, DataFramePackage assumes index_col=0.
• This is connected to

  oemoflex/oemoflex/model/datapackage.py

  Lines 494 to 495 in ad39494

  	# TODO: Check if this step is necessary only because function is used differently in some cases.
  	_stacked_frame = stacked_frame.reset_index()

RTD fails to install package due to dependency problems. setuptools 58 stopped supporting use_2to3, which is needed by simpleeval.

As a temporary fix it has been suggested to pin setuptools < 58 as long as some packages have not dropped the dependency on use_2to3.

In the facade_attr file of excess a wrong attribute is listed: capacity. It is not an attribute that is passed in class Excess in oemof.tabular.

Related issues are: #85 and oemof/oemof-tabular#65

Facades that can be expandable have an attribute capacity_potential, which means the maximal possible capacity. It is missing in facade_attrs.

How to fix that? Have a look at the files in oemoflex/model/facade_attrs/. Each file describes the attributes that the respective facade has. Have a look at oemof.tabular.facades to see which facade classes have the attribute capacity_potentialand if they do, add a line in the respective file in oemoflex/model/facade_attrs/<file_name.csv>.

There are different ways to check the results.
One opportunity is to check the results of electricity supply and demand:
(Background: I checked the oemof-B3 results data for the bus BB-electricity and demand minus supply was not always zero.)

• Calculate the balance in every time step. (supposed to be zero)

There is no consequence if I add attributes of a component which do not appear in its class to the csv files in facade_attrs.

I would expect a test or error message which ensure that a valid attribute is passed.

Fix to oemof.tabular dev and hence fix to oemof.solph==0.5.2dev0

Including "capacity" in the results is inconsistent because it is an input parameter, not a result.

@MaGering: Can you please check if we can drop "capacity" from the results?

The generic functionality here can move step-by-step to oemof.tabular. If most or all can be moved, this would make maintenance easier.

These can be addressed one after the other:

• Postprocessing (after #82 is merged and tested in practice for a bit)
• Plots

These belong together

• DataFramepackage class
• Define schemas for tabular data packages that describe energy systems in facade_attrs and the available components and busses in component_attrs.yml and busses.yml
• Setup datapackages by passing the lists of regions, links, busses and components to EnergyDataPackage.setup_default. Custom-defined busses and components can be passed as dictionaries bus_attrs_update and component_attrs_update.
• Parametrize the EnergyDataPackage with EnergyDataPackage.parametrize
• stacking, unstacking
• sensitivity

This could be checked, too:

• Infer metadata (mainly done by oemof.tabular already, but maybe there are some extra features that can improve tabular).

Proposal:

• Could remove all component attributes where no default is set and draw the attributes from the facade (defined by type) when creating empty dataframes.
• Could also remove region and name, as these are there by default

Con: This would mean that component_attrs are not a comprehensive documentation of the attributes any more.

There is no docs. The readme should be more descriptive as well.

Capacity is set to a flow in a component, internally. The postprocessed data does not tell to which bus it is connected.

Suggestion: Do not collect capacity. but rather nominal value of the flow.

Should set up github actions.

The facades Backpressure and ExtractionTurbine allow investment. Investment attributes (capacity_cost, expandable) are not defined in the facade_attrs.

TODO: Update facade_attrs.

The variable names that appear in postprocessed data should be documented. In the course of that, we can check if the naming system is consistent.

So far, modeling with a single-node does not seem to be possible in oemoflex.

setup_default function requires positional argument 'links'

Setting up github actions in PR #23, I've specified the version of black to black==20.8b1 orientating on https://github.com/rl-institut/oemof-B3/pull/25/files.

This has led to the following question:

Does it have to be this specific black version?

Originally posted by @jnnr in #23 (comment)

Preparation

• Finish issues and PRs related to the release
• Increase version that is installed running pip install oemoflex
• Test the examples
• Keep an eye on open issues that are set to your release but seem to be forgotten.
• Check that the docs look good.

Day of release

• Optional: Open a release branch to avoid conflicts with other uses while the release progress.
• Close "forgotten" issues with a recapitulatory comment or set them to a later release if they are still important.
• Test if everything works
• If you have failing test fix them or postpone the release.
• Check the whatsnew-file
• Check if the latest documentation looks right at readthedocs.
• Change the version number everywhere!!! (e.g. from 0.2.1dev to 0.2.1) -> pyproject.yaml and docs/conf.py
• If everything seems to work, merge the release branch into the main branch. (--no-ff)
• Push your local main branch to the remote.
• Set a release on github. Select the main branch (default: dev)! A label is set automatically.
• Use git fetch to see the label in your local main branch.
• Merge the release branch into the dev branch. (--no-ff)
• Remove the obsolete release branch.
• Prepare the dev branch for further development: Adapt the version number at (e.g. from 0.2.1 to 0.2.2dev). Also add a new whatsnew file and a link in the whatsnew.rst file. Open the file locally or use the RAW button to see the links.
• Close the release issue with informations for the community and relax

oemof is installed with the installation of oemof.tabular in install_requires of oemoflex' setup.py. As far as I'm concerned oemof is obsolete and might lead to errors when using it. Should we consider dropping oemof from the install_requires?

Originally posted by @MaGering in #26 (comment)

Preparation

• Finish issues and PRs related to the release
• Increase version that is installed running pip install oemoflex
• Test the examples
• Keep an eye on open issues that are set to your release but seem to be forgotten.
• Check that the docs look good.

Day of release

• Optional: Open a release branch to avoid conflicts with other uses while the release progress.
• Close "forgotten" issues with a recapitulatory comment or set them to a later release if they are still important.
• Test if everything works
• If you have failing test fix them or postpone the release.
• Check the whatsnew-file
• Check if the latest documentation looks right at readthedocs.
• Change the version number everywhere!!! (e.g. from 0.2.1dev to 0.2.1) -> pyproject.yaml and docs/conf.py
• If everything seems to work, merge the release branch into the main branch. (--no-ff)
• Push your local main branch to the remote.
• Set a release on github. Select the main branch (default: dev)! A label is set automatically.
• Use git fetch to see the label in your local main branch.
• Merge the release branch into the dev branch. (--no-ff)
• Remove the obsolete release branch.
• Prepare the dev branch for further development: Adapt the version number at (e.g. from 0.2.1 to 0.2.2dev). Also add a new whatsnew file and a link in the whatsnew.rst file. Open the file locally or use the RAW button to see the links.
• Close the release issue with informations for the community and relax

Hi @jnnr,

I revisited the postprocessing code, here my suggestions for refactoring the module:

• helper functions look very good, only some minor refactoring possible but not prio 1 (i.e. get_losses and subtract_output_from_input could be improved)
• Actual calculations in run_postprocessing could be refactored using my suggestion from https://gist.github.com/henhuy/2f94df3f80dd5c8b01c739218df9f82e
• I would refactor code to only make use of str-based keys (instead of oemof.solph components) - this is needed i.e. in digiplan as data is sored/restored from DB in str-based format and postprocessing is done afterwards. Also we get rid of those nasty pickles!
• change end of script in order to support multiple output formats (calculations are fine until every thing is gathered - then some oemof-B3 specific output formatting is done). Here I could think of a adapter-like interface for individual output formats

If we agree on refactoring, I would start by adding tests for postprocessing, so that we can guarantee results to be the same!

What do you think?

Running simulations on oemof-B3 the plotting errors out hence the directory postprocessed/sequences/bus and all its content is missing.

I suppose the error occurs about here.

All functions and methods should have a docstring.

Installing with setuptools >= 58 will lead to errors because simpleeval (a dependency of frictionless) uses use_2to3.

Python3.7 is outdated and must be removed from github action checks.
Instead versions 3.8 - 3.10 should be activated

Preparation

• Finish issues and PRs related to the release
• Increase version that is installed running pip install oemoflex
• Test the examples
• Keep an eye on open issues that are set to your release but seem to be forgotten.
• Check that the docs look good.

Day of release

• Optional: Open a release branch to avoid conflicts with other uses while the release progress.
• Close "forgotten" issues with a recapitulatory comment or set them to a later release if they are still important.
• Test if everything works
• If you have failing test fix them or postpone the release.
• Check the whatsnew-file
• Check if the latest documentation looks right at readthedocs.
• Change the version number everywhere!!! (e.g. from 0.2.1dev to 0.2.1) -> pyproject.yaml and docs/conf.py
• If everything seems to work, merge the release branch into the main branch. (--no-ff)
• Push your local main branch to the remote.
• Set a release on github. Select the main branch (default: dev)! A label is set automatically.
• Use git fetch to see the label in your local main branch.
• Merge the release branch into the dev branch. (--no-ff)
• Remove the obsolete release branch.
• Prepare the dev branch for further development: Adapt the version number at (e.g. from 0.2.1 to 0.2.2dev). Also add a new whatsnew file and a link in the whatsnew.rst file. Open the file locally or use the RAW button to see the links.
• Close the release issue with informations for the community and relax

The functions for reading and saving csv files in datapackage.py do not allow a specification of the delimiter as mentioned in rl-institut/oemof-B3#110 (comment)

The delimiter could be specified by passing sep here:

• _write_resource
• _read_resource

When extending the components in oemoflex, one must not forget to add them to the foreign keys as well.

Problem: When passing component_attrs_update to the method EnergyDatapackage.setup_default(), one would need to update the foreign keys as well, which is not done atm. One solution would be to generate the list of foreign keys automatically from the component definitions.

When postprocessing scalars, the label of the variable is mapped from tuple to a single label of the form <in/out><bus_name>. The idea here is that the name of the bus defines the energy carrier of the flow. It is possibe however to connect oemof components without intermediate buses - which makes the described approach fail.

Currently, investment is not possible for these types of components:

• backpressure #21
• extraction #21
• link
• reservoir

The function get_losses returns 4 values for transmission losses. If directed losses are of interested, it should be two values, if not only one.

The error occurs because subnodes appear in the tuples of the results. However, the subnodes do not have the classifying attributes region, carrier, tech.

How to reproduce: Run a model with Bev or AssymetricStorage, run postprocessing.