Calliope 0.7x enhancements on technologies operation and reserve margins

[mkarmellos]

I noticed there are some related open issues on these topics but I would like to discuss about their implementation in Calliope 0.7x. Specifically, I'd suggest that Calliope should have minimum uptime and downtime parameters and associated startup costs to reflect the operation of an electricity system more accurately. Also, I wanted to ask if there are updates on the implementation of reserve margins in Calliope 0.7x since there is an open issue but it is not clear what the plans are. Moreover, I'd suggest to follow an approach similar to FlexTool on that aspect, which is relatively simple.

[brynpickering]

Hi @mkarmellos - we do have examples of implementing up/downtime mathematics: https://calliope.readthedocs.io/en/v0.7.0.dev7/user_defined_math/examples/uptime_downtime_limits/

We haven't considered re-implementing reserve margins yet. That's because the concept of a "reserve" becomes much more complex when you have systems with limited/no dispatchable generation. How do you set a margin for renewables linked to storage? You could enforce a +X% capacity for storage but the availability of that depends on how that storage is operated in other timesteps. Saying that, setting storage discharge depth can be one way to effectively set a reserve margin via storage devices.

It would be very easy to add a reserve margin as a +X% capacity requirement:

parameters:
  reserve_margin:
    description: Fractional margin above nominal technology capacity requirements that must be invested in, to provide reserve capacity
    unit: unitless
    default: 0

  reserve_margin_nodal:
    description: Fractional margin above combined nominal technology capacity requirements that must be invested in, to provide reserve capacity for a given carrier at each node
    unit: unitless
    default: 0

constraints:
  set_reserve_margin:
    foreach: [nodes, techs, carriers, timesteps]
    where: reserve_margin
    equations: [{expression: "flow_out * (1 + reserve_margin) <= flow_cap * timestep_resolution * flow_out_parasitic_eff"}]

  set_reserve_margin_nodal:
    foreach: [nodes, carriers, timesteps]
    where: reserve_margin_nodal
    equations: [{expression: "sum(flow_in, over=techs) * (1 + reserve_margin_nodal) <= sum(flow_cap * timestep_resolution * flow_out_parasitic_eff, over=techs)"}]

This could be easily set to absolute reserve requirements easily, too. Or indeed to the FlexTool implementation.

If you are interested in examples of reserve margin constraints then I would recommend contributing examples to our list of user-defined math. Hopefully you can see that it's quite straightforward to add your own math without needing to rely on it being available in the core Calliope math.

[mkarmellos]

Hello @brynpickering and thanks for your reply.

Those examples on uptime/downtime are useful and of course can be adapted. There is another attempt to model this (see #827). I am trying to model typical unit commitment constraints, e.g. if a technology turns on it needs to operate for at least 6 hours before shutting down and was thinking on working on writing down additional math for that.

On the reserve margin constraints, I agree with you that we could write our own math as well. It is true that the concept of reserves becomes much more complex when you have systems with limited/no dispatchable generation. That is why I suggested to follow FlexTool approach on that aspect, in which you can define a parameter indicating which technologies (and by what percentage) can contribute to the reserves, and also define reserve targets for the system. Therefore, if there is a need for reserves in the model the user can decide which technologies would contribute to reserves according to the technical requirements of the system.

Nevertheless, I still think that those features I suggest should be implemented as core functionalities as they refer to typical modelling practices of electricity systems modelling. In my opinion additional math should be considered for "extra" functionalities, that refer to specific requirements of users. Something that is typical or standard practice should be implemented as core functionality.

I am a new user of Calliope so I am not sure what the standard practice in the community is, but I thought this suggestion would be useful. In any case, thanks for your response.

[brynpickering]

It'll always be difficult to define what is "standard" practice as it really depends on the user and their use-case. We often only see things from the perspective of the sector we work in!

We are keen for modellers to start thinking of math as a component library, hooking in what they need for their use-case and even writing their own when they need it. You never need math to be available in the core code, since it can be just as easily loaded in from a separate file. Having it hooked in as part of your modelling workflow even makes it more transparent.

Nevertheless, we welcome contributions of all kinds, including to our core math! Maybe you could propose some math expressions here for reserve margins and updates to how we handle uptime/downtime?