I'm going to remove this from the dev and start a PR to fix this example.

I found bugs / inconsistencies in the solar thermal collector documentation.

1. Equations are missing due to a wrong path in the solar_thermal_collector.rst file
2. There is a name inconsistency between the symbol of collectors inlet temperature in the equation → Index: "collector in", the symbol convention in the documentation → Index: "coll" and the collectors inlet temperature in the table → Index: "Collector, in"

First, the module name chp.py is an abrevation unlike the other names where "thermal_storage" is used instead of TES, and "concentrating_solar_power" instead of CSP. In my opinion it would be nice to rename the module combined_power_and_heat.py.

Second, we could even use the renaming to find a more appropiate and less missleading name for the module. "CHP" indicates that the module can be used to model the component CHP power plant because such power plant are often called CHP itself. I suggest we use a name that does not refer to a actual machine/unit - such as cogeneration.py.

Do you agree to renaming the modue combined_power_and_heat.py?
What do you think about changing the name to cogeneration.py?

Because of the history of the repo, the project slug of the docs is oemof-heat-components rather than oemof-thermal. Therefore, the docs appear under https://oemof-heat-components.readthedocs.io/en/latest/

I created a second, new project in readthedocs which builts the docs here:
https://oemof-thermal.readthedocs.io/en/latest/

TODOs @oemof/oemof-heat:

• Check if the docs at the new url are correct.
• Update all existing links to the old docs.

Finally, I will

• shutdown the old docs.

Index is empty, module_index leads to 'maze found'.

The combination of heat pumps and phase change material can be used as a rather inexpensive and ecological seasonal energy storage (German: Eisspeicher). This is one component to be developed in this repository.

(This is a todo note for myself. Assign me when I become part of the team.)

So far and to my knowledge, the modules contain functions for preprocessing only. PR #16 introduces a function for allocating emissions in CHP. Maybe there are other situations in which postprocessing functions can help. We should discuss if this demands a change the structure of the modules or the docs.

While reading the api docs I noticed that the csp module header has a different form than the others. Maybe there are other inconsistencies? A quick check will be helpful.

The documentation of the new components should be consistent across the different components. To get there, we need some kind of template. Here a first draft:

• Scheme of the component (e.g. flow diagram).
• Description.
• Link to docstrings for equations (as e.g. https://oemof.readthedocs.io/en/stable/oemof_solph.html#extractionturbinechp-component).
• Insightful output graphics (the same as in the example).

For the docstrings, align along the existing docstring template of oemof/oemof (see this issue https://github.com/oemof/oemof/issues/597)

Please extend this description with your points!

This repo needs a license. I suppose we take the same license as for most other repos in oemof, GPL-3.0?

Travis doesn't test all documents in the tests directory, but only the tests/test_functions.py file.
Can we change this configuration to the whole directory? I would make a PR for that, but I didn't find the place, where it is defined.
@jnnr, can you help me with that? Thanks.

We do not have any tests yet. It would be very helpful for developers to have some automatic tests. I suggest that we do the following: First, think about how reasonable tests for the package would look like. Then, the contributors to the different modules write some tests for the functions.

TODO

• Write tests for solar_thermal_collector

The gitignore file holds comments that are personalized for specific users:

# data from Franzi
CSP_data/
CSP_results/

# results
examples/flat_plate_collector/results/

I suggest either
a) to keep that structure but use git-alias to make identification more easily (Franzi --> FranziPl)
or
b) remove user names and list CSP_data/ and CSP_results/ under # results

Me personally, I prefere option b).

The schematics of the 4 components in this package follow a different logic. Where the ones for stratified_thermal_storage and compression_heat_pumps_chillers show the energy/mass flows and balance in a diagram, the solar_thermal_collector and concentrating_solar_power rather show information flows.

If I remember correctly, we said that we would like to follow the former concept (energy/mass flows). In my opinion, this is useful to know what we are talking about. It makes it easier to understand the concept of the component that is to be represented.

If you agree, this would mean that the collector and csp module would get new schematics in the next release.

Maybe, the information flow picture is helpful in its own right. It could then move further down in the text. Also, keep in mind that this might change when facades are implemented.

Also, the schematics of

