[FEATURE] Valid bounds for virtual components

[sanderclaeys]

Relaxations often require bounds on all variables. Adding bounds at ENGINEEERING level does not suffice, since unbounded variables are created in the data model transformation. Therefore, an ENGINEERING data model only workflow would not work with relaxations.

This could be fixed by automatically adding valid bounds for virtual components if this is possible thanks to other bounds in the ENGINEERING model.

An alternative would be to have the user pass default bounds into the data model transformation, which are then applied to all unbounded variables.

I will compile a list below of unbounded virtual component variables.

[sanderclaeys]

Decompositions

List of decompositions and resulting virtual components

• source decomposition: branch, bus
• transformer decomposition: branches, buses, dy/yy transformers
• switch decomposition: switch, branch, bus

Virtual components

List of virtual components and required bounds to make relaxations work

• branch:
• bus: vmax
• switch:
• yy transformer:
• dy transformer:

[pseudocubic]

@sanderclaeys The transformer decomposition is an important one, we have a draft of a relaxation of the transformer yy and dy constraints for AbstractUBFModels that we hope to add soon

[sanderclaeys]

@pseudocubic that's great news! Can you specify which bounds are required for the yy/dy transformer relaxation to work?

[pseudocubic]

we need at least a power upper bound on the transformer and voltage min/max on the buses

[sanderclaeys]

I prototyped some valid bound propagation, but without angle bounds on the voltage magnitude variables these become loose to the extent that they are not useful anymore.

Perhaps it is more useful to provide a feature like
transform_data_model(data_eng..., default_math_bounds=Dict("bus"=>Dict("vmax"=>1.1, "vmin"=>0.9))),
to allow passing default bounds in the data model transformation?

[pseudocubic]

It seems like it should be possible to derive this from the engineering model though by checking the relative voltage magnitude bounds on either side of the ENG transformer and choosing either the tighter or looser relative bounds for the virtual buses in the transformer decomposition. That seems equivalent to your suggestion to me, without users having to add yet more additional options. Also, if users want to propagate bounds in this way, we already have the eng2math_extensions that they could use for that purpose.

For transformers themselves, I assumed the power bounds would just propagate to all virtual transformers from the ENG sm_ub property.

[sanderclaeys]

Yes, that is indeed no problem. The tricky part are the voltage bounds on the internal buses. They cannot be the same as the external voltage bounds, because then they can become binding internally before they are binding on the external ones (due to the voltage drop/rise over the internal resistances etc.). This would be rare, but I want to guarantee that they are valid bounds, and not ones that might change the solution in some edge cases.

Given your preference, I will try again; if I exploit the fact that the internal rs/xs has diagonal elements only, I might be able to do it without requiring voltage angle bounds.

[pseudocubic]

Related #233