Cloud-Scale Reservoir Modeling Brings Subsurface Uncertainty into the Engineering Workflow

Reservoir decisions are made against an incomplete picture of what lies underground. A single simulation captures one interpretation of a reservoir, but actual geology can support many plausible models—and those alternatives can lead to different forecasts, drilling plans, and investment outcomes. SLB’s generally available Agile Reservoir Modeling (ARM), integrated with Microsoft Azure Data Manager for Energy (ADME), is designed to make large-scale ensemble analysis a repeatable cloud workflow rather than a specialized infrastructure project.

The development matters because reservoir teams have traditionally faced a mismatch between the value of uncertainty analysis and the resources available to perform it. Evaluating hundreds of model realizations requires substantial compute, storage, data movement, and operational coordination. ARM on Azure combines an ensemble workflow engine with governed subsurface data services and elastic high-performance computing, giving organizations a way to increase study scale without relying solely on fixed, on-premises capacity.

From one reservoir model to an ensemble

A conventional reservoir model represents one plausible view of subsurface structure and behavior. Ensemble modeling evaluates many realizations, varying uncertain properties and assumptions to reveal how those differences affect simulated outcomes. Instead of treating a single forecast as definitive, asset teams can examine a range of results, identify influential uncertainties, and assess whether a development decision remains robust across plausible scenarios.

The computational challenge grows with the ensemble. Each realization may require model preparation, simulation, intermediate files, and result management. Running cases sequentially can extend study timelines, while launching many jobs on fixed infrastructure can overwhelm compute queues, shared storage, or both. The cloud architecture behind ARM is intended to distribute realization generation and simulation across Azure high-performance computing resources, with scalable storage supporting concurrent access by simulation workloads.

A connected data and compute architecture

The integrated workflow assigns distinct roles to the participating systems. Azure Data Manager for Energy provides the governed data foundation, with services aligned to the OSDU Technical Standard and domain data management capabilities for subsurface information such as seismic, wellbore, interpretation, and simulation data. Petrel subsurface software is used to define interpretation and uncertainty workflows and connect engineering work to data managed in ADME. ARM orchestrates the generation of realizations, preparation of supported simulation cases, and execution of ensemble studies.

In a typical flow, reservoir engineers define uncertainty workflows in Petrel and prepare simulation models for supported SLB simulators, including Intersect and Eclipse. ARM coordinates case creation and dispatches simulation runs to Azure HPC. A shared Azure Files volume holds inputs, grids, simulation decks, temporary files, and results, allowing multiple compute workers to read and write data concurrently. This shared-storage pattern reduces the need to shuttle files between isolated project environments, although storage throughput and IOPS still need to be sized for the intended job concurrency.

Compute and storage can be adjusted as separate capacity dimensions. An organization can provision more simulation workers when a study needs to finish quickly, then reduce capacity after the peak workload. Storage capacity, throughput, and performance can likewise be selected to match the volume and access patterns of the ensemble. This flexibility is useful, but it does not eliminate architecture planning: poorly matched storage performance, network limits, or excessive parallelism can create bottlenecks even when compute capacity is available.

When runs finish, reservoir engineering services manage the ensemble outputs. ADME search capabilities support discovery, filtering, and sorting across studies, helping engineers find relevant realizations and published results without manually browsing disconnected stores. Teams can analyze results in the reservoir engineering workspace or return them to Petrel for further interpretation, history matching, and related engineering work. Results can also be published to the governed data foundation, supporting reuse by other teams.

Governance is part of the workflow

Scaling simulation across cloud infrastructure also expands the importance of identity, access control, and data handling. ADME integrates entitlement-based access control with Microsoft Entra ID and supports compliance mechanisms such as OSDU legal tags. Linking modeling workflows to these controls can help organizations apply consistent access policies to corporate subsurface data as it is used across applications and teams.

For IT and data leaders, this is more than a way to launch additional simulation jobs. It offers a path to connect engineering applications with a governed, searchable data environment and reduce dependence on unmanaged copies of project data. Organizations should still validate how identity groups, data entitlements, retention requirements, and publication workflows map to existing policies. Cloud adoption does not automatically resolve inconsistent data definitions or legacy access practices.

Operational implications for engineering teams

For reservoir engineers, the main change is that ensemble studies can become part of the regular decision process rather than a bespoke exercise requiring separate orchestration and infrastructure setup. Teams can compare development concepts against calibrated realizations that reflect production history, and incorporate new well or operational data as it becomes available. That can support more frequent updates to reservoir understanding instead of waiting for a major model rebuild.

For platform and infrastructure teams, the workflow introduces cloud capacity planning, job orchestration, storage-performance monitoring, and cost controls as operational responsibilities. Parallel simulations can shorten elapsed study time, but they may also increase peak consumption. Teams should establish budgets or workload limits, monitor compute and storage usage, and test representative ensembles before committing to production-scale concurrency. They should also define how failed runs are retried, how temporary data is cleaned up, and how simulation outputs are versioned and retained.

Integration is another practical consideration. The described workflow is centered on Petrel and supported SLB simulators, so organizations should map existing application versions, licensing, data formats, and engineering procedures before migration. A pilot focused on one asset or decision workflow can expose data-quality gaps and performance constraints while giving teams a basis for estimating cost and operational effort. The goal should be to improve decision quality and turnaround time, not simply to maximize the number of simulations.

Where the approach can be useful

Cloud-scale ensemble modeling is relevant when uncertainty materially affects drilling or development choices. An asset team might compare alternative well placements, production strategies, or development concepts across realizations, then identify options that perform acceptably under a wide range of assumptions. It can also help teams assess the consequences of new measurements, update forecasts as field data changes, and prioritize additional data acquisition when uncertainty is driving a consequential decision.

Organizations with distributed subsurface teams can benefit from publishing results to a shared, governed foundation, where other authorized users can discover and reuse them. This is particularly valuable when separate teams have historically maintained their own datasets and simulation outputs. Reuse depends, however, on consistent metadata, clear model provenance, and documented assumptions; a searchable result is not automatically a comparable or trustworthy result.

A step toward more continuous reservoir workflows

The integration reflects a broader move toward cloud-native technical computing: connect domain applications to governed data services, scale compute for demanding workloads, and make outputs discoverable across the organization. Continued work within the OSDU community on standardizing reservoir data and workflows could improve interoperability among applications and reduce reliance on proprietary formats. More consistent data access could also create a stronger foundation for analytics and AI-assisted discovery, though reliable automation will depend on well-governed data and transparent engineering validation.

For now, ARM on Azure Data Manager for Energy offers a practical architecture for organizations seeking to scale reservoir uncertainty studies while keeping modeling, simulation, and data governance connected. The most effective adoption path is likely to begin with a defined engineering decision, a representative ensemble, and explicit measures for turnaround time, cost, data reuse, and decision impact. That approach helps teams determine whether cloud-scale modeling improves the quality and timeliness of decisions—not just the size of the simulation run.