• concentrating solar power (@FranziPl),
• solar collector (@c-moeller) and
• stratified thermal storage (@jnnr) resolved in #42

do not have a caption. Please add a caption similar to the one in https://oemof-thermal.readthedocs.io/en/latest/compression_heat_pumps_and_chillers.html

In this issue we plan the next release, scheduled for mid of March 2020.

• For all new features, fixes, etc.: Remember to fill in the information in the whatsnew file.

Readthedocs told me recently: "The project oemof_heat_components doesn't have a valid webhook set up, commits won't trigger new builds for this project."

Who would add a webhook?

As mentioned in PR #77, there are some improvements, which should be done, but which are not part of the PR:

• mention in docs that time index has to be in the time zone consistent to the position defined by lat/long
• In example: Here we define the timezone dataframe.index.tz_localize
• leave out unused data from input data
• pandas problems freq='H' with version 0.24.2
• give warnings, if the selected methods don't match the number of parameters

c_1 and c_2 of the flat plate collector should be named a_1 and a_2 like in the documentation and in data sheets of solar thermal collectors.

csp part of the docu should be extended for the facades

We should add the missing api documentation in api/oemof-thermal.rst
When doing that, we can adapt the order of the modules to alphabetical.

There is no clear data or figure that helps to choose if one wants to use the stratified thermal storage or a simpler model for thermal storages. The plots coming out of examples/stratified_thermal_storage.py give an idea about the difference in the concept, but not about the consequences of choosing this component.

Running a typical model with a simple vs. stratified thermal storage for a whole year would help to quantify the differences.

At the past dev meeting in Berlin, we had a session on facades in oemof. The session is documented here: https://github.com/oemof/organisation/wiki/Meeting-December-2019#facades and the decisions are summarized in this issue: https://github.com/oemof/oemof/issues/594

The proposals that emerged from the session could be implemented as a test. If we like it, we could establish it in the next release.

Before the release, the examples should be polished so that they are easier to read. Skimming through some of them, I saw some typos and a different structure for all of them. As we should test them anyway before releasing, we could also take an hour to clean them up.

The path in the scripts is given in uppercase letters, therefore the files cannot be found.

It would be helpful if the docs on the api is built automatically, as in oemof/oemof:

https://github.com/oemof/oemof/tree/dev/doc/api

Edit: Locally, building the apidocs work. However, readthedocs fails. See below for an error log.

