DC transmission line feature

[kasparm]

Add DC line feature to most. The following implementation is needed:

• most detects if case with dcline.
• Use run_userfcn function to add formulation.
• Adapt run_userfcn in matpower to handle additional arguments.
• Adapt toggle_dcline in matpower to distinguish between call from opf and most.

Additional the dclinecost needs to be added.

[kasparm]

Initial code modifications are here:
https://github.com/kasparm/most/tree/dcline-in-most
https://github.com/kasparm/matpower/tree/dcline-in-most

I am working on dclinecost and adding a test.

Comments are welcome.

[rdzman]

My original concern was related to the fact that most() does not have mechanisms in place to automatically call any of the OPF callbacks. However, upon further thought, I suspect your idea is that the user would call ext2int() and int2ext() manually to invoke those callbacks. Something like this?

mpc = loadcase(<mycase>);       % loads case with dcline field
mpc = toggle_dcline(mpc, 'on'); % register the callbacks
mpci = ext2int(mpc);            % convert to internal, callback adds dummy
                                % generators for DC line model to base case
mdi = loadmd(...);
mdo = most(mdi);                % runs 'formulation' callback to add constraints
                                % to model before calling optimization

mpc_tjk = int2ext(mdo.flow(t,j,k).mpc);
                                % removes dummy gens, populates DC line
                                % results for individual `mpc`

Thinking out load here ...

If I recall, there were a few reasons we did not include calls to ext2int() and int2ext() directly in most().

1. All inputs should be consistent with one another. If we automatically reorder things in mpc, then we need to do the corresponding reordering of all other inputs, including xGen, profiles, etc. This is probably the right way, but a lot of work.
2. Currently ext2int() eliminates off-line equipment, which is not what we want for a unit commitment problem where a unit may be off-line in the base case, but "commitable".
3. Even on-line generators can get reordered by ext2int().

So, because of 2 you'll want to make sure that all generators that you want to be considered are on-line in the base case.

Since MOST already requires consecutive numbering of buses starting at 1, the call to ext2int() shouldn't cause any problems there.

I'm afraid 3, the re-ordering of generators, might still be an issue with this approach, since it could potentially make the ordering inconsistent between the gen/gencost matrices and the other generator related data (xGen, profiles, etc.).

[kasparm]

Yes, that is right. The current implementation I am working on requires that the user invokes the callbacks by hand as you described above(ext2int() / int2ext()).

Thank you for pointing out the consequences of calling ext2int(). I was not aware of Point 3. So in case where there are more than one generators for one bus these generators can get reordered?
Am I correct that fixing Point 1. would fix the consequences of Point 3.?

I assume the way I am going with this implementation is doable and I could maybe do some checks to make sure the ordering does not get messed up but it would not be a very clean implementation.

[rdzman]

Yes, I think fixing 1 would deal with the consequences of 3.

Regarding 3, however, unfortunately it looks like ext2int() reorders generators in order of increasing bus number, even if there is only one gen per bus. I need to see if I can uncover the reason for doing this. I suspect it's something historical that is no longer relevant ... in which case, maybe we should just modify ext2int() so it stops doing that.

[rdzman]

I just pushed a commit (710277f) to the MATPOWER master branch with a change that eliminates the reordering of generators in ext2int. So now it only removes offline units, but does not change the order.