makePTDF error: use ext2int() to convert to internal ordering

[thomsonian2023]

I am using the following code:

fn = 'X:\z2.RAW' mpc = psse2mpc(fn); %%%%%% Converts PSSE/RAW File to MATPOWER Case

I am using Windows OS, Octave 6.2.0 and Matpower 7.1

I get the error: makePTDF: buses must be numbered consecutively in bus matrix. Use ext2int() to convert to internal ordering. error called from: makePTDF at line 120 column 5

I am not sure how to use the ext2int() in my process above.

[rdzman]

mpci = ext2int(mpc);
H = makePTDF(mpci);

[thomsonian2023]

I am curious why this was not put in the original code itself instead of printing an error. Why do you want the user to be aware of fact that he is sorting the bus. i.e. is there a downside to user not being aware of this sorting?

[rdzman]

Good question.

There are many functions (e.g. makeYbus), used internally by MATPOWER in the process of solving a power flow, OPF, etc, that assume their inputs, which may be a sub-set of the full MATPOWER case, have already been converted to internal indexing by the top-level function, runpf, runopf, etc. This allows these functions to be much simpler and their interfaces cleaner. And the documentation for these functions always mentions explicitly that the inputs are expected to be in internal format.

I suppose makePTDF was initially conceived as a function in the same category, and developed with these simplifying assumptions. However, it really is typically used directly by the end user and it does have the option to supply the full mpc (as opposed to just the bus and branch matrices), so ideally, in that case, I agree it would be useful to allow the user to pass in the original mpc in external format and have it handle the conversion automatically.

However, this raises a few additional questions that I'd need to sort out to maintain a consistent interface to the function.

• Do we modify the output matrix by inserting zero rows/columns for the offline branches/buses that are removed during conversion in order to make the rows and columns correspond to the original external format?
• Should the scalar slack input be interpreted as a bus number rather than a bus index?
• How do we handle txfr and bus_idx inputs that refer to off-line buses that get removed during conversion?

Anyway, I've seen users stumble over this before, so I'm going to leave this issue open as a feature request. Thanks for bringing it to my attention.