ArticlePDF Available

Conceptual model development for FEFLOW or MODFLOW models–a new generation of Schlumberger Water Services software

Authors:
  • Waterloo Hydrogeologic

Abstract and Figures

In order for a groundwater model to be accurate, reliable, and robust, it requires a tremendous amount of information and understanding of the aquifer. The first step in developing a groundwater model, and perhaps the most important, involves the design of a conceptual model. Developing a good conceptual model requires compiling detailed information on the geological formations, groundwater flow directions, recharge, rivers, hydraulic parameters, extraction or injection from wells, and the groundwater quality. Today's groundwater modeler has at his/her disposal, a variety of tools and data sources for designing a conceptual model. The challenge is bringing together this data, into one common application. A revolutionary new tool in the suite of Schlumberger Water Services software encourages a conceptual approach to groundwater modeling. The modeler loads the raw conceptual data, (wells, surfaces, cross-sections, lines, polygons, XYZ points, maps, etc.), and conceptualizes the geological structure, properties, and boundary conditions, independent of any particular numerical simulator. Once complete, the modeler selects the desired simulator, then seamlessly generates the input for the appropriate numerical model, such as FeFLOW or MODFLOW. Since the conceptual data remains in one location, it is a simple task to generate or update multiple numerical models, of different types, in minutes. Using a conceptual model also allows for generating a variety of numerical discretizations from the same source, such as a number of finite element meshes and a variety of finite difference grids (deformed, uniform, or a combination) The result is improved quality, credibility, and efficiency of the modeling.
Content may be subject to copyright.
Conceptual Model Development for FEFLOW or MODFLOW Models –
A New Generation of Schlumberger Water Services Software
Serguei Chmakov
schmakov@slb.com
Wayne Hesch
whesch@slb.com
Collin Tu
xtu@slb.com
Marconi Lima
jlima4@slb.com
Schlumberger Water Services, Canada
Petr Sychev
Schlumberger Water Services, Russia
ABSTR ACT: In order for a groundwater model to be accurate, reliable, and robust, it requires a
tremendous amount of information and understanding of the aquifer. The first step in developing a
groundwater model, and perhaps the most important, involves the design of a conceptual model.
Developing a good conceptual model requires compiling detailed information on the geological formations,
groundwater flow directions, recharge, rivers, hydraulic parameters, extraction or injection from wells, and
the groundwater quality. Today’s groundwater modeler has at his/her disposal, a variety of tools and data
sources for designing a conceptual model. The challenge is bringing together this data, into one common
application. A revolutionary new tool in the suite of Schlumberger Water Services software encourages a
conceptual approach to groundwater modeling. The modeler loads the raw conceptual data, (wells,
surfaces, cross-sections, lines, polygons, XYZ points, maps, etc.), and conceptualizes the geological
structure, properties, and boundary conditions, independent of any particular numerical simulator. Once
complete, the modeler selects the desired simulator, then seamlessly generates the input for the
appropriate numerical model, such as FeFLOW or MODFLOW. Since the conceptual data remains in one
location, it is a simple task to generate or update multiple numerical models, of different types, in minutes.
Using a conceptual model also allows for generating a variety of numerical discretizations from the same
source, such as a number of finite element meshes and a variety of finite difference grids (deformed,
uniform, or a combination) The result is improved quality, credibility, and efficiency of the modeling.
INTRODUCTION
The groundwater modeler has to deal with different types of uncertainties, in particular with parameter
uncertainties (Hill, 2007, Doherty 2007) and conceptualization uncertainties (Poeter, 2006). In order
to handle conceptualization uncertainty, the modeler needs to create a reasonable set of different
alternative conceptual models. This in turn, produces a demand for the software giving the modeler a
tool for developing such conceptualizations. Currently the cost of developing such alternative models
is usually so prohibitive that the majority of the projects can only afford to explore the effects of
parameter uncertainties.
The goal of this paper is to present a conceptual approach to groundwater modeling that addresses
these issues. This approach allows the modeler to maintain a number of conceptual models within a
single project and provides an easy way to generate a number of different numerical models from the
same conceptual source.
WORKFLOW OVERVIEW
The groundwater model development is inherently very complex and comprises of a number of tasks
that requires the hydrogeologist to use a vast variety of tools. One of the main challenges for the
graphical user interfaces and visualization software is to organize the tools and provide an intuitive
workflow for the model development from raw data to the numerical model. Sometimes, even though
the appropriate tools are available, the modeler is getting lost trying to navigate to the right tool at the
right time.
Another challenge – raw data are usually handled outside of the model building workflow. Workflows
for creating groundwater meaningful objects from the raw data are usually left beyond the graphical
user interfaces for simulation software, which makes it difficult to trace the final model to the original
data.
To address these issues, the Hydro GeoBuilder (HGB) approach focuses on arranging the building of
the model into a natural workflow from Data Processing => Conceptual Model => Numerical Model =>
Simulation => Analysis of Results (Figure 1). The simulation related part of workflow is taken care of
by Visual MODFLOW. When the simulation is done, the results (heads, concentrations, etc.) can be
analyzed in Visual MODFLOW or brought back into the HGB for further analysis.
Figure 1: General workflow outline
DATA PROCESSING
The Hydro GeoBuilder provides a workspace for organizing and management of the raw data. The
object complexity ranges from rather simple ones such as points, polylines, polygons and surfaces to
as complex as wells (vertical, deviated, or horizontal), or vertical cross-sections.
These objects all share a common characteristic: they are not required to carry any hydrogeological
semantics. The objects at this level are considered to be just pure geometry with attached attributes
having little or no semantics with respect the modeling goal. This is the way how the HGB allows the
modeler to load the raw data in the context of the modeling project and organize them for future use
depending on the modeling objectives. At all times the raw data stored in the objects are left intact
and kept grid and mesh-independent.
All objects can be imported from a variety of data sources such as Digital Elevation Models (DEM),
shapefiles, spreadsheets, databases, or created manually. The list of supported formats is open and
can be extended as necessary. To facilitate import of geographical information, the HGB supports a
number of geographic and projected (UTM, State Plane, ETRS89) coordinate systems and
transformations between them. User-defined non-earth coordinate systems are also supported.
Although these objects may not be used directly in the numerical model, they serve as its building
blocks. To facilitate this, each object exposes a set of operations to change its own state or generate
other objects. Possible examples of operations includes creating surfaces from points using various
interpolation methods, spatial transformation like shifting and rotating, converting points to polylines,
etc. Operations may include another object’s as operands, for instance it is possible to drape a
polygon on a surface. To facilitate traceability of the model, each object carries with it a revision
history: the creation date and the author of the object, what other data were used, and what
operations were applied to it.
The HGB makes use of plug-in based architecture and allows adding more data objects with required
functionality as necessary. Adding a new data object does not require recompiling the whole
application – they are deployed in the form of .Net assemblies. Each such assembly is accompanied
by a manifest that allows the HGB to discover and load them into the project data workspace
dynamically. The set of consistent programmatic interfaces facilitates using the objects as the
operands for the operations.
VIEWING AND EDITING
Another feature of the Hydro GeoBuilder is a set of 2D and 3D viewers and editors. Rather than limit
the user to a set of fixed views of the model being developed, the HGB introduces a concept of
universal viewers and editors. Any object created in the project workspace can be visualized provided
it exposes a set of pre-defined programmatic interfaces. The modeler can display a number of 2D and
3D views and have different objects simultaneously visualized in those views.
The editing process includes geometry editing and attributes editing. Geometry editing can be
performed concurrently in a graphical or tabular view thus allowing for increased level of control on
the object geometry changes. If the object being edited is simultaneously visualized in other graphical
views, all the changes are reflected live in those views during the editing session. To increase
usability all editing includes multi-level undo capabilities.
Attribute editing is based on a selector mechanism that allows the modeler to delineate zones in data
objects where attributes of the object’s geometrical elements can be specified in a uniform way.
Figure 2 shows a simple example, where lines imported from a shapefile were delineated in a number
of zones and used for assigning a river boundary condition. Each zone is assigned a particular
method for defining attributes.
Figure 2: Feature Zonation
There are a number of methods that can be used to define the attributes: constant value, linear
interpolation between nodes, values from a surface data object (imported from DEM), values from a
set of river gauge stations, etc. Once again, the modeler can make use of data objects loaded into the
data workspace – for instance assign river stage from a DEM imported during the course of data
management activity. This mechanism is similar to the one used in Visual MODFLOW (Chmakov,
2003) to handle the MODFLOW Stream Routing Package (STR) (Prudic, 1989).
Although the example presented in Figure 2 is one dimensional, the zone based approach for
assigning and editing the attributes does not depend on the object dimension, and is similarly used for
attributes of 2D and 3D objects. This mechanism is used for defining both property and boundary
condition attributes.
CONCEPTUAL MODEL
The Conceptual Model in HGB is represented by a workspace that is separate from that of the raw
data. Similar to the data workspace, the content of the conceptual workspace is comprised of objects.
The difference between the objects in the conceptual model and the data workspace is that
conceptual model workspace objects must have particular semantics and adhere to business rules
specific to the conceptual model objects.
The Conceptual Model (CM) workspace contains a fixed structure of folders for organizing the CM
objects. In contrast to the data workspace, there is no option to have arbitrary objects in the
conceptual model – the CM structure is fixed and the modeler typically builds CM objects using data
objects as building blocks. The modeler can create as many conceptual models as (s)he wants, using
objects from data workspace.
Every conceptual model is comprised of three sub-models: Structural Model, Property Model and
Boundary Condition Model, each one with its own (fixed) structure. Accordingly, the CM creation
workflow includes creating these models in succession.
Figure 3: Horizon Types
The Structural Model (SM) consists of a bounding polygon and a set of horizons; the horizons
represent the geological structure of the site. Typical SM creation workflow assumes creating horizons
from surfaces existing in the data workspace (surfaces can be imported or created from 2D-XY scatter
points, cross-section interpretations, or well tops). At this step, the HGB enforces business rules for
different types of horizons (base, erosional, conformable, and discontinuous (Figure 3)) by properly
modifying the original surfaces used for horizon creation. This simplifies the process of designing
pinchout and discontinuous layers. The volumes in between the horizons constitute the structural
zones used later on for property modeling.
At the next step the property zones are created using structural zones as the compartmental basis;
the modeler has an option to further subdivide the compartment structure provided by the structural
model using data objects such as polygons and surfaces in order to create more property zones.
Based on these property zones the modeler assigns property attributes required by the modeling
objectives.
The most complex part of conceptual modeling is defining the Boundary Conditions (BC). In essence,
these are independent models ranging from relatively simple ones that are incorporated in the main
simulator (like River BC in MODFLOW) to rather complex models like MIKE 11 (Havnø et al, 1995)
providing very detailed model for channel flow.
In both cases, however, the external models share the same geometry (river network) but require a
different set of model attributes. In the first case (MODFLOW River BC), it is sufficient to specify just a
few attributes; in the second case (MIKE 11) there is a complex workflow defining the model which is
linked together through OpenMI interface. On the HGB side, however, specifying MIKE 11 as the BC
model of choice is rather simple – the modeler should just specify a path to the .omi manifest of the
respective MIKE 11 project (Graham, Chmakov et al., 2006). A simplified linking, where boundary
conditions for the numeric model are taken from another model – numerical or analytical – can also be
handled this way.
NUMERICAL MODEL
On the conceptual level a numerical model is represented by its simulation domain. There can be
more than one simulation domain for every conceptual model, thus providing a method to generate a
regional-local relationship between the numerical models and facilitate scenarios with local grid
refinement.
Each simulation domain can have one or more numerical grid or meshes attached to it, which defines
the horizontal discretization. The grid (mesh), though not linked to the conceptual model, is defined in
this workspace only at the time of translating the conceptual model to the numerical model. It is
important to emphasize, that in the contrast to the conventional approach, the numerical grid/mesh is
not used as the definition domain for the model properties – it only serves as one of the inputs to the
process of translating a conceptual model to the numerical one.
If the project objectives change, a new grid or mesh type and corresponding numerical model can be
easily generated (Figure 4), or existing ones updated, from the conceptual objects. This way the
modeler can explore different modeling scenarios by changing discretizations, boundary conditions or,
ultimately, even switch to another main simulator (MODFLOW, FEFLOW, ECLIPSE, analytical
models, etc.).
Figure 4: Different vertical grid types translated from the same conceptual model
Most three-dimensional numerical models use vertical discretization that primarily accounts for
geological layers. In some cases, this is not sufficient as it can create small pinchout layers with
instabilities. Using Hydro GeoBuilder it is possible to generate model layers that are independent of
the geologic structure. During conversion to the numerical model, properties are upscaled based on
geometry, using a weighted average method to provide appropriate representation of the conceptual
model properties. Examples of different vertical finite difference grids, with properties, are shown in
Figure 4, while examples of two different vertical finite element meshes are shown in Figure 5.
Figure 5: Different vertical mesh types generated for the same conceptual model
(Deformed (left) and Semi-Uniform (right))
DATA ANALYSIS
Including numerical grid/mesh into conceptual model allows one to establish a link between the
conceptual model and the resulting numerical model(s) and simplifies the process of bringing the
simulation results back into the Hydro GeoBuilder.
SUMMARY AND FUTURE DEVELOPMENT
A fully conceptual, simulator-independent approach to groundwater model building is presented. The
current implementation provides support for the MODFLOW and FEFLOW engines. Future plans
include extending it to other flow and transport engines.
REFERENCES
Hill, M., C., Tiedeman, C., R., 2007. Effective Groundwater Model Calibration: With Analysis of Data,
Sensitivities, Predictions and Uncertainties, John Wiley and Sons.
Doherty, J., 2007. Model predictive error: how it arises and how it can be accommodated, Model
Care, 493-498
Poeter, E., 2006. All Models Are Wrong: How Do We Know Which Are Useful?, MODFLOW and More
2006, Proceedings v.1, 11.
Chmakov, S., Delaney, P., 2003. Grid-Independent, Graph-Based Approach for Supporting the
Streamflow-Routing Package in Visual MODFLOW, MODFLOW and More 2003,
Proceedings, 144-148.
Prudic, D.E., 1989. Documentation of a computer program to simulate stream-aquifer relations using
a modular, finite-difference, ground-water flow model, U.S. Geological Survey Open-File
Report 88-729,113 p.
Havnø, K., Madsen, M.N. and Dørge, J., 1995. MIKE 11 – A generalized river modeling package,
Computer Models of Watershed Hydrology, Singh, V.P., Ed., Water Resources Publications,
Colorado, USA, (1995), p809-846.
Graham, D.N., Gijsbers, P.J.A, Gregersen, J.B., 2003. OpenMI: Harmonizing Water Management
Through an Open Modelling Interface, MODFLOW and More 2003, Proceedings, 121-125.
Graham, D. N., Chmakov S., Sapozhnikov, A., Gregersen, J. B., 2006. Coupling the MIKE 11
Channel Flow Model to MODFLOW, MODFLOW and More 2006, Proceedings v.2, 727-731.
ACKNOWLEDGMENTS
The workflow based approach was strongly motivated by the seismic to simulation workflows
available in Petrel (http://www.slb.com/content/services/software/geo/petrel/index.asp?), developed by
Schlumberger. For more information on the OpenMI project, please refer to the extensive OpenMI
website at www.openmi.org.
... Otro detallado documento que trata las virtudes y desventajas entre ambos métodos (FE-FD) es propuesto por Faust y Mercer (1980b). La descripción de herramientas adicionales disponibles para la implementación de datos de uso común a los dos simuladores presentada por Chmakov et al. (2009). El estudio comparativo de las capacidades y limitaciones de los métodos FD-FE, en la simulación de flujo y transporte de calor en fracturas documentada por Eckart et al. (2011). ...
Conference Paper
Full-text available
Groundwater is an important technical difficulty regarding the feasibility of open pit mines. An example, shown here, is a complex limestone formation quarry in North Spain. Numerical groundwater simulations help to quantify the problem. Here we present the development and results of a numerical model for this aquifer, using both FEFLOW (finite elements) and MODFLOW (finite differences). Differences in approach and implementation are detailed. The results match reasonably well the measured flows and have allowed simulation of practical scenarios of inmediate interest. Furthermore, the model gives aditional information regarding the location of a groundwater divide and propose a permeability zonation, dependent of the degree of fracturing. This zonation is able to explain the spatially localized groundwater measured flows and is consistent with other observations.
Article
Full-text available
Regulatory frameworks are evolving to require water management on a watershed or catchment basis, which implies an integrated groundwater-surface water approach.. However, there is currently no way - short of custom programming - to link surface water models (e.g. MIKE 11) to groundwater models (e.g. MODFLOW). MIKE 11 is a widely-used one-dimensional channel flow model for problems ranging from advanced fully dynamic hydraulics to basin scale hydraulic routing, whereas, MODFLOW is the de facto standard for groundwater modeling. The MIKE 11 engine and MODFLOW have been explicitly coupled together using the new OpenMI standard, which provides a set of interface methods for coupling disparate hydrology-related codes. These methods allow each code to pull required input data from any other OpenMI compliant code. To represent the leakage from MIKE 11 in MODFLOW, MODFLOW was first modified to make it OpenMI compliant and then a modified version of MODFLOW's FHB package was developed. At the beginning of every groundwater time step the modified FHB package requests the current stream leakage from MIKE 11, which MIKE 11 then calculates forward, based on the current groundwater level and the calculated stream flow over the coming groundwater time step.
Article
This paper presents a brief overview of the means by which the potential error associated with predictions made by a calibrated model can be estimated. This is important both in its own right, and as a means of optimizing the acquisition of future data to reduce this potential error. It is shown that there are two major contributors to the predictive error of a calibrated model, referred to herein as the "null space" and "solution space" contributions. The first is an outcome of the fact that system properties can only be estimated in broad detail through the calibration process; to the extent that a prediction is sensitive to finer detail than this, its potential for error is not reduced through model calibration. The second is an outcome of the fact that even estimates of broad-scale system properties carry some error, this resulting from the fact that they are estimated on the basis of data contaminated by (measurement and structural) noise. Methodologies for computation of these two terms are presented; reference is made to publicly available software through which these methodologies are implemented.
OpenMI: Harmonizing Water Management Through an Open Modelling Interface
  • D N Graham
  • P J.A Gijsbers
  • J B Gregersen
Graham, D.N., Gijsbers, P.J.A, Gregersen, J.B., 2003. OpenMI: Harmonizing Water Management Through an Open Modelling Interface, MODFLOW and More 2003, Proceedings, 121-125.
Effective Groundwater Model Calibration: With Analysis of Data, Sensitivities, Predictions and Uncertainties
  • M Hill
  • C Tiedeman
Hill, M., C., Tiedeman, C., R., 2007. Effective Groundwater Model Calibration: With Analysis of Data, Sensitivities, Predictions and Uncertainties, John Wiley and Sons.
Coupling the MIKE 11 Channel Flow Model to MODFLOW, MODFLOW and More
  • D N Graham
  • S Chmakov
  • A Sapozhnikov
  • J B Gregersen
Graham, D. N., Chmakov S., Sapozhnikov, A., Gregersen, J. B., 2006. Coupling the MIKE 11 Channel Flow Model to MODFLOW, MODFLOW and More 2006, Proceedings v.2, 727-731.
MIKE 11 – A generalized river modeling package, Computer Models of Watershed Hydrology
  • K Havnø
  • M N Madsen
  • J Dørge
Havnø, K., Madsen, M.N. and Dørge, J., 1995. MIKE 11 – A generalized river modeling package, Computer Models of Watershed Hydrology, Singh, V.P., Ed., Water Resources Publications, Colorado, USA, (1995), p809-846.
Grid-Independent, Graph-Based Approach for Supporting the Streamflow-Routing Package in Visual MODFLOW
  • S Chmakov
  • P Delaney
Chmakov, S., Delaney, P., 2003. Grid-Independent, Graph-Based Approach for Supporting the Streamflow-Routing Package in Visual MODFLOW, MODFLOW and More 2003, Proceedings, 144-148.
All Models Are Wrong: How Do We Know Which Are Useful?
  • E Poeter
Poeter, E., 2006. All Models Are Wrong: How Do We Know Which Are Useful?, MODFLOW and More 2006, Proceedings v.1, 11.