Energy
/ Industries

Energy

Boost efficiency across the energy sector with computational methods — from wind farms and oil reservoirs to solar thermal and hydrogen fuel cells.

The energy sector is undergoing simultaneous pressure from two directions: reducing the cost of renewable energy generation and maximizing recovery from existing hydrocarbon assets. High-performance computing addresses both. Wind turbine aerodynamics, subsurface reservoir simulation, solar thermal optimization, and hydrogen fuel cell design all require simulation fidelity that exceeds what a single workstation can provide. For utility-scale projects — a 500 MW offshore wind farm, a fractured shale reservoir with thousands of wells, a multi-gigawatt solar installation — computational methods are the only way to evaluate design alternatives at the scale and speed that development timelines and capital allocation decisions demand.

Key Workloads

Energy simulation spans geophysical, fluid mechanical, and electrochemical physics domains, each with distinct software requirements and cluster profiles.

Software Stack and HPC Requirements

SoftwareWorkload TypeParallel ScalingGPU SupportTypical Core Count
OpenFOAMWind turbine CFD, thermal, generalExcellentLimited (v10+)32–2,048
ANSYS FluentCFD — turbine rotor, solar thermalExcellentYes64–2,048
OpenFASTAero-hydro-servo-elastic wind turbineGoodNo8–64 (per turbine)
Eclipse (SLB)Reservoir simulation — black oil, compositionalGoodNo32–512
CMG IMEX/GEMReservoir simulation — EOS compositionalGoodNo32–256
TOUGH2 / TOUGH+Geothermal, CO₂ storage, subsurface flowModerateNo16–128
COMSOL MultiphysicsFuel cell, electrochemical, coupledGoodNo16–128
ANSYS MechanicalStructural — turbine tower, foundationGoodNo32–256
SeisSpace / PetrelSeismic processing and interpretationVery goodYes (GPU)64–1,024

Seismic processing is the most GPU-accelerated workload in energy computing. Reverse-time migration (RTM) and full-waveform inversion (FWI) on 3D seismic datasets are embarrassingly parallel across shot gathers and benefit substantially from GPU acceleration — a GPU node with 4× A100 or H100 cards can replace 32–64 CPU cores for these specific algorithms.

Application Areas

Wind Energy

Wind energy CFD spans three distinct scales, each with different computational requirements:

Turbine rotor aerodynamics: Blade element momentum (BEM) methods are fast but insufficient for complex flow regimes — deep stall, tower shadow interaction, yawed inflow. High-fidelity CFD of a single rotor using OpenFOAM or Fluent with rotating reference frame or sliding mesh requires 10–80 million cells and 64–512 cores per run. LES of rotor wake turbulence — necessary for accurate wake deficit characterization — is substantially more expensive and can require 256–2,048 cores running for 24–72 hours per operating point.

Aero-hydro-servo-elastic analysis with OpenFAST (the NREL open-source platform) couples aerodynamic loads, structural dynamics, control systems, and for offshore turbines, hydrodynamic loading. Individual OpenFAST runs are not massively parallel, but uncertainty quantification studies (UQ) and fatigue load case evaluations require running thousands of stochastic cases — which is a throughput problem that SLURM array jobs and a well-sized cluster solve efficiently.

Wind farm layout optimization and wake modeling: Optimizing turbine positions within a wind farm to minimize wake losses requires evaluating hundreds to thousands of layout configurations. Engineering wake models (FLORIS, PyWake) are computationally light but must be calibrated against high-fidelity CFD data. The calibration CFD — full wind farm LES with realistic atmospheric boundary layer inflow — is one of the most computationally demanding workloads in the sector, potentially requiring 1,024–8,192 cores and weeks of compute time for large offshore arrays.

Wind turbine tower and foundation structural analysis (fatigue under turbulent load spectra, buckling under extreme events) uses ANSYS Mechanical or Abaqus on models that scale with tower height and monopile complexity. Offshore jacket structures with fatigue damage equivalent load (DEL) accumulation require spectral analysis over thousands of sea states.

Oil & Gas: Reservoir Simulation and Seismic Processing

Reservoir simulation with Eclipse (SLB) or CMG predicts hydrocarbon production over field development lifetimes — decades of reservoir behavior compressed into hours of compute time. Black oil models for conventional reservoirs may run on 32–128 cores. Compositional EOS models for gas condensate or EOR (enhanced oil recovery) scenarios — CO₂ injection, surfactant flooding — add thermodynamic flash calculations at every cell and timestep that substantially increase compute cost. Naturally fractured reservoirs with dual-porosity or discrete fracture network (DFN) models can require 256–512 cores for field-scale history matching.

History matching — calibrating reservoir models to production data — is an inverse problem typically addressed with ensemble methods (EnKF, ES-MDA) or derivative-free optimization. These approaches require running 100–1,000 forward simulation instances, making cluster throughput and job scheduling efficiency critical. A history-matching workflow that runs on a 512-core cluster can compress weeks of sequential simulation into a single business day.

Seismic data processing for exploration and reservoir characterization is GPU-dominated. Prestack depth migration (PSDM), reverse-time migration (RTM), and full-waveform inversion (FWI) on modern 3D wide-azimuth datasets involve petabytes of input data and GPU-accelerated compute kernels that deliver 10–50× speedup over CPU equivalents. Fast NVMe storage — capable of sustaining 10–50 GB/s of read throughput during migration — is as important as GPU core count.

CO₂ geological storage simulation with TOUGH2 or Eclipse predicts plume migration, caprock integrity, and injection pressure evolution over decades. These workloads are reservoir simulation in character, with added geomechanical coupling (rock deformation under CO₂ injection pressure) that requires iterative coupling between flow and structural solvers.

Solar and Hydrogen

