A methodology to model groundwater flow in sub

Transcription

A methodology to
model groundwater
flow in sub-areas of
the Canterbury Plains
Report No. R10/43
ISBN 978-1-877574-17-7
M Thorley
D Scott
November 2010
Report R10/43
ISBN 978-1-877574-17-7
This document should be cited as: “Thorley, MJ and DM Scott, 2010. A methodology to
model groundwater flow in sub-areas of the Canterbury Plains; Environment Canterbury
technical report R10/43, 75 p.”
58 Kilmore Street
PO Box 345
Christchurch 8140
Phone (03) 365 3828
Fax (03) 365 3194
75 Church Street
PO Box 550
Timaru 7940
Phone (03) 687 7800
Fax (03) 687 7808
Website: www.ecan.govt.nz
Customer Services Phone 0800 324 636
A methodology to model groundwater in sub-areas of the Canterbury Plains
Executive summary
Environment Canterbury is continuing to develop numerical flow models of the Canterbury Plains
aquifer system. This report describes the component methodologies used to develop a numerical
groundwater flow model over the central Canterbury Plains area.
The initial stages of the modelling project attempted to explicitly deal with the inherent uncertainty
involved, particularly in relation to prediction, and is reported in Scott & Moore (2008), and Moore &
Scott (2008). The current project has built on that earlier work by adopting or adapting several
additional tools, and refining the methodology to accommodate the demands of a multi-layered model
and to maximise the use of observational data.
The regional modelling project takes an approach that acknowledges model uncertainty, and
recognises that different predictions will be influenced by different model configurations. This
approach requires the modeller to think about defining an individual model project in terms of the
prediction objectives.
The United States Geological Survey (USGS) MODFLOW model was employed for groundwater flow
simulation and the Parameter ESTimation (PEST) toolkit was adopted for model calibration and
uncertainty analysis. The Groundwater Vistas (GW Vistas) Package was adopted to provide a
graphical interface to the MODFLOW model and to support the use of PEST. The model calibration
process depends critically on the distributed processing capacity of Environment Canterbury’s Local
Area Network (LAN) to support parallel computing.
Geological structure is often a fundamental component in the definition of a numerical flow model.
Environment Canterbury and Applied Research Associates New Zealand (ARANZ) have been
collaborating to develop software called Leapfrog HYDRO that provides a three-dimensional
representation of the geology beneath the Canterbury Plains. This is beneficial not only for developing
structural context for a groundwater flow model, but also for communicating our understanding of the
structural composition of the aquifer system.
Once the geological model is complete, Leapfrog HYDRO provides the functionality to construct a
MODFLOW model grid complete with zonation based on the geological model. The MODFLOW grid
and hydraulic conductivity zonation exported from Leapfrog HYDRO are taken into GW Vistas. From
here boundary conditions and parameterisation of the model are undertaken using GW Vistas.
GW Vistas is not only used as an interface for the MODFLOW model, but also for PEST. GW Vistas
assigns and stores the PEST setup, such as observations, variables in the PEST control file and
parameters. It will write out all the necessary PEST files consistently and correctly which makes the
generation of a PEST run easily repeatable and less error prone.
PEST evaluates many more model solutions than a manual calibration. Typically when a model,
especially a transient model, has a run time of the order of 20 minutes, then hundreds if not thousands
of CPU processing hours are required for its iterative calibration. Given that Environment Canterbury
has hundreds of computers; it makes sense for us to harness the unused capacity of the LAN to
complete many model runs.
Most of the post-processing of model results and calibration can be completed using GW Vistas and
ARCGIS. Three-dimensional visualisation of model results in Leapfrog HYDRO is still under
development. The aim is to be able to visualise parameter fields, groundwater flow and goodness of
fit between model and field observations in three-dimensions. Model results to date demonstrate the
utility of the three dimensional model-building procedure and illustrate the flexibility and efficiency of
the model calibration technique in evaluating alternative conceptual models. We expect to progress
various aspects of the model in the coming years with an immediate focus on the representation of
intermittent river recharge in the model and the spring-fed stream flow targets.
Environment Canterbury Technical Report
i
ii
Table of contents
Executive summary .................................................................................................... i
1
Introduction ..................................................................................................... 1
2
Background ..................................................................................................... 1
3
Methodology.................................................................................................... 1
4
5
3.1
Model scope....................................................................................................................2
3.2
Geological model ............................................................................................................3
3.3
Flow model definition ......................................................................................................3
3.3.1 Land-surface recharge .......................................................................................4
3.3.2 Pumping .............................................................................................................4
3.4
Model calibration .............................................................................................................5
3.4.1 Graphical user interfaces ...................................................................................5
3.4.2 Generation of calibration targets ........................................................................5
3.4.3 Regularisation ....................................................................................................6
3.5
Parallelisation of model calibration process ...................................................................7
3.5.1 Automated batch processing .............................................................................7
3.5.2 BeoPEST ...........................................................................................................7
3.6
Post-processing of results ..............................................................................................8
Demonstration – Central Plains example...................................................... 9
4.1
Purpose...........................................................................................................................9
4.2
Geological model ............................................................................................................9
4.3
Model grid .....................................................................................................................10
4.4
Temporal discretisation .................................................................................................13
4.5
Boundary conditions .....................................................................................................14
4.5.1 Recharging wells (alpine rivers) .......................................................................14
4.5.2 Drains ...............................................................................................................15
4.5.3 Abstraction wells (analytic element).................................................................15
4.5.4 Streams ............................................................................................................16
4.5.5 Constant heads ................................................................................................16
4.5.6 Inactive cells.....................................................................................................16
4.6
Land-surface recharge ..................................................................................................17
4.7
Model calibration ...........................................................................................................18
4.7.1 Head targets.....................................................................................................18
4.7.2 Flux targets ......................................................................................................22
4.7.3 Weighting of observation groups .....................................................................23
4.7.4 Hydraulic conductivity ......................................................................................23
4.7.5 Specific storage (Ss) ........................................................................................25
4.7.6 Super parameters ............................................................................................26
4.8
Results ..........................................................................................................................27
Model development and future applications .............................................. 35
iii
6
Conclusions .................................................................................................. 36
7
Acknowledgements ...................................................................................... 36
8
References..................................................................................................... 37
APPENDIX 1: Wells Database Query report for geological model building ...... 38
APPENDIX 2: FORTRAN code for calculation of monthly recharge................... 48
APPENDIX 3: Fortran codes for aggregation of Wells/Consents data and
synthesis of water use.................................................................................. 52
APPENDIX 4: Batch files used for distributed processing ................................. 58
APPENDIX 5: Documentation of the code and instruction files for the
program checkout.exe .................................................................................. 64
APPENDIX 6: FORTRAN code of post.exe used for post-processing of
transient model calibration results.............................................................. 66
iv
List of Figures
Figure 3-1:
Figure 4-1:
Figure 4-2:
Figure 4-3:
Figure 4-4:
Figure 4-5:
Figure 4-6:
Figure 4-7:
Figure 4-8:
Figure 4-9:
Figure 4-10:
Figure 4-11:
Figure 4-12:
Figure 4-13:
Figure 4-14:
Figure 4-15:
Figure 4-16:
Figure 4-17:
Figure 4-18:
Figure 4-19:
Figure 4-20:
Figure 4-21:
Figure 4-22:
Figure 4-23:
Figure 4-24:
Running BeoPEST on a homogeneous local area network (LAN) (from Schreüder,
2010) .................................................................................................................................8
Westerly facing view of the geological model for central Canterbury plains (labels are
the geological formation names and alpine rivers in italics) ..............................................9
MODFLOW model grid extent .........................................................................................10
Conceptual geological model of the Central Plains and the assignment of layer
guides and MODFLOW grid layers .................................................................................11
Conceptual geological model translation to MODFLOW model......................................12
Boundary conditions used in the MODFLOW model ......................................................14
Estimated total pumping demand over the simulation period .........................................16
Weighted spatial averages of soil properties used to model land-surface recharge
over the model area ........................................................................................................17
Location of Group 1 & 2 head targets which are derived from eigenmodel analyses.....18
Location of Group 3 head targets which represent average piezometric head ..............19
Location of Group 4 head targets which are the vertical differences in head between
sites located within 500 m of each other .........................................................................20
Location of Group 5 head targets which are sites containing time series groundwater
level data .........................................................................................................................21
Boundary condition reaches or groups. Waterways are represented by groups of
boundary cells demarcated by the common reach references i.e. the number 14
represents Lake Ellesmere/Te Waihora ..........................................................................23
Location of Kx and Ky pilot points ....................................................................................24
Location of Kz pilot points ................................................................................................25
Location of specific storage pilot points ..........................................................................26
Calibrated horizontal hydraulic conductivity (Kx) distribution for each model layer
(m/day) ............................................................................................................................28
Calibrated vertical hydraulic conductivity (Kz) distribution for each model layer
(m/day) ............................................................................................................................29
Calibrated specific storage (SS) distribution for each model layer ..................................30
Scatter plot of modelled versus measured hydraulic head (m) .......................................31
Plot of modelled versus observed transient piezometric head at well M35/5144 ...........31
Scatter plot of modelled versus measured drain boundary and spring-fed stream flow
(m3/day) ...........................................................................................................................32
Plot of modelled and observed transient stream flow from the groundwater system
into Harts Creek and Birdlings Brook (m3/day)................................................................33
Map of modelled and observed transient hydraulic head root mean squared
residuals ..........................................................................................................................34
Map of the simulated piezometric contours .....................................................................35
List of Tables
Table 3.1:
Table 4-1:
Table 4-2:
Table 4-3
Table 4-4:
Summary of head targets and their primary calibration purpose ......................................5
Key statistics relating to model grid .................................................................................13
Preferred values of average flow loss and reach references for recharging rivers.........15
Expected average flows and waterway/reach references for groundwater dependent
water bodies ....................................................................................................................22
Expected versus modelled flow and reach references for recharging alpine rivers........32
v
vi
1
Introduction
This report provides a background to the regional groundwater modelling project and its current status.
We then provide an overview of the modelling methodology and describe its component parts. An
example of the latest application of the methods is then provided.
Environment Canterbury is continuing to develop numerical flow models of the Canterbury Plains
aquifer system. One of the guiding principles of the project is to develop tools and methods that
support our modelling philosophy. That is to move away from the tradition of developing deterministic
models, or “one model to rule them all”, to a more probabilistic approach whereby a prediction is
identified as required for a particular purpose and the model is constructed, calibrated and reported on
for that particular purpose. This approach essentially acknowledges model uncertainty, and
recognises that predictions will span a range of possibilities that will be influenced by some parts of
the model more so than others.
2
Background
This project is part of an ongoing modelling investigation that commenced in 2006. Earlier phases of
the investigation are reported in Scott & Moore (2008), and Moore & Scott (2008). That preliminary
work set out an approach to modelling which attempted to explicitly deal with the inherent uncertainty
involved, particularly in relation to prediction. The United States Geological Survey (USGS)
MODFLOW model was employed for groundwater flow simulation and the Parameter ESTimation
(PEST) toolkit was adopted for model calibration and uncertainty analysis. The model calibration
process depends critically on the distributed processing capacity of Environment Canterbury’s Local
Area Network (LAN) to support parallel computing.
3
Methodology
The current project has built on previous work by adopting or adapting several additional tools:
- the Groundwater Vistas (GW Vistas) Package as a modelling database, pre- and postprocessing tool and PEST support tool
- the Leapfrog HYDRO1 Package for development of 3-dimensional geological models and
translation to MODFLOW2 grid
- new development in parallel computing, and
- modifications to the preparation of model transient boundary inputs (recharge and pumping).
Other refinements to the methodology have been developed to accommodate the demands of a multilayered model and to maximise the use of observational data. The project methodology has five main
phases (which are sequential but can be iterative):
1.
2.
3.
4.
5.
identify area and/or issue of interest
geological representation
flow model definition
calibration and prediction
interpretation of results
1
Leapfrog HYDRO is an integrated 3D software solution for developing hydrogeologic models. This software can
be found via the following website address: http://www.aranzgeology.com/
2
We currently use MODFLOW-2000 Version 1.19.01. This software can be found via the following website
address: http://water.usgs.gov/nrp/gwsoftware/modflow2000/modflow2000.html
1
The type of modelling application that is required to evaluate regional scale groundwater development
and management options means that all phases are likely to be required. These phases can be
summarised as:
• Model scope
o determine a sub-regional area where predictions are required for a particular purpose and,
in keeping with the project’s philosophy, focus modelling efforts on a sub-area rather than
spreading the effort thinly over a (potentially unnecessarily) larger area;
• Geological model
o query geological data from the Wells Database at Environment Canterbury and build a
geological model from borehole data and other sources of “general geological knowledge”
using Leapfrog HYDRO;
• Flow model definition
o build a numerical MODFLOW grid and assign hydrogeological zones based on the
geological model;
o estimate land-surface recharge across the Canterbury Plains potentially incorporating
delay functions for areas of deeper groundwater;
o estimate pumping development over time.
• Model calibration
o further develop the distributed network system for parallelising the model calibration
3
process using Parallel PEST, and more recently, a beta version of BeoPEST ;
o calibrate a zone based model using automated calibration techniques offered by PEST;
o use the calibrated zone based model to assign “preferred values” to pilot points in order to
impose our knowledge of the geological structure in the calibration process via
regularisation constraints;
o estimate several heterogeneous parameter fields consisting of Kx, Kz, and Ss for each
model layer;
o estimate the steady contribution of recharge from alpine rivers;
o estimate the flow and/or conductance of head dependent boundaries representing
transient recharge from rivers and spring-fed streams;
o assign head and flow targets that require the calibration process to fit:
piezometric and river components based on eigenmodel analysis;
average piezometric head and vertical gradients;
time varying groundwater level signals;
time varying flows in spring-fed streams;
transformed and compressed groundwater level signals using the Discrete Cosine
Transform (DCT); and
super-observations of groundwater level observations using Singular Value
Decomposition (SVD-Assist from the PEST suite of calibration tools).
• Interpretation of results
o interpret model and calibration results to determine goodness of fit and reasonableness of
parameter estimates; and
o presentation of model calibration results using the Leapfrog HYDRO 3D viewer
3.1 Model scope
Identifying an area and/or issue of interest is important to any project scope. We believe the project
should be scoped in terms of the prediction objectives rather than a philosophy of “let’s build the
perfect model that will be all things to all stakeholders”. This means the modeller and the client need
to identify what predictions will be required in order to define the model. This will help the modeller
focus on variables and observations that are important and identify those which are more peripheral.
As a consequence, the regional modelling effort is now more focussed on doing sub-regional scale
models rather than spreading the effort thinly over a larger area. Experience to date suggests that it
may not presently be feasible to apply the preferred model calibration techniques to a model that
covers an area as large as the entire Canterbury Plains. This is a consequence of limitations of
3
2
We are currently using PEST and Parallel PEST version 12.0, BeoPEST version 12.0.1 and some of the
groundwater utilities found via the following website address: http://www.pesthomepage.org
currently available computer systems. Nevertheless, the methodology that is being developed will
allow the evaluation of relatively large areas like the Central Plains. Once several sub-regional
models have been developed it is possible to integrate them. There are currently no sub-regional
models built for a specific purpose, but that is the next area of effort (see Section 4).
3.2 Geological model
Environment Canterbury collects and classifies borehole information in the Wells Database. This
information, along with other pertinent sources of geological data such as geological maps and
geomorphology, can be used to build a geological model. Environment Canterbury and ARANZ have
been collaborating to develop software that provides a three-dimensional representation of the
interpreted geology beneath the Canterbury Plains.
Three-dimensional geological model building assists the development of a conceptual model for a
groundwater flow model, and at the same time provides visual media to communicate our
understanding of the structure of the aquifer system. The ARANZ software also allows integration and
synthesis of hard borehole data and “soft knowledge” through its use of user-defined control points in
the surface interpolation process. The three-dimensional functionality also allows a move away from a
predominantly layered and two-dimensional view of geological structure.
Building a geological model using Leapfrog HYDRO also acts as a valuable quality assurance process
for the Wells Database. Errors relating to bore log entry, well location and screen depth can be
scrutinised efficiently when plotted as a group in three-dimensions. This provides a useful quality
assurance feedback loop for data management.
A system of Wells Database queries has been developed to enable a smooth data export and import
to the ARANZ software. Query reports are shown in Appendix 1. An example of the geological model
building capability is shown later in the report in Section 4.2.
3.3 Flow model definition
Once the geological model is complete, Leapfrog HYDRO provides the functionality to construct a
MODFLOW model grid complete with zonation based on the geological model. The output is a
MODFLOW grid and hydraulic conductivity fields that can be imported directly into GW Vistas. This is
carried out using the standard import utility in the model initialisation menu.
Boundary conditions and parameterisation of the model are undertaken using GW Vistas. There are
three broad types of boundary conditions that need to be simulated for the Canterbury plains aquifer
system – rivers, springs and the coast.
Rivers and drains can be specified in several ways. Firstly, river recharge can be specified using the
MODFLOW River Package. The river boundary can be assigned by arbitrarily elevating the head of
the river boundary say 100 m above land surface in order to make it “disconnected” or “independent”
of adjacent groundwater level conditions. This means that a constant rate of river recharge can be
assigned by adjusting the conductance variable to constrain the flow of water from the river boundary.
Another option to represent river recharge is to use the MODFLOW Well Package. That is appropriate
when focussing on the water balance component of river recharge. The stage of the river can still be
reproduced as part of the modelled piezometric surface during model calibration by assigning
“pseudo-observations” of the river stage.
A system for routing flow overland is needed in the case of rivers like the Selwyn where flow is lost to
the groundwater system variably depending on river flow and wetted length. The MODFLOW Stream
Routing Package (Prudic, 1989) can be used to distribute a variable base flow component of an
intermittent river over its length upstream of the spring discharge area.
3
Drains can be specified as pumping wells if the water balance component is the focus. However the
choice of boundary condition representing these features depends on the prediction required from the
simulation. Changes in flow to spring-fed surface water bodies resulting from climate variability and
abstraction are likely to be important predictions for the model and therefore the MODFLOW Drain
Package is considered more appropriate than the Wells Package. Relating spring flows to nearby
groundwater heads and setting these as observations or prior information could be part of the
calibration target set.
Simulation of the “stream-depletion” effect of further groundwater development would require more
accurate and detailed assignment of river or stream boundary conditions than the methods outlined
above. The stream depletion effect is concerned with the pumping effect on discharging and
recharging streams. The spatial distribution of stream-bed conductance, and stream stage and bed
elevations would need to be specified to a more detailed scale. Field testing information would inform
the model calibration including aquifer test data and stream bed conductance surveys.
The offshore margin of the model can be represented as a static head boundary to which aquifer
system discharge occurs. Therefore we typically use constant heads within MODFLOW for
representation of the coast.
3.3.1
Land-surface recharge
The method for calculating MODFLOW Recharge Package input described in Moore and Scott (2008)
has been modified to write the Recharge Package input in MODFLOW2000 format to be compatible
with the Groundwater Vistas Package. Recharge is calculated using a simple lumped parameter soil
moisture model for each 1 km square of the model grid. Water budget calculations are performed at a
daily time step using rainfall and potential evapotranspiration data derived from NIWA’s Virtual Climate
Network. Average profile available water (PAW) for each model cell is determined from Environment
Canterbury’s GIS (combined soils layer) and monthly recharge is accumulated from the increments of
daily drainage occurring when the soil water holding capacity is exceeded.
The FORTRAN code which carries out these calculations is listed in Appendix 2. An option to include
a simple single reservoir model to allow for depth-dependent delay of drainage has yet to be
incorporated in the code.
3.3.2
Pumping
An estimate of pumping history can be synthesized using data from Environment Canterbury’s Wells
and Consents databases (which provide a record of potential demand for irrigation) and from the
NIWA Virtual Climate Network (which, together with soil information, provides an estimate of soil
moisture condition). Synthesis of irrigation pumping is based on the assumption that soil moisture
deficits during a nominal irrigation season (October through April) above a specified threshold will be
met by irrigation (with an assumed efficiency of 80%) when and where that is permitted by a
groundwater abstraction consent.
The FORTRAN codes developed to implement this synthesis are listed in Appendix 3. The first of
these (aggregate_wells) reads a list of wells and corresponding consent conditions and assembles an
annual series of irrigable area (for irrigation consents) or volumes (for non-irrigation) for each well to
reflect the consent history for that well. The second code (irrigsim) uses the annual series of irrigable
area for each irrigation well together with climate and soil data to estimate monthly pumping. At this
stage in the development of methodology the recharge-enhancing effect of irrigation has not been
factored into the recharge calculations. An interim allowance for that effect has been allowed for by
discounting the calculated irrigation demand to provide an estimate of the “net use” of groundwater for
4
irrigation . The appropriate discount depends on soil properties, type of irrigation system and climate
but is likely to be in the range 20% to 40% (Scott, 2003).
4
Canterbury Strategic Water Study (CSWS) (Morgan et al., 2002) developed the concept of net use which takes
account of the enhanced recharge that occurs when groundwater is used for irrigation i.e.
Rainfall + Irrigation = Evapotranspirationirrigated + Rechargeirrigated
4
3.4 Model calibration
3.4.1
Graphical user interfaces
There are many graphical user interfaces (GUI) for MODFLOW. We have selected GW Vistas
because it provides:
• advanced interface for MODFLOW;
• advanced PEST capability including calibration setup, assignment of observations and
parameters; and
• automated PEST file generation that makes PEST runs repeatable and less error prone.
3.4.2
Generation of calibration targets
The method for generating and applying head targets is similar to that described in
Moore & Scott (2008) with a number of modifications. Five groups of head targets are now deployed
as summarised in Table 3.1.
Table 3.1:
1
2
3
4
5
Summary of head targets and their primary calibration purpose
Head target
An average piezometric head component related to
land-surface and river recharge at selected sites as
derived using the eigenmodel
An average piezometric component related to river
recharge only at selected sites as derived using the
eigenmodel
Average piezometric heads at all sites with more than
three groundwater level readings, and well screen
and/or well depth information
Head difference targets which specify the vertical
hydraulic gradients between the average piezometric
sites (mentioned above)
Transient groundwater level data over the simulation
period
Primary Calibration Purpose
Representing alpine river
recharge
Constraining hydraulic
conductivity
Constraining specific storage
Due to the large number of available observation data and parameters, we can easily exhaust the
capacity of a standard desktop computer (using a 32-bit operating system and 4 gigabits of readily
accessible memory (RAM)) to hold a Jacobian matrix in RAM, we have investigated ways of
compressing observation data5. This can be done in two main ways:
a) Data compression; and
b) Super-observations
3.4.2.1 Data compression
Environment Canterbury has an extensive collection of groundwater level data. The Wells Database
contains nearly 1 million groundwater level readings (excluding recorder data). When we attempted to
use a tenth of these data for calibrating a groundwater model, we exceeded the limits of our
computing resources. The challenge was to live within our current computing resources but utilise as
much of the information in the data as possible. The solution: data compression using truncated
discrete cosine transform (DCT).
5
A Jacobian matrix is the matrix of sensitivities of all model outputs corresponding to observations comprising the
calibration dataset to all adjustable parameters. Where sensitivities are calculated using finite parameter
differences, this requires as many model runs as there are adjustable parameters for each occasion on which
the Jacobian matrix is re-computed. We can generate a Jacobian matrix with more integer rows and columns
than can be held in memory by a standard desktop computer. More information about the Jacobian matrix
used by PEST can be found at www.pesthomepage.org
5
Groundwater level data over time form signals, and can therefore be represented as such. The DCT
process linearly transforms the groundwater level data from the time domain into the frequency
domain. The frequencies are then listed from lowest to highest frequency conditions which can then
be truncated by the user to get rid of noise and redundant detail. The compression ratio is such that
approximately 80% of the information is still present but is represented by only approximately 20% of
the frequency coefficients. This is the equivalent of JPEG (image) compression.
There are two significant advantages in compressing the data in this way compared to sub-sampling
(taking every nth sample). First, since the noise in the data is white, removing the high-frequency
signal greatly improves the signal-to-noise ratio. Second, different weights could be applied to
different frequencies in the parameter estimation. For example, we might be more interested in
matching the response of the groundwater system to stresses rather than fitting the average head
value. This method can also be described as a smoothing method that samples the data in a more
elegant way than random or regular sub-sampling (Thorley et al., 2009).
3.4.2.2 Super-observations
Super-observations are derived using the SUPOBSPREP utility from the PEST suite of utilities
(Doherty, 2010a). This uses singular value decomposition (SVD) which describes the dependence
across observations to reduce the number of observations required to calibrate the model in the same
way as Super Parameters are employed in SVD-Assist. The main advantage is the reduction in size
of the observation dataset in order and reduces the computing requirements. Applying SVD to the
observations also helps the calibration process focus on aspects of the observation dataset that are
more pertinent to finding a unique solution.
3.4.3
Regularisation
Typically, it is difficult to find a unique parameter set for a groundwater model because there are many
different combinations of parameters that can provide equally good fits to our measurements. Unless
we provide some additional information in the calibration process it can be impossible to estimate
properties like transmissivity and storage terms uniquely or at all. Including additional information into
the calibration process is referred to as regularisation and can consist of prior estimates of
parameters, and/or relationships between parameters (Doherty, 2010b; Doherty, 2010c).
There are three frequently used types of mathematical regularisation: Tikhonov, subspace, and hybrid
methods. Tikhonov regularisation uses a constrained minimisation formulation such as preferred
value or preferred homogeneity. These are most useful for including geological constraints and/or
“soft knowledge” about the parameter fields that being estimated. Subspace methods such as SVD
determine combinations of parameters that can be estimated uniquely even though individual
parameters may not be able to be able to be estimated uniquely. Hybrid methods such as SVD-assist
utilise the strengths of both Tikhonov and subspace regularisation. We have utilised SVD-assist in
PEST in order to reduce the run time of a calibration process, include prior information about
parameters such as geology, providing a mechanism to achieve a unique solution to an ill-posed
problem, and allow the calibration process to focus on the most sensitive parameters (Doherty, 2010b;
Doherty, 2010c).
Pilot points are assigned to the model grid on the basis of observations such that more parameters are
6
assigned to areas that contain a greater number of observation sites (Doherty, 2010b; Doherty,
2010c). The initial and preferred parameter values are assigned based on the geological model to
incorporate our conceptual understanding of the aquifer structure into the calibration process.
The advantage of preferred value regularisation is that fewer regularisation observations are required
to implement smoothing and structural prior information in the generation of a heterogeneous field
than the preferred homogeneity regularisation method7. Preferred value regularisation also allows the
6
7
6
Pilot points are the adjustable parameters at a point location that are then interpolated to form a heterogeneous
parameter array. More information about pilot points can be found at www.pesthomepage.org.
Preferred value regularisation in PEST will try to keep the property values as close to the preferred parameter
value as possible which is user defined. If several parameters near each other have the same of similar
parameter estimation process to adjust the geological boundaries imposed by the prior information
more readily than preferred homogeneity which only interpolates parameter values within the
geological boundaries provided by the prior information (Doherty, 2010b; Doherty, 2010c).
3.5 Parallelisation of model calibration process
3.5.1
Automated batch processing
PEST evaluates many more model solutions than a manual calibration. Typically, when a model,
especially a transient model, has a run time of the order of 20 minutes, then thousands of CPU
processing hours are required to minimise an objective function. Given that Environment Canterbury
has hundreds of computers; it makes sense for us to harness the unused capacity of the office
network to complete many model runs. The general behaviour of this system is outlined in Moore &
Scott (2008). In essence the system allows us to use the computers of other ECan staff members
when they would otherwise be idle.
Batch processing is used to deploy model runs from a “master” to “slave” computers and also to run
the various processes that contribute to a PEST calibration run. An example of the batch file
(enrol.bat) used to deploy the files and start a slave is provided in Appendix 4. The enrol.bat file is
called by a programme that monitors the screensaver program. If the screensaver commences
running, enrol.bat is called and a job will begin, until the user interrupts the process by turning off the
screensaver.
Batch file processing is also used on the slaves to complete the model run perturbations and return
results to the master. These batch files (pestgv.bat & svdabatch.bat) are written by GW Vistas and
are also included in Appendix 4. We have made a modification to the final part of the batch files to
avoid the calibration stopping due to incomplete MODFLOW model runs. This may occur where
parameter perturbations cause a solver convergence failure. Following the MODFLOW run, and
before targpest reads out the model observations, a program called checkout reads the MODFLOW
*.lst file to ensure that the final stress period is reported. This program and associated files are
included in Appendix 5. If the final stress period is not found in the *.lst file, model observations of
zero are delivered back to PEST. As a result PEST will see large residuals due to that particular
parameter perturbation and steer clear of it. Otherwise the results of the model run are delivered via
targpest to PEST for evaluation of the residuals.
3.5.2
BeoPEST
Parallel PEST has been used for distributed processing of many model runs in order to reduce the
elapsed time to complete a calibration run. However, the Parallel PEST system has been recently
superseded by BeoPEST. We downloaded, free of charge, a beta version of BeoPEST from
www.pesthomepage.org in order to evaluate this new system of distributed model calibration
described in Doherty (2010d), Schreüder (2009) and Schreüder (2010). We have provided feedback
to the authors of BeoPEST on what works well and what could be improved to assist with their
development efforts. The following figure (Figure 3-1) depicts how BeoPEST works across an office
network (from Schreüder, 2010).
preferred values, then with regularization, these properties will be as homogeneous as possible. More
information about regularisation in PEST can be found at www.pesthomepage.org.
7
Figure 3-1:
Running BeoPEST on a homogeneous local area network (LAN) (from Schreüder,
2010)
BeoPEST can also be run across the internet and on cloud computing system if required. This will
increase the capability to harness more distributed computing resources for model calibration and
prediction. BeoPEST has radically altered the calibration process of our groundwater model by
increasing slave participation and reducing the communication time between the master and slaves
that had plagued Parallel PEST. Some alterations to the distributed processing procedure have been
required such as starting the BeoSlaves after the BeoMaster (which is the opposite of Parallel PEST)
and using different command line protocols. Generally it has helped to streamline the process as the
network folders, run management files and run instruction files (such as ppmodel.bat) are no longer
needed. A BeoPEST run is generated using GW Vistas and all the files are copied over to the slaves.
Few file alterations are now needed because with BeoPEST, the slaves are actually running PEST
with direct communication using TCP/IP internet protocols.
3.6 Post-processing of results
Most of the post-processing of model results and calibration can be completed using GW Vistas and
ARCGIS. Examples of post-processing are provided in Section 4.8.
Three-dimensional visualisation of model results using Leapfrog HYDRO is still under development.
The aim is to be able to visualise parameter fields, groundwater flow and goodness of fit between
model and field observations. We expect to make significant progress in the coming year in this area.
A FORTRAN program has been written to report residuals and statistics of transient modelled and
observed data. This information can be plotted in map form to show where spatial bias may be
occurring in the model-measurement misfit. The code for this program (post.for) is included in
Appendix 6.
8
4
Demonstration – Central Plains example
4.1 Purpose
The purpose of this section is to describe a numerical groundwater flow model that is “proof of
concept” of the methodologies described previously by considering the area between the Rakaia and
Waimakariri rivers (the Central Plains) where current and potential demand for groundwater for
irrigation has raised concerns about the impacts on groundwater-dependent streams. In the future,
we expect the model will be developed and used as a tool for evaluating water resource management
options. Such options may include simulation of managed aquifer recharge scenarios or the
delineation of capture zones for public supply wells or spring-fed streams. The work programme for
this has yet to be determined.
4.2 Geological model
A three dimensional geological model has been constructed for the Central Plains area. We have
fashioned this from borehole information, geological maps and the uniformitarianism principle (the
present is the key to the past). The geological model is shown in Figure 4-1 and we plan to publish a
description and provide access to an interactive viewer via the Environment Canterbury website:
www.ecan.govt.nz.
Rakaia River
N
Waimakariri River
Fill
Riccarton
Springston
Bromley
Linwood
Christchurch
Wainoni
Shirley
Figure 4-1:
Heathcote
Burwood
Westerly facing view of the geological model for central Canterbury plains (labels
are the geological formation names and alpine rivers in italics)
The glacial, post or inter glacial formations can be seen in Figure 4-1. This shows the coastal
confined deposits to be discontinuous as they pinch out a third to halfway up the Canterbury Plains.
The land-based equivalents of the coastal confining units, such as the Springston Formation, can be
clearly seen with the inland extents demarcated from the geological map (Forsyth et al., 2008). These
formations incise into the glacial formations such as the Riccarton – Wainoni. The base of the lowest
formation is assumed to be 200 m below mean sea level.
9
4.3 Model grid
The model grid is shown in Figure 4-2 and is a cut-down version of that used in Scott & Thorley
(2009). The grid was generated in Leapfrog HYDRO and imported into GW Vistas. The model is
aligned with the mid-reaches of the Selwyn River, is active over the Central Plains area, and has 13
layers.
Figure 4-2:
MODFLOW model grid extent
The layer geometry is guided by major geological formations. Figure 4-3 depicts the conceptual
model of the geology and shows how layer guides were applied in Leapfrog HYDRO. Layer guides
are used as continuous surfaces in Leapfrog HYDRO to create layers that are continuous across the
MODFLOW grid. Therefore, the position of these layer guides must be based on geological contacts
that are also continuous across the model domain. The user then specifies the number of layers to be
created between each layer guide. The model layers are vertically distributed equally between the
layer guides. If a geological formation fills more than half of a grid cell, Leapfrog HYDRO assigns the
hydraulic conductivity zone corresponding to that geological formation. This enables Leapfrog
HYDRO to create complex three-dimensional hydraulic conductivity distributions, where
hydrostratigtraphic units can pinch out or continue across the MODFLOW grid, and allows
10
discontinuous units like the coastal confined deposits to be assigned on the basis of zonation and
layer geometry.
MODFLOW layer
Marine deposit Terrestrial deposit
Layer guide
Christchurch
Springston
Riccarton
Bromley
Bromley Gravel
Linwood
Layer 1
Layer 2
Layer 3
Layer 4
Layer 5
Layer 6
Layer 7
Layer guide
Heathcote
Layer 8
Layer 9
Heathcote Gravel
Burwood
Layer 10
Layer guide
Layer 11
Shirley
Shirley Gravel
Wainoni
Layer guide
Layer 12
Layer 13
Layer guide
Figure 4-3:
Conceptual geological model of the Central Plains and the assignment of layer
guides and MODFLOW grid layers
In Figure 4-3 we have applied two layers per aquitard unit (Christchurch, Bromley, Heathcote, and
Shirley) because replicating vertical head gradients will be most pertinent across these units.
Modelling horizontal flow is most relevant in the aquifer units (Riccarton, Linwood and Burwood) and
therefore one model layer was applied. Two model layers were applied to the Wainoni as this is a
composite of less distinctive aquifer and aquitard units compared to overlying units. An example of
the translation of the geological model to a MODFLOW grid and hydraulic conductivity zonation is
shown in Figure 4-4.
11
Figure 4-4:
12
Conceptual geological model translation to MODFLOW model
Key grid statistics are shown in Table 4-1. The LAYCON variable in MODFLOW was set to 0
(confined) to prevent transmissivity changing with saturated thickness and therefore avoid dry model
cells occurring. Initial heads are set equal to the topographic elevation and to zero offshore where
fixed heads represent the coastal boundary.
Table 4-1:
Key statistics relating to model grid
Grid origin (NZMG 1949)
Orientation
Spacing
Discretisation
2383986.3392E, 5701706.0961N
335°
1000 m x 1000 m
108 rows x 106 columns x 13 layers
Number of model cells
148824
Number of active cells
82498
Initially the model domain was set sufficiently wide to cover the entire Canterbury Plains area with
inactive cells specified to limit the active model extent to a sub-area of the plains. This approach has
been abandoned for two reasons:
- Firstly, the number of inactive wells has been reduced in order to lower the transient model
run time. We conducted a series of speed tests in order to optimise key settings in the
MODFLOW run and found one third of the run time was shed by minimising the number of
inactive cells. We believe this is due to improved or less onerous preconditioning in the
Geometric Multi-Grid (GMG) solver; and
- Secondly, GW Vistas allows the addition or subtraction of model cells of any shape and
quantity to the margins of the model. Therefore the extent of the grid can easy be adjusted to
incorporate more or less of the Canterbury Plains area as required
4.4
Temporal discretisation
Both steady-state and transient models are used in the model to represent steady recharge, spatial,
and temporal components of the aquifer system. This model was set up with 3 initial steady-state
models and one transient model which had 460 monthly stress periods from January 1972 to
April 2010.
Two steady-state models are used to establish alpine river recharge from estimates of the steady-state
piezometric effects of alpine river recharge and land surface recharge at 17 sites. These steady
piezometric components were identified through eigenmodel analyses (Moore & Scott, 2008). The
first model establishes alpine river recharge only in relation to hydraulic conductivities. The second
steady-state simulation then uses the known estimates of land surface recharge to compute hydraulic
conductivities and hence the absolute estimates of alpine river recharge.
The third steady-state stress period is used to reproduce average hydraulic head under average
recharge and pumping conditions and with the alpine river contribution as constrained by the two
previous steady-state stress periods. The third steady-state stress period also acts to define starting
heads for the first of 460 transient stress periods that follow. The spatial components mostly relate to
the geological or resistance properties of the aquifer system such as Kx and Kz. These parameters are
adjusted so as to reproduce observed hydraulic gradients between observation points. Average
piezometric head and vertical hydraulic gradients are very pertinent observations when estimating
heterogeneous resistance fields.
Transient stress periods require storage parameters in order to reproduce time varying aquifer system
responses to climate and pumping. Time series observations are most pertinent when estimating a
storage parameter field.
13
4.5 Boundary conditions
The boundary conditions assigned to the model are shown in Figure 4-5 and include drains,
recharging wells (alpine river), abstraction wells, streams, constant heads, and inactive cells.
Figure 4-5:
Boundary conditions used in the MODFLOW model
The current version of the model uses recharging wells to apply alpine river recharge to the model, the
stream boundary (STR) to route Upper Selwyn River inflow across the plains and into the groundwater
system. Drain and constant head cells are used to represent discharge from the groundwater system
such as flow to springs and the coast.
4.5.1
Recharging wells (alpine rivers)
The rates of recharge applied to the model are constrained by PEST for the alpine rivers (Rakaia and
Waimakariri rivers) using initial and preferred values. These are shown in Figure 4-5 and summarised
in Table 4-2. Reach references are shown in Figure 4-12.
14
Table 4-2:
Preferred values of average flow loss and reach references for recharging rivers
Waterway/s
Upper Rakaia River
Lower Rakaia River
Upper Waimakariri River
Lower Waimakariri River
Expected average
flow loss
12 m3/s
21 m3/s
2 m3/s
8 m3/s
Reach
1012
101
1001
100
Source
Gauging Data <2010
Gauging Data <2010
Gauging Data <2010
Gauging Data <2010
Recharge from the major rivers was assumed to be evenly distributed along each reach with the two
alpine rivers divided into upper and lower reaches (Waimakariri River at Halkett, and Rakaia River at
the SH1 Bridge) over a total of 120 recharging wells. The main advantage of this approach is that we
have estimates of the changes in flow across the alpine rivers and therefore potential losses, but not
the properties of the river bed. Therefore the alpine river recharge rate can be included as prior
information through preferred value regularisation. This approach also avoids the complications that
non-linearity adds to the calibration process.
This approach to specifying river recharge has the potential disadvantage of allowing simulated
groundwater levels to rise above the true ground surface in areas adjacent to recharging rivers. In
areas of the model where this proved to be an issue additional head calibration targets were added to
constrain the model calibration process. Such pseudo-head observations, set at the true topographic
elevation of the river, were added for the Rakaia River and the Waimakariri River.
4.5.2
Drains
Drain cells are assigned to represent spring discharge from the groundwater system as shown in
Figure 4-5. The stage of the drains was set equal to topographic elevation along with an arbitrarily
high initial estimate of bed conductance. The initial values are used as preferred values in the
regularisation component of the parameter estimation process. The target flows are discussed in
Section 4.7.2.
4.5.3
Abstraction wells (analytic element)
Analytic element wells are used in GW Vistas as point or vector based data like that used in GIS. This
means that each element is stored in GW Vistas as an individual well and pumping record rather than
as a combined flux for a model cell. The total pumping load assigned to a model cell from all the
analytic wells assigned to a model cell are summed and assigned during model translation.
We imported 4016 pumping wells into the model each with a simulated pumping history. Not all of the
wells will have been pumping over the same time periods but will represent the gradual increase in
irrigation demand met by groundwater abstractions based on the rate of resource consent
grants/renewals since 1972. A plot of the simulated pumping demand is shown in Figure 4-6. In order
to account for irrigation return water and actual use, 60% of the estimated demand was applied to the
model.
15
200
Pumping demand
(million cubic metres)
150
100
50
Figure 4-6:
4.5.4
Jan-10
Jan-09
Jan-08
Jan-07
Jan-06
Jan-05
Jan-04
Jan-03
Jan-02
Jan-01
Jan-00
Jan-99
Jan-98
Jan-97
Jan-96
Jan-95
Jan-94
Jan-93
Jan-92
Jan-91
Jan-90
Jan-89
Jan-88
Jan-87
Jan-86
Jan-85
Jan-84
Jan-83
Jan-82
Jan-81
Jan-80
Jan-79
Jan-78
Jan-77
Jan-76
Jan-75
Jan-74
Jan-73
Jan-72
0
Estimated total pumping demand over the simulation period
Streams
The upper Selwyn River and tributaries are simulated using the Stream Package in MODFLOW. The
result is shown in Figure 4-5 (above). Base flow derived from the Whitecliffs recorder is routed down
the upper Selwyn River. Manning’s roughness has been set at 0.035, the value used in recent river
modelling work (Aurecom, 2009). The bed conductance parameter, which controls the rate of loss to
the groundwater system from the stream, will be adjusted during the calibration process.
Average flows were used for the steady-state stress periods as were the inflows to the Hororata and
Waianiwaniwa rivers. We plan to use more refined runoff records for the upper Selwyn River and
tributaries in the future as more information becomes available.
4.5.5
Constant heads
Constant head cells are applied across the marine areas of the model. Constant head cells are
applied to layers one through three so that the aquifer system’s discharge to the sea is predominantly
via the Riccarton unit. The position of the constant head cells are also shown in Figure 4-5 (above).
The assignment of constant head cells over the offshore area aims to simulate the saltwater boundary.
4.5.6
Inactive cells
The limits of the active model domain are illustrated in Figure 4-5. Bedrock outcropping to the west of
the Canterbury Plains alluvium has been assigned as inactive cells. Unconsolidated deposits to the
north of the Waimakariri River and to the south of the Rakaia River have been excluded along regional
groundwater flow divides.
16
4.6 Land-surface recharge
Land-surface recharge (LSR) has been estimated using a soil moisture model which determines
drainage through the soil profile. Daily rainfall and potential evapotranspiration data for the soil
moisture model have been obtained on a 0.05º latitude-longitude grid from NIWA’s virtual climate
network. Daily water budget calculations have been carried out for the 1972-2010 period, for each 1
km2 model cell. The soil water holding capacity has been determined using the average Profile
Available Water (PAW) from the Environment Canterbury’s GIS Combined Soils layer as shown in
Figure 4-7.
Figure 4-7:
Weighted spatial averages of soil properties used to model land-surface recharge
over the model area
17
4.7 Model calibration
4.7.1
Head targets
Five groups of head targets were included in the calibration process following the strategy for
assigning target/observation groups outlined Section 3.4 and Table 3.1.
Group 1
Group 1 comprised steady-state piezometric head estimates determined using eigenmodel analyses
(Moore & Scott, 2008) under average dry land LSR conditions at 17 sites (Figure 4-8). These sites
were selected based on the length of record and the representativeness of the system dynamics and
are the same sites used in Moore & Scott (2008) for the Central Plains area. This group of targets
was applied to steady-state simulation number 1.
Figure 4-8:
Location of Group 1 & 2 head targets which are derived from eigenmodel
analyses
Group 2
Group 2 uses the same sites as Group 1; however, the observation is the “steady” river recharge
component within the piezometric head signal. No LSR is applied to the model in this steady-state
stress period. By removing the LSR component, the model is forced to adjust the alpine river
18
contribution to fit to these Group 2 targets. The observations for Groups 1 and 2 are summarised in
Table 3.1. Group 2 observations were applied to steady-state simulation number 2.
Group 3
Average piezometric head provides a representation over the greatest number of sites of the three
dimensional flow fields within the groundwater system. Fourteen hundred and thirty-five sites were
utilised to represent the long-term system-wide piezometric head distribution and comprised those
wells with three or more readings (Figure 4-9). The targets were applied to steady-state stress period
number 3, with average LSR (dryland) applied. Steady-state stress period 1 is included as
preconditioning for the second steady-state stress period simulation. The third steady-state stress
period provides the starting heads for the subsequent transient simulation.
Figure 4-9:
Location of Group 3 head targets which represent average piezometric head
Targets of river stage for each model cell representing a river (alpine rivers and the upper Selwyn
River only) were also included in this group. These were derived from the digital elevation model
(DEM) using GIS.
Group 4
Group 4 targets are vertical head differences between those Group 3 sites that are within 500 metres
of each other and in different model layers. These head difference targets are generated in GW
Vistas. Head difference targets help PEST find a solution that matches head, but also represents the
19
hydraulic gradients across model layers. This head target group is applied to steady-state stress
period 3 and contains 732 sites. The head difference targets are shown in Figure 4-10.
Figure 4-10: Location of Group 4 head targets which are the vertical differences in head
between sites located within 500 m of each other
Group 5
Group 5 contains the time-series head data used for the transient calibration of the model. Just over
37,000 data points from approximately 833 sites were used in this group (Figure 4-11). Only sites
which had more than 12 consecutive monthly readings were accepted. Data collected at finer
temporal frequencies were sub-sampled using the DCT method described in Section 3.4.2. We
started with just over 500,000 data points and sampled at 60-day intervals in order to create an
observation dataset that can be handled using a 32-bit operating system.
20
Figure 4-11: Location of Group 5 head targets which are sites containing time series
groundwater level data
21
4.7.2
Flux targets
Twenty-eight waterways were grouped into 14 model reaches represented by 439 drain cells as
shown in Figure 4-12. Estimates of average flow derived from the available literature and from
Environment Canterbury databases are listed in Table 4-3. The expected groundwater discharge for
each reach was established by evenly distributing the flow over the number of cells for the particular
waterway.
Table 4-3
Expected average flows and waterway/reach references for groundwater
dependent water bodies
Expected average flow
Reach
No. of
cells
Reference
3 m3/s
53
12
Environment Canterbury
database - gauging
1.6 m3/s
45
27
database – gauging &
recorder
1.8 m3/s
1
30
database - gauging
Heathcote River
1 m3/s
20
19
Halswell River
Halswell Canal
1 m3/s
17
39
1.9 m3/s
29
10
3
1 m /s
14
169
Ettema & Moore (1995)
3 m3/s
55
39
Clausen & Horrell
(2007)
0.7 m3/s
23
12
Clausen & Horrell
(2007)
3
1.5 m /s
13
32
Clausen & Horrell
(2007)
1.5 m /s
19
19
Clausen & Horrell
(2007)
0.2 m3/s
48
11
Clausen & Horrell
(2007)
3
3 m /s
30
13
0.5 m3/s
24
10
Waterway/s
South Branch
Waimakariri River
/Otukaikino
Kaputone Creek
Styx River
Avon River/Ōtakaro
Estuary
of
the
Heathcote and Avon
rivers/Ihutai
LII River
Lake
Ellesmere/Te
Waihora
Miles Drain
McGraths Stream
Silverstream
Lower
Selwyn
River/Waikirikiri
Irwell River
Hanmer Road Drain
Boggy Creek
Doyleston Drain
Tramway
Reserve
Drain
Nairns Drain
Birdlings Brook
Harts Creek
Parkin Drain
Waikekewai-Taumutu
Creek
Lee River
Tentburn Stream
Jollies Brook
Cryers Creek
22
3
database - gauging
Clausen & Horrell
(2007)
Clausen & Horrell
(2007)
database - gauging
database - gauging
Figure 4-12: Boundary condition reaches or groups. Waterways are represented by groups of
boundary cells demarcated by the common reach references i.e. the number 14
represents Lake Ellesmere/Te Waihora
4.7.3
Weighting of observation groups
Due to the differing number and nature (flow and head) of the observation groups, the groups were
weighted to evenly balance the composite sensitivities. Without a weighting strategy, PEST is likely to
focus too much effort on the flow targets, due to the magnitude of the flow (m3) versus the magnitude
of head targets. We used the PWTADJ1 utility, from the PEST suite of utilities, to ensure each head
observation group and the flux observation group contributed equally to the objective function.
4.7.4
Hydraulic conductivity
The zones of hydraulic conductivity created with Leapfrog HYDRO were used to assign preferred and
initial values for the pilot points. Pilot points for Kx, Ky, and Kz were applied to each model layer.
These were assigned on the basis of observation data and ensured a pilot point is assigned no less
than 3 km apart and in gaps no greater than 10 km. One thousand and seventy-nine (Kx and Ky) pilot
points were used and assigned mid-way between triplets of observations in each layer (Figure 4-13).
23
Figure 4-13: Location of Kx and Ky pilot points
Vertical hydraulic conductivity (Kz) pilot points were assigned at the actual head observation locations.
This method is recommended for reproducing vertical gradients across model layers. In total, nine
hundred and thirty Kz pilot points were assigned (Figure 4-14). These were assigned on the basis of
observation data and ensured a pilot point is assigned no less than 3 km apart and in gaps no greater
than 10 km.
24
Figure 4-14: Location of Kz pilot points
4.7.5
Specific storage (Ss)
Eight hundred and thirty pilot points were used and assigned at the transient observation sites. Pilot
points were assigned no less than 3 km apart and in gaps no greater than 10 km. These are shown in
Figure 4-15, for all layers. An initial and preferred value of Ss=0.01 was assigned to all pilot points and
did not use the geological pre-conditioning as used for the hydraulic conductivity pilot points. Another
approach would be to use one value for the “unconfined” Layer 1, and another “confined” value for the
other layers. The geological preconditioning of hydraulic conductivities was not used for the
preconditioning of storage parameters.
25
Figure 4-15: Location of specific storage pilot points
4.7.6
Super parameters
A total of 2,881 parameters were assigned to the parameter estimation problem. Given the large
number of parameters and the possibility of parameter insensitivity, super parameters were employed
using SVD-Assist (a method in PEST).
Ten to twenty percent of the base parameters were used as a guide for the number of super
parameters resulting in 288 being assigned. At the completion of each calibration run the base
parameter sensitivities were re-tested and the weights of the super parameters readjusted. This
adjustment is usually done two or three times or until little more can be gained in the reduction of the
objective function.
The current run used 288 super parameters in the first calibration run (10% of base parameters) which
resulted in the model reaching a more realistic initial condition. During the second iteration we
increased the number of super parameters to 576 (20% of base parameters) in order to allow a
greater degree of detail in the calibrated parameter fields and boundary conditions when PEST is
fitting the model and observed data.
26
4.8 Results
This Section describes the results of a model calibration run to illustrate what can be achieved via the
methodologies described throughout preceding Sections of this report.
Estimated hydraulic
conductivity and specific storage fields are presented with accompanying analyses of the model misfit
and uncertainty. The performance of the model is summarised in terms of residuals between
observed and simulated heads, and flows. Spatial bias of modelled to measured residuals is also
illustrated.
The following figures (Figure 4-16, Figure 4-17 and Figure 4-18) show estimates of Kx, Kz, and Ss
parameter fields respectively for each of the thirteen layers of the model. The parameter fields were
exported from GW Vistas and plotted in GIS.
27
Figure 4-16: Calibrated horizontal hydraulic conductivity (Kx) distribution for each model layer (m/day)
28
Figure 4-17: Calibrated vertical hydraulic conductivity (Kz) distribution for each model layer (m/day)
29
Figure 4-18: Calibrated specific storage (SS) distribution for each model layer
30
Figure 4-19 shows the modelled versus observed values of piezometric head. These data are from
head targets Groups 1 to 5 and give an indication of model to measurement misfit. Figure 4-20
compares modelled and observed data over the transient simulation period for a single monitoring
site. We expect to improve the fit of the modelled and measured heads in the coming months.
Layer 1
409.5
Layer 2
Layer 3
327.6
Model Value
Layer 4
Layer 5
245.7
Layer 6
Layer 7
163.8
Layer 8
Layer 9
81.9
Layer 10
Layer 11
0.0
0.0
81.9
163.8
245.7
327.6
409.5
Layer 12
Observed Value
Figure 4-19: Scatter plot of modelled versus measured hydraulic head (m)
Observed
5.1
Piezometric head (masl)
Computed
4.8
4.4
4.1
3.8
3.5
1.0
2801.4
5601.8
8402.2
11202.6
14003.0
Time (days past 1/1/1972)
Figure 4-20: Plot of modelled versus observed transient piezometric head at well M35/5144
31
Alpine river recharge was estimated (summarised in Table 4-4) on the basis of eigenmodel derived
piezometric observations. Some reaches are showing very encouraging results and agreement with
measured flow changes across these rivers.
Table 4-4:
Expected versus modelled flow and reach references for recharging alpine rivers
Waterway/s
Upper Rakaia River
Lower Rakaia River
Upper Waimakariri River
Lower Waimakariri River
Expected average
flow loss
~12 m3/s
~21 m3/s
~2 m3/s
~8 m3/s
Reach
Modelled flow loss
1012
101
1001
100
~15 m3/s
~3 m3/s
~9 m3/s
~15 m3/s
Spring-fed stream flows were represented by drain cells in the MODFLOW model. Gauging data were
included as calibration targets for modelled flow into the drain cells. Figure 4-21 shows a scatter plot
of all modelled flows over the observed values. This shows the modelled and observed data fit can be
improved. However the distribution of residuals is centred and not overly skewed. A plot of modelled
and observed data from a water body over the simulation period is shown in Figure 4-22.
g
0
Model Value
-127510
-255020
-382530
-510040
-637550
-637550
-510040
-382530
-255020
-127510
0
Observed Value
Figure 4-21: Scatter plot of modelled versus measured drain boundary and spring-fed stream
flow (m3/day)
32
Groundwater flux (cubic metres)
-9170
Observed
-37024
Computed
-64879
-92733
-120587
-148441
-176295
-204149
-232004
-259858
-287712
1
1401
2801
4202
5602
7002
8402
9802 11203 12603 14003
Time (days past 1/1/1972)
Figure 4-22: Plot of modelled and observed transient stream flow from the groundwater
system into Harts Creek and Birdlings Brook (m3/day)
Figure 4-23 shows a map of the root mean square of the modelled and observed residuals which is
calculated over the transient simulation period. This provides an indication of spatial bias in the
calibration process and/or where efforts to improve model performance are most or least required.
33
Figure 4-23: Map of modelled and observed transient hydraulic head root mean squared
residuals
Figure 4-24 shows a map of simulated piezometric contours in the last transient stress period (463).
The warping of the piezometric contours reflects the influence of the boundary conditions such as the
Selwyn River/Waikirikiri in combination with the estimated parameter fields such as hydraulic
conductivity. This shows simulated groundwater flow directions are reflecting observed patterns of
groundwater flow.
34
Figure 4-24: Map of the simulated piezometric contours
5
Model development and future applications
Many of the tasks outlined in this report were identified as tasks in Moore & Scott (2008). The major
milestones that the modelling project has achieved are as follows:
1. refinement of spring-fed stream definition – more gauging information is now incorporated and
a base flow record for the lower Selwyn River/Waikirikiri has been used as a flow target. Work
is currently underway to improve the synthetic flow records for the Lake Ellesmere/Te Waihora
tributaries;
2. refinement of layer definitions – this has been achieved through the application of the ARANZ
Leapfrog HYDRO tool;
3. definition of transient pumping regime – this component has developed but will improve as
water use data becomes more readily available;
4. refinement of recharge estimates – this is an ongoing process and irrigated land recharge
remains a challenge due to the lack of water use data and irrigated land use data;
5. incorporate model in Groundwater Vistas Graphical User Interface – this has been completed;
6. refinement of coastal boundary consideration – we have yet to make progress with this
aspect;
7. further consideration of aquifer property variability – some progress has been made but is very
reliant on aquifer test information, which is an ongoing data collection issue;
35
8. sub-model integration – the modelling project team has shifted focus to sub-regional models
because modelling a smaller area well is preferred to spreading computing resources thinly
over a larger area. Sub-regional models can be joined at a later date if required; and
9. improving the measured and modelled fit of heads and spring-fed stream flows.
While the numerical model and calibration system still require refinement, we are now at a stage in the
project where the model is ready to use for resource evaluations. The modelling project team will be
seeking to support Environment Canterbury work programmes with the numerical model.
6
Conclusions
The methodologies and example case outlined in this report demonstrate how to conceive and
calibrate a numerical flow model of part of the Canterbury Plains while acknowledging uncertainty.
The methods require significant computing resources and we are continuing to add to the distributed
networking system as new machines replace older ones. Details of the methodologies are presented
in appendices 1 to 6. Continuing development is required to maintain and enhance the modelling
capabilities within Environment Canterbury. Application of the model to particular areas and issues is
expected to be a major work component for the modelling project.
7
Acknowledgements
This project is being carried out by the Groundwater Resources Section of the Investigations and
Monitoring Group. Several members of the Groundwater Resources Section have contributed to the
development of the modelling methodology described in the report. Matt Smith and Jamie Glass have
collaborated on the development of the programs which control the distributed networking system.
Nicola Wilson has conducted many of the database queries.
External consultants have also assisted: Catherine Moore of Environmental Science and Research
(ESR) with PEST methodology; Marcos Van Dam and Richard Lane from Applied Research
Associates New Zealand (ARANZ) with ongoing collaboration efforts in developing Leapfrog HYDRO
and writing the data compression (DCT) utility.
We would also like to acknowledge the very helpful and valuable support and software provided by
Jim Rumbaugh of Environmental Simulations Inc, John Doherty of Watermark Numerical Computing,
and Willem Schreüder of Principia Mathematica.
Dr Vince Bidwell peer reviewed this report and the authors would like to thank him for his constructive
criticism.
36
8
References
Aurecom 2009. Selwyn River hydraulic modelling.
Reference 43451-001.
Final Report for Environment Canterbury.
Clausen, B & G Horrell 2007: Estimation of daily flows in Lake Ellesmere tributaries (1 April 1991 – 31
December 2006). Environment Canterbury Technical Report U07/85. ISBN: 978-1-86937-736-6.
Doherty, J 2010a. Groundwater Support Software – Groundwater Data Utilities. Watermark Numeric.
Watermark Numeric. Document can be found via the following website address:
http://www.pesthomepage.org/Downloads.php
Doherty, J 2010b. PEST Model Independent Parameter Estimation User Manual: 5th Edition.
Watermark Numeric. Document can be found via the following website address:
http://www.pesthomepage.org/Downloads.php
Doherty, J 2010c. Addendum to the PEST manual. Watermark Numeric. Document can be found via
the following website address: http://www.pesthomepage.org/Downloads.php
Doherty, J 2010d. Documentation for Windows BeoPEST. Watermark Numeric. Document can be
found via the following website address: http://www.pesthomepage.org/Downloads.php
Ettema, M & C Moore 1995: Seepage in Lake Ellesmere. Environment Canterbury Technical Report
U95/18.
Forsyth, PJ, DJA Barrell and R Jongens (compilers) 2008. Geology of the Christchurch area. Institute
of Geological & Nuclear Sciences 1:250 000 geological map 16. 1 sheet + 67 p. Lower Hutt,
New Zealand. GNS Science.
Prudic, DE Documentation of a computer program to simulate stream-aquifer relations using a
modular, finite-difference, ground-water flow model. Open file report 88-729. U.S. Geological Survey.
Carson City, Nevada.
Moore, C & DM Scott 2008. Canterbury Plains regional groundwater model: Progress report to
February
2008.
Environment
Canterbury
unpublished
technical
report
U08/05.
ISBN 978-1-86937-771-1.
Schreüder, W 2009. Running BeoPEST. Principia Mathematica. Document can be found via the
following website address: http://www.prinmath.com/
Schreüder, W 2010. BeoPEST Programmer’s Documentation. Principia Mathematica. Document can
be found via the following website address: http://www.prinmath.com/
Scott, DM 2003. Net use of groundwater for irrigation: a review of the concept.
Canterbury unpublished technical report U04/53, 31pp.
Environment
Scott, DM & C Moore 2008. Canterbury Plains regional groundwater model: Project overview.
Environment Canterbury unpublished technical report U08/20. ISBN 978-1-86937-801-1.
Scott, DM & MJ Thorley 2009. Steady-state groundwater models of the area between the Rakaia and
Waimakariri rivers. Environment Canterbury report R09/20. ISBN 978-1-86937-940-7.
Thorley, MJ, DM Scott, M van Dam and R Lane 2009. JPEG- like compression in model calibration.
Abstract and presentation at The New Zealand Hydrological & Freshwater Sciences Societies Joint
Conference. Whangarei, NZ.
37
APPENDIX 1:
Wells Database Query report for
geological model building
Procedure for preparing Wells data for Leapfrog HYDRO
David Scott
18 February 2010
1) Select wells using ArcMap
2) Export table of selected wells
Creates a dbf file including all fields
3) Update Well input.xls on O:\Software\Wells Database\ARANZ
Paste well_no column from dbf file of selected wells
NB: This is used to provide the selection criteria in Access
Do not delete Wells input.xls since that will remove the link used
Access query which generates the table of strata data
in
the
4) Open Aranz Hydro.mdb
O:\Software\Wells Database\ARANZ
4.1) Click on the Well details button on the Startup form
This runs a query to create table of wells & details
st
1 four columns containing:
Well_no
38
Grid_east
Grid_north
QAR code
Plus other fields of interest
Query details are described in Appendix A (NB wells with depth
< 3 m are
excluded!)
4.2) Export to well_detail_selection.txt
Select the following options:
Field delimiter {tab}
Text qualifier {none}
include field name
4.3)
Select Strata data button on the Startup form
This runs a query and creates table of wells/depths/strata
Query details are described in Appendix B
4.4)
Export to strata_data.txt
Select the following options:
Field delimiter {tab}
Text qualifier {none}
include field name
5) Open well_detail_selection.txt in Excel and sort by:
Strata (descending)
QAR_CODE(ascending)
Save as well_detail_selection_sorted.txt
NB: This sorting is intended to ensure that coordinate adjustments are applied to those
wells with the least available strata information and
to those with the least reliable location
information.
If you plan to use the Max_WL and/or Min_WL attributes check whether these include flags
such as -999 (dry well) or 999 (
6) Run resolve_coincident_wells.exe (Fortran program in Appendix C)
Prompts for name of collar file
Respond with well_detail_selection_sorted
Reads:
well_detail_selection_sorted.txt
Writes:
well_detail_selection_sorted.out
well_detail_selection_sorted.dup
(list of coinciding wells)
7) Run screens_from_collar_file
Python script in Appendix D operates on C:\Projects\screens
Reads:
well_detail_selection_sorted.out
Writes:
screens.csv
8) Run Leapfrog HYDRO
Create new project
Import boreholes
Collar:
Well_detail_selection_sorted.out
39
Interval Tables: Strata_data.txt
Screens:
Screens.csv
Select fields from collars file - Hole ID, X, Y, Elev(z)
Select fields from strata data – Hole Id, From, To, Lithology, Test
40
Select fields from screens.csv – Hole Id, From, To
Potential errors & warnings during import process
Collars
Errors: Non-numeric values
Warnings:
Errors in unused collars, Collar has no samples
Strata data
Errors: Non-numeric values, Hole ID not in collar table
From depth >= to depth, Overlapping segments
Screens
Errors: Overlapping segments
NB Errors can be exported to *.csv files for inspection & resolution
41
View of imported borehole data.
42
Appendix A: Well detail selection query
Query can be ammended by switching to query view mode.
O:\Software\Wells Database\ARANZ\Aranz Earth Research.mdb
Query: Well detail selection
Properties
DateCreated:
DOL:
GUID:
MaxRecords:
OrderBy:
Orientation:
RecordsAffected:
ReturnsRecords:
Updatable:
9/07/2009 5:35:02 p.m.
Long binary data
{guid {58068FCC-BCC2-4EAEB28F-F51D83381A9E}}
0
[Well detail selection].GL_amsl
Left-to-Right
0
True
True
Friday, 25 September 2009
Page: 1
DefaultView:
FrozenColumns:
LastUpdated:
Datasheet
1
24/07/2009 4:48:50 p.m.
ODBCTimeout:
OrderByOn:
RecordLocks:
RecordsetType:
Type:
60
True
No Locks
Dynaset
0
SQL
SELECT dbo_WELL_DETAILS.WELL_NO, dbo_WELL_DETAILS.GRID_EAST,
dbo_WELL_DETAILS.GRID_NORTH, dbo_WELL_DETAILS.QAR_CODE, dbo_WELL_DETAILS.REFERENCE_RL,
dbo_WELL_DETAILS.QAR_RL,
IIf(IsNull(dbo_WELL_DETAILS!GROUND_RL),dbo_WELL_DETAILS!REFERENCE_RL,dbo_WELL_DETAILS!GROU
ND_RL+dbo_WELL_DETAILS!REFERENCE_RL) AS GL_amsl, dbo_WELL_DETAILS.DEPTH,
dbo_WELL_DETAILS.Strata, dbo_WELL_DETAILS.TOP_SCREEN_1, dbo_WELL_DETAILS.BOTTOM_SCREEN_1,
dbo_WELL_DETAILS.TOP_SCREEN_2, dbo_WELL_DETAILS.BOTTOM_SCREEN_2,
dbo_WELL_DETAILS.TOP_SCREEN_3, dbo_WELL_DETAILS.BOTTOM_SCREEN_3,
dbo_WELL_DETAILS.SpecificCapacity,
dbo_WELL_DETAILS!Highest_Water_Level+dbo_WELL_DETAILS!REFERENCE_RL AS Max_WL,
dbo_WELL_DETAILS!Lowest_Water_Level+dbo_WELL_DETAILS!REFERENCE_RL AS Min_WL
FROM dbo_WELL_DETAILS INNER JOIN [Well Input] ON dbo_WELL_DETAILS.WELL_NO = [Well
Input].WELL_NO
WHERE (((dbo_WELL_DETAILS.DEPTH)>3) AND ((dbo_WELL_DETAILS.Well_Status) Not Like "P*" And
(dbo_WELL_DETAILS.Well_Status)<>"ni" And (dbo_WELL_DETAILS.Well_Status)<>"ND"));
43
Appendix B: Strata data query
Query can be ammended by switching to query view mode.
O:\Software\Wells Database\ARANZ\Copy of Aranz Earth Research.mdb
Query: Strata Data
Properties
DateCreated:
DOL:
9/07/2009 5:36:59 p.m.
Long binary data
DefaultView:
GUID:
LastUpdated:
ODBCTimeout:
Orientation:
RecordsAffected:
ReturnsRecords:
Updatable:
25/09/2009 11:29:35 a.m.
60
Left-to-Right
0
True
True
MaxRecords:
OrderByOn:
RecordLocks:
RecordsetType:
Type:
Friday, 25 September 2009
Page: 1
Datasheet
{guid {8A7E2AB0-8C06-4B25902E-ED10B2934CE4}}
0
False
No Locks
Dynaset
0
SQL
SELECT dbo_STRATA_DATA.WELL_NO, -1*[DepthFrom] AS Expr1, -1*[DEPTH] AS Expr2,
dbo_STRATA_DATA.STRATA_CODE, dbo_STRATA_DATA.LITHOLOGY_CODE,
dbo_STRATA_DATA.STRATA_DESCRIPT
FROM dbo_STRATA_DATA INNER JOIN [Well Input] ON dbo_STRATA_DATA.WELL_NO = [Well
Input].WELL_NO
ORDER BY dbo_STRATA_DATA.WELL_NO, -1*[DepthFrom];
44
Appendix C: Fortran source code to resolve coincident wells
c
This program reads tab delimited output from the Wells database, identifies wells with
c
coincident co-ordinates, assigns offset coordinates to eliminate co-incident locations
c
and rewrites the file with the trailing information intact.
c
c
The first four attributes listed for each well must be as follows:
c
- well_no (8 or 9 character field)
c
- grid_east (7 character field)
c
- grid north (7 character field)
c
- qar_code (1 character field)
c
c
The program is dimensioned to cater for up to 50000 wells - an error message is
displayed
c
if this limit is exceeded. The location of the first four horizontal tab characters is
c
determined in order to extract the grid coordinates. If the 1st tab is not in position
9
c
or 10 an error message is displayed warning of a format error.
c
c
Note:
c
To ensure that coordinate adjustments are made to those wells with the least available
c
information the records should be sorted by stratacode count (descending) and qar_code
(ascending).
c
c
David Scott
c
14 July 2009
c
c
Modifications
c
- redimensioned & additional comment added 25 September 2009
character*512
character*32
character*25
character*9
character*7
character*1
integer
integer*4
logical*1
line
file_in
patch
well(50000)
string
ht
tab(4)
x, y, east(50000), north(50000), qar(50000)
coincidence
max = 50000
num = 1
ht = ' '
write(*,*) 'Enter name of collars file: '
read(*,*) file_in
open(10,charnb(file_in)//'.txt')
open(11,charnb(file_in)//'.out')
open(12,charnb(file_in)//'.dup')
read(10,1) line
1 format(a)
write(11,1) charnb(line)
the output file
! horizontal tab character
!
rewrite
the
header
to
2 read(10,1,end=99) line
coincidence = .false.
c........locate the first four tabs
tab(1) = 0
tab(2) = 0
tab(3) = 0
tab(4) = 0
j = 1
do i = 1,512
if(line(i:i) .eq. ' ') then
tab(j) = i
j = j + 1
endif
if(j .gt. 4) go to 3
end do
c........extract the coordinates
3 read(line(1:tab(1)-1),4) well(num)
4 format(a)
read(line(tab(1)+1:tab(2)-1),*) x
45
read(line(tab(2)+1:tab(3)-1),*) y
read(line(tab(3)+1:tab(4)-1),*) qar(num)
c........test for coincidence
if(num .eq. 1) then
east(num) = x
north(num) = y
else
5
do i = 1,num - 1
if(x .eq. east(i) .and. y .eq. north(i)) then
coincidence = .true.
write(12,*) well(num),' ',well(i)
file
x = x + 1
y = y + 1
go to 5
consequent coincidence
endif
end do
east(num) = x
north(num) = y
endif
! coincidence
! record coincident wells in *.dup
!
reset
to
guard
against
c........update line for coincident wells
if( coincidence) then
if(tab(1) .eq. 9) then
! cater for 4 digit well
numbers (i.e. tab in position 9)
write(patch,6) well(num),ht,east(num),ht,north(num)
6
format(a8,a1,i7,a1,i7)
npatch = 24
elseif(tab(1) .eq. 10) then
! cater for 5 digit well numbers
(i.e. tab in position 10)
write(patch,7) well(num),ht,east(num),ht,north(num)
7
format(a9,a1,i7,a1,i7)
npatch = 25
else
! tab not in position 9 or 10 something is wrong with input
write(*,*) 'format error for well ', well(num)
endif
do i = 1,npatch
! patch the line with adjusted
east & north coordinates
line(i:i) = patch(i:i)
end do
endif
c........write line to output file
write(11,1) charnb(line)
num = num + 1
if(num .gt. max) then
write(*,*) 'num > max'
go to 99
endif
go to 2
99 stop
end
46
Appendix D Python script to extract screen information from well details
## read the collar file and output the screens
input_filename=r'C:\Projects\screens\Well_detail_selection.txt'
output_filename=r'C:\Projects\screens\screens.csv'
import FastRBF, Numeric
import csv
dialect=csv.excel
dialect.lineterminator='\n'
f=open(output_filename, 'w')
dataWriter = csv.writer(f, delimiter=',',dialect=dialect)
dataWriter.writerow(["well id","from","to"])
input_file=open(input_filename)
fileReader = csv.reader(input_file, delimiter='\t')
for idx,row in enumerate(fileReader):
if (idx > 0):
WELL_NO,GRID_EAST,GRID_NORTH,QAR_CODE,REFERENCE_RL,QAR_RL,Expr1,
DEPTH,Strata,TOP_SCREEN_1,BOTTOM_SCREEN_1,TOP_SCREEN_2,BOTTOM_SCREEN_2,TOP_SCREEN_3,BOTTOM_SCR
EEN_3,SpecificCapacity,Highest_Water_Level,Lowest_Water_Level=row
TOP_SCREEN_1=TOP_SCREEN_1.rstrip()
BOTTOM_SCREEN_1=BOTTOM_SCREEN_1.rstrip()
if TOP_SCREEN_1 != '' and BOTTOM_SCREEN_1 != '':
dataWriter.writerow([WELL_NO,TOP_SCREEN_1,BOTTOM_SCREEN_1])
f.close()
47
APPENDIX 2: FORTRAN code for calculation of
monthly recharge
c
c
c
c
c
c
CP model 108 rows x 106 columns
19720101 start
climate data read from *.lst files
averages written as separate model input
recharge written in MODFLOW2000 format
DMS 3 June 2010
implicit real*8 (a-h,o-z)
dimension
x(200,200), y(200,200), paw(200,200),
*
j0(200,200), k0(200,200), w_rain(200,200),
*
recharge(200,200), rain(31), pet(31), total(200,200)
real*8
lat, long
integer*4
date, yyyymmdd, lastdate
integer
cellid, yyyy, dd, daysinmonth, row, col
logical
first, exists
character*132 line, file_in, data_directory
character*9
fmtin
character*7
climate
data_directory = "C:\TEMP\vcs\"
nrow = 108
ncol = 106
do j = 1,ncol
do k = 1,nrow
total(k,j)
paw(k,j)
x(k,j)
y(k,j)
end do
end do
! CP model
! initialise arrays
=
=
=
=
0.0
-999.0
-1e30
-1e30
open(15,'recharge.dat')
open(16,'total_recharge.dat')
nrchop = 3
active cell
irchcb = 51
cell flow terms will be written
inrech = 1
fluxes
inirch = 1
locat = 18
cnstnt = 1.0
fmtin = '(10e12.4)'
iprn
= -1
factor = 1.0/30.44/1000.0
day
write(15,2)
2 format('# MODFLOW2000 Recharge Package')
write(15,3)
3 format('PARAMETER 0')
write(15,1) nrchop, irchcb
1 format(2i10)
! total recharge per cell
! flag unread paw values
!
!
!
recharge
unit
applied
number
layer
to
variable
to
highest
which
cell-by-
of
recharge
! only read if nrchop=2
!
mm
per
month
=>
m
per
c.......read the grid cell details
open(10,'grid_paw.csv')
read(10,*) line
! ignore header
i = 1
10 read(10,*,end=20) row, col, x(row,col), y(row,col), pawavg
paw(row,col)
= 0.67*pawavg
w_rain(row,col) = paw(row,col)
! start fully saturated
i = i + 1
go to 10
20 imax = i - 1
write( *,*) imax, 'grid_cell details read'
48
c.......relate model grid cells to virtual climate stations
inquire(file='recharge.dbg',exist=exists)
if( exists ) then
! assign vcs from saved
file
write(*,*) 'Assigning vcs to grid from saved file'
open(17,'recharge.dbg')
do j = 1,ncol
do k = 1,nrow
read(17,*) ks, js, pawkj, j1, k1
if(j .ne. js .or. k .ne. ks) then
! incompatible saved file
write(*,*) 'recharge.dbg incompatible'
go to 99
else
j0(k,j) = j1
k0(k,j) = k1
endif
end do
end do
close(17)
else
! create new assignment
open(17,'recharge.dbg')
write(*,*) 'Calculating vcs grid assignments'
do j = 1,ncol
write(*,*) j
do k = 1,nrow
j0(k,j) = 999
k0(k,j) = 999
distance = 1e6
if(paw(k,j) .gt. 0) then
! skip grid cells with paw >= 0
open(11,'coords.prn')
30
read(11,*,end=31) x1, y1, j1, k1
write(climate,41) j1, k1
c
write(*,*) k, j, climate
file_in = charnb(data_directory)//charnb(climate)//'.lst'
inquire(file=file_in,exist=exists)
if( .not. exists ) then
c
write(*,*) k, j, x1, y1, j1, k1, file_in
go to 30
endif
r = ((x1 - x(k,j))/1000.0)**2 + ((y1 - y(k,j))/1000.0)**2
if(r .lt. distance) then
distance = r
j0(k,j) = j1
k0(k,j) = k1
endif
go to 30
endif
31
close(11)
write(17,*) k, j, paw(k,j), j0(k,j), k0(k,j), distance
end do
end do
close(17)
endif
write( *,*) 'Virtual climate stations assigned to model grid'
c.......now step
j0old
=
k0old
=
yyyymmdd =
icount
=
through the daily time steps
0
0
19720101
0
40 total_recharge = 0.0
do j = 1,ncol
do k = 1,nrow
recharge(k,j) = 0.0
paw >= 0
j0new = j0(k,j)
! set initial target date
! count number of outputs
! dont run budget for cells with
! test if last climate site can be
reused
k0new = k0(k,j)
if(j0new .eq. j0old .and. k0new .eq. k0old) then
go to 45
endif
! use current rain & pet
c........open climate station record (file 12) and corresponding average pet (file 13)
49
41
c
write(climate,41) j0new, k0new
format('P',2i3.3)
write(*,*) file_in
open(12,charnb(file_in),status='old',err=98)
c.......find the right record
42
read(12,46,end=90) line
46
format(a)
read(line(11:80),*) lat, long, date
if(date .eq. yyyymmdd) then
! yyyymmdd is the date of
the end day of the previous month
daysinmonth = 0
first = .true.
43
read(12,46,end=90) line
yyyy = date/10000
mm
= (date - 10000*yyyy)/100
dd
= date - 10000*yyyy - 100*mm
read(line(11:80),*) lat, long, date, dayrain, daypet
if(first) then
first = .false.
elseif(dd .eq. 1) then
! new month encountered
go to 44
! go to budgeting
endif
daysinmonth
= daysinmonth + 1
lastdate
= date
rain(daysinmonth) = 1.1*dayrain
! apply ground-level gauge
correction
if(daypet .lt. 0.0) then
!
correct
negative
pet
estimates
pet(daysinmonth) = 0.0
else
pet(daysinmonth) = daypet
endif
go to 43
else
go to 42
endif
44
close(12)
j0old = j0new
k0old = k0new
c........dryland
45
appl = 0.0
!
zero
application
dryland option
do i = 1,daysinmonth
call budget(paw(k,j),rain(i),pet(i),aet,w_rain(k,j),appl,
*
drainage)
recharge(k,j) = recharge(k,j) + drainage
total(k,j)
= total(k,j) + drainage
total_recharge = total_recharge + drainage
end do
49
depth
for
endif
continue
end do
end do
write(*,*) yyyymmdd
c
write(15,1) inrech, inirch
write(15,51) locat, cnstnt, fmtin, iprn, yyyymmdd
51 format(i10,f10.3,11x,a9,i10,5x,'RECHARGE (',i10,')')
do k = 1,nrow
write(15,53) (factor*recharge(k,j),j=1,ncol)
53
format(10e12.4)
end do
write(16,*) yyyymmdd, total_recharge
write(*,*) yyyymmdd, daysinmonth
yyyymmdd = lastdate
icount
= icount + 1
go to 40
c........write model cell summary
50
90 write(*,*) 'Transient recharge written to recharge.dat'
close(15)
open(15,'model_cell.dat')
do k = 1,nrow
do j = 1,ncol
write(15,91) k, j, j0(k,j), k0(k,j), x(k,j), y(k,j),
*
paw(k,j), total(k,j)
91
format(4i5,2g12.0,2g12.4)
endif
end do
end do
close(15)
c........write average recharge for model input - divide total by icount months
open(15,'average_recharge.dat')
write(15,2)
write(15,3)
write(15,1) nrchop, irchcb
write(15,1) inrech, inirch
write(15,51) locat, cnstnt, fmtin, iprn, yyyymmdd
do k = 1,nrow
write(15,53) (factor*total(k,j)/real(icount),j=1,ncol)
end do
close(15)
write(*,*) 'Average recharge written to average_recharge.dat'
write(*,*) icount, ' months of recharge averaged'
go to 99
98 write(*,*) 'Error opening ', file_in
99 stop
end
subroutine budget(paw,rain,pet,aet,w,appl,drainage)
a
= 6.0
relationship
smfac
= (1.0 - exp(-a*w/paw))/
*
(1.0 - 2.0*exp(-a) + exp(-a*w/paw))
aet
= smfac*pet
w
= w + rain + appl - aet
drainage = 0.0
if(w .gt. paw) then
drainage = w - paw
w
= paw
elseif(w .lt. 0.0) then
w = 0.0
endif
return
end
!
constant
in
aet/pet
vs
w/paw
51
APPENDIX 3: Fortran codes for aggregation of
Wells/Consents data and synthesis of water use
(a) Aggregation of Wells and Consents data
c
Program Aggregate_wells
character*132 header
character*50 WaterUseDe, WaterUseDe_old
character*20 well, old_well, wateruse_records(1000)
character*2
well_status, use_1, use_2, use_3, aquifer_name,
*
well_status_old, use_1_old, use_2_old, use_3_old,
*
aquifer_name_old
dimension
areas(51)
real
minArea, minArea_old, MaxRate, MaxVolume
integer*4
commence_date, expiry_date, start_date,
*
end_date, grid_east, grid_north, countwu,
*
grid_east_old, grid_north_old, countwu_old
logical*1
wateruse_record, irrigation
common old_well,well,use_1_old,use_1,use_2_old,use_2,use_3_old,
*
use_3,well_status_old,well_status,countwu_old,countwu,
*
area_old,area,grid_east_old,grid_east,grid_north_old,
*
grid_north,aquifer_name_old,aquifer_name,depth_old,depth,
*
WaterUseDe_old,WaterUseDe,Mod_grid_I_old,Mod_grid_I,
*
PAW_AVG_old,PAW_AVG
nyears = 51
open(11,'out.csv')
write(11,*) 'well,yn,start_date,end_date,area,use_1,use_2,use_3,Wa
*terUseDe,countwu,grid_east,grid_north,aquifer_name,depth,Mod_grid,
*PAW_AVG,y60-61,y61-62,y62-63,y63-64,y64-65,y65-66,y66-67,y67-68,y6
*8-69,y69-70,y70-71,y71-72,y72-73,y73-74,y74-75,y75-76,y76-77,y77-7
*8,y78-79,y79-80,y80-81,y81-82,y82-83,y83-84,y84-85,y85-86,y86-87,y
*87-88,y88-89,y89-90,y90-91,y91-92,y92-93,y93-94,y94-95,y95-96,y96*97,y97-98,y98-99,y99-00,y00-01,y01-02,y02-03,y03-04,y04-05,y05-06,
*y06-07,y07-08,y08-09,y09-10,y10-11'
nrec = 0
open(12,'wells_with_wateruse_data.txt',status='old',err=6)
do i = 1,1000
read(12,*,end=3) wateruse_records(i)
end do
3 nrec = i - 1
6 write(*,*) nrec, ' wells with wateruse data'
! note use records
open(10,'in.txt')
read(10,*) header
c........read the first record
! ignore header
read(10,*) well, well_status, area, use_1, use_2, use_3,
commence_date, expiry_date, countwu, grid_east,
grid_north, aquifer_name, depth, MaxRate,
MaxVolume, consecDays,
minArea, WaterUseDe, Mod_grid_I, PAW_AVG
call zero(areas,nyears)
! initialise
start_date = 999999
end_date
= -999999
if(charnb(WaterUseDe) .eq. 'Irrigation') then
irrigation = .true.
else
irrigation = .false.
endif
call set_dates(start_date,end_date,commence_date,expiry_date)
call set_old
call assign_areas(nyears,commence_date,expiry_date,
*
minArea,consecDays,MaxVolume,MaxRate,areas,irrigation,
*
WaterUseDe,well)
*
*
*
*
c........read the remaining records
1 read(10,*,end=99) well, well_status, area, use_1, use_2, use_3,
*
commence_date, expiry_date, countwu, grid_east,
52
*
*
*
grid_north, aquifer_name, depth, MaxRate,
MaxVolume, consecDays, minArea, WaterUseDe,
Mod_grid_I, PAW_AVG
if(charnb(well) .ne. charnb(old_well)) then
4
*
*
*
*
*
2
*
! new well
! write previous well
if(nrec .eq. 0) then
wateruse_record = .false.
else
do i = 1,nrec
if(charnb(old_well).eq.charnb(wateruse_records(i))) then
wateruse_record = .true.
go to 4
endif
end do
endif
write(11,2) charnb(old_well), wateruse_record,
start_date, end_date, area_old,
use_1_old, use_2_old, use_3_old, WaterUseDe_old,
countwu_old, grid_east_old, grid_north_old,
aquifer_name_old, depth_old, Mod_grid_I_old,
PAW_AVG_old, (areas(i),i=1,nyears)
format(a,','l1,2(',',i8),',',f10.1,3(',',a2),',',a,
3(',',i8),',',a2,',',f6.1,',',i8,',',f8.1,51(',',f12.1))
call zero(areas,nyears)
! reinitialise
start_date = 999999
end_date
= -999999
irrigation = .true.
else
irrigation = .false.
endif
call set_old
*
*
WaterUseDe,well)
else
! update existing well
*
*
WaterUseDe,well)
endif
go to 1
99 do i = 1,nrec
if(charnb(old_well) .eq. charnb(wateruse_records(i))) then
wateruse_record = .true.
go to 5
endif
end do
5 write(11,2)
*
*
*
*
*
stop
end
charnb(old_well), wateruse_record,
start_date, end_date, area_old,
use_1_old, use_2_old, use_3_old, WaterUseDe_old,
countwu_old, grid_east_old, grid_north_old,
aquifer_name_old, depth_old, Mod_grid_I_old,
PAW_AVG_old, (areas(i),i=1,nyears)
c
*************************************************************************
subroutine zero(array,n)
c
*************************************************************************
dimension array(51)
do i = 1,n
array(i) = 0.0
! initialise
of areas
end do
return
end
c
array
*************************************************************************
53
*
*
c
subroutine assign_areas(nyears,commence_date,expiry_date,
WaterUseDe,well)
*************************************************************************
character*50 WaterUseDe
character*20 well
dimension
areas(51)
real
minArea, MaxRate, MaxVolume
integer*4
commence_date, expiry_date
logical*1
irrigation
do i = 1,nyears
date = 21916 + real(i)*365.25
if(date .gt. commence_date .and. date .lt. expiry_date) then
for year i
if( irrigation) then
indicates irrigation well
record as area
if(minArea .gt. 0.0) then
areas(i) = minArea
else
write(*,*) well, minArea, ' <= 0 '
endif
endif
else
indicates non-irrigation
if(consecDays .gt. 0) then
areas(i) = MaxVolume/consecDays
elseif(MaxRate .gt. 0) then
areas(i) = -86.4*MaxRate
daily volume, flag as negative
else
areas(i) = -999.0
data
endif
endif
endif
end do
return
end
c
c
consent
initial
active
WaterUseDe
! consistent use so
! use minArea
! ignore inconsistent uses
!
initial
WaterUseDe
! use MaxVolume/consecDays
! use MaxRate converted to
!
indicate
no
available
*************************************************************************
subroutine set_old
*************************************************************************
character*50 WaterUseDe, WaterUseDe_old
character*20 well, old_well
character*2
well_status, use_1, use_2, use_3, aquifer_name,
*
well_status_old, use_1_old, use_2_old, use_3_old,
*
aquifer_name_old
integer*4
countwu,countwu_old
common old_well,well,use_1_old,use_1,use_2_old,use_2,use_3_old,
*
use_3,well_status_old,well_status,countwu_old,countwu,
*
area_old,area,grid_east_old,grid_east,grid_north_old,
*
grid_north,aquifer_name_old,aquifer_name,depth_old,depth,
*
WaterUseDe_old,WaterUseDe,Mod_grid_I_old,Mod_grid_I,
*
PAW_AVG_old,PAW_AVG
old_well
use_1_old
use_2_old
use_3_old
well_status_old
countwu_old
area_old
grid_east_old
grid_north_old
aquifer_name_old
depth_old
WaterUseDe_old
Mod_grid_I_old
PAW_AVG_old
return
end
54
!
!
=
=
=
=
=
=
=
=
=
=
=
=
=
=
well
use_1
use_2
use_3
well_status
countwu
area
grid_east
grid_north
aquifer_name
depth
WaterUseDe
Mod_grid_I
PAW_AVG
c
c
*************************************************************************
subroutine set_dates(start_date,end_date,commence_date,
*
expiry_date)
*************************************************************************
integer*4 commence_date, expiry_date, start_date, end_date
if(commence_date .gt. 0 .and.
start_date .gt. commence_date) then
start_date = commence_date
endif
if(expiry_date .gt. 0 .and.
*
end_date .lt. expiry_date) then
end_date = expiry_date
endif
return
end
*
(b) Synthesis of irrigation water use
c
program irrigsim
character*132 header
character*80 line, file_in, file_out, data_directory
character*50 WaterUseDe
character*20 well
character*7
climate
character*2
well_status, use_1, use_2, use_3, aquifer_name
character*1
map
dimension
areas(51), demands(1000), q(1000)
real*8
lat, long
integer*4
start_date, end_date, grid_east, grid_north, date,
*
well_ident
integer
countwu, year, day, period_length(1000),
*
period_from(1000), period_to(1000), well_no, prefix
logical
exists, irrig
nyears = 51
index = 0
do i = 1,1000
demands(i) = 0.0
end do
c
c
data_directory = "O:\DATA\NIWA Virtual Climate Station Network\Vir
*tual Climate Data\"
data_directory = "C:\TEMP\vcs\"
open(15,'irrigsim.out')
c........read stress period specification
open(10,'time_steps.csv')
i = 1
2 read(10,*,end=3) period_length(i), idum1, idum2,
*
period_from(i), period_to(i)
i = i + 1
go to 2
3 nper = i - 1
write(*,*) nper, 'stress period details read'
close(10)
c........read irrigation well details
open(10,'irrigation.csv')
read(10,*) header
1 read(10,*,end=50) well, start_date, end_date, area,
*
use_1, use_2, use_3, WaterUseDe, countwu,
*
grid_east, grid_north, aquifer_name, top, bot,
*
Mod_grid_I, PAW_AVG, (areas(i),i=1,nyears)
paw = 0.67*PAW_AVG
x0 = grid_east
y0 = grid_north
c........identify closest synthetic climate station (file 11)
j0 = 0
k0 = 0
open(11,'coords.prn')
distance = 1e12
55
10 read(11,*,end=20) x, y, j, k
write(climate,21) j, k
inquire(file=file_in,exist=exists)
if( .not. exists ) go to 10
r = ((x - x0)/1000.0)**2 + ((y - y0)/1000.0)**2
if(r .lt. distance) then
distance = r
j0
= j
k0
= k
endif
go to 10
20 close(11)
if(j0 .eq. 0 .or. k0 .eq. 0) then
! no station identified
write(*,*) j0, k0, ' no station identified'
go to 50
endif
c........open climate station record (file 12)
write(climate,21) j0, k0
21 format('P',2i3.3)
open(12,charnb(file_in),status='old')
c.........initialise parameters
w_irrig = paw
demand = 0.0
imnth
= 0
c........step through daily climate record
31 read(12,32,end=35) line
32 format(a)
c........for the Selwyn tribs case ignore years prior to 1972 (i.e. those without pet data)
year = date/10000
if(year .lt. 1972) go to 31
c
read(line(11:80),*) lat, long, date, rain, pet
write(*,*) well
year = date/10000
month = (date - 10000*year)/100
day
= date - 10000*year - 100*month
iyr
= year - 1959
! pointer for areas()
rain = 1.1*rain
if(pet .lt. 0.0) then
pet = 0.0
endif
if(month .ge. 5 .and. month .le. 9) then
! apply ground-level gauge correction
! correct negative pet estimates
! irrigation season october thru
april
irrig = .false.
else
irrig = .true.
endif
if(day .eq. 1) then
! start a new month
if(imnth .gt. 0) then
q(imnth)
= demand
demands(imnth) = demands(imnth) + demand
endif
imnth = imnth + 1
demand = 0.0
endif
c........generic irrigation
appl = 0.0
if( irrig ) then
if(w_irrig .lt. 0.5*paw) then
appl = (paw - w_irrig)/0.8
!
appl
capacity with 80% efficiency
endif
endif
call budget(paw,rain,pet,aet,w_irrig,appl,drainage)
demand = demand + appl*areas(iyr)*10.0
! mm x ha => m3
go to 31
56
to
restore
to
field
c........end of record, write non-zero demand to GW Vistas input file
35 close(12)
non_zero = 0
num_mnth = imnth - 1
do i = 1,num_mnth
if(q(i) .gt. 0.0) then
non_zero = non_zero + 1
endif
end do
write(*,33) charnb(well), grid_east, grid_north, top, bot,
*
non_zero
write(15,33) charnb(well), grid_east, grid_north, top, bot,
*
non_zero
33 format(a20,2(',',i10),2(,',',f10.2),',',i5)
do i = 1,num_mnth
if(q(i) .gt. 0.0) then
write(15,34) i+3, i+3, -q(i)/real(period_length(imnth+3))
34
format(i5,',',i5,',',f10.3,', 0.0')
endif
end do
imnth = 0
go to 1
50 open(13,'demands.txt')
do i = 1,1000
write(13,*) i, demands(i)
end do
stop
end
subroutine budget(paw,rain,pet,aet,w,appl,drainage)
a
= 6.0
relationship
smfac
= (1.0 - exp(-a*w/paw))/
*
(1.0 - 2.0*exp(-a) + exp(-a*w/paw))
aet
= smfac*pet
w
= w + rain + appl - aet
drainage = 0.0
if(w .gt. paw) then
drainage = w - paw
w
= paw
elseif(w .lt. 0.0) then
w = 0.0
endif
return
end
!
constant
in
aet/pet
vs
w/paw
57
APPENDIX 4:
processing
Batch files used for distributed
a) Batch file used to initiate Parallel PEST distributed processing
@echo off
echo ****************************************
echo %date%, %time%, ENROL.BAT START
echo ****************************************
Title PESTRUN
::prompt $d,$s$t,$s
echo Preparing to enrol in parallel processing
echo ----------------------------------------if exist c:\temp\pest\ goto update
echo Creating temporary directory on local drive
::mkdir c:\temp\pest\
mkdir c:\temp\pest\logs\
:update
echo Updating model files to temporary directory
echo ------------------------------------------cd /d c:\temp\pest
replace I:\GWmodel\model\*.* c:\temp\pest /a
replace I:\GWmodel\model\*.* c:\temp\pest /u
if exist I:\GWmodel\slaves\%computername% goto enrol
echo Creating sub-directory on network drive
echo --------------------------------------mkdir I:\GWmodel\slaves\%computername%\
if exist I:\GWmodel\slaves\%computername% goto enrol
REM Abandon process if sub-directory has not been successfully created
echo Unable to create sub-directory...
echo Abandoning parallel processing
goto end
:enrol
echo Registering availability for parallel processing
echo -----------------------------------------------rem pushd \\opal\corpdata\GWmodel\slaves\%computername%
cd /d I:\GWmodel\slaves\%computername%
del *.* /q
REM Check to confirm that directory is empty
dir |find " 0 File(s)" > nul
if not errorlevel 1 goto doit
REM Abandon process if it has not been possible to delete all files
echo Unable to delete all files from sub-directory...
echo Abandoning parallel processing
echo ----------------------------goto end
:doit
echo ****************************************
echo %date%, %time%, STARTING SLAVE
echo ****************************************
copy I:\GWmodel\model\ppmodel.bat
::I:\GWmodel\bin\pslave < I:\GWmodel\pslave.in
C:\temp\PEST\pslave < C:\temp\PEST\pslave.in
IF ERRORLEVEL 1 GOTO RUNfail
echo Parallel processing task completed
echo ---------------------------------GOTO end
:RUNfail
ECHO.
ECHO =================ENROL.BAT FAIL=========================
ECHO *** Problem with PPest execution, batch terminated ***
ECHO ========================================================
58
GOTO end
:end
echo.
echo ****************************************
echo %date%, %time%, ENROL.BAT END
echo ****************************************
b) Batch file used to initiate the BeoPEST distributed processing
@ECHO
TITLE
ECHO.
ECHO
ECHO
ECHO
SET
SET
SET
SET
SET
SET
off
Groundwater Model ENROL.BAT - Contact MikeT or MattS for more info
-------------------------------------------%date%, %time%, ENROL.BAT START
--------------------------------------------
master=HP1204
port=4006
pestfile=gv2_svd.pst
slavedir=c:\temp\%computername%
modeldir=\\opal\corpdata\GWmodel\model
logdir=\\opal\corpdata\GWmodel\logs
ECHO Settings: Master=%master% Port=%port% Pestfile=%pestfile%
ECHO.
:dirs
ECHO *** Preparing to enrol in parallel processing...
IF EXIST %slavedir%\ GOTO update
ECHO ...Creating pest directory on local drive......
MD %slavedir%
IF ERRORLEVEL 1 GOTO updatefail
:update
ECHO *** Updating model files in local directory.....
REPLACE %modeldir%\*.* %slavedir% /a
REPLACE %modeldir%\*.* %slavedir% /u
IF ERRORLEVEL 1 GOTO updatefail
GOTO beopest
:beopest
FOR /F "TOKENS=2 delims=:" %%A IN ("%time%") DO SET startmin=%%A
cD /d %slavedir%
beopest32 %pestfile% /H %master%:%port%
IF ERRORLEVEL 1 GOTO runchk
GOTO end
:runchk
REM If BeoPEST has run for less then 2 minutes then report error
FOR /F "TOKENS=2 delims=:" %%A IN ("%time%") DO SET stopmin=%%A
SET/A delta = %stopmin%-%startmin%
IF %delta% LSS 2 GOTO runfail
GOTO end
:reset
ECHO *** Waiting 30 minutes then will retry beopest......
PING 1.1.1.1 -n 1 -w 1800000 > NUL
ECHO *** %date%, %time% RESTARTING BEOPEST......
GOTO beopest
REM Error reporting
:updatefail
ECHO %date%, %time% File update error >> %logdir%\%computername%_err.log
ECHO %computername% %date%, %time% File update error >> %logdir%\~Error_summary.log
ECHO.
ECHO =================ENROL.BAT FAIL====================
ECHO *** Problem with files update, batch terminated ***
ECHO ===================================================
GOTO end
:runfail
ECHO
%date%,
%time%
BEOPEST
%logdir%\%computername%_err.log
FAIL
ERRORLEVEL:%errorlevel%
See
main
log
>>
59
ECHO
%computername%
%date%,
%time%
BEOPEST
FAIL
%logdir%\~Error_summary.log
ECHO.
ECHO =================ENROL.BAT FAIL====================
ECHO ***
Problem with BeoPest execution
***
ECHO ===================================================
GOTO reset
ERRORLEVEL:%errorlevel%
>>
c) Batch file used to initiate PEST and MODFLOW runs on each slave when determining
base parameter sensitivities (pestgv.bat)
@echo off
del gv2.hds
del gv2.ddn
fac2real <fac2real1.in >nul
kmakr <kmakr1.in >nul
fac2real <fac2realz1.in >nul
kmakr <kmakrz1.in >nul
copy
gv21._kz+gv22._kz+gv23._kz+gv24._kz+gv25._kz+gv26._kz+gv27._kz+gv28._kz+gv29._kz+gv210._kz+gv2
11._kz+gv212._kz+gv213._kz gv2._kz >nul
fac2real <fac2reals1.in >nul
kmakr <kmakrs1.in >nul
60
copy
gv21._s1+gv22._s1+gv23._s1+gv24._s1+gv25._s1+gv26._s1+gv27._s1+gv28._s1+gv29._s1+gv210._s1+gv2
11._s1+gv212._s1+gv213._s1 gv2._s1 >nul
copy gv2._s1 gv2._s2 >nul
@echo on
mf2k gv2.nam
Del finishchk.dat >nul
checkout <checkout.in
if exist finishchk.dat goto OK
goto matt
:OK
targpest
goto end
:matt
copy blank.out targpest.out
:end
d) Batch file used to initiate PEST and MODFLOW runs on each slave in calibration mode
using SVD assist (svdabatch.bat)
@echo off
REM This part of batch file added by SVDAPREP
REM
REM Delete model input files.
del points1.dat > nul
del pointz1.dat > nul
del Spoint1.dat > nul
61
del gv2.drn > nul
del gv2.wel > nul
REM
REM Run PARCALC to compute base parameters from super parameters.
parcalc > nul
REM
REM Run PICALC to compute base parameter prior information.
picalc > nul
REM
REM The following is copied directly from file pestgv.bat
REM
@echo off
del gv2.hds
del gv2.ddn
62
copy
gv21._kz+gv22._kz+gv23._kz+gv24._kz+gv25._kz+gv26._kz+gv27._kz+gv28._kz+gv29._kz+gv210._kz+gv2
11._kz+gv212._kz+gv213._kz gv2._kz >nul
copy
gv21._s1+gv22._s1+gv23._s1+gv24._s1+gv25._s1+gv26._s1+gv27._s1+gv28._s1+gv29._s1+gv210._s1+gv2
11._s1+gv212._s1+gv213._s1 gv2._s1 >nul
copy gv2._s1 gv2._s2 >nul
@echo on
mf2k gv2.nam
Del finishchk.dat >nul
checkout <checkout.in
if exist finishchk.dat goto OK
goto matt
:OK
targpest
goto end
:matt
copy blank.out targpest.out
:end
63
APPENDIX 5:
Documentation of the code and
instruction files for the program checkout.exe
a) FORTRAN code for the program checkout.exe (checkout.for)
program checkout
C
Program checkout reads a modflow list output to check if it terminated normally and
returns a code to say whether it did or not.
implicit none
integer msteps
integer iline,n,m,mstep,i,istep,ierr,num
character*200 infile,outfile
character*300 cline
logical
exists
C -- The input file is opened.
100 write(6,110,advance='no')
110 format(' Enter name of modflow output file: ')
read(5,*) infile
open(unit=10,file=infile,status='old',err=100)
140 format(' How many time steps are represented in this file? ')
read(5,*,err=130) MSTEPS
if(MSTEPS.le.0) go to 130
! Checkout will expect the final stress period to
match this value
C -- The name of the output site sample file is now acquired.
write(6,*)
260 format(' Enter name for output file: ')
read(5,*) outfile
C -- The output file is now read.
istep = 0
do
read(10,'(a)',end=500) cline
n = index(cline,'TIME SUMMARY AT END OF TIME STEP')
if(n .ne. 0) then
read(cline,501) istep
501
format(64x,i)
end if
end do
500 if(istep .eq. msteps) then
! list output is complete
open(unit=20,file=outfile)
! create output file to signal completion
write(20,*) 'finished'
close(unit=20)
else
inquire(file='count.dud',exist=exists)
if( exists ) then
open(20,'count.dud')
read(20,*) num
num = num + 1
close(20)
else
num = 1
endif
open(20,'count.dud')
write(20,*) num
close(20)
end if
close(unit=10)
write(6,510) trim(infile)
510 format(/,' - file ',a,' read ok.')
end
64
b) Instruction file (checkout.in)
gv2.lst
463
finishchk.dat
c) Blank model observation output which is copied to targpest.out if MODFLOW model
run does not converge (blank.out)
GV Processing Complete
o
1 Computed Value=
o
2 Computed Value=
o
3 Computed Value=
…
o42487 Computed Value=
0.0000
0.0000
0.0000
0.0000
0.0000
0.0000
65
APPENDIX 6: FORTRAN code of post.exe used for
post-processing of transient model calibration
results
character*132 line
character*10 well, well0
integer
group
logical*1
first
open(10,'target.out')
read(10,*) line
! ignore header
open(11,'post.csv')
write(11,*) 'well,x,y,rms,dif@mean,dif@max,dif@min,sdv,num'
well0
first
= '
= .true.
'
1 read(10,*,end=99) well, time, x, y, layer, observed, computed,
*
weight, group
if(well .ne. well0) then
! record results for well0
if( first ) then
first = .false.
else
denom = real(num)*real(num - 1)
arg1 = real(num)*obs_ssq - obs_sum*obs_sum
arg2 = real(num)*sim_ssq - sim_sum*sim_sum
if(denom .gt. 0.0 .and. arg1 .gt. 0 .and. arg2 .gt. 0) then
obs_sdv = sqrt(arg1)/denom
sim_sdv = sqrt(arg2)/denom
sdv_rat = obs_sdv/sim_sdv
else
sdv_rat = -9999.
endif
write(11,2) charnb(well0), x0, y0, sqrt(ssq_dif/real(num)),
*
(obs_sum-sim_sum)/real(num), obs_max-sim_max,
*
obs_min-sim_min, sdv_rat, num
endif
2
format(a,2(',',f9.1),5(',',f8.3),',',i)
well0
= charnb(well)
x0
= x
y0
= y
ssq_dif = (observed - computed)**2
num
= 1
obs_max = observed
obs_min = observed
obs_sum = observed
obs_ssq = observed*observed
sim_max = computed
sim_min = computed
sim_sum = computed
sim_ssq = computed*computed
else
ssq_dif = ssq_dif + (observed - computed)**2
obs_sum = obs_sum + observed
obs_ssq = obs_ssq + observed*observed
sim_sum = sim_sum + computed
sim_ssq = sim_ssq + computed*computed
if(observed .gt. obs_max) then
obs_max = observed
sim_max = computed
endif
if(observed .lt. obs_min) then
obs_min = observed
sim_min = computed
endif
num = num + 1
endif
66
go to 1
99 denom
= real(num)*real(num - 1)
if(denom .gt. 0.0) then
obs_sdv = sqrt(real(num)*obs_ssq - obs_sum*obs_sum)/denom
sim_sdv = sqrt(real(num)*sim_ssq - sim_sum*sim_sum)/denom
sdv_rat = obs_sdv/sim_sdv
else
sdv_rat = 0.0
endif
write(11,2) charnb(well0), x0, y0, sqrt(ssq_dif/real(num)),
*
(obs_sum-sim_sum)/real(num), obs_max-sim_max,
*
obs_min-sim_min, sdv_rat, num
stop
end
67

A methodology to model groundwater flow in sub

Transcription

Similar documents

The excitement this week in Lower and Upper Elementary centered

associate membership - Canterbury Golf Club

February 27, 2014 - Canterbury Christian School

the cartoonization of life

New TradiTioNs

Unitemps: Candidate brochure - Canterbury Christ Church University

NINE SUPERB APARTMENTS IN THE HEART OF

Christmas 2011

Anniversary