Feature proposal: Change node parameters after creation of nodes

[jnnr]

It would be useful to be able to set parameters of components of an energysystem not only upon initialisation, but also as part of an existing energysystem. Use cases are (as I see now, might be more):

• Interactive modeling with quick feedback
• Parameter studies

At the moment, a model has to be created anew for each scenario. This hinders quick feedback when modeling small systems. Being able to access parameters would make experimenting with models easier, more insightful and fun.

For larger models, this could speed up scenario optimization, as a model does not have to be setup from scratch for every parameter variation.

What is your view on this and what obstacles do you see? Your experience and comments are very welcome. If you agree that this would be worthwhile, I can take the initiative on this feature.

[henhuy]

Ah - okay! When we spoke, I thought you only want to edit the energysystem itself and sent it to optimization model for setup afterwards, but

speed up scenario optimization, as a model does not have to be setup from scratch

would mean that changes in energysystem have to be transferred into optimization model! Which is more complicated, right @simnh @gnn ?

I like it, but more as a "nice to have" - so not a prioritization from my side.

[jnnr]

I meant editing the energysystem. Changing parameters in the optimisation_model after it has been created would be much more demanding.

However, it might be that it is there were most of the time is spent when creating large models. That is what I have heard, have not performed any time profiling myself.

The function to address objects of the energy system and change them should not be as complicated as working on the optimisation model. Anyway, it would extend the API to something useful in many modeling situations.

[henhuy]

For the case only energysystem shall be edited and not the model, here some ideas: I think a problem in editing attributes of some components would be, that those components are sometimes changed within the __init__ function (i.e. change value into a Sequence). Thus, changing an attribute would lead to unknown errors when optimization model is build. To avoid this, one could implement a setter function which is called whenever a user edits an attribute and within initialization. Thereby, changing of values could be integrated safely (without destroying the components internal attributes).

[uvchik]

@henhuy You are right. We do not have a setter so you have to make sure to use the right class. In most cases a sequence would be the right choice. It should work like this.

node[label].attribute = solph.sequence(new_value)

In my case it will not speed up the process. Creating the nodes needs one second, creating the model needs about 1200 seconds, solving and dumping about 2400 seconds. The absolute values may vary.

You need to change the constraints directly to speed up the process significantly and as you mentioned this needs much more effort.

[henhuy]

Todos transferred from oemof/organisation:

• [ ] Implement node removal in an energy system. This will be a rather "expensive" operation, as the groups will be reset and recreated. For convenience, bulk removal can be implemented, so that group recreation doesn't happen after every node is removed.

  • [ ] Implement mutable node attributes. There's one big caveat for this: it is impossible to intercept node attribute mutation for all scenarios. So while user's can mutate, they also have to explicitly notify the EnergySystem that they have done so, before rebuilding the optimization model.

@gnn: I slightly remember that you wanted to change something in core to support implementation of this feature. I cannot remember the details. Can you?