Optimizing Performance

Background

Before discussing performance, it is useful to understand the structure of the PLEXOS simulation engine. This is illustrated here.

The engine separates the 'business logic' from the mathematical programming. The Simulation Core contains all the logic to model a power system, whereas the AMMO component deals entirely with mathematical objects, and integrates tightly with the solver(s)(see below).

The total simulation time is thus a combination of the time spent in the simulation logic plus the time spent in the mathematical solver. In general the solver accounts for between 60 - 99% of the total simulation time. With the Performance Summary diagnostic switched on, the simulation and solver performance is summarized at the end of each simulation phase in the log file as in the following example:

----------------------------------------------------------------------------
 Component                                     Time (sec.)       Contrib. (%)
 ----------------------------------------------------------------------------
   Setup.....................................     0:00:04.629          2.92 %
   Modify....................................     0:00:04.375          2.76 %
   Solver:...................................     0:02:25.767         91.83 %
 ----------------------------------------------------------------------------
    - Interior Point.........................     0:00:00.474          0.33 %
    - Dual Simplex...........................     0:00:07.280          4.99 %
    - MIP....................................     0:02:18.012         94.68 %
 ----------------------------------------------------------------------------
   Solution..................................     0:00:02.838          1.79 %
   Write.....................................     0:00:00.112          0.07 %
   Other.....................................     0:00:01.010          0.64 %
 ----------------------------------------------------------------------------
   Peak Memory...............................                       307.42 MB
   Current Memory............................                       251.69 MB
 ----------------------------------------------------------------------------

In this example the time in the solver was nearly 92% of the overall simulation time. The other items in this report refer to:

• Setup: time spent creating the mathematical programming formulation
• Modify: time spent updating the formulation between simulation steps or samples
• Monitor: Time spent checking and enforcing constraints that are 'monitored' rather than being loaded 'upfront'
• Solution: Time spent calculating solution properties
• Write: Time spent writing solution data to the solution database

Solver and Settings

The AMMO component of PLEXOS supports several solvers. See Performance Solver for details.

It is not easy to predict with certainty solver performs 'best', because the solvers all perform differently depending on the size, type, and complexity of the problem, and the solvers are subject to continuous improvement from version to version. Thus it is best to test the available alternatives and chose the solver that performs best on your problems.

A range of solver-related options are available via the Performance object as shown in the following figure.

The default solver settings will perform best on the majority of problems. You should only change these settings with the help and advice of your support representative.

As a general guide however, the following are some occasions where you might need to change the default settings:

1. You are running a very large number of small optimization problems in parallel. For example you might be running 100s or 1000s of Monte Carlo simulations where each simulation is relatively small and Stochastic Method = "Parallel". In this case it can be an advantage to run Dual Simplex only and avoid the overhead of the Concurrent solver. Try setting the Small LP Nonzero Count parameter to a value larger than the number of non-zeros in your problem and the Small LP Optimizer to "Dual Simplex". Alternatively set LP Threads = 1 which will force the use of Simplex.
2. For mixed integer programming problems the default gap of 0.01% can be adjusted to improve speed at potential cost of accuracy. See Performance MIP Relative Gap for details. It is common to run gaps between 0.05 - 0.1% however you should check your case for the appropriateness of these settings.

Customizing Solver Parameters

Even though popular linear programming solution methods like simplex or Barrier (Interior) are developed, tested and documented for a wide variety of optimization problems, these methods can show significant performance differences depending on the selection of (many) configuration parameters. When it comes to MIP, non-polynomial execution times are expected for NP-hard problems like the Unit Commitment problem. Solver developers may offer a series of default values. Most relevant, like algorithm selection, target MIP gap and Max Execution time can be configured using PLEXOS Performance objects (as screens above). Excluding some few exceptions, PLEXOS doesn't change the default settings for many other configuration parameters available in most of the commercial solvers. If the user desires to extend the configuration parameters available in the Performance object, he/she can use a special performance configuration xml file. It is strongly recommended some experience before changing the default settings as they can seriously affect performance. The structure of the XML is shown below. An xml syntax example is also included above.

1. Create an XML file called: PLEXOS_SolverParam.xml. This exact name is mandatory.
2. Fill the xml fields specifying the following mandatory tags:
   1. ParameterNames: Parameter name (string) as in the solvers parameter list.
   2. Type: Type of configuration parameter (e.g. Double, Integer)
   3. Value: Parameter new value (be careful to introduce allowed values!)
3. Save file in the same location as the input database. This file is optional. DO NOT copy it in the PLEXOS installation folder.

Each solver has it's own set of parameter and intrinsic nomenclature, so it is recommended to visit the solver's webpage before creating your own performance file.

XML Advanced Custom Solver Performance File Example

The following xml code shows how to activate solution polisher after 1000secs in CPLEX (disabled by default).

                 
 <?xml version="1.0" standalone="yes"?>
 <SolverParam xmlns="http://tempuri.org/SolverParam.xsd">
  <CPLEX>
    <ParameterName> CPX_PARAM_POLISHAFTERTIME </ParameterName>
    <Type>Double</Type>
    <Value>1000.0</Value>
  </CPLEX>
 </SolverParam>
                

Reducing Memory Consumption

Large-scale PLEXOS problems can consume significant quantities of Random Access Memory (RAM). Some solver parametes can reduce peak memory consumption, generally at the cost of increased runtimes. This tradeoff may be desirable through reducing the size (and therefore cost) of virtual machines (VMs) necessary to run frequency simulations in PLEXOS Cloud or Connect.

Some parameters which can vary the memory/runtime computational envelope include:

• Performance Maximum LP Threads
• Performance Maximum MIP Threads
• Gurobi barrier ordering algorithm (BarOrder). Both Approximate Minimum Degree ordering (0) or Nested Dissection ordering (1) can be specified. In some large models explicitly choosing the former reduced peak memory consumption by 50% at a cost of 30% additional runtime. Example PLEXOS_SolverParam.xml:

  <?xml version="1.0" encoding="utf-8"?>
  <SolverParam xmlns="http://tempuri.org/SolverParam.xsd">
    <Gurobi>
      <ParameterName>BarOrder</ParameterName>
      <Type>Integer</Type>
      <Value>0</Value>
    </Gurobi>
  </SolverParam>
                  

  Note that this parameter only applies when using Gurobi with a barrier algorithm.
• Gurobi maximum barrier ordering threads. Limiting the number of threads available to Gurobi's ordering algorithm can also significantly reduce peak memory consumption. In one model appropriate ordering thread limiting reduced peak memory by 40% while increasing rntime by less than 15%. Note that this must be passed as a String-type parameter to Gurobi. To limit to 4 threads for example:

  <?xml version="1.0" encoding="utf-8"?>
  <SolverParam xmlns="http://tempuri.org/SolverParam.xsd">
    <Gurobi>
      <ParameterName>GURO_PAR_BARMAXORDERTHREADS</ParameterName>
      <Type>String</Type>
      <Value>4</Value>
    </Gurobi>
  </SolverParam>
                  

  This parameter is also only applicable to the Gurobi solver and in conjunction with a barrier algorithm.