Solar thermal analysis for concentrated solar power (CSP) receivers and parabolic trough heat transfer fluid systems uses conjugate heat transfer CFD. Receiver tube simulation with non-uniform solar flux boundary conditions (derived from ray-tracing of the heliostat field) runs on 16–64 cores per tube section. Full-collector or full-receiver arrays scale to 128–512 cores. For photovoltaic installations, inverter and power electronics thermal management simulation mirrors the automotive electronics cooling workload in character and scale.

Hydrogen fuel cell simulation is a multiphysics problem: mass transport of hydrogen and oxygen through gas diffusion layers (GDL), electrochemical reactions at catalyst layers, membrane proton transport, and water management in two-phase flow mode. COMSOL Multiphysics is widely used for cell and stack-level simulation. Individual cell models run on 8–32 cores; stack-level or system-level models require 64–256 cores and high-memory nodes. Electrolyzer optimization — alkaline or PEM electrolysis for green hydrogen production — involves similar multiphysics coupling and comparable HPC requirements.

Typical HPC Configuration

Energy HPC Cluster — Reference Architecture
├── Login / Pre-/Post-Processing Nodes (2×)
│   └── Dual EPYC 9354, 256 GB DDR5
│       → Petrel, ResInsight, ParaView visualization
├── CFD / Reservoir Compute Nodes (32–96 units)
│   └── Dual AMD EPYC 9654 (192 cores/node), 512 GB DDR5
│       → OpenFOAM, Fluent, Eclipse, CMG
│       → InfiniBand HDR200 per node
├── GPU Nodes (8–32 units)
│   └── 4× NVIDIA A100 or H100 SXM5 per node
│       → Seismic RTM/FWI, ANSYS Fluent GPU solver
│       → NVLink interconnect for large GPU memory models
├── High-Memory Nodes (2–4 units)
│   └── Large-memory EPYC configuration: 1–2 TB DDR5
│       → CMG compositional EOS with large property tables
│       → Coupled geomechanical reservoir models
└── Parallel Storage
    └── Lustre on NVMe (hot tier, 50–200 TB)
        BeeGFS on SAS (warm tier, 500 TB–2 PB)
        Aggregate NVMe read bandwidth: 20–100 GB/s
        → Critical for seismic I/O throughput

Network: InfiniBand NDR400, fat-tree topology
Scheduler: SLURM with GPU and CPU partition separation
Monitoring: Grafana + Prometheus for job and storage telemetry

Mevasis Energy HPC Services

Mevasis supports energy companies, research institutions, and engineering consultants across the full spectrum of energy simulation — from offshore wind development to reservoir management and hydrogen technology.

  • Workload profiling and sizing: Assess your current Eclipse, OpenFOAM, or seismic processing jobs for hardware sizing accuracy — accounting for parallel scaling efficiency, I/O patterns, and peak demand seasonality
  • Turnkey cluster installation: Hardware procurement, InfiniBand and storage design, SLURM configuration, GPU driver and CUDA environment setup, commercial solver license server deployment
  • Seismic processing infrastructure: GPU cluster design optimized for RTM/FWI I/O patterns, fast scratch storage, and checkpoint/restart workflows for long-running inversion jobs
  • Reservoir simulation tuning: Eclipse and CMG parallelism configuration, memory-mapped I/O settings, MPI process placement for compositional models
  • HPC Rental: Burst capacity for exploration campaigns, wind farm design phases, or reservoir history-matching projects — without long-term capital commitment
  • HPC Consulting: Ongoing cluster performance monitoring, job scheduling optimization, storage capacity planning, and solver performance benchmarking

Frequently Asked Questions

How many cores does Eclipse reservoir simulation require? It depends on grid size, fluid model complexity, and time-stepping. A black oil model with 1–5 million active cells typically parallelizes well on 32–128 cores. Compositional EOS models with the same cell count require 2–4× more compute per timestep due to flash calculations and scale to similar core counts. History-matching workflows that run 100–500 ensemble members benefit most from clusters with high job throughput — 512–2,000 total cores running many simultaneous instances — rather than high per-job core count.

What GPU hardware is best for seismic processing? For RTM and FWI workloads, high-memory GPUs are critical: a 3D wide-azimuth dataset can require 40–80 GB of GPU memory per process for intermediate wavefield storage. NVIDIA A100 (80 GB HBM2e) and H100 (80 GB HBM3) are the current production standard. NVLink within a multi-GPU node allows wavefield data sharing across GPU memory, enabling larger model patches per node. Fast NVMe scratch — capable of 20–50 GB/s sustained reads — is equally important; GPU cores sit idle waiting on I/O in storage-bottlenecked configurations.

Can OpenFOAM run effectively on a cost-optimized cluster without InfiniBand? For single-node or small core counts (up to 32 cores on one node), high-speed Ethernet (25 GbE or 100 GbE) is adequate. For multi-node OpenFOAM runs above 64 cores — particularly LES of wind farm wakes or time-accurate turbine rotor simulations — InfiniBand is strongly recommended. MPI halo exchange in OpenFOAM at 256+ cores on a 100 GbE network introduces latency overhead that typically adds 20–40% to wall-clock time compared to InfiniBand HDR. For sustained wind energy simulation programs, the InfiniBand capital cost is recovered within months through reduced compute time.

How is data managed for multi-year reservoir simulation projects? Reservoir simulation projects generate model files, restart files, and production output that accumulate over years. A tiered storage approach — fast NVMe scratch for active simulations, high-capacity SAS or object storage for completed runs and model archives — is the standard approach. Mevasis designs storage policies with automated data lifecycle management: active job data on NVMe, recent results on SAS, archival data on tape or object storage — matched to your retrieval frequency and budget constraints.

← All Industries