I'm very interested in this, as we need this in our project.
I already looked into the paper and have an idea on how to implement this.
As in newest solph version multi-periods are supported as well, we have to apply timeseries aggregation via TSAM within each period.

My first idea would have been to only implement new storage behavior depending on TSAM config and neglect automatic timeseries aggregation within solph and leave this part to the user, as there are tricky parts:

• apply TSAM for all timeseries within each period
• adapt summed energies, full_load_hours and other vars to consider reduced timesteps (i.e. a component which originally holds full load hours of 200h per year must be reduced to 200h * 100d/365d in case of using 100 typical days of a year instead of whole year)

Instead, user has to do aggregation for each period and adaption of variables up front, but inter-period (period in the sense of TSAM-periods, not multi-periods) storage levels are handled by solph.

In order to implement new storage behavior, followinging code lines would have to be adapted (IMO):

• _add_parent_block_sets in Model class in order to add information on TSAM aggregations (how many groups originally, how many resulting cluster groups and mapping between those)
• _storage_balance_rule for GenericInvestmentStorageBlock
• _storage_balance_rule for GenericStorageBlock

After having a discussion with developer of FINE, I learned that adapting summed energies, full_load_hours etc. is not as simple as dividing it by reduction factor, but instead they have to be weighted according to TSAM clustering of typical periods (aka multiply full_load_hours of a given period by "occurrences" of that typical period in original timeseries - sum of all weighted full_load_hours should meet original full_load_hours given by user). Therefore, oemof rules for setting up summed energies or full_load_hours, etc. have to be adapted.
My first approach would be to adapt following lines:

• _flow_full_load_time_max_rule in SimpleFlowBlock
• _flow_full_load_time_min_rule in SimpleFlowBlock

For now, I would neglect NonConvexFlowBlock and positive or negative gradients (which might have to be adapted as well, if they should be used in time-reduced scenario) and instead raise a warning, when used in time-reduced setup.

The group around SESMG seems to have implement some time series aggregation methods in context of oemof-solph models, maybe worth a look: https://spreadsheet-energy-system-model-generator.readthedocs.io/en/latest/01.03.00_model_simplification.html

The group around SESMG seems to have implement some time series aggregation methods in context of oemof-solph models, maybe worth a look: https://spreadsheet-energy-system-model-generator.readthedocs.io/en/latest/01.03.00_model_simplification.html

Thanks for the hint! As far as I can see, the timeseries reduction mentioned there seems to be a simple reduction or aggregation of timesteps with no attention to resulting effects on storage behaviour etc.
The approach mentioned here, consists of two steps:

1. reduction of timeseries by identifying typical periods (same methods as in SESMG can be used therefore)
2. adapting model constraints and rules to preserve storage and flow behaviours

Ideally, quality of results and "real" storage behaviour and investment are preserved by the second step.

Just to draw your attention to it, there is also some interest from the user community side, see: https://forum.openmod.org/t/oemof-in-combination-with-time-series-aggregation-module-tsam/4157/6