Integrate stratified thermal storage of oemof.thermal

[MaGering]

At present, in the mvs the oemof.solph component GenericStorage is defined with the following input parameters (cf. D1_model_components.py):

• label
• nominal_storage_capacity
• initial_storage_level
• loss_rate
• inflow_conversion_factor
• outflow_conversion_factor
• min_storage_level
• max_storage_level

To implement the oemof.thermal stratified thermal storage, two further input parameter would be needed (cf. example 01_operation_generic_storage.py):

• fixed_losses_relative
• fixed_losses_absolute

They are used to take into account temperature dependent losses of the GenericStorage.

The solution to this issue would fulfil the fourth goal of this PR in pvcompare: https://github.com/greco-project/pvcompare/pull/148

What do you think @smartie2076, is the implementation of the stratified thermal energy storage feasible?

[smartie2076]

Hi @MaGering ! Thanks for the issue. I am a bit confused: You actually are using a generic storage in the example code (maybe the thermal storage ways does?), and adapt it to the thermal storage by using preprocessing functions.

What is the workflow you would use? Manual preprocessing* (thermal coefficients) for Greco, and then providing the input sheets with the usual parameters and relative/absolute losses? Or integrating the preprocessing into the MVS, requiring the user to enter all thermal coefficients in a newly added CSV specific for thermal storages?

Both options would be possible.

Edit: * meaning, a script that preprocesses the data for pvcompare. Would you also use a CSV input if this is what you planned?

[MaGering]

Hi @MaGering ! Thanks for the issue. I am a bit confused: You actually are using a generic storage in the example code (maybe the thermal storage ways does?), and adapt it to the thermal storage by using preprocessing functions.

What is the workflow you would use? Manual preprocessing* (thermal coefficients) for Greco, and then providing the input sheets with the usual parameters and relative/absolute losses? Or integrating the preprocessing into the MVS, requiring the user to enter all thermal coefficients in a newly added CSV specific for thermal storages?

Both options would be possible.

Edit: * meaning, a script that preprocesses the data for pvcompare. Would you also use a CSV input if this is what you planned?

Hi @smartie2076 sorry for the confusion and thanks for your feedback! :)

My chosen workflow is your first mentioned option: Writing a preprocessing script in pvcompare with functions that take in input parameters of the stratified thermal storage (similar to these input parameters of oemof.thermal's example calculation) and calculate and write the parameters nominal_storage_capacity, loss_rate, fixed_losses_relative and fixed_losses_absolute into the mvs file storage_xx.csv. I hope this clarifies the workflow. :)

In order to pass fixed_losses_relative and fixed_losses_absolute the GenericStorage in D1_model_components.py needs to be extended and the template probably adjusted, don't they?

[smartie2076]

My chosen workflow is your first mentioned option: Writing a preprocessing script in pvcompare with functions that take in input parameters of the stratified thermal storage (similar to these input parameters of oemof.thermal's example calculation) and calculate and write the parameters nominal_storage_capacity, loss_rate, fixed_losses_relative and fixed_losses_absolute into the mvs file storage_xx.csv. I hope this clarifies the workflow. :)

Okay. That is definitly the easiest way to do it, and probably a good start. If you can try and keep the code semi-seperate from pvcompare (ie. in seperate clean functions) for the pre-processing, we could think about integrating it better with the MVS later (as the end-user may want to use the pvcomparepre-processing for the stratified thermal storage asset).

In order to pass fixed_losses_relative and fixed_losses_absolute the GenericStorage in D1_model_components.py needs to be extended and the template probably adjusted, don't they?

Yes, that would mean there are following todos:

• [ ] Add fixed_losses_relative and fixed_losses_absolute to expected values of storage_*.csv, including default value
• [ ] Explain fixed_losses_relative and fixed_losses_absolute in RTD, add valid values and example for battery storage
• [ ] Change all files storage_*.csv to include fixed_losses_relative and fixed_losses_absolute
• [ ] Change all files *.json to include the new parameters
• [ ] Check and update the pytests that include batteries (D1, benchmark tests)

@SabineHaas Do you think the input template for storages grows to complicated with the two new parameters fixed_losses_relative and fixed_losses_absolute? Do you have an idea how to include pre-processing with oemof-thermal into the MVS itself?

[smartie2076]

For example, we could also leave storage_*.csv as it is (write default values for fixed_losses_relative and fixed_losses_absolute), and instead add a file for thermal storages that is then processed to in C0.

[SabineHaas]

For example, we could also leave storage_*.csv as it is (write default values for fixed_losses_relative and fixed_losses_absolute), and instead add a file for thermal storages that is then processed to in C0.

Do you mean that the user could use a storage_*.csv with and without the new parameters and in case it is without new parameters, the default values will be set in C0? Or adding thermal_storage*.csv for less confusion? (But this is just our example the user is free to choose the name of the storage file anyways.)

If I understand it right / otherwise I propose:

• [ ] Add thermal_storage*.csv including fixed_losses_relative and fixed_losses_absolute
• Leave storage_*.csv and *.json as they are
• [ ] fixed_losses_relative and fixed_losses_absolute are accepted but not necessarily required parameters of storage files

[SabineHaas]

@SabineHaas Do you think the input template for storages grows to complicated with the two new parameters fixed_losses_relative and fixed_losses_absolute?

I don't think it's too complicated. Do you think it's a good option to accept these parameters but to not require them?

Do you have an idea how to include pre-processing with oemof-thermal into the MVS itself?

I wouldn't include any pre-processing like that into MVS. I have a clearer opinion on that now (clearer than the last time we discussed about it) - maybe we can discuss again!

[Bachibouzouk]

Is it then closed by #718 ?

[MaGering]

Yes, thank you! :) Issue closed by https://github.com/rl-institut/multi-vector-simulator/pull/718.