sourcegen bounds

[sanderclaeys]

For the branches, the power flow bounds are determined from the 'rate_a' property.

The sourcegen bounds are inferred by summing the power flow bounds of all connected branches (and transformers in #117 ). However, in the relevant mehod in opendss.jl, the 'rate_b' property is used.

Is this intentional, and if so, why? This was not the behaviour that I was expecting when imposing line flow limits through the dss file.

[frederikgeth]

Not answering your question, but expanding on this a bit, for some formulations it is important to have rather tight flow bounds on the branches and the slack bus to avoid numerical issues (not forgetting the choice of power base is very important as well).

You can set flow limits through the normamps branch parameter in OpenDSS. But you'd need to set emergamps as well to have a bound on the slack bus power. The OpenDSS default values for normamps and emergamps are too high to avoid the numerical issues for some of the cases we've been testing (e.g. case3_unbalanced.dss).

[pseudocubic]

@frederikgeth has the gist of it, we used emergamps as our upper bound to the flow limit specifically for the generator that we simulated at sourcebus , but this isn't set in stone, in fact there is an open discussion about flow limits, see #56. Basically we wanted to be able to supply the absolute maximum power to the circuit from a connected trunk (which I think is assumed to have no upper limit), and therefore used emergamps, which is higher than normamps. As @frederikgeth implied, this was mainly in the hopes of having some kind of numerical stability (rather than just having infinite bounds on the sourcebus generator).

[frederikgeth]

If rate_a is defined, it provides a valid bound on the slackbus power as well, not only on the branch flow. Now you need to define both normamps and emergamps to end up with bounds on both. This seems unnecessarily inconvenient.

[ccoffrin]

I am no sure I follow all the details, but my take is. If you read data from OpenDSS the parser will define a valid bound on the slackbus generator for you (inferred from branch flow limits), becouse it is not standard to provide this from OpenDSS. The parser can reason on the amps limits or the rate limits, whatever is more convenient.

If a user defines a problem in the internal dict data, then it is the user's responsibility to put a resonable bound on all generators.

Does this ramble answer any of these questions?

[pseudocubic]

@sanderclaeys @frederikgeth was this issue resolved to your satisfaction, or do we still need to have more discussion?

[sanderclaeys]

The default values for emergamps and normamps often lead to numerical issues in the SDP models, so it is crucial the user understands how the sourcegen bounds are arrived at (so they can be tightened).

For me it was counter-intuitive that the sourcegen bounds are based on emergamps. Because the line bounds are based on normamps, this also gives a valid (tighter) bound. I have a slight preference for using normamps.

As long as this is explained in the docs eventually, I am good either way. Maybe a good moment to start a list with tricks like this which are needed to get the models to work?

[pseudocubic]

I can see the point about normamps being the most intuitive bound, I therefore suggest in this case that we switch to normamps, but provide a kwarg to parse_file to enable "emergency mode" where emergeamps is used.

[ccoffrin]

@sanderclaeys, the challenge is that when parsing an OpenDSS file you don't know if the problem being solved will be using normamps or emergeamps and we don't want to accidentally add a constraint to the model via the fictitious generator that we are adding. If you prefer, another option would be to make this generator unbounded, I don't know if that will help with the numerical issues or not, but my experience is that it is always best to bound a variable if it has reasonable values.

In the near term, if there is no problems with the AC formulation, I would suggest reducing these generator bounds only when solving the SDP model.

[sanderclaeys]

@ccoffrin In light of possible future changes that will use emergamps, it would indeed make more sense to use emergamps. I prefer the current behavior over no bounds at all.

@pseudocubic For me this issue can thus be closed without changes.