matpower / matpower

MATPOWER – steady state power flow simulation and optimization for MATLAB and Octave

A Power System Simulation Package for MATLAB and Octave

• MATPOWER Website - https://matpower.org
• MATPOWER GitHub Project - https://github.com/MATPOWER/matpower

MATPOWER is a package of M-files for solving power flow, continuation power flow and optimal power flow problems using MATLAB or Octave. It is intended as a simulation tool for researchers and educators that is easy to use and modify. MATPOWER is designed to give the best performance possible while keeping the code simple to understand and modify.

MATPOWER releases can be downloaded from the MATPOWER website, and the latest stable and work-in-progress versions can always be downloaded or cloned from the MATPOWER GitHub project. The master branch should always contain a stable version.

System Requirements

For all features, including those based on the new MP-Core:

• MATLAB version 9.0 (R2016a) or later, or
• GNU Octave version 6.2 or later

Legacy features only (from 7.1 and earlier) are also available on:

• MATLAB version 7.9 (R2009b) or later, or
• GNU Octave version 4 or later

Getting MATPOWER

You can either download an official versioned release or you can obtain the current development version, which we also attempt to keep stable enough for everyday use. The development version includes new features and bug fixes added since the last versioned release.

Versioned Releases

Download the ZIP file of the latest official versioned release from the MATPOWER website. Note: This does include the MATPOWER Extras.

Current Development Version

There are also two options for obtaining the most recent development version of MATPOWER from the master branch on GitHub. Note: This does not include the MATPOWER Extras.

1. Clone the MATPOWER repository from GitHub. Use this option if you want to be able to easily update to the current development release, with the latest bug fixes and new features, using a simple git pull command, or if you want to help with testing or or development. This requires that you have a Git client (GUI or command-line) installed.

   • From the command line:
     • git clone https://github.com/MATPOWER/matpower.git
   • Or, from the MATPOWER GitHub repository page:
     • Click the green Clone or download button, then Open in Desktop.

