Issue 11: How to Improve Numerical Simulation
Computation Performance (1)
Diagnosing Poor Convergence, Interpreting Timestep Logs, and Optimizing Run Settings
This technical brief focuses on how to diagnose poor numerical simulation computation performance, analyze
convergence bottlenecks, and implement targeted recommendations and improvements to accelerate
runtimes.
1. How to Interpret the Timestep Summary Records
In addition to the standard simulation results written to the text output file (*.OUT), STARS dumps real-time
computational logs for each individual timestep. When running a model in the foreground via "Run
Immediately," this stream appears on the screen monitor. When submitting a model to the background via
"Submit to Scheduler," this run summary stream is redirected into the log file (*.log).
The STARS TIME STEP SUMMARY data stream contains six primary operational categories:
1. Time Step Columns: Contains four diagnostic indicators:
◦ No. — The absolute timestep counter.
◦ Size days — The temporal size of the current timestep (increment in days).
◦ IT — The number of Newton-Raphson iterations consumed to reach convergence.
◦ Cut — The number of timestep truncation occurrences (convergence failures forcing a retry).
2. Time: Specifies the exact elapsed simulation time (in days) and the corresponding calendar date (yy/mm/
dd).
3. Production: Reports real-time phase rates for oil, gas, and water (m³/d or dm³/d), alongside the
instantaneous Gas-Oil Ratio (GOR) and Water Cut (Wat. Cut).
4. Injection: Reports instantaneous gas and water injection rates.
5. Mat Bal Err: The instantaneous material balance error metric across the current timestep, expressed as a
raw percentage.
6. Maximum Changes: Displays the maximum absolute local fluctuations in pressure (kPa), phase
saturations (w/o/g), and temperature (deg C) recorded across any single grid block during that step.
2. Deconstructing the Numerical Engine Architecture
A reservoir simulator translates physical sub-surface mechanisms into a discrete, structured mathematical
model. This requires rigorous mathematical solving power coupled with precise thermodynamic and
hydrodynamic flow descriptions. The solver engine achieves this by performing spatio-temporal discretization
—discretizing spatial boundaries via grid architectures and temporal pathways via automated timesteps.
Commercial simulators like STARS contain millions of lines of source code. For engineering applications, it is
essential to understand the three concentric operational layers executed during every single timestep:
CMG Performance Optimization Guide — Issue 11 1
Outer Layer: Timestep Control
Governs overall stability by defining temporal limits and tracking fluid front progression variables. Core
keywords include *DTMAX / *DTWELL (maximum/minimum allowable timestep bounds) and *NORM
(target normal variable variation tolerances per step).
Middle Layer: Newton-Raphson Non-Linear Iteration (Outer Loop)
Linearizes the highly non-linear partial differential flow equations (e.g., Darcy's Law, mass/energy
conservation, boundary constraints). This outer loop strips down derivatives to build massive linear
sparse matrices. Controlled by *NEWTONCYC (maximum Newton iterations permitted before failing)
and *NCUTS (maximum permitted timestep cuts before aborting the run).
Inner Core: Linear Matrix Solver Engine
Executes the core numerical matrix inversions. The speed, memory management, and robustness of
this inner solver dictate overall runtime performance. Standard single-CPU configurations utilize
AIMSOL, whereas parallel high-performance processing executes via Parasol. Key solver control
parameters include:
• *CONVERGE — Solver residual error tolerance thresholds governing variable convergence, well
controls, and material balance equations.
• *ITERMAX — Maximum allowable inner solver iterations.
• *NORTH — Maximum number of orthogonalizations allowed.
• *SDEGREE — Incomplete LU (ILU) matrix factorization degree limit.
• *PRECC — Target linear solver convergence precision limits.
3. How the Timestep Size is Determined
The size of each timestep is adjusted automatically by the simulator engine based on the state of convergence
and several operational variables:
• Maximum Local Variable Fluctuations: The engine tracks the maximum absolute change in grid block
pressure, saturation, and temperature between steps. Rapid, abrupt changes trigger an automatic
reduction in timestep size. For example, opening a well or starting an injector induces massive localized
pressure spikes within the completion block, causing the engine to contract the timestep down to
DTWELL.
Grid Quality Impact: Severe grid block pore volume (PV) contrasts drastically slow down simulation
speeds. If a massive 1000 m³ grid block directly drives fluid into an adjacent 1 m³ block, the fluid flux
triggers extreme, rapid saturation and pressure changes within the tiny pore volume. This forces the
engine to drastically shrink the timestep across the entire model, grinding performance to a halt.
Poorly defined grid arrays or highly irrational physical properties (porosity, permeability, viscosity, or
density) cause identical performance loss.
CMG Performance Optimization Guide — Issue 11 2
• The *DTMAX Constraint: If defined inside the Numerical keyword block, the timestep size is strictly
capped at the *DTMAX limit. This acts as a speed limit on a highway, preventing overshooting in highly
stable, smooth regimes.
• Timestep Cuts (Convergence Failures): If the Newton-Raphson loop fails to find a valid converged
solution within the iteration limit, the engine rejects the step, cuts the timestep size in half (CUT), and
retries the calculation. Successive convergence failures result in extremely small timesteps and prolonged
runtimes.
4. Diagnostic Checklist for Small Timestep Bottlenecks
Case 1: Small Timesteps Occurring Without Cuts (The *NORM Constraint)
If timesteps remain very small but the log shows zero CUT occurrences, the step size is likely throttled by the
normal change per timestep keyword (*NORM). This optional keyword sets the target maximum change
allowed for fundamental variables during any single step:
*NORM { *PRESS x | *SATUR x | *TEMP x | *Y x | *X x | *W x | *FLUIDH x | *ZO x | *ZNCG x | *ZAQ
Example: *NORM *PRESS 145.0 *SATUR 0.08 constrains the maximum pressure variance to 145.0 kPa and
saturation variance to 0.08 per step. If the actual grid changes approach these boundaries, the simulator pre-
emptively limits the next timestep size. If the model is completely stable and experiencing zero cuts, slightly
increasing the default *NORM limits can safely expand the timestep size and accelerate the run.
Case 2: Resolving Frequent Timestep Cuts
When frequent CUT events occur, the step size drops exponentially (scaled down by 1/2, then 1/3, etc.). In
these cases, you must **decrease** the *NORM values. This forces the model to take smaller, more stable
steps from the start, preventing the solver from overshooting and triggering expensive non-linear failures.
Additionally, check for underlying grid flaws such as highly irregular pore volume distributions.
Case 3: Unnecessary Well Constraint Throttling (*DTWELL)
Unless managing complex localized chemical reactions or extreme physical transitions, avoid setting an
excessively low *DTWELL value. Recovering and accelerating back to a normal timestep size from a very low
well-initiation timestep requires many intermediate steps. STARS implements a default acceleration multiplier
factor of approximately 2.3x per step. Keeping *DTWELL reasonable allows the simulator to ramp back up to
optimal execution speeds much faster.
Case 4: Misconfigured Maximum Step Speed Caps (*DTMAX)
Only implement *DTMAX constraints when strictly necessary to capture specific transient behaviors or well
management schedules. Artificially limiting the speed during a highly stable simulation window limits
performance. If a stable model can safely run at larger steps, do not force it to take smaller increments, as this
directly delays the time required to complete the study.
CMG Performance Optimization Guide — Issue 11 3
Note: Next-tier performance solutions addressing material balance errors, linear solver iteration tuning,
and techniques for auditing the `.OUT` numerical tables will be thoroughly mapped in the subsequent
optimization brief.
CMG Technical Support Division
CMG Performance Optimization Guide — Issue 11 4