In the documentation of the components (e.g. https://oemof-thermal.readthedocs.io/en/latest/stratified_thermal_storage.html), the link to apidocs is not very precise. I mean this section:

To learn about all parameters that can be passed to the facades, have a look at the api reference for the facade module.

We should correct this by pointing directly to the apidocs of the thermal storage (or the respective component).

In #76, a scheme of the solar thermal collector has been added. However, the image was not included in docs/solar_thermal_collector.rst, so it is not shown. In a new PR, the image should be included.

In the example for the solar thermal collector, results have been pushed. This may have been an accident, possibly because gitignore was not set up properly at the time. They should be removed. Do you agree?

MILP-extension for heat modelling and generally:

• Start costs
• Min./max. run- and downtimes
• Piecewise linear terms like fuel costs/consumption
• Coupling of investment variables e.g. when investment in transmission capacities takes place, both flows have to get the same investment capacity volumes
• Building groups of flows that can be switched of e.g. when a technology is represented within the network logic internally

I found some mistake in die docu. (At least I think they are mistakes.)

1. The parameter table lists Gamma and Delta. As attribute names fixed_losses and fixed_absolute_losses are given. In the code I only find fixed_losses_relative and fixed_losses_absolute instead.

We plan to have a second release of oemof.thermal around springtime. This brings the chance to release some some bug fixes and corrections of errors in the docs, but also new features. Please check your issues and PRs and assign them to the milestone if you think that that's a fit.

These features are planned to be part of the new release:

• Add tests,
• Add facades for the new components,
• Improve the docs,
• for all new features, fixes, etc.: Remember to fill in the information in the whatsnew file. For open PRs this can happen in the respective PR. For closed PRs where we forgot to add the entry, this could happen in the release branch, as soon as we have one.
• Before releasing: Test all examples, try if they work and behave nicely. Also check that results are ignored (.gitignore).

Please add if there is something missing.

On oemof-thermal.readthedocs.io, you can download document versions of the docs if you click on latest:

There is a pdf, an epub and a html version.

There are the following bugs:

• The title is 'oemof heat documentation', not oemof.thermal. Should be fixed by changing conf.py
• .svg-files do not seem to render.

In .epub version:

• Image size leads to pixelized appearance
• .svg images are not properly handled either

The import statement:

from oemof.thermal.solar_thermal_collector import flat_plate_precalc

is not working (v.0.0.1), with the following error being displayed:

Cannot find reference 'solar_thermal_collector' in 'init.py'

• Maybe move table to extra section at the bottom of the page?
• Loss terms are mentioned twice (not too urgent, maybe v0.03)
• Legend hard to read (lines are better and they should be thicker) (not too urgent, maybe v0.03)
• Check overview table for consistency

We set a milestone for the first release of oemof-thermal by December 24th.

@oemof/oemof-heat Let's use this issue to discuss what need to be done to achieve this.

I was ask if I could make the compression_heatpumps_and_chillers.py module take a Pandas.Series (time-indexed) as input and return the COPs as time-indexed Series.

Now I wonder, if that would be a good feature.
It seems to be very useful when using the module as stand-alone calculation but when using the calculation to generate input to a solph.component it has to be a List, as far as I know.

I would like to have a repository to collect/exchange/discuss ideas arround the extension of oemof but apart from the standard repository oemof/oemof since some discussions might exploit the scope of the standard repository.

The first purpose would be to collect, sort and discuss ideas and formulations arround heat technologies that should/could be integrated in oemof.

Other purposes might appear in future..

So the idea would be to capture this repository or create a new one and call it "sandbox" or "thinktank" or similar..

@oemof/oemof-developer-group : What do you think?

@jakob-wo

• Add example with solph.

As the title says, the present example for investment in thermal storages only optimizes the height and therefore the max. thermal energy content of the storage, not the max. thermal power of charging/discharging.

Question: Is this a good idea, or is it more realistic to size the nominal power with the size?

As far as I know, a rule of thumb is to size the storage in a way that it can provide its max. thermal power for ~ 6-8h. This would be an argument to rather provide a ratio when doing storage optimization. With this approach, one would have to set some costs for the investment in power, too.

What do you think, @oemof/oemof-heat? If we come to the conclusion that the latter is closer to reality, we might change the example.

This is the case for the solar_thermal_collector.

• Create heat demand time series with the demandlib beforehand.
• Remove demandlib dependency from the repository.

Citing @ciaradunks:

I’ve noticed that the ‘s_iso’ (thickness of isolation) variable is said to be in mm, but in the csv example file it is in m. And then in the function it looks like the input is in mm but then it gets converted to m in line 45 of the ‘calculate_storage_u_value’ function. In the csv file should it actually be in mm?

Thanks for noting this! Can you get an overview and make a proposol how to fix this, @MaGering?

There is no text in the README.rst yet. We should add a short description of the project so that the users know what to expect from this package.

On the last user meeting we discussed different technologies that should be representable either by implementing them or by describing them in the network logic. There's also a research project coming which will extend oemof for heat modelling that probably starts next summer.

This issue is meant to provide an overview about the current state and future plans in terms of oemof heat modelling.

Here's the first suggestion for technologies that should be representable adequately within oemof:

• Heat sink
  • District heating networks / @ckaldemeyer
• Heat storage
  • Water heat storages (atmosperic and higher pressures) / @ckaldemeyer
  • Downhole heat exchanger heat storages / someone from RLI
• Peak load
  • Peak load boilers working with gas, oil, ... / @ckaldemeyer
• Power to heat
  • (Electrode) heating rods / @ckaldemeyer
  • Heat pumps (having air/ground as heat source) / @birgits has some experience here
• CHP
  • Back-pressure turbines / @ckaldemeyer
  • Extraction turbines / @uvchik has adopted @simnh approach from HESYSOPT in this PR
  • Motoric combined heat and power plants / @ckaldemeyer

Proposed methodology:

1.) The idea would be to use the wiki to collect formulations (LP/MILP) from literature and discuss their pros and cons.
2.) Subsequently, the technologies can be represented with existing possibilities (network-logic) or within classes based on the literature formulations and results of the discussion.
3.) The wiki could also be extended to an information source on how to model different technologies within oemof.

