Add `initial_node_state` in p.u.

[datejada]

For the European case study, the initial_node_state parameter should be defined as per unit, since in the investment case, the capacity is a variable and therefore the initial node state can't be defined as an absolute value.

Before implementing, please discuss with the rest of the developers on the best way to include this. I see two options:

1. Redefined the current parameter to be in per unit instead of absolute value, and of course, modify the code accordingly. In this case, we need a migration script to translate the old value to the new definition when upgrading databases to a new version.
2. Have two parameters, one in per unit and another in absolute values, and in then use in the constraint the max(?) of those two (or any other calculation we agree on it). Changing the code accordingly and also explaining this in the documentation very well.

I am more keen on option 1, but I am open to alternatives or other suggestions.

@aporrasc any extra comment?

[tarskul]

If we can do everything with 1 parameter, I prefer 1 parameter too.

If we have two parameters, we should throw an error if both parameters are defined at the same time. That brings it closer to the user, makes it easier to debug, makes the documentation less crucial and we can simply generate the constraint based on the defined parameters, similar to other parts of the code.

[gnawin]

I do not have a strong preference on either 1 or 2 parameters for future use. But I do think having 2 parameters makes the migration easier.

• We can add a parameter initial_node_state_per_unit. We do nothing for the existing initial_node_state, and provide this new parameter so users can choose. We can throw an error if both are defined.

• I agree that having 1 parameter p.u. makes sense for an investment case. But for a non-investment case, maybe there is no difference. And if existing users use it for an investment case already, how shall we convert it? No matter how we will convert, it needs extra explanation etc.

@tarskul @aporrasc @Tasqu ideas?

[DillonJ]

I thought we had agreed that 1 doesn't really work as the behaviour of existing models will change silently - so my strong preference is 2. There isn't really a strong argument against 2 which provides the required functionality and preserves backwards compatibility with existing models

[gnawin]

I thought we had agreed that 1 doesn't really work as the behaviour of existing models will change silently - so my strong preference is 2. There isn't really a strong argument against 2 which provides the required functionality and preserves backwards compatibility with existing models

Oh I did not know that, probably because I missed the last meeting. If that has been agreed, then we move to option 2.

[DillonJ]

Also - something to be aware of with a relative initial node state is that it can drive investments for the energy, so it's best to use it with cyclic node state.

Edit: also option 1 doesn't allow for an absolute initial node state which we should support, paricularly since that's the current behaviour

[DillonJ]

Actually, @aporrasc are you sure this is needed - if you leave the initial node state free and instead impose cyclic_condition = true, then the model is free to optimise the starting level but must replenish the energy at the end... this avoids the value of the energy driving the investment

[gnawin]

At the moment, @aporrasc confirms that this issue is no longer relevant, but it is an interesting request so maybe it comes back in the future.