case118 solution is suspect

[sharnett]

MATPOWER comes up with a perfectly reasonable solution on the transformed tree. The custom tree algo requires high voltages to get a solution. I'd like to think that isn't possible since the solution space here should include the MATPOWER solution (ignoring Q after all).

Maybe somehow including the additional generators is screwing things up?

[sharnett]

Idea: are the real power losses much greater in the tree algo for some reason? Check that analytic expression.

[sharnett]

This converges, sane voltages:

N = 11
R1 = 25
R2 = 50
vmin = .8
vmax = 1.2

[sharnett]

Analytic expression for power loss: Pkm+Pmk=gkm(|Vk|−|Vm|)^2

So no to the idea. I think.

[sharnett]

Next idea/sanity check: run the MATPOWER solution through your 'check_all' function. Does it work?

[sharnett]

That wasn't it. New theory: using large values of R1/R2 is setting up too coarse a grid. This one gets damn close to the matpower solution:

N = 21
R1 = 2.5
R2 = 5.0
vmin = .9
vmax = 1.1

but of course it took 78 seconds to finish.

New idea: develop a smart heuristic to refine solutions. Only pass up the tree a particular number or fraction of solutions?

[sharnett]

Once we have solutions at the root, use that information to ignore certain future solutions on refinements of the search grid. For instance, it shouldn't be too hard to find a reasonable upper bound on the power output at each bus.

So a possible next step is to have the algo drop solutions at a bus that exceed an upper bound. Will need to add an upper bound field to the Bus type.

[sharnett]

Okay that's done. Next step is to trace back all candidate solutions at the root to get full solutions, then look at the distribution of bus power injections for each bus. (Maybe only do a sample of 1000 root candidate solutions if there are a lot). First proposed heuristic: only consider power injections that are at most 1.5x or 2x the minimum feasible one.