@uvchik : Did I forget anything?

Has not been used since two years

My question regards the heat pumps and chillers function calc_cops() and more specifically the parameters temp_low and temp_high. In the documentation they are described as "Temperature of the low/high temp. heat reservoir" (see here).

In this heat pump example temp_high is 65°C, which looks to me more like the temperature of the outflow of the heat pump (f.e. flow that heats a room), not the temperature of the reservoir (f.e. room temperature).

Should I take the temperature of the outflow or the (in my case) room temperature as temp_high?

Jann made some good suggestions to improve the code. I will adapt it soon.

Some more comments:

• in concentrating_solar_power.py:
  • The dataframe df already has a timeindex, which is internally replaced. This can lead to errors.
  • Passing df and then telling which column means what is kind of complicated.
    I mean these 3:
    date_col: string, default: 'date'
    irradiance_col: string, default: 'E_dir_hor'
    temp_amb_col: string, default: 'temp_amb'

Suggestion: Pass irradiance (E_dir_hor or dni, depending on irradiance_method) and temp_amb as pd.Series and check that it has a valid timeindex (which is necessary for the pvlib). E_dir_hor/dni should be passed as kwargs, and depending on the method it should be checked that the right keyword argument is passed.

def csp_precalc(
                lat, long, timezone,
                collector_tilt, collector_azimuth, cleanliness,
                eta_0, c_1, c_2,
                temp_collector_inlet, temp_collector_outlet,
                temp_amb,
                a_1, a_2, a_3=0, a_4=0, a_5=0, a_6=0,
                loss_method='Janotte',
                irradiance_method='horizontal',
                **kwargs):
                """ ... """
               required_dict = {'horizontal': 'E_hor_ir', 'other': 'dni'}

               irradiance_required = required_dict[irradiance_method]

               if not irradiance_required in kwargs:
                   raise AttributeError(f"'{irradiance_required}' necessary for {irradiance_method} is not provided")

               irradiance = kwargs.get(irradiance_required)

• parameter names

  • tz: why not call it timezone?
  • x: why not call it cleanliness? I would be ok with x however if it is an established convention to name it like this.

• I do not quite understand the difference btw. collector_irradiance and irradiance_on_collector. The explanation in the table does not make it clear to me. Also, we should check how the pictures in the docs help understanding these (#76)

Originally posted by @jnnr in #68 (comment)

Till now there is no overview of the available examples.
I propose we add a section "Examples" in the docu (readthedocs) with a list of the examples with (at least) a short description.

I just realized that the module test_functions.py holds tests for the modules cogeneration.py and stratified_thermal_storage.py.

I would prefere to have seperated test modules (one for each module) named after the module it is testing, e.g. test_compression_heatpumps_and_chillers.py for the module compression_heatpumps_and_chillers.py.

This would have two advantages:

1. clear structure makes it easy to find tests belonging to one module
2. avoid merge conflicts (like in PR #72 ) when tests for different modules are written at the same time.

The list of available examples needs to be adjusted in the documentation:
https://oemof-thermal.readthedocs.io/en/latest/examples.html

After discussing this with @jnnr these two approaches emerged:

1. Adjusting the list of examples manually (now and every time there are changes)
2. Working with links to the components examples on GitHub and leaving the list of the specific examples out

Are there further suggestions?

There is no component in oemof that models an absorption chiller.

A simple way it can be done already is using a transformer. For a rough estimation of the cooling capacity or cold production it might be sufficient to model the unit with a constant COP and constant nominal cooling capacity.
For a more realistic examination the temperature dependencies of both the COP and the (actual) max cooling capacity should be considered. Especially the latter is very sensitive to the three temperature levels the absorption chiller is working at whereas the former is much lesser sensitive to the temperature levels.

I am currently working on implementing a precalculation of the (actual) max cooling capacity and the COP based on the characteristic equation method.

Who else is working on absorption chillers (or absorption heat pumps)?
And who would be interested in using an absorption chiller model with temperature dependency?
@oemof/oemof-solph @oemof/oemof-heat