GoPhast is a graphical user interface (GUI) for PHAST (Parkhurst and others, 2004). PHAST simulates multi-component, reactive solute transport in three-dimensional saturated ground-water flow systems. PHAST can model both equilibrium and kinetic geochemical reactions. PHAST is derived from HST3D (flow and transport) (Kipp, 1987; 1997) and PHREEQC (geochemical calculations) (Parkhurst, 1995; Parkhurst and Appelo, 1999). The flow and transport calculations are restricted to constant fluid density and constant temperature. GoPhast is a tool used to transform data about an aquifer system into a data input file for PHAST. GoPhast is used to create the flow and transport data file required by PHAST. However, GoPhast does not create the chemistry data file required by PHAST. PHREEQCI (Charlton and Parkhurst, 2002), PHREEQC for Windows (http://www.geo.vu.nl/users/posv/phreeqc/index.html), or a text editor can be used to create it.
Tools such as GoPhast are a bridge between the conceptual model of an aquifer system in the mind of a hydrologist and the numerical model used to represent that aquifer system. Such tools are useful because of the great disparity between aquifers and the models used to understand them. Models are typically orderly; the aquifers are not. In PHAST, for example, the aquifer system consists of a series of nodes arranged in a grid. The aquifer has no such grid. In PHAST, nothing outside the grid affects the model results. The aquifer system is embedded in a landscape with which it interacts. (Boundary conditions are used to approximate the outside landscape but the boundary conditions are defined at grid nodes and are not affected by the model.) In PHAST, aquifer properties are defined in block-shaped zones that often encompass several nodes in the grid. In aquifers, zones, if they exist at all, will almost certainly not be block-shaped unless humans have engineered them to be so. Thus, the block-shaped zones are an unnatural representation of the aquifer system. All of these differences mean that it is not a simple matter to represent an aquifer system in a model effectively. In addition, the actual characteristics of the aquifer are imperfectly known. Often a property of interest is known at only a few sampling points and these data must be used to infer a likely value of the property elsewhere in the aquifer system.
Resolving disparities between the requirements of the model and the nature of the aquifer system is one of the ways in which a GUI can be most useful. A GUI can allow the modeler to specify the aquifer properties in ways that do not correspond directly to the requirements of the model. For example, instead of block-shaped zones, the aquifer properties and boundary conditions can be specified in ways that seem more natural such as zones with irregular boundaries. Hydrologists often conceive of an aquifer system as comprising a series of zones with uniform properties within those zones. The very existence of the words “aquifer” and “confining layer” show how prevalent is this zonal conception. Each aquifer and confining layer might be considered as a separate zone. More often an aquifer might be considered as several separate but similar zones. These zones do not correspond directly to block-shaped zones required by PHAST because their boundaries are irregular. However, it is a purely mechanical process to transform the irregular zones as conceived by the modeler to the block-shaped zones required by the model. The GUI can make this transformation for the modeler so that the modeler does not have to. If, instead of zones, the user wishes to interpolate among a series of data points to infer aquifer properties, those data points can be entered in the GUI and the GUI can perform the required interpolation. If the grid is changed, the GUI can automatically detect the change and reinterpolate the data to the new grid.
Another benefit of a GUI is its graphical representation of data. Models typically require that all or nearly all of the input be in the form of numbers. A river, for example, is represented in PHAST by a series of X and Y coordinates. A GUI can make those numbers more comprehensible by mapping them as a series of line segments on a computer screen. Graphical representation of the data, including the use of color, has enormous benefits. The graphical representation allows the user to specify and check the data much more rapidly and accurately than would otherwise be the case.
The graphical representation of the data is ultimately converted to the numeric form required by the model. By freeing the modeler of the drudgery of preparing the model input files, the GUI allows the modeler to concentrate his or her effort on higher-level tasks. Ultimately, the quality of the model that results from these efforts is likely to be improved through the use of a GUI.
The GUI of an aquifer system is most effective when it represents a system in two different ways (1) as the modeler conceives it, and (2) as the model requires it. The latter representation can be largely hidden from the modeler. With current technology, the user must still be aware of the existence of the model requirements because the modeler is responsible for creating the grid. Similarly, the model may provide a number of different options and the modeler must decide which of these options to use. The GUI can not hide those choices from the user. However, there are many aspects of the model the user does not need to know about. The block-shaped zones in PHAST are an example of a model requirement that can be hidden from the modeler.
Another detail that can be largely hidden is the time discretization. Models typically require that time be broken up into a series of simulation periods. In each simulation period, the boundary conditions may need to be respecified. In the modeler’s conception of the aquifer, only one or a few of the boundary conditions may have changed. Thus, there is no conceptual reason why the modeler must respecify the boundary conditions that have not changed. Instead, the GUI can hide this detail from the modeler. In the case of PHAST, this is made easier by the fact that the boundary conditions do not need to be respecified in each simulation period. However, GoPhast must also implement a separate simulation-period independent method for specifying boundary conditions to allow the values of the boundary conditions to be visualized.
This report (1) describes the basic concepts needed to work with GoPhast, (2) documents the features of GoPhast, and (3) gives examples of how to use GoPhast.
The examples are based on the examples provided with PHAST. Some of the text of this report consists of quotations from or paraphrases of the PHAST documentation (Parkhurst and others, 2004). Information for programmers is included in the Appendix 1.
The software described in this report may be obtained from the USGS Ground-Water Software web page (http://water.usgs.gov/software/ground_water.html).
I would like to thank Scott R Charlton, Peter Engesgaard, Rasmus Jakobsen, Kenneth L. Kipp, Peter Kroopnick, Paul Misut, and David Parkhurst for numerous helpful suggestions during the development of GoPhast. I would also like to thank Alden M. Provost, Ward E. Sanford, and Brendan A. Zinn for helpful comments on this publication.