How to get the storage_content current value at runtime

[gbrunaccini78]

Hi all, I have just started studying examples and I would like to use _storagecontent as variable to define constraint or define a function to calculate the variable_cost to drain power from (or inject to) a storage component of my simulated energy system, but I could not succeded in this. Even through the example with the external for loop along model.TIMESTEPS I could not access the _storagecontent attribute. Is it possible to do this? Is there any similar example to follow? Thank you in advance

[p-snft]

To my knowledge, the best way to get the storage content during runtime is based on the underlying pyomo model as soon as it is created:

model = solph.Model(energysystem)
model.GenericStorageBlock.storage_content

However, I am currently wondering if the problem will still be linear. Won't you have c(P) = P * c_{storage level} * E_{storage}, where c(P) is the total cost of the flow, P is the instantaneous power (actual value of the flow), c_{storage level} is the cost factor and E_{storage} is the storage content?

[gbrunaccini78]

Thanks for answering. Anyway, this was what I did, let say by using print(model.GenericStorageBlock.storage_content[:,t-1]()[1]) (there are two storage devices in the system, and t is in model.TIMESTEPS and t>5 just to avoid to worry about initialization issues). Despite being fine at the end of the simulation (it does hold plausible values), during the solving process it printed None at every timestep. On the contrary, flows IndexedVar are correctly accessible during the simulation running. Could you help me? What's the difference?

[p-snft]

What exactly do you mean by "during the solving process"? My view is the following:

model = solph.Model(energysystem)  # Model is created, fixed values are known, variables are unknown
model.solve(solver=solver)  # Model is optimised, variables are set to optimal values

What was possible is to set Pyomo constraints between the first and the second step, e.g. limiting the content of one storage to the (also unknown) content of another storage. You still wouldn't know the value, as the optimisation has yet to come.

[gbrunaccini78]

Thank you. Probably it is clear to me now. All timesteps are solver at once, I tought that the optimization would have been done timestep per timestep, so that the results of stet N-1 were the (known) initial conditions for the next iteration. What I would like to do is use the _storagecontent at timestep N-1 to include it in the variable_cost of using that storage in timestep N. More or less to try to have a target SoC of the battery (i.e. it should become more "expensive" to have the battery almost full or almost empty). I hope to have explained better my intention. Thank you again!

[p-snft]

Yes, this is the way it works. The time is actually just an index in the optimisation problem, we do not perform a (chronological) simulation. In fact, I see four options to approach your problem. I will just shortly name them here. In case you want to discuss them, it's probably better to head over to https://forum.openmod.org/c/modelling/15, as it's not directly related to oemof.solph.

• Create models with short time horizon and solve those. This way you can iterate through time and can use storage contents of previous time steps for defining the costs. (As storage only makes sense when multiple time steps are included, you cannot use just one.)
• Formulate a variable cost that is function of the (unknown) storage content. This would create a non-linear problem and cannot be done using solph.
• Reformulate the problem, so that storage content has a "storage costs". This would still be a linear problem that can be optimised using solph. However, the functionality is currently not implemented.
• Solve the model, starting with initial guesses feeding into the storage. Then iteratively solve it while adjusting the costs until it converges to the combination of costs of storage usage you had in mind.

[gbrunaccini78]

Thank you so much. I will check the openmod forum you suggested or by implementing an iteratively one-step configuration.