Express reserves and inertia explicitly in the input data

[jkiviluo]

At the moment SpineOpt input DB expresses reserves and inertia using a system of nodes to represent these requirements. Reserve/inertia is an additional output from a unit to a separate reserve node that has a reserve requirement. In other models that cover power system details, reserves and inertia are expressed as explicit properties of units and electricity nodes (or group of nodes).

The main reasons to make reserves explicit to the user:

• make the input data easier to understand because
  • it's more like input data in other models people may have used
  • it takes additional leap to understand that reserve provision needs to be expressed separately (not as a property between unit and its electricity node)
  • parameter names can be explicitly about reserves. nodes: activation_time, duration, reserve_type. unit__nodes: increase_reserve_ratio, large_failure_ratio, inertia_constant
• to reduce the number of nodes and unit__node connections
• all unit__node connections would be about physical flows (and not about reservations of possible flows, which feels confusing to me)

Downsides:

• implementation work
• it's a change for those who are accustomed to the current system
• new entity class for reserve, that would list the available reserve types (there would be no parameters, so it could be kept hidden when not needed - just ensuring name integrity when reserve data is provided)
• more parameters on the unit__node (depends on the implementation, maybe just reserve_provision map and inertia_constant)
• more parameters on the node_group (depends on the implementation, maybe just reserve_requirement map and inertia_min)
• if it's nicer to give parameters for reserve__node_group entity, then this would require one more entity class. Same goes for reserve__unit__node as an alternative to giving parameters with the unit__node.

There is an argument that we shouldn't express things explicitly when they can be generalized. This reduces the number of parameter definitions needed in the database. However, we already model many things in explicit manner (e.g. DC power flows) and we also have some parameters that refer explicitly to reserves. While there is value in being generic, the downside is that things become more abstract and require the user to remember more, since there are no parameter based cues. It's a trade-off.

[DillonJ]

I think we already discussed the implementation of reserves quite extensively and came to the conclusion / a concensus that it is worth doing and I was under the impression that's what TNO was working towards (@datejada @g-moralesespana )

Generally speaking - I like the SpineOpt philosophy that we can implement any kind of output or service with nodes and units and the fundamental constraints like capacity and fix/min/max ratio etc.

From my point of view, the rationale behind doing it differently for reserves is that there is a level of complexity there, it can involve quite a lot of constraints and the impact on the formulation can be significant - so it's important to get it right. However, my position has always been that this level of complexity should be opt-in and a user should be able to model ramp constraints independently of reserves and model reserves independently of ramping (with a simple capability (capacity) and headroom constraint).

However, I don't think inertia fits in here. It's so easy to model with nodes and units. You just need to create a node, call it "inertia" and connect a unit to it with a capacity and hey-presto, you've implemented inertia. I don't think the additional complexity of implementation and underminining of the SpineOpt philosophy is worth it here.

My thinking is that when we want to do nice things like this for a user, we should do them upstream of SpineOpt. E.g. in SpineOpt we have just nodes, units and connections.... and taking the example of inertia, this is a node in SpineOpt and a unit's capability is a unit_capacity to that node... but in the upstream "importer" whatever that looks like (and we have created spreadsheets that do this - it's very easy using SpineIterface), you have a "Inertial Contribution" and your importer tool (not necessarily the toolbox importer item) does the conversion from the specific to the general.

Another thing in favour of this approach is that I feel there is a desire to keep a lid on the number of parameters, classes and relationships - keeping SpineOpt general which handling the nice-for-users specific things upstream of SpineOpt will help a lot with this and keep the implementation nice

[jkiviluo]

Right. I had mixed up two things in the original issue description: what the user sees in the DB and how SpineOpt equations are written. I was thinking just about the former, but the text didn't reflect that. So, it's been modified. My view on the equation side is that it would be best to keep things explicit when code clarity and/or computational efficiency require that. But this issue was not supposed to be about that.

When it comes to inertia (and this would probably also apply to many of the emissions), creating node and unit__output_node feels unnecessary work to me. At the unit side, it's just about the properties of the existing connection between the unit and the electricity node - why create new ones? Furthermore, as far as I can see, the current way creates unnecessary variables in the model. Inertia constraint could just use the online variable multiplied by inertia_constant of the unit__output_node.

[DillonJ]

I think creating a flow via a unit__to_node / unit__from_node relationship is one of the most basic fundamental things in SpineOpt and one of the things I wouldn't like to interefere with. For example, think of when we view a unit in graph view - for every relationship between a unit and nodes, we understand a flow, and a flow can be anything. The whole philosophy of SpineOpt is that we don't know what someone's unit will produce and we don't want to bake very specific concepts like inertia into the code or the DB structure.

For me, this holds at DB level as this is where users typically create and view their models. I think there are hazards making it too complex and specific even at DB level, that's not what SpineOpt is in my opinion.

I think if we want to provide conveniences like this (inertia for example) then it should be done in a tool upstream via a conversion/importer tool like I propose here: #775

I think creating models via units, nodes and connections with nodes representing commodities and sectors and technologies as units with different inputs and outputs is a defining, empowering characteristic of SpineOpt that drives its flexibility.

[nhniina]

Either way, I think we need a tutorial/example/test about inertia modelling, including provision and static vs. dynamic requirement.

Often you want to model MW electricity flows at a high geographical resolution whereas inertia requirements would more often be modelled at synchronous system level. So you would anyway need to create node groups (maybe you can use the same for reserves?) but of course you would not need those extra unit__nodes when using the specific way.

In general, I also like keeping the structure general and not adding very specific concepts, as long as the general way is not too inaccurate, too difficult to understand, too cumbersome to do, or making the model too large/slow. But the general way makes clear examples even more crucial.

I would think that people with power system (or other specific sector) background would like to see inertia etc. as separate parameters and people with energy system background prefer the general way but maybe it's the other way. People with narrower backgrounds get excited about the power of generalising and people with broader backgrounds desire to finally see some lovely details.