RESQML Version 1.1 specifications
|
Standard
|
Browsable
|
Files
|
|
Data Schema Specifications
|
|
|
NOTE: Version 1.1 is intended for commercial implementation. v1.0 was a development version and has been removed from the website. If v1.0 schema or guides are needed, please contact standards@energistics.org.
resqml documentation
RESQML v1.1 Business Overview
RESQML v1.1 Use Case Guide
RESQML v1.1 Technical Usage Guide
NOTE: The above guides will continue to evolve as additional information and examples are contributed.
HDF5
RESQML v1.0 includes use of a standard binary file format called HDF5 for transmission of large amounts of data. This standard is developed and maintained by HDF Group.
HDF5 may be downloaded from HDF Group.
Use of HDF5 for RESQML is authorized by HDF Group under their license agreement.
Any comments and concerns re: HDF5 and how it is used specifically for RESQML should be directed to Energistics.
version 1.1 main features
RESQML is designed to enable seamless transfer of geophysical, geological, and engineering structural data among the many software applications used in the reservoir modeling and simulation workflow.
RESQML is the successor of RESCUE, the reservoir modeling data exchange standard used since the mid-1990s. RESQML uses newer technologies, data structures, and other standards to address limitations of RESCUE and to provide a modern, robust, yet flexible solution with the potential to expand the capabilities of data exchange along the entire reservoir modeling and simulation workflow.
Many of the companies and people currently developing RESQML were also involved with RESCUE.
Version 1.1 includes the capabilities noted below that were available in v1.0 with updates based on continued testing. Schema changes are noted in the change history and supporting documentation was updated accordingly.
· XML. The primary transfer document is XML.
The RESQML XML schemas are based on the design patterns, common types, and reference data from the previously published Energistics-stewarded standards, WITSML (Well Information Transfer Markup Language, for drilling and completions data) and PRODML (Production Markup Language). Leveraging these existing standards and schemas allows integration of a rich set of data objects for cross-domain workflows and makes it possible for RESQML to adopt the WITSML version of well data (such as logs, directional surveys, formation markers, etc.), instead of developing new ones.
· HDF. Additionally, to handle multi-million cell models, the XML file can optionally reference an auxiliary Hierarchical Data Format Version 5 (HDF5) file, where geometry and properties can be stored.
Benefits of HDF5. HDF5 is an open file format with libraries designed to store and organize large amounts of numerical data, and improve speed and efficiency of data processing. Specifically, it provides: machine/architecture-independent "binary" format (supported on Windows, Linux, etc. APIs available in C, C++, Java, etc); hyper-slabbing of array data so that IJK sub-arrays may be extracted from the RESQML document without reading the entire data file; and built-in data compression.
· Traceability. Implementation of global unique identifiers (GUID) and use of Dublin Core elements for documents and objects within documents provides traceability of creation and updates of documents and objects for users, software used, and time/date stamp.
· Coordinate Reference System (CRS). Use of a global CRS allows models to be accurately located on the Earth. (The CRS is specified using Geographic Markup Language (GML), which includes EPSG codes to identify coordinates for specific, well known global locations). Each geometric representation is specified with respect to a local CRS, which is embedded in the global CRS (with optional rotation, translation and change of units of measure). A Local CRS vertical axis may represent depth (always increases downward, thereby removing the ambiguity that occurred in RESCUE, which permitted depth or elevation) or it can represent time (a frequent user request for RESCUE).
· Grids. The grid itself is now a completely general corner point grid with each cell described by its eight cell nodes and each node, by default, lying on a coordinate line.
- A new indicator clearly shows whether the cell geometry is defined for a cell (addressing a known ambiguity issue in RESCUE).
- Topological indicators are supplied with the grid, not just a geometric description, thereby removing ambiguities in the interpretation of the internal adjacency of a model.
- The grid index origin is preserved and cannot be swapped, thereby preserving the connection to reservoir simulation data, which is often index-based but otherwise not included within a RESQML document.
- For unfaulted grids, each node is described only once but shared among 8 cells.
- Coordinate lines need not be straight and need not be monotonic functions of depth. Additional coordinate line node lists are used on faults to describe fault throw. Additional nodes may also be described individually, e.g., to allow for the description of stair-step faults without forcing the introduction of additional coordinate line node lists.
- Indicators in the grid header are used to indicate the complexity of a grid, so that the reading software knows how complex the grid is without a cell-by-cell analysis of the grid geometry.
- Support for multiple grids, e.g., to support multiple reservoir problems, and flexible definition of local grids.
· Faults and horizons: may now be independently transferred (a grid is no longer required); may have multiple versions, and multiple geometry representations of each version, including point sets, triangulated surfaces and orthogonal grids (horizons only).
- Each fault or horizon representation may have its own set of associated properties.
· New Data Type! The nonStandardAdjacency consists of a cell-face-pair list that explicitly represents the adjacency between "non-standard" cells, which avoids the differences in interpretation between different applications for faulted corner point grids.
· Well Blocking. The blockedWellbore consists of the cell list that is intersected by a wellbore, ordered by increasing measured depth, and includes support for multi-lateral wells.
· Property data, which may be static or dynamic, may be associated with a horizon, a fault, a grid, a blockedWellbore list or a nonStandardAdjacency list.
- Property groups are used to group, for instance, all of the properties at one time or simulation time step within a RESQML document.