2. Download a ZIP file of the MATPOWER repository from GitHub. Use this option if you need features or fixes introduced since the latest versioned release, but you do not have access to or are not ready to begin using Git (but don't be afraid to give Git a try).

   • Go to the MATPOWER GitHub repository page.
   • Click the green Clone or download button, then Download ZIP.

See CONTRIBUTING.md for information on how to get a local copy of your own MATPOWER fork, if you are interesting in contributing your own code or modifications.

MATPOWER Docker Image

MATPOWER is also available on Docker Hub as the pre-packaged Docker image tagged matpower/matpower, providing a Linux environment with Octave, MATPOWER, and the MATPOWER Extras pre-installed. See the MATPOWER-Docker page for more details.

Docker images are provided for both versioned releases and development versions.

Installation

Installation and use of MATPOWER requires familiarity with the basic operation of MATLAB or Octave. Make sure you follow the installation instructions for the version of MATPOWER you are installing. The process was simplified with an install script following version 6.0.

1. Get a copy of MATPOWER as described above. Clone the repository or download and extract the ZIP file of the MATPOWER distribution and place the resulting directory in the location of your choice and call it anything you like. We will use <MATPOWER> as a placeholder to denote the path to this directory (the one containing install_matpower.m). The files in <MATPOWER> should not need to be modified, so it is recommended that they be kept separate from your own code.

2. Run the installer.

   • Open MATLAB or Octave and change to the <MATPOWER> directory.

   • Run the installer and follow the directions to add the required directories to your MATLAB or Octave path, by typing:

       install_matpower
     

3. That's it. There is no step 3.

   • But, if you chose not to have the installer run the test suite for you in step 2, you can run it now to verify that MATPOWER is installed and functioning properly, by typing:

       test_matpower
     

Running MATPOWER

To run a simple Newton power flow on the 9-bus system specified in the file case9.m, with the default algorithm options, at the MATLAB or Octave prompt, type:

runpf('case9')

To load the 30-bus system data from case30.m, increase its real power demand at bus 2 to 30 MW, then run an AC optimal power flow with default options, type:

define_constants;
mpc = loadcase('case30');
mpc.bus(2, PD) = 30;
runopf(mpc);

By default, the results of the simulation are pretty-printed to the screen, but the solution can also be optionally returned in a results struct. The following example shows how simple it is, after running a DC OPF on the 118-bus system in case118.m, to access the final objective function value, the real power output of generator 6 and the power flow in branch 51.

results = rundcopf('case118');
final_objective = results.f;
gen6_output     = results.gen(6, PG);
branch51_flow   = results.branch(51, PF);

For additional info, see the MATPOWER User's Manual, the on-line function reference, or the built-in help documentation for the various MATPOWER functions. For example:

help runpf
help runopf
help mpoption
help caseformat

Documentation

There are a number of sources of documentation for MATPOWER

User's Manuals

The User's Manuals are available as PDF files in the MATPOWER distribution as well as online.

• MATPOWER User's Manual -- docs/MATPOWER-manual.pdf
• MOST User's Manual -- most/docs/MOST-manual.pdf
• MP-Opt-User's Manual -- mp-opt-model/docs/MP-Opt-Model-manual.pdf
• MIPS Manual -- mips/docs/MIPS-manual.pdf
• MP-Test README -- mptest/README.md

Current and past versions of the manuals are also available online at:

• https://matpower.org/doc/manuals

MATPOWER Documentation website

The new MATPOWER Documentation site is intended to be the home for all future MATPOWER documentation. It is very much a work-in-progress and currently contains only the new:

• MATPOWER Developer's Manual

As new documentation is written and legacy manuals are rewritten, they will be found here in HTML and PDF formats. The site is generated by Sphinx and the content is written in reStructuredText (reST) format.

MATPOWER Online Function Reference

Built-in Help

Each M-file has its own documentation which can be accessed by typing at the MATLAB/Octave prompt:

help <name of M-file>

Documentation for the case data file format can be found by typing:

help caseformat

If something is still unclear after checking the manual and the help, the source code is the documentation. 😉

Changes

Changes to MATPOWER in each released version are summarized in the release notes, found in docs/relnotes and in Appendix H of the MATPOWER User's Manual. A complete, detailed change log, even for unreleased versions, is available in the CHANGES.md file.

Contributing

Please see our contributing guidelines for details on how to contribute to the project or report issues.

Sponsoring the MATPOWER Project

If you have found MATPOWER to be valuable, please consider supporting the project by becoming a sponsor. MATPOWER development and support require significant resources. Any contributions from the community or other sponsors free us to focus on that support and the development of valuable new features.

Publications and Tech Notes

1. R. D. Zimmerman, C. E. Murillo-Sanchez, and R. J. Thomas, "MATPOWER: Steady-State Operations, Planning and Analysis Tools for Power Systems Research and Education," Power Systems, IEEE Transactions on, vol. 26, no. 1, pp. 12–19, Feb. 2011.
   doi: 10.1109/TPWRS.2010.2051168.

2. R. D. Zimmerman, C. E. Murillo-Sanchez, and R. J. Thomas, "MATPOWER's Extensible Optimal Power Flow Architecture," Power and Energy Society General Meeting, 2009 IEEE, pp. 1-7, July 26-30 2009.
   doi: 10.1109/PES.2009.5275967.

   • slides of presentation

3. H. Wang, C. E. Murillo-Sánchez, R. D. Zimmerman, R. J. Thomas, "On Computational Issues of Market-Based Optimal Power Flow," Power Systems, IEEE Transactions on, vol. 22, no. 3, pp. 1185-1193, Aug. 2007.
   doi: 10.1109/TPWRS.2007.901301.

4. C. E. Murillo-Sanchez, R. D. Zimmerman, C. L. Anderson, and R. J. Thomas, "Secure Planning and Operations of Systems with Stochastic Sources, Energy Storage and Active Demand," Smart Grid, IEEE Transactions on, vol. 4, no. 4, pp. 2220–2229, Dec. 2013.
   doi: 10.1109/TSG.2013.2281001.

5. A. J. Lamadrid, D. Munoz-Alvarez, C. E. Murillo-Sanchez, R. D. Zimmerman, H. D. Shin and R. J. Thomas, "Using the MATPOWER Optimal Scheduling Tool to Test Power System Operation Methodologies Under Uncertainty," Sustainable Energy, IEEE Transactions on, vol. 10, no. 3, pp. 1280-1289, July 2019. doi: 10.1109/TSTE.2018.2865454.

6. R. D. Zimmerman, "Uniform Price Auctions and Optimal Power Flow," MATPOWER Technical Note 1, February 2010.
   Available: https://matpower.org/docs/TN1-OPF-Auctions.pdf
   doi: 10.5281/zenodo.3237850.

7. R. D. Zimmerman, "AC Power Flows, Generalized OPF Costs and their Derivatives using Complex Matrix Notation," MATPOWER Technical Note 2, February 2010.
   Available: https://matpower.org/docs/TN2-OPF-Derivatives.pdf
   doi: 10.5281/zenodo.3237866.

8. B. Sereeter and R. D. Zimmerman, "Addendum to AC Power Flows and their Derivatives using Complex Matrix Notation: Nodal Current Balance," MATPOWER Technical Note 3, April 2018.
   Available: https://matpower.org/docs/TN3-More-OPF-Derivatives.pdf
   doi: 10.5281/zenodo.3237900.

9. B. Sereeter and R. D. Zimmerman, "AC Power Flows, Generalized OPF Costs and their Derivatives using Complex Matrix Notation and Cartesian Coordinate Voltages," MATPOWER Technical Note 4, April 2018.
   Available: https://matpower.org/docs/TN4-OPF-Derivatives-Cartesian.pdf
   doi: 10.5281/zenodo.3237909.

Citing MATPOWER

We request that publications derived from the use of MATPOWER, or the included data files, explicitly acknowledge that fact by citing the appropriate paper(s) and the software itself.

Papers

All publications derived from the use of MATPOWER, or the included data files, should cite the 2011 MATPOWER paper:

R. D. Zimmerman, C. E. Murillo-Sanchez, and R. J. Thomas, "MATPOWER: Steady-State Operations, Planning and Analysis Tools for Power Systems Research and Education," Power Systems, IEEE Transactions on, vol. 26, no. 1, pp. 12-19, Feb. 2011.
doi: 10.1109/TPWRS.2010.2051168

Publications derived from the use of the MATPOWER Optimal Scheduling Tool (MOST) should cite the 2013 MOST paper, in addition to the 2011 MATPOWER paper above.

C. E. Murillo-Sanchez, R. D. Zimmerman, C. L. Anderson, and R. J. Thomas, "Secure Planning and Operations of Systems with Stochastic Sources, Energy Storage and Active Demand," Smart Grid, IEEE Transactions on, vol. 4, no. 4, pp. 2220-2229, Dec. 2013.
doi: 10.1109/TSG.2013.2281001

Work making specific reference to the MATPOWER Interior Point Solver (MIPS) should also cite:

H. Wang, C. E. Murillo-Sánchez, R. D. Zimmerman, R. J. Thomas, "On Computational Issues of Market-Based Optimal Power Flow," Power Systems, IEEE Transactions on, vol. 22, no. 3, pp. 1185-1193, Aug. 2007.
doi: 10.1109/TPWRS.2007.901301

NOTE: Some of the case files included with MATPOWER request the citation of additional publications. This includes the ACTIVSg, PEGASE, and RTE cases. Details are available in the help text at the top of the corresponding case files.

Software

For the sake of reproducibility of research results, it is best to cite the specific version of the software used, with the version-specfic DOI. For example, for version 8.0 of MATPOWER, use:

R. D. Zimmerman, C. E. Murillo-Sanchez (2024). MATPOWER (Version 8.0) [Software]. Available: https://matpower.org
doi: 10.5281/zenodo.11212330

To cite the MATPOWER software generally, without reference to a specific version, use the following citation and DOI, with <YEAR> replaced by the year of the most recent release:

R. D. Zimmerman, C. E. Murillo-Sanchez (<YEAR>). MATPOWER [Software]. Available: https://matpower.org
doi: 10.5281/zenodo.3236535

A list of versions with release dates and version-specific DOI's can be found via the general DOI at https://doi.org/10.5281/zenodo.3236535.

User's Manuals

The MATPOWER, MIPS and MOST User's Manuals should also be cited explicitly in work that refers to or is derived from their content. As with the software, the citation and DOI can be version-specific or general, as appropriate. For version 8.0 of the MATPOWER User's Manual, use:

R. D. Zimmerman, C. E. Murillo-Sanchez. MATPOWER User's Manual, Version 8.0. 2024.
[Online]. Available: https://matpower.org/docs/MATPOWER-manual-8.0.pdf
doi: 10.5281/zenodo.11212313

For a version non-specific citation, use the following citation and DOI, with <YEAR> replaced by the year of the most recent release:

R. D. Zimmerman, C. E. Murillo-Sanchez. MATPOWER User's Manual. <YEAR>.
[Online]. Available: https://matpower.org/docs/MATPOWER-manual.pdf
doi: 10.5281/zenodo.3236519

A list of versions of the User's Manual with release dates and version-specific DOI's can be found via the general DOI at https://doi.org/10.5281/zenodo.3236519.

For information on citing the MIPS or MOST User's Manuals, please see the mips/CITATION and most/CITATION files, respectively.

Recommendation

In the interest of facilitating research reproducibility and thereby increasing the value of your MATPOWER-related research publications, we strongly encourage you to also publish, whenever possible, all of the code and data required to generate the results you are publishing. Zenodo/GitHub and IEEE DataPort are two of many available options.

E-mail Lists

There are two e-mail lists available to serve the MATPOWER community:

• Discussion List (MATPOWER-L) – to facilitate discussion among MATPOWER users and provide a forum for help with MATPOWER related questions

• Developer List (MATPOWER-DEV-L) – to provide a forum for discussion among MATPOWER users and developers related to the development of the MATPOWER software or proposed contributions

For details see the Mailing Lists section of the MATPOWER website.

Please select the most appropriate list for your post and do not cross-post to both Discussion and Developer lists. Bug reports, software patches, proposed enhancements, etc. should be submitted to the issue tracker on GitHub.

Optional Packages

There are numerous optional packages to enhance the performance of MATPOWER that must be installed separately. The terms of use and license agreements vary. Some are free of charge for all to use, others are only free for academic use, and others may require a commercial license. Please see Appendix G of the MATPOWER User's Manual for details.

License and Terms of Use

MATPOWER is distributed as open-source under the 3-clause BSD license.

---

matpower's Issues

Can't add storage to a MOST Multi-Period OPF test

Greetings Everyone

I am doing a dissertation on energy storage systems influence on Multi-period OPF and i'm trying to use MOST to solve the OPF and use it's functionalities for adding storage and solving the multi-period OPF easier.

However, im having problems adding the storage to the test case while using the addstorage function. I might be doing something wrong so i'll try and add the scripts i am using in attatch.

Would be very appreciate of any help

Best Regards
Storage_test.zip

branch angle difference limit anomaly

The manual states in the section on Branch Angle Difference Limits, that ...

The voltage angle difference for branch k is taken to be unbounded below if branch(k, ANGMIN) is less than −360 and unbounded above if branch(k, ANGMAX) is greater than 360. If both param- eters are zero, the voltage angle difference is unconstrained.

However, it appears that if either limit is set to zero, that limit is ignored. This should either be fixed in the code in makeAang, to make it consistent with the manual (only ignore if both ANGMIN and ANGMAX are zero, or update the manual to more accurately reflect what the code actually does.

Bug in var limiting in CPF

I noticed for case300, while the maximum generator var limits were being respected, the minimum var limit of one generator was being violated at the LIB. The generator at bus number 76 (generator status is 1), has a QG of 0 MVAr at the LIB whereas its minimum QG is 12 MVAr. Hence, the violation was greater than the default tolerance for limit detection (0.01 MVAr).

Also, for a larger test case with 6000 buses,, 33 generators were violating the max. var limit, while 61 generators were violating the min. var limit out of 531 committed generators.

Here is a sample code I used:
mpcb=loadcase('case300');
mpct = mpcb; % set up target case with
mpct.bus(:, PD) = mpcb.bus(:, PD)*5; % and increased load
mpct.bus(:, QD) = mpcb.bus(:, QD)*5; % and increased load
mpct.gen(:, PG) = mpcb.gen(:, PG)*5; % and increased gen
mpopt = mpoption('cpf.stop_at', 'NOSE','cpf.enforce_q_lims',1,'cpf.enforce_p_lims',0);
results = runcpf(mpcb, mpct, mpopt);

t_psse..................error: Invalid call to length.

I own a notebook running Arch Linux where I am trying to run version 6.0 (latest stable release at this point) on GNU Octave (version 4.4.0).

After adding the paths suggested in the installation guide from the user manual, I ran the code "test_matpower" to which I get the following result:

[..}
t_opf_dc_mips...........ok
t_opf_dc_mips_sc........ok
t_opf_userfcns..........ok
t_opf_softlims..........ok
t_runopf_w_res..........ok
t_dcline................ok
t_get_losses............ok
t_makePTDF..............ok
t_makeLODF..............ok
t_printpf...............ok
t_vdep_load.............ok
t_total_load............ok
t_scale_load............ok
t_apply_changes.........ok
t_psse..................error: Invalid call to length. Correct usage is:

-- length (A)
error: called from
print_usage at line 91 column 5
psse_parse_line at line 65 column 12
t_psse at line 61 column 14
t_run_tests at line 58 column 5
test_matpower at line 128 column 1

I've searched the archives, and googled it but I was not able to find the cause of the error.
I ran the same test on Matlab, on the same computer and despite some warnings, all tests were successful.

allow user to clear have_fcn caching of optional functionality

The have_fcn() function detects the availability of optional functionality (e.g. 3rd party solvers) and caches the result, including version and release date info if available. This cached information can become invalid if the Matlab/Octave path is subsequently modified, leading to the potential for incorrect behavior based on the now invalid cached results returned by have_fcn().

Currently this cache can be cleared for a given functionality by toggling it off then back on. E.g. for ipopt ...

have_fcn('ipopt', 0);
have_fcn('ipopt', 1);

It would be useful to be able to easily clear all of the cached information to force a recheck for all optional functionality, e.g. after modifying the Matlab path.

Something like ...

have_fcn('all', 'clear_cache');

We could also include the following as a shortcut for the two steps of disabling and re-enabling a particular functionality mentioned above.

have_fcn('ipopt', 'clear_cache');

Sparse Structure of Hessian and Jacobian changing during OPF iterations

Dear Ray,
I have encountered that the sparse structure of the Hessian and Jacobian matrices do not stay the same during OPF iterations. Specifically, Matlab can eliminate elements that have a zero value, thus changing the sparsity structure. IPOPT, KNITRO, and other NLP solvers expect the sparsity structure of the matrix passed to it to match exactly that of the sparsity structure provided even if some of the values in that structure are numerically zero. An easy fix is to add a perturbation to the zero entries 1e-32 or 1e-64 and then MATLAB will not eliminate them.

A more rigorous approach would be to create our own sparse matrix class for MATPOWER, which does what MATLAB sparse structure is supposed to do but doesn't. More precisely if a constructor is provided accepting the sparse structure from the user, it should honour the provided sparse structure even if some entries are zero. Many applications rely on the fact that the topology of the graph (whether we are solving PDEs or OPF problems ) does not change through the iterations and this way linear solvers perform the symbolic once and for all. An easy solution for MATLAB would be to add an additional flag in the constructor to allow the user to choose whether he wishes MATLAB to eliminate zero entries or not in case a fixed sparse structure is important for his application.

Best wishes.

Calculate PTDF for large cases

For large cases, makePTDF will fail because it tries to invert a very large matrix. I found this discussion on the mailing list which gave some hints on how to proceed:

https://www.mail-archive.com/[email protected]/msg05580.html

However, I am having trouble understanding what you mean by factoring B_dc to efficiently solve for dx. I was hoping you might be able to provide some additional guidance on how to proceed.

Here is what I have done so far:

% https://www.mail-archive.com/[email protected]/msg05580.html

% Calculate the shift factors without inverting Z
% Here I consider a 7 bus case that comes with PowerWorld and I try to compute the PTDFs with matpower

define_constants;

mpc = loadcase ('B7OPF.m');

[Bbus, Bf, Pbusinj, Pfinj] = makeBdc(mpc);

% For debugging
Bbus = full(Bbus)

% Bp is reduced Bbus obtained by removing ref bus:
Bp = full(Bbus);
Bp(:,7) = [];
Bp(7,:) = [];

% For debugging
Z = inv(Bp)

% Calculate H(1,1) element wise (equal to H(1,1))
x1 = mpc.branch(1, BR_X)
(Z(1,1) - Z(2,1)) / x1

% Shift factors
H = makePTDF(mpc)

% Calculate PTDF without inverting
% This matches Z(:,1)
a = Bp \ [1,0,0,0,0,0]';
b = Bp \ [0,1,0,0,0,0]';

Z
% This is H(1,:)
(a - b) / x1

% How can I calculate H(:,1) efficiently?

B7OPF.zip

Thanks so much for a very helpful project and your time spent maintaining it.

Scott

CPF: Basecase and targetcase identical (runcpf)

Hi everyone!
I´m new to Github and Matpower, forgive me if this isn´t the right place for bug-reporting...

I found the following: When basecase and targetcase are identical, e.g. both is case9, there should be an error displaying:
'Base case and target case have identical load and generation'; (Line 384)

I know that the whole concept of cpf is stupid when they are both the same cases but the error should be displayed correctly anyway :D

The problem: runcpf never reaches the end, because the 'success' variable, that is needed in line 586 is not initiated.

In my runcpf-file I initiated success in the beginning with 0. But I don´t yet have the courage to propose the right change myself or maybe I understood sth. the wrong way, who knows? :/

Thank you for your patience with me :)

slack bus has no generator in RTE cases

It appears that the RTE cases have no generator at the slack/reference bus.

case1888rte
case1951rte
case2848rte
case2868rte
case6468rte
case6470rte
case6495rte
case6515rte

Currently, MATPOWER's runpf handles this by (silently) converting the specified slack/reference bus to a PQ bus, and selecting the first PV bus as a new slack/reference bus.

However, this should be corrected in the cases by specifying a slack/reference bus that has a generator.

Thanks to Drosos Kourounis for pointing this out.

CPF - Converted PQ buses have 0 QG

Generator 5 is at its minimum Q-limit already in the base case of the CPF. Since Qlimits are enforced it is converted to a PQ bus. However, in the target case the Q value has been set to 0 instead of the limit that was reached in the base case. This is due to line 272 and 284 in runcpf, where only the Q-values for active generators are copied to the target case.

Base case:

================================================================================
|     Generator Data                                                           |
================================================================================
 Gen   Bus   Status     Pg        Qg   
  #     #              (MW)     (MVAr) 
----  -----  ------  --------  --------
  1      1      1      40.00     56.55
  2      1      1     170.00    -40.87
  3      3      1     323.49    194.65
  4      4      1       5.02    180.86
  5      5      1     466.51    -20.00
                     --------  --------
            Total:   1005.02    371.20

Target case:

================================================================================
|     Generator Data                                                           |
================================================================================
 Gen   Bus   Status     Pg        Qg   
  #     #              (MW)     (MVAr) 
----  -----  ------  --------  --------
  1      1      1     432.12   2311.84
  2      1      1    1836.52   2216.62
  3      3      1    3494.68   5093.80
  4      4      1    1049.50   4240.78
  5      5      1    5039.74      0.00
                     --------  --------
            Total:  11852.56  13863.04

Code:

clear; 
close all;

define_constants;

%% options

mpopt  =  mpoption('out.all',  -1,  'verbose',  2);

mpopt = mpoption(mpopt, 'out.sys_sum', 1,  ...
                        'out.area_sum', 0, ...
                        'out.bus', 1, ...
                        'out.branch', 0, ...
                        'out.gen', 1, ...
                        'out.force', 0 );

% pf options
mpopt = mpoption(mpopt, 'pf.nr.max_it', 20);
mpopt = mpoption(mpopt, 'pf.enforce_q_lims', 1);

% cpf options
mpopt = mpoption(mpopt, 'cpf.stop_at', 'NOSE', 'cpf.step', 1); 
mpopt = mpoption(mpopt, 'cpf.plot.level', 2);
mpopt = mpoption(mpopt, 'cpf.plot.bus', 2);
mpopt = mpoption(mpopt, 'cpf.parameterization', 2);
mpopt = mpoption(mpopt, 'cpf.enforce_q_lims',1);
mpopt = mpoption(mpopt, 'cpf.adapt_step',1);


mpcbase = case5;

% switch limits to make generator at bus 5 reach Qmax but not generator at
% slack bus
mpcbase.gen(:,QMAX) = 1e5;
mpcbase.gen(5,[QMAX QMIN]) = [20 -20];

runpf(mpcbase,mpopt);

% target case: increase load and generation 
mpctarget = mpcbase;
mpctarget.bus(:,[PD QD]) = mpctarget.bus(:,[PD QD])*2;
mpctarget.gen(:,[PG QG]) = mpctarget.gen(:,[PG QG])*2;

runcpf(mpcbase,mpctarget,mpopt);

Version:

MATPOWER               Version 6.0        16-Dec-2016
MATLAB                 Version 8.6        13-Aug-2015   Release: (R2015b)  
Optimization Toolbox   Version 7.3        13-Aug-2015   Release: (R2015b)  
MIPS                   Version 1.2.2      16-Dec-2016
MOST                   Version 1.0        16-Dec-2016
SDP_PF                 -- not installed --
YALMIP                 -- not installed --
BPMPD_MEX              -- not installed --
CLP                    -- not installed --
CPLEX                  -- not installed --
GLPK                   -- not installed --
Gurobi                 -- not installed --
IPOPT                  -- not installed --
KNITRO                 -- not installed --
MINOPF                 -- not installed --
MOSEK                  -- not installed --
PARDISO                -- not installed --
PDIPMOPF               -- not installed --
SCPDIPMOPF             -- not installed --
SDPT3                  -- not installed --
SeDuMi                 -- not installed --
TRALMOPF               -- not installed --
Architecture:          PCWIN64

  MATPOWER 6.0 is distributed under the 3-clause BSD License.
  Please see the LICENSE file for details.

update psse2mpc() to handle RAW format v34

The current psse2mpc() function handles RAW files only up to v33.

Thanks to Atif Naveed for bringing this to our attention.

Nodal LMP components

Hi,

I am interested in calculating the components of the nodal LMPs (energy, loss, congestion). After reading the documentation I understand that the bus(i, LAM_P) value represents the total LMP at bus i.

I searched through the code for where this is calculated and I think the file lib/fmincopf_solver.m is where this value is set, is that correct? It is not clear to me how I can calculate the individual components of the LMP, is this done anywhere in the code?

Thank you for your time and efforts.

have_fcn fails on Octave when fmincon is not present

I have the latest stable version of matpower. I'm not sure it applies to the development version.

In octave when octave-optim is not installed, have_fcn(fmincon) crashes.

`octave:3> test_matpower
error: value on right hand side of assignment is undefined
error: called from
have_fcn at line 191 column 26
test_matpower at line 44 column 1
stopped in .../matpower6.0/have_fcn.m at line 191
191: vstr = v.Version;
debug> v
v =

0x0 struct array containing the fields:

Name
Version
Release
Date

debug> v.Version
debug> v.Release
debug> v.Date
This is because fmincon is not installedoctave:6> fmincon
warning: the 'fmincon' function belongs to the optim package from Octave Forge
`

after installing it, everything works.

Expected behaviour: have_fcn should output that the function is not available.
Best!
Eike

Issue with adding nonlinear cost constraint

I'm trying to add a non-linear cost constraint : cost = x' H x+e'x+M
I've used the direct method to create field which I've attached in the file below.

Cost_constraint.docx

One of the errors I get is the following :

Subscripted assignment dimension mismatch.
Error in opt_model/eval_nln_constraint (line 89)
dg(i1:iN, 1:size(dgk, 2)) = dgk;

When I debugged I found, size(dgk, 2)=0 and the om.(" ") fields still have values from the branch flow non-linear constraint. I think my code is correct. It'd be helpful if you could point-out my mistake(s) or find out why I'm not able to add a new non-linear constraint.

Matpower version:

mpver

MATPOWER Version 6.1-dev 27-Sep-2017
MATLAB Version 9.2 16-Feb-2017 Release: (R2017a)
Optimization Toolbox Version 7.6 16-Feb-2017 Release: (R2017a)
MIPS Version 1.3-dev 16-Mar-2017
MOST Version 1.0.1-dev 27-Sep-2017
SDP_PF -- not installed --
YALMIP -- not installed --
BPMPD_MEX -- not installed --
CLP -- not installed --
CPLEX -- not installed --
GLPK -- not installed --
Gurobi -- not installed --
IPOPT -- not installed --
KNITRO -- not installed --
MINOPF -- not installed --
MOSEK -- not installed --
PARDISO -- not installed --
PDIPMOPF -- not installed --
SCPDIPMOPF -- not installed --
SDPT3 -- not installed --
SeDuMi -- not installed --
TRALMOPF -- not installed --
Architecture: GLNXA64

MATPOWER 6.1-dev is distributed under the 3-clause BSD License.
Please see the LICENSE file for details.

Problem in newtonpf.m

Hi,

I am having a problem when using newtonpf.m alone. This problem exists in github version as well as in 6.0. Version 5.1 and before are fine.

Line 53: mis = V .* conj(Ybus * V) - Sbus(Vm);

Since Vm is non-integer, MATLAB will give an error message saying subscript cannot be a non-integer.

In the previous version, only Sbus is used.

Similar usage can be found in Line 88 and 115.

Can anyone explain this?

test_matpower fatal error with SDP_PF & YALMIP, but no SDP solver

Thanks for your patience and help all the time. The following is the previous procedure and error details:

• I've download a zip file of the MATPOWER repository from GitHub.
• I've changed the directory to .
• install_matpower has been executed
• addpath done
• mpver(CPLEX already removed from the MATLAB search path)

MATPOWER               Version 6.1-dev    17-Mar-2017
MATLAB                 Version 9.1        25-Aug-2016   Release: (R2016b)  
Optimization Toolbox   Version 7.5        25-Aug-2016   Release: (R2016b)  
MIPS                   Version 1.3-dev    16-Mar-2017
MOST                   Version 1.0        16-Dec-2016
SDP_PF                 Version 1.0        17-Jan-2014
YALMIP                 Version                       
BPMPD_MEX              -- not installed --
CLP                    -- not installed --
CPLEX                  -- not installed --
GLPK                   -- not installed --
Gurobi                 Version 7.0.2                 
IPOPT                  -- not installed --
KNITRO                 -- not installed --
MINOPF                 -- not installed --
MOSEK                  -- not installed --
PARDISO                -- not installed --
PDIPMOPF               -- not installed --
SCPDIPMOPF             -- not installed --
SDPT3                  -- not installed --
SeDuMi                 -- not installed --
TRALMOPF               -- not installed --
Architecture:          PCWIN64

• test_matpower reports error in t_opf_sdpopf

t_test_fcns.................ok
t_nested_struct_copy........ok
t_feval_w_path..............ok
t_mpoption..................ok
t_loadcase..................ok
t_ext2int2ext...............ok
t_jacobian..................ok
t_hessian...................ok
t_margcost..................ok
t_totcost...................ok
t_modcost...................ok
t_hasPQcap..................ok
t_mplinsolve................ok (2 of 21 skipped)
t_mips......................ok
t_qps_matpower..............ok (216 of 360 skipped)
t_miqps_matpower............ok (178 of 240 skipped)
t_pf........................ok
t_pf_radial.................ok
t_cpf.......................ok
t_islands...................ok
t_opf_model.................ok
t_opf_fmincon...............ok
t_opf_mips..................ok (137 of 274 skipped)
t_opf_mips_sc...............ok (137 of 274 skipped)
t_opf_dc_gurobi.............ok
t_opf_dc_mips...............ok
t_opf_dc_mips_sc............ok
t_opf_dc_ot.................ok
t_opf_sdpopf................Error using eig
Input to EIG must not contain NaN or Inf.

Error in sdpopf_solver (line 1016)
        [evc, evl] = eig(double(A{i}));

Error in opf_execute (line 124)
      [results, success, raw] = sdpopf_solver(om, mpopt);

Error in opf (line 204)
[results, success, raw] = opf_execute(om, mpopt);

Error in runopf (line 75)
[r, success] = opf(casedata, mpopt);

Error in t_opf_sdpopf (line 61)
[baseMVA, bus, gen, gencost, branch, f, success, et] = runopf(casefile, mpopt);

Error in t_run_tests (line 61)
    feval( test_names{k}, ~verbose );

Error in test_matpower (line 140)
all_ok = t_run_tests( tests, verbose );

Add option for proportional Qg scaling in pfsoln

The logic in pfsoln for scaling Qg in proportion with Qmax and Qmin is quite complicated. Perhaps it could be made optional, with Qg otherwise just divided equally among the online generators. Of course, the option would default to proportional scaling in order to maintain the current default behaviour.

Either way, pfsoln might benefit from some additional documentation. Particularly around handling infinite limits and zero Qg range.

CPF termination problem

I have found what I believe to be a bug in the CPF function. For some systems, when close to the nose point, i.e. when the voltage starts falling steeply, instead of terminating the CPF will continue and voltages will instead start to increase rapidly. Although I have not investigated what causes this I believe it may be some numerical issue.

An example is provided here with the 4 bus system. The voltage at bus 3 falls to 0.55 and then starts increasing again. I have also observed the same behavior for more complicated systems. :

clear;
close all;

define_constants;


mpc = case4gs();

% change parameters
mpc.bus(4,[PD QD]) = [-1820 -1307.2];
mpc.gen(1,[PG QMAX QMIN PMAX]) = [300 200 -1e9 250];
mpc.gen(2,[QMAX PMAX]) = [1e9 500];

mpcb = mpc;
mpct = mpc;
% target case
mpct.bus(3,[PD QD]) = 2*mpcb.bus(3,[PD QD]);

% options
mpopt = mpoption();
mpopt.cpf.enforce_q_lims = 1;
mpopt.cpf.parameterization = 3;
mpopt.adapt_step = 0;
mpopt.step = 0.1;
mpopt.cpf.enforce_v_lims = 0;
mpopt.cpf.enforce_flow_lims = 0;
mpopt.cpf.plot.level = 2;

runcpf(mpcb,mpct,mpopt)

My matpower version:

MATPOWER               Version 6.1-dev    23-Aug-2017
MATLAB                 Version 8.6        13-Aug-2015   Release: (R2015b)  
Optimization Toolbox   Version 7.3        13-Aug-2015   Release: (R2015b)  
MIPS                   Version 1.3-dev    16-Mar-2017
MOST                   Version 1.0.1-dev  07-Aug-2017
SDP_PF                 -- not installed --
YALMIP                 -- not installed --
BPMPD_MEX              -- not installed --
CLP                    -- not installed --
CPLEX                  -- not installed --
GLPK                   -- not installed --
Gurobi                 -- not installed --
IPOPT                  -- not installed --
KNITRO                 -- not installed --
MINOPF                 -- not installed --
MOSEK                  -- not installed --
PARDISO                -- not installed --
PDIPMOPF               -- not installed --
SCPDIPMOPF             -- not installed --
SDPT3                  -- not installed --
SeDuMi                 -- not installed --
TRALMOPF               -- not installed --
Architecture:          PCWIN64

distribution power flow

The suggestion I would like to make is about the power flow calculation module of distribution network. Although the module has only one requirement for node numbers, many cases cannot be met. I am doing a research on distribution network reconfiguration, in which the power flow calculation should not have any other node number requirements except the power supply node.

OPF (and PF) crash in ext2int() when all buses are isolated

mpver:
MATPOWER Version 6.0 16-Dec-2016
I believe this crash will also occur in the present github version of matpower.

MWE:
mpc = loadcase('case30');
mpc.bus(:,2) = 4;
runpf(mpc); %alternatively runopf(mpc) will result in the same crash

Bug:
Matpower does not presently handle cases in which all buses are set to isloated (mpc.bus(:,BUS_TYPE) = 4), causing ext2int() to crash with the following error report:

Error using sparse
Sparse matrix sizes must be non-negative integers less than MAXSIZE as defined by COMPUTER. Use HELP COMPUTER for more details.

Error in ext2int (line 169)
o.bus.e2i = sparse(max(o.bus.i2e), 1);

Expected outcome:

• text to screen stating, "powerflow not valid - all buses in casefile are isolated"
• mpc.success = 0
• does not cause matlab to stop the active script or to enter debugging mode

Justification for bug fix:
It is possible that any user who is simulating cascading faults or blackouts may arrive at such a case. Given that it is valid input (within the rules of matpower) to have all buses with type = 4, the code should therefore handle this case without requiring the user to manually catch/treat the case prior to running a PF/OPF.

Possible typos of matpower manual

There might be a typo of the matpower manual, at Section 7.2.3, page 81 (lines 2672 and 2678 in MATPOWER-manual.tex).
The functions for adding user-defined linear/nonlinear constraints shall be om.add_lin_constraint/om.add_nln_constraint, instead of om.lin_constraint/om.nln_constraint.

linprog and intlinprog parameters

Hi,

I just downloaded MATPOWER version 6.0 to use it together with MATLAB R2016b, on a MAC OS X Yosemite. When launching the testing script test_matpower, I experienced the following error:

---

t_miqps_matpower........Error using intlinprog (line 132)
INTLINPROG has stopped because it encountered an internal error. We are sorry
for the inconvenience.

Please contact technical support for assistance with your problem, quoting the
code "-96@30".

Error in miqps_ot (line 281)
intlinprog(c, intcon, Ai, bi, Ae, be, xmin, xmax, ot_opt);

---

After contacting MATLAB, I learnt that this issue is due to the parameter LPPreprocess in the options of initlinprog, which should be set to 'none' (instead of its default value 'basic') in order to avoid the error. I modified it before the call to intlinprog in the file miqps_ot.m, and it worked fine. I had the same issue (with the same error code) when linprog is called. In that case, the parameter to change is Preprocess (from 'basic' to 'none', as for LPPreprocess).

Having not seen previous messages regarding this error, I am wondering whether it is due to the latest version of MATLAB (in the 2016b release, there was indeed a change on the default algorithm in linprog, see https://www.mathworks.com/help/optim/release-notes.html). I would also like to know whether you recommend using the version with the adjusted value of this Preprocess parameter or an older version with the default settings.

I hope this report will be helpful for the maintenance of this code, which I otherwise find very well organized and easy to use.

Thanks,

C. Royer

Newton's method power flow did not converge in simple example

Am I incorrectly setting up the problem? I'm trying to solve this example.

clear all
close all
clc

%% MATPOWER Case Format : Version 2
mpc.version = '2';

%%-----  Power Flow Data  -----%%
%% system MVA base
mpc.baseMVA = 100;

%% bus data
%	bus_i	type	Pd      Qd	Gs	Bs	area	Vm      Va	baseKV	zone	Vmax	Vmin
mpc.bus = [
    1       3       0       0   0   0   1       1.05    0   100     1       1.1     0.9;
    2       1       400     250 0   0   1       0       0   100     1       1.1     0.9;
    3       2       -200    0   0   0   1       1.04    0   100     1       1.1     0.9;
];

%% generator data
%	bus	Pg	Qg	Qmax	Qmin	Vg	mBase	status	Pmax	Pmin	Pc1	Pc2	Qc1min	Qc1max	Qc2min	Qc2max	ramp_agc	ramp_10	ramp_30	ramp_q	apf
mpc.gen = [
    1   0   0   0       0       0   100     1       0       0       0   0   0       0       0       0       0           0       0       0       0;
    3   0   0   0       0       0   100     1       0       0       0   0   0       0       0       0       0           0       0       0       0;
];

%% branch data
%	fbus	tbus	r       x       b	rateA	rateB	rateC	ratio	angle	status	angmin	angmax
mpc.branch = [
    1       2       0.02    0.04    0   0       0       0       0       0       1       -360    360;
    1       3       0.01    0.03    0   0       0       0       0       0       1       -360    360;
    2       3       0.0125  0.025   0   0       0       0       0       0       1       -360    360;
];

%% run pf
mpopt = mpoption('pf.nr.max_it', 100);
results = runpf(mpc, mpopt)

Output from PF analysis:

...
Warning: Matrix is close to singular or badly scaled. Results may be inaccurate. RCOND = -1.000000e+00. 

Newton's method power flow did not converge in 100 iterations.

In addition, is there an easy way to initialize a nonlinear PF with the solution of a linear PF?

some files in matpower6.0.zip can't be found in matpower-master

like yalmip_options

improve slack distribution among multiple gens at slack bus

Currently, when there are multiple generators at the slack bus, MATPOWER's power flow considers the first generator at the bus to be the slack generator, taking up all of the slack. However, I'm not sure if this convention is documented anywhere and it is probably not the behavior intuitively expected by most users.

I propose to update MATPOWER's handling of slack allocation among multiple generators at a slack bus in the following way:

1. If area participation factors (APF column of gen matrix) are provided, split the slack according to the proportions indicated by the relative participation factors.
2. If area participation factors are not provided (i.e. set to 0), the slack will be distributed according to the size of the generator. I.e. for identical generators it will be distributed evenly.

This also needs to be mentioned explicitly in the documentation.

rate B and rate C not included in OPF

Current MatPower version includes only branch rate A for OPF, and there is no automated way to include rate B or rate C even though they are defined in the MatPower case.

add option for makePTDF() to compute (efficiently) for subset of buses

The current makePTDF() function is not suitable for large systems, since it computes sensitivities of flows in all branches with respect to injections at all buses, which is a very large dense matrix.

It would be nice for makePTDF() to allow the user to specify the option to compute the shift factors for a small subset of buses. We could either specify the subset of buses as a bus index vector, or specify an nb x 1 vector (whose elements sum to zero) that specifies a transfer directly.

The method to implement this feature is discussed in this post to MATPOWER-L as well as in this comment in #37.

Volunteers to implement this are welcome! 😉

callback functions need mechanism to distinguish PF vs OPF

Since some extensions (e.g toggle_softlims) are only relevant for OPF problems and not for simple power flow problems, the callbacks need a canonical way to determine the context (PF or OPF) in which they are being called.

Put default tap ratio (=1) to documentation

As one can see in makeYbus.m there is a default tap ratio , used when its value is 0. This appears quite often in case5, case9, case14... (I suppose there are even more examples, but I think three are enough). Whithout knowing about the default bahavior, these cases seem to be very weird, as in many branches (assuming r=x=b=0 for cases of simplicity to show this weird ratio).

There is no hint on this default tap ratio in the documentation. This led me to spend (waste?) time on understanding, why the above mentioned cases actually work.

I'd be thankful if you could add this information to the ducumentation, e.g. in Table B-3: Branch Data. Think this could help others too. Thank you.

DC lines with negative losses

When defining a bidirectional dcline the line losses can be negative (e.g. for Loss0 = 0 and Loss1>0). It feels that a console warning / error / override is appropriate when defining such scenario.

have_fcn('ipopt') with ipopt ver 3.12.7 gives an error because constraints are not arrays

I use OPTI Toolbox for Windows

It seems in have_fcn it's better to use
str = evalc('qps_ipopt([],[1; 1],[1 1],[2],[2],[1; 1],[1; 1],[1; 1],struct(''verbose'', 2))');
instead of
str = evalc('qps_ipopt([],1,1,1,1,1,1,1,struct(''verbose'', 2))');

The first str is
'This is Ipopt version 3.12.7, running with linear solver ma57.

 All variables are fixed and constraint violation 0.000000e+00
    is below tolerance 1.000000e-08. Declaring success.
 
 EXIT: Optimal Solution Found.
 
 ans =
 
      1
      1
 
 '

The second str is
'This is Ipopt version 3.12.7, running with linear solver ma57.

 *** Error using Ipopt Matlab interface: ***
 The constraints must return a real, dense, double precision vector.
 
 Exception of type: IpoptException in file "Unknown File" at line -1:
  Exception message: Unknown Exception caught in Ipopt
 
 ans =
 
      1
 
 '

Problem with runopf

An error occurred while trying to determine whether "opf_model" is a function name.

This is the error message I get while either testing Matpower or running the opf. Have you got any clue what the cause might be?

matpower invalid call to length (psse2mpc)

Can't figure out why the following error is thrown when calling psse2mpc in command line and on test_matpower.

t_psse..................error: Invalid call to length. Correct usage is:

-- length (A)
error: called from
print_usage at line 91 column 5
psse_parse_line at line 65 column 12
t_psse at line 61 column 14
t_run_tests at line 58 column 5
test_matpower at line 128 column 1

Bug: runcpf with full trace and qlims

Here's what i stumbled on:
When a gen exceeds his Qlim in the first iteration, a rollback is initiated and during this rollback the target Lambda (which is Zero in FULL trace mode) triggers the target lamda zero Event.
=> cpf terminates to early

CPF bug when cpf_corrector fails on first iteration

I have found a small bug in the CPF function. Suppose the base case power flow converges but the very first corrector step fails. Then the following happens

1. cpf loop sets cont_steps = 0 and terminates with break
2. callback function is called with k=0 and thus executes initialization instead of final callback loop
3. cpf_results is now missing the field V (and all other fields which are supposed to be set in final callback loop)
4. missing cpf_results.V causes error on line 634 in runcpf:
   n = size(cpf_results.V, 2);

So the reason for this error is that the first parameter taken by the callback functions has two different functions. It is both

1. An indicator what stage the cpf is in, i.e. initialization stage, continuation stage, or final stage
2. A counter for the number of iterations which has been run
   So the possibility of being in the final stage (because the corrector did not converge) in the very first iteration creates problems.

Working example code:

clear;
close all;
define_constants;

mpc = case4gs();

% base case, change bus 4 to PQ, change limits for generator at bus 1
mpc.bus(4,[BUS_TYPE PD QD]) = ...
   [1 -820 238.3673];
mpc.gen(1,GEN_STATUS) = 0;
mpc.gen(2,[QMAX PMAX]) = [1e9 500];

% target case, increase load at bus 3
mpc1 = mpc;
mpc2 = mpc;
mpc2.bus(3,[PD QD]) = 2*mpc.bus(3,[PD QD]);

mpopt = mpoption();
mpopt.cpf.enforce_q_lims = 1;

mpc3 = runcpf(mpc1,mpc2,mpopt);

an improvement suggestion for makeYbus.m

In makeYbus.m, we use the multiplication of the connection matrices and branch admittance matrices to get the node admittance matrices, like this:

Ybus = Cf' * Yf + Ct' * Yt

 In fact, since we have get the lists of "from" buses and "to" buses, we could from the node admittance matrices directly without multiplication, like this

Ybus = sparse([f,f,t,t], [f,t,f,t], [Yff,Yft,Ytf,Ytt], nb, nb)

 If we use the latter to replace the former, the time to form the node admittance matrix could reduce 70%. And the performance of this function could have of lift of 18%, which has been tested  on the forming of the case39.

mpc = case39(); for i=1:100000 makeYbus(mpc); end for i=1:100000 makeYbus_modified(mpc); end

The time consumed are shown in this figure.

The makeYbus_modified.m is
`function [Ybus, Yf, Yt] = makeYbus(baseMVA, bus, branch)
%MAKEYBUS Builds the bus admittance matrix and branch admittance matrices.
% [YBUS, YF, YT] = MAKEYBUS(MPC)
% [YBUS, YF, YT] = MAKEYBUS(BASEMVA, BUS, BRANCH)
%
% Returns the full bus admittance matrix (i.e. for all buses) and the
% matrices YF and YT which, when multiplied by a complex voltage vector,
% yield the vector currents injected into each line from the "from" and
% "to" buses respectively of each line. Does appropriate conversions to p.u.
% Inputs can be a MATPOWER case struct or individual BASEMVA, BUS and
% BRANCH values. Bus numbers must be consecutive beginning at 1
% (i.e. internal ordering).
%
% See also MAKEJAC, MAKESBUS, EXT2INT.

% MATPOWER
% Copyright (c) 1996-2016, Power Systems Engineering Research Center (PSERC)
% by Ray Zimmerman, PSERC Cornell
%
% This file is part of MATPOWER.
% Covered by the 3-clause BSD License (see LICENSE file for details).
% See http://www.pserc.cornell.edu/matpower/ for more info.

%% extract from MPC if necessary
if nargin < 3
mpc = baseMVA;
baseMVA = mpc.baseMVA;
bus = mpc.bus;
branch = mpc.branch;
end

%% constants
nb = size(bus, 1); %% number of buses
nl = size(branch, 1); %% number of lines

%% define named indices into bus, branch matrices
[PQ, PV, REF, NONE, BUS_I, BUS_TYPE, PD, QD, GS, BS, BUS_AREA, VM, ...
VA, BASE_KV, ZONE, VMAX, VMIN, LAM_P, LAM_Q, MU_VMAX, MU_VMIN] = idx_bus;
[F_BUS, T_BUS, BR_R, BR_X, BR_B, RATE_A, RATE_B, RATE_C, ...
TAP, SHIFT, BR_STATUS, PF, QF, PT, QT, MU_SF, MU_ST, ...
ANGMIN, ANGMAX, MU_ANGMIN, MU_ANGMAX] = idx_brch;

%% check that bus numbers are equal to indices to bus (one set of bus numbers)
if any(bus(:, BUS_I) ~= (1:nb)')
error('makeYbus: buses must be numbered consecutively in bus matrix; use ext2int() to convert to internal ordering')
end

%% for each branch, compute the elements of the branch admittance matrix where
%%
%% | If | | Yff Yft | | Vf |
%% | | = | | * | |
%% | It | | Ytf Ytt | | Vt |
%%
stat = branch(:, BR_STATUS); %% ones at in-service branches
Ys = stat ./ (branch(:, BR_R) + 1j * branch(:, BR_X)); %% series admittance
Bc = stat .* branch(:, BR_B); %% line charging susceptance
tap = ones(nl, 1); %% default tap ratio = 1
i = find(branch(:, TAP)); %% indices of non-zero tap ratios
tap(i) = branch(i, TAP); %% assign non-zero tap ratios
tap = tap .* exp(1jpi/180 * branch(:, SHIFT)); %% add phase shifters
Ytt = Ys + 1jBc/2;
Yff = Ytt ./ (tap .* conj(tap)); %
Yft = - Ys ./ conj(tap);
Ytf = - Ys ./ tap;

%% compute shunt admittance
%% if Psh is the real power consumed by the shunt at V = 1.0 p.u.
%% and Qsh is the reactive power injected by the shunt at V = 1.0 p.u.
%% then Psh - j Qsh = V * conj(Ysh * V) = conj(Ysh) = Gs - j Bs,
%% i.e. Ysh = Psh + j Qsh, so ...
Ysh = (bus(:, GS) + 1j * bus(:, BS)) / baseMVA; %% vector of shunt admittances

%% build connection matrices
f = branch(:, F_BUS); %% list of "from" buses
t = branch(:, T_BUS); %% list of "to" buses

%% build Ybus
i = [1:nl; 1:nl]';
Yf = sparse(i, [f; t], [Yff; Yft], nl, nb);
Yt = sparse(i, [f; t], [Ytf; Ytt], nl, nb);
Ybus = sparse([f,f,t,t], [f,t,f,t], [Yff,Yft,Ytf,Ytt], nb, nb) + ... %% branch admittances
sparse(1:nb, 1:nb, Ysh, nb, nb); %% shunt admittance
`
Hope you could adopt this suggestion, and thanks for providing such a powerful instrument!

fatal error in opf_setup with case33bw on older Matlab

Thanks to to Jane Cheung for reporting this on Nov 21, 2018 on the MATPOWER-L mailing list (direct link not currently available to due to issues with the MATPOWER-L archive).

Running runopf('case33bw') results in the following fatal error in Matlab versions prior to R2016b (9.1).

>> runopf('case33bw')
Error using +
Matrix dimensions must agree.

Error in opf_setup (line 212)
    cpg(ip1) = cpg(ip1) + pcost(ip1, COST) * baseMVA;

Error in opf (line 225)
om = opf_setup(mpc, mpopt);

Error in runopf (line 75)
[r, success] = opf(casedata, mpopt);

This appears to be a caused by a bug in Matlab where it throws an error when adding empty matrices if any of the dimensions do not match.

Problems with energy storage in MOST

I was trying to build a 30-bus system with wind energy and storage system base on the seven tutorials provided in MOST. However, it's not working. The storage system started to discharge at the very beginning and kept doing so even though the initial energy level was zero. Or it kept charging regardless of the storage cap. And these problems persisted no matter what values I set to 'InitialStorage' and 'ExpectedTerminalStorageMax/Min'.

Then I tried it in both most_ex6 and most_ex7. The system worked just fine in ex6. All conditions, initial and terminal values, could be changed and met. But when it came to ex7, as long as I left the terminal storage min/max level alone, it worked just fine. The whole charging and discharging process were normal when only the initial energy level was modified. And when I added the terminal level in the system, the same issue happened again.

I'm not sure if it's a bug or I missed something.

Ipopt Hessian incorrect for opf.v_cartesian = 1

According to a report from Juraj Kardoš, the Hessian provided by MATPOWER to Ipopt has both incorrect sparse structure and incorrect numerical values when opf.v_cartesian is true (and only when it is true).

The suggestion was to use Ipopt's derivative checker by including derivative_test second-order in the ipopt.opt file. Details on how to interpret the Ipopt’s derivative checker output can be found here.

Thanks @goghino.

load2disp assumes OPF solution not present in gen matrix

When the load2disp function adds the dispatchable loads it assumes that columns 22-25 do not exist in the input gen matrix:

matpower/lib/load2disp.m

Line 73 in b366a7b

mpc.gen = [mpc.gen; gen]; %% add dispatchable loads

This can cause an error if mpc0 is the solution to an OPF problem.

https://github.com/MATPOWER/matpower/blob/master/lib/idx_gen.m#L84-L89

xgd changes in profile

I have tried to update the CommitKey using a profile. Using example 6, but adding the following profile:
xgd_profile = struct( ...
'type', 'xGenData', ...
'table', 'CommitKey', ...
'rows', 0, ...
'col', 0, ...
'chgtype', CT_REP, ...
'values', [] );
xgd_profile.values = ones(12,1);

Results in the following error:

Operands to the || and && operators must be convertible to logical scalar values.

I believe I fixed it by changing line 190 from ng = dim; to ng = dim(3), since dim is an array of [nt nj_max ng] that is passed from line 575 in loadmd. However since this is such a small change, I wasn't sure whether to go through the pull request process or simply put the issue here.

%MOST_EX6_UC Examples of deterministic unit commitment problems.

% MOST
% Copyright (c) 2015-2016, Power Systems Engineering Research Center (PSERC)
% by Ray Zimmerman, PSERC Cornell
%
% This file is part of MOST.
% Covered by the 3-clause BSD License (see LICENSE file for details).
% See http://www.pserc.cornell.edu/matpower/ for more info.

%% set up options
define_constants;
verbose = 1;
mpopt = mpoption('verbose', verbose);
mpopt = mpoption(mpopt, 'out.gen', 1);
mpopt = mpoption(mpopt, 'model', 'DC');
mpopt = mpoption(mpopt, 'most.solver', 'DEFAULT');
if ~verbose
mpopt = mpoption(mpopt, 'out.all', 0);
end
mpopt = mpoption(mpopt, 'most.price_stage_warn_tol', 1e-5);

%% solver options
if have_fcn('cplex')
%mpopt = mpoption(mpopt, 'cplex.lpmethod', 0); %% automatic
%mpopt = mpoption(mpopt, 'cplex.lpmethod', 1); %% primal simplex
mpopt = mpoption(mpopt, 'cplex.lpmethod', 2); %% dual simplex
%mpopt = mpoption(mpopt, 'cplex.lpmethod', 3); %% network simplex
%mpopt = mpoption(mpopt, 'cplex.lpmethod', 4); %% barrier
mpopt = mpoption(mpopt, 'cplex.opts.mip.tolerances.mipgap', 0);
mpopt = mpoption(mpopt, 'cplex.opts.mip.tolerances.absmipgap', 0);
mpopt = mpoption(mpopt, 'cplex.opts.threads', 2);
end
if have_fcn('glpk')
mpopt = mpoption(mpopt, 'glpk.opts.mipgap', 0);
mpopt = mpoption(mpopt, 'glpk.opts.tolint', 1e-10);
mpopt = mpoption(mpopt, 'glpk.opts.tolobj', 1e-10);
end
if have_fcn('gurobi')
%mpopt = mpoption(mpopt, 'gurobi.method', -1); %% automatic
%mpopt = mpoption(mpopt, 'gurobi.method', 0); %% primal simplex
mpopt = mpoption(mpopt, 'gurobi.method', 1); %% dual simplex
%mpopt = mpoption(mpopt, 'gurobi.method', 2); %% barrier
mpopt = mpoption(mpopt, 'gurobi.threads', 2);
mpopt = mpoption(mpopt, 'gurobi.opts.MIPGap', 0);
mpopt = mpoption(mpopt, 'gurobi.opts.MIPGapAbs', 0);
end
if have_fcn('mosek')
sc = mosek_symbcon;
%mpopt = mpoption(mpopt, 'mosek.lp_alg', sc.MSK_OPTIMIZER_FREE); %% default
%mpopt = mpoption(mpopt, 'mosek.lp_alg', sc.MSK_OPTIMIZER_INTPNT); %% interior point
%mpopt = mpoption(mpopt, 'mosek.lp_alg', sc.MSK_OPTIMIZER_PRIMAL_SIMPLEX); %% primal simplex
mpopt = mpoption(mpopt, 'mosek.lp_alg', sc.MSK_OPTIMIZER_DUAL_SIMPLEX); %% dual simplex
%mpopt = mpoption(mpopt, 'mosek.lp_alg', sc.MSK_OPTIMIZER_FREE_SIMPLEX); %% automatic simplex
%mpopt = mpoption(mpopt, 'mosek.opts.MSK_DPAR_MIO_TOL_X', 0);
mpopt = mpoption(mpopt, 'mosek.opts.MSK_IPAR_MIO_NODE_OPTIMIZER', sc.MSK_OPTIMIZER_DUAL_SIMPLEX);
mpopt = mpoption(mpopt, 'mosek.opts.MSK_IPAR_MIO_ROOT_OPTIMIZER', sc.MSK_OPTIMIZER_DUAL_SIMPLEX);
mpopt = mpoption(mpopt, 'mosek.opts.MSK_DPAR_MIO_TOL_ABS_RELAX_INT', 1e-9);
%mpopt = mpoption(mpopt, 'mosek.opts.MSK_DPAR_MIO_TOL_REL_RELAX_INT', 0);
mpopt = mpoption(mpopt, 'mosek.opts.MSK_DPAR_MIO_TOL_REL_GAP', 0);
mpopt = mpoption(mpopt, 'mosek.opts.MSK_DPAR_MIO_TOL_ABS_GAP', 0);
end
if have_fcn('intlinprog')
%mpopt = mpoption(mpopt, 'linprog.Algorithm', 'interior-point');
%mpopt = mpoption(mpopt, 'linprog.Algorithm', 'active-set');
%mpopt = mpoption(mpopt, 'linprog.Algorithm', 'simplex');
mpopt = mpoption(mpopt, 'linprog.Algorithm', 'dual-simplex');
%mpopt = mpoption(mpopt, 'intlinprog.RootLPAlgorithm', 'primal-simplex');
mpopt = mpoption(mpopt, 'intlinprog.RootLPAlgorithm', 'dual-simplex');
mpopt = mpoption(mpopt, 'intlinprog.TolCon', 1e-9);
mpopt = mpoption(mpopt, 'intlinprog.TolGapAbs', 0);
mpopt = mpoption(mpopt, 'intlinprog.TolGapRel', 0);
mpopt = mpoption(mpopt, 'intlinprog.TolInteger', 1e-6);
%% next line is to work around a bug in intlinprog
% (Technical Support Case #01841662)
% (except actually in this case it triggers it rather than working
% around it, so we comment it out)
%mpopt = mpoption(mpopt, 'intlinprog.LPPreprocess', 'none');
end

casefile = 'ex_case3b';
mpc = loadcase(casefile);
xgd = loadxgendata('ex_xgd_uc', mpc);
[iwind, mpc, xgd] = addwind('ex_wind_uc', mpc, xgd);
xgd_profile = struct( ...
'type', 'xGenData', ...
'table', 'CommitKey', ...
'rows', 0, ...
'col', 0, ...
'chgtype', CT_REP, ...
'values', [] );
xgd_profile.values = ones(12,1);

profiles = getprofiles('ex_wind_profile_d', iwind);
profiles = getprofiles('ex_load_profile', profiles);
profiles = getprofiles(xgd_profile,profiles);
nt = size(profiles(1).values, 1); % number of periods

%%----- Base : No Network -----
mpopt = mpoption(mpopt, 'most.dc_model', 0); % use model with no network
mdi = loadmd(mpc, nt, xgd, [], [], profiles);
mdo = most(mdi, mpopt);
if verbose
ms = most_summary(mdo);
end

update Knitro related docs (Ziena -> Artelys)

Thanks to Richard Waltz for reporting.

Make the following updates to the User's Manual, website, MATPOWER code, etc?

• replace Ziena with Artelys (with link reference www.artelys.com for Artelys)

• The solver name has been officially changed from "KNITRO" to "Artelys Knitro"

• Use www.artelys.com/knitro for link reference to Knitro.

• In the code, change
  Error using opf_execute (line 120)
  opf_execute: MPOPT.opf.ac.solver = 'KNITRO' requires KNITRO (see http://www.ziena.com/)

to

opf_execute: MPOPT.opf.ac.solver = 'KNITRO' requires Artelys Knitro (see http://www.artelys.com/knitro)

and similarly for any other reference to Knitro or Ziena in the code.

Missing Transformer data in the save2psse function

In the save2psse file, in the TRANSFORMER DATA part, two pieces of information are missing, namely, VMA1 and VMI1. Therefore, two columns similar to RMA1 and RMI1 should be added.
The original code is:
fprintf(fd, '%6d, %6d, %d, %d, %d, %d, %d, %d, %d, %d, '' '', %d, %d, %d, %d, %d, %d, %d, %d, %d, '' ''\n%g, %g, %g\n%5g, %d, %5g, %7g, %7g, %7g, %d, %d, %g, %g, %d, %d, %g, %g, %g\n%5g, %g\n', ... [ mpc.branch(it, [F_BUS T_BUS]) zeros(nt, 1) ones(nt, 4) ... zeros(nt, 2) 2*ones(nt, 1) mpc.branch(it, BR_STATUS) ones(nt, 2) ... zeros(nt, 1) ones(nt, 1) zeros(nt, 1) ones(nt, 1) ... zeros(nt, 1) ones(nt, 1) ... mpc.branch(it, [BR_R BR_X]) mpc.baseMVA*ones(nt, 1) ... mpc.branch(it, TAP) zeros(nt, 1) mpc.branch(it, SHIFT) ... mpc.branch(it, [RATE_A RATE_B RATE_C]) zeros(nt, 2) ... 1.1*ones(nt, 1) 0.9*ones(nt, 1) 33*ones(nt, 1) zeros(nt, 4) ... ones(nt, 1) zeros(nt, 1) ... ]');

It seems that it should be as follows:

fprintf(fd, '%6d, %6d, %d, %d, %d, %d, %d, %d, %d, %d, '' '', %d, %d, %d, %d, %d, %d, %d, %d, %d, '' ''\n%g, %g, %g\n%5g, %d, %5g, %7g, %7g, %7g, %d, %d, %g, %d, %g, %g, %d, %d, %g, %g, %g\n%5g, %g\n', ... [ mpc.branch(it, [F_BUS T_BUS]) zeros(nt, 1) ones(nt, 4) ... zeros(nt, 2) 2*ones(nt, 1) mpc.branch(it, BR_STATUS) ones(nt, 2) ... zeros(nt, 1) ones(nt, 1) zeros(nt, 1) ones(nt, 1) ... zeros(nt, 1) ones(nt, 1) ... mpc.branch(it, [BR_R BR_X]) mpc.baseMVA*ones(nt, 1) ... mpc.branch(it, TAP) zeros(nt, 1) mpc.branch(it, SHIFT) ... mpc.branch(it, [RATE_A RATE_B RATE_C]) zeros(nt, 2) ... 1.1*ones(nt, 1) 0.9*ones(nt, 1) 1.1*ones(nt, 1) 0.9*ones(nt, 1) 33*ones(nt, 1) zeros(nt, 4) ... ones(nt, 1) zeros(nt, 1) ... ]');

Please note that an additional 1.1*ones(nt, 1) 0.9*ones(nt, 1) is added to the code (the second line from below).
Thanks.

Multiple branches/transformers between two buses in the save2psse function

In the case of multiple branches/transformers between two buses, CKT should uniquely identify such branches/transformers. However, the current version of the code is using "1" for CKT in all cases and this causes problems while using the RAW file.

After compile the matpower, the IPOPT can not be found

Usually, I use Matlab GUI to run matpower code. Call the IPOPT solver(ipopt.mexa64) to solve the problems, it works perfectly.
However, Recently I need to compile it to be an executable program. I use the Matlab compile toolbox to generate the executable file. When I try to run the program in the cmd window, It comes the error: "Error using opf_execute (line 86) opf_execute: MPOPT.opf.ac.solver = 'IPOPT' requires IPOPT (see http://www.coin-or.org/projects/Ipopt.xml)" i.e. It can not find the IPOPT solver, I did include the IPOPT files in the setpath interface.

I tried a lot about this problem but still can not solve it, does anyone can help me?

make OPF automatically supply missing gencost

If a user tries to run an OPF with a case that does not define the gencost matrix, it would be nice if MATPOWER (warned and) created a default gencost that used equal linear costs to minimize system active power losses.

It would also make sense to add an option opf.objective that would allow the user to request loss minimization instead of using gencost even when it is provided. There may be other "auto-generated" objective options that could be useful as well.

Why the column header is not exactly above the values?

Why the column header is not exactly above the values?

Issue regarding Installation

I tried installing MATPOWER on my computer. After adding it to the path in MATLAB, I typed in test_matpower and I got this error. How do I resolve this issue?

Matlab crash caused by incompatibility between CPLEX & Matlab versions

I really tried hard to solve this issue by myself, and the following is the details.

1. MATLAB crashes when the toolbox from github is used, MATLAB and other toolboxes run normally.

When mpver runs, the result is:

MATPOWER Version 6.1-dev 17-Mar-2017
MATLAB Version 9.1 25-Aug-2016 Release: (R2016b)
Optimization Toolbox Version 7.5 25-Aug-2016 Release: (R2016b)
MIPS Version 1.3-dev 16-Mar-2017
MOST Version 1.0 16-Dec-2016
SDP_PF Version 1.0 17-Jan-2014
YALMIP Version
BPMPD_MEX -- not installed --
CLP -- not installed --

then the crash occurs, the log is recorded in the closed issue

2. Even I delete the items in set path and reuse the zip files from the website, the bug remains.

Thanks a lot!

CPF - issue with PQ/PV conversion with multiple generators at PV bus

I think there is a problem with converting PV buses with multiple generators to PQ buses in the CPF. What happens is that if one generator reaches its QMAX, the bus will be converted to a PQ bus even if there are other generators at the bus that still have more Q capacity.

It happens in the following example using case4gs, where I have added an extra generator to bus 4. In the CPF, in the very first few steps, the QMAX = 167.2 of the new generator is reached, and bus 4 is converted to PQ. However, generator 1 is only at Q =-2.26 MVAr, i.e. not at its q limit.

If instead an ordinary PF with the target case is run, the q limits are handled correctly, and both generators at bus 4 are at their maximum q limits, for a total of 367.8 MVAr.

clear;

define_constants;

% options
mpopt = mpoption();

mpopt.out.all = 1;
mpopt.pf.enforce_q_lims = 1;

mpopt.cpf.enforce_q_lims = 1;
mpopt.cpf.parameterization = 3;
mpopt.adapt_step = 0;
mpopt.step = 0.1;
mpopt.cpf.enforce_v_lims = 0;
mpopt.cpf.enforce_flow_lims = 0;
mpopt.cpf.plot.level = 2;
mpopt.cpf.stop_at = 'FULL';



mpc = case4gs();


mpc.gen(1,[PG QMAX QMIN]) = [300 200 -1e9];
mpc.gen(2,QMAX) = 1e9;

% add extra generator
mpc.gen = [mpc.gen;
    4   200     0   167.8199 -167.8199 1.02 100 1 200 zeros(1,12)
];

mpcb = mpc;
mpct = mpc;
% increase load
mpct.bus(:,[PD QD]) = 2*mpct.bus(:,[PD QD]);

% run cpf
mpcc = runcpf(mpcb,mpct,mpopt);
% run pf
mpc2 = runpf(mpct,mpopt);

Matpower version:

MATPOWER               Version 6.1-dev    23-Aug-2017
MATLAB                 Version 8.6        13-Aug-2015   Release: (R2015b)  
Optimization Toolbox   Version 7.3        13-Aug-2015   Release: (R2015b)  
MIPS                   Version 1.3-dev    16-Mar-2017
MOST                   Version 1.0.1-dev  07-Aug-2017
SDP_PF                 -- not installed --
YALMIP                 -- not installed --
BPMPD_MEX              -- not installed --
CLP                    -- not installed --
CPLEX                  -- not installed --
GLPK                   -- not installed --
Gurobi                 -- not installed --
IPOPT                  -- not installed --
KNITRO                 -- not installed --
MINOPF                 -- not installed --
MOSEK                  -- not installed --
PARDISO                -- not installed --
PDIPMOPF               -- not installed --
SCPDIPMOPF             -- not installed --
SDPT3                  -- not installed --
SeDuMi                 -- not installed --
TRALMOPF               -- not installed --
Architecture:          PCWIN64