Nodal balance for node_group / How to handle obligatory default values? #312

Closed spine-o-bot closed 3 years ago

In GitLab by @mihlema on Apr 2, 2020, 09:46

I came across this problem working on my Case study. In particular, it concerned the nodal_balance. We assume that for any kind of optimization model, nodes will always result in our standard nodal_balance. However, for the case that I was studying, I had to enforce a special case of nodal_balance: First, I introduced a demand for a region (alias node_group). This node_group contained several nodes. flow_indices and trans_indices expand to the contained nodes, giving us all flows and trans involved that can possibly contribute to the demand. To make sure that only trans from outside the region where taken into account, I had to introduce some conditional on the sum of trans variables.

In a nutshell: I added another constraint for this type of nodes/node_groups e.g. node_alternative_balance. To avoid that both node_alternative_balance and nodal_balance are enforced at the same time, I needed to remove the default value for demand to nothing. But I'm wondering if we can find a nicer way to deal with such problems.

In GitLab by @Tasqu on Apr 8, 2020, 10:05

I'm not completely clear how this is different from combining the nodes contained within the region into a single node.

Even in the case you wanted the nodes separate for some reason, wouldn't it also be possible to implement a "common demand" for a group of nodes as an additional node with the desired demand? The new "common demand" node would then be connected to the nodes able to contribute to it via unrestricted one-directional connections. Of course this results in technically unnecessary connection_flow variables, but should work, right?

In GitLab by @DillonJ on Apr 8, 2020, 16:40

I have a very similar issue and maybe we can find a single resolution.

When implementing load flow based on PTDFs, you get a set of constraints that are equivalent to the node balance constraints in many cases. In fact, if you take the case of a node with a single line in and a single line out - the ptdf load flow and the node balance generate identical constraints. Because of numerical issues, you may have RHS values that differ slightly and this causes infeasibilities that relate to accumulated rounding errors.

So in this case, for balance purposes, you really want to treat all the nodes in an area as a single node while the ptdf constraints regulate the flow on the connections.

When I looked at implementing this, it seemed messy, because in the node balance constraint you would need to check whether a node is part of a node__group or not and decide what to do based on that.

The basic problem is this... we have this :

And from a node balance point of view, would like to switch between that, and effectively, this :

Using the ptdf load flow, we would sill know what is flowing on each internal connection inside each area, but we don't need the internal connection flows in the nodal balance.

Any thoughts @manuelma @jkiviluo @Tasqu

@mihlema it sounds like what you have done deals with this issue - but what I would like, is the ability to switch between area based balance to node base based balance within the same dataset.

Edit @mihlema also.. using fractional demand is nice here, because you have total area demand already without doing a sum... we should be able to come up with something that solves both our issues

In GitLab by @Tasqu on Apr 9, 2020, 07:21

I'm having a hard time understanding what it is you're trying to achieve, probably because of me not having very limited background in electrical engineering and my lack of understanding regarding power flow optimization.

Do you need to implement a balance constraint both at the area and node levels at the same time? Or is this about being able to easily divide an area level demand data to the node level within the model, instead of within the input database?

If the power flow constraints result in very similar equations than the balance constraints, are they both required? Could either be modified to handle the functionality of both?

In GitLab by @DillonJ on Apr 9, 2020, 08:24

@Topi - the fundamental problem I have is that there are multiple ways to determine flows on lines - a transport model with nodal balance (current formulation) and ptdf based DC load flow is another. If we have both of these at the same time, we can get conflicting answers - so when PTDF load flow is enabled, you want to "turn off" the connection flows in node balance, because the PTDF constraints determine the flows.

In GitLab by @Tasqu on Apr 9, 2020, 09:00

Ok, I think I might be starting to understand the problem. Are there separate variables for load flow? I thought the connection_flow variables were going to be used for that when load flow was enabled, meaning that they would be "repurposed" rather than "turned off".

In GitLab by @DillonJ on Apr 9, 2020, 09:17

Actually, this is where you would like a simple node_node connection, that just establishes an unconstrained link between the nodes and the common demand node

In GitLab by @manuelma on Apr 9, 2020, 09:55

We could also have a switch listed parameter in the db that tells the model how to do nodal balance, possibly resulting in a different constraint being generated?

In GitLab by @DillonJ on Apr 9, 2020, 10:31

This is the way I'm leaning.... this is the way we said we would try and do it when there are choices regarding formulation... to use method parameters...

I spoke with @mihlema and I think we have a nice way to implement factional demand and have the choice of node_group and/or node level balance.

In GitLab by @mihlema on Jul 7, 2020, 11:54

I believe this issue is solved now with nodal_balance_sense balance_type_group etc. in the master. Re-open if necessary

In GitLab by @mihlema on Jul 7, 2020, 11:54

closed

spine-tools / SpineOpt.jl

Nodal balance for node_group / How to handle obligatory default values? #312