Use Threading in Logic
This option will allow the application to utilize multiple processors on a single workstation.
NOTE: Speed improvements may not be seen with threading turned on if there are other significant processes taking place on the machine while Aurora is running. If the Use threading in logic option is selected, the user may want to turn off hyper-threading in the computer BIOS (when applicable). Hyper-threading adds some overhead and may degrade performance. To ensure the best run times the user should test with and without hyper-threading enabled.
NOTE: On computers with a non-uniform memory access (NUMA) architecture, Aurora will only run threads on a single NUMA node. However, a separate Aurora process can be run on each NUMA node using the start command with the /Node command line switch.
Parallelize the Run Across Years
NOTE: The Parallelize option is not available for use with nodal studies.
Additionally, the Parallelize the Run Across Years setting divides up the different years of the study period and solves the chronological dispatch for all specified hours in a year in parallel with those of all other years. Each of these parallel processes more fully utilizes the cores on the machine and results in drastic reductions in run times, especially for zonal studies that span multiple years.
The Maximum Concurrent Solves setting is used to determine how many different solves to run in parallel at the same time, and the Years Per Thread parameter determines how many years to run in each thread. Both of these options can be dynamically determined by Aurora based on the number of processors and the total memory on the machine.
The use of this setting gives the fastest results when there is not a significant amount of output that needs to be written with the run; and as such, it is particularly beneficial in long-term simulations which generally do not write very much output until the final LT iteration. The amount of runtime reduction will vary depending on system size, constraints, and computer memory availability, but in many instances LT studies with this setting employed will be more than twice as fast as ones without it.
The Dynamically Limit Solver Threading option will update the number of threads that the solver (Gurobi or Mosek) can use based on how many concurrent parallel runs are taking place. When doing commitment optimization runs with multiple years run in parallel selecting this setting can improve performance by limiting how many threads each instance can use.
NOTE: Results will not always be exactly reproducible with the Dynamically Limit Solver Threading switch because solver settings are changed dynamically throughout the simulation based on the current number of parallel runs.
Use Threading in Logic
