Minimum "storage" time biogas digester

Hi everybody,
first of all thank you to all developers of oemof and contributors to this forum, (a.o. Patrik Schönfeld, Uwe Krien and Robbie Morrison).
I am curious about how to best implement biogas/waste to energy plants in this framework. What I am especially curious about is how to design a digester. As far as I know, a digester should receive as inputs the biomass feedstock (input_1) and heat (input_2). It should take some couple of timesteps then to generate any biogas (output_1). How would I implement such a time dependent behaviour? In my first idea I would separate the digester unit into a transformer and a storage, with the storage invest_relation_input_output >>1, and fix the nominal storage capacity. But I doubt this is the best approach. Has anyone dealt with this subject before and can support me here?
Thanks in advance!

PS: I am a research associate at Technische Universität Berlin, applying the framework to investigate (isolated) energy systems in Sub Saharan Africa and related topics - please feel free to contact for any discussion/related activities.

2 Likes

This August 2021 posting might be of interest:

Thanks Robbie, that is interesting indeed. However, it does not address the core of my question. I am interested how to include a time dependency, as i.e. that the input flow must be “stored” in a component for x timesteps, before leaving as output flow. Sorry, if I express myself clumsily.

The long defunct deeco modeling framework supported a subset of dynamical systems — in the sense that “system components (both physical and informational) may interact across discrete time”. More specifically, “variable process states allow the model to support dynamical systems interactions”. More in the following MSc, including the underpinning mathematical formulations, see section 8.4 in particular:

Similar material would also be covered here (my source for the above in any case):

The deeco codebase is on GitHub for archival purposes, licensed GPLv2+:

  • deeco contributors (28 February 2018). deeco. GitHub. Last compiled 30 September 2005.

Ancient history, I know, but perhaps you can salvage something from this formulation? R

1 Like

I think what you want to model cannot be expressed using the components currently in solph. At the moment, we are discussing delays for energy transport networks (https://github.com/oemof/oemof-solph/issues/795). You will probably also profit from the implementation. If you like, we can have a chat about the feature.

2 Likes

I think such a delay would solve my case here. I agree with your comment in the reference chat that a delay in flow would probably be more intuitive than in component (in this case), as the delay actually depends on the properties of the flow rather than the characteristics of the component. However, this might be different for transport networks (?). I would be very happy to have a chat on how to best implement this!