The original version of PEST was written in 1995. Its purpose was to assist in model calibration. At that time, what set it apart from other software was its non-intrusive interface with any model that it calibrated. PEST exchanges information with a model through the model's own input and output files.

In these pages we will discuss just what "calibration" means. We will discuss whether a model earns its right to assist in environmental management just because it is "well calibrated". Looking ahead, there is a lot more to effective decision-support modelling than this.

It has been a long journey. In the old days, a PEST user had to ensure that the inverse problem that he/she asked PEST to solve was well-posed. Being "well-posed" means that the inverse problem has a unique solution. This can only happen if "parameter parsimony" is the golden rule.

The truth is that when it comes to groundwater model calibration, uniqueness must always be manufactured. The question is how to do this best.

Uniqueness is best achieved mathematically. This allows model parametrisation to recognise the inherent complexity and heterogeneity of natural systems. This leads to better calibration.

Just as importantly, with the ability to work with a large number of parameters comes the ability to examine the repercussions of subsurface hydraulic property heterogeneity on predictive uncertainty. If a decision-maker does not know the uncertainties that are associated with management-critical model predictions, then he/she cannot answer the question that is fundamental to any decision-making - what can go wrong?

So over the years since its first release, PEST development has focused on highly parameterised inversion, and concomitant parameter and predictive uncertainty analysis. At the same time, much effort has been devoted to the development of utility software that assist in PEST setup while enabling PEST-to-model linkages in highly-parameterised and data-intensive contexts.

Most of PEST, and all of its utility programs are written in FORTRAN. (Some C++ is used for parallelisation of model runs) These are all provided as WINDOWS executables. Source code and makefiles are also provided so that they can be compiled to run on Linux platforms. All of these can be downloaded from the PEST web pages.

The PEST suite and its utility support suites are comprised of many programs. This presents a problem. Which programs should be used for what purposes? Part of the role of these pages is to help you know what software support is available to you, so that you can make these choices.

However these pages have a broader purpose. Whether you use PEST or not, these pages can help you understand important issues such as:

•what modelling can, and cannot, provide to the decision-making process;

•the role of history-matching in decision-support modelling;

•options for parameter and predictive uncertainty analysis.

PEST++ began its life in 2012. As the name suggests, it is written in C++. It is designed from the ground up to work in highly parameterised environments. Its design is also more modular than that of PEST. This makes programming teamwork easier. To download PEST++, and to find out more about it, visit its GitHub site.

Importantly, programs of the PEST++ work with a model in the same way that PEST does. That is, their interface with a model is non-intrusive. They communicate with a model through the model's own input and output files. Furthermore, they do this using the same protocols as PEST.

At the time of writing, there are seven members of the PEST++ suite. They are as follows.

The PEST++ program that most resembles PEST is PESTPP-GLM. However it does not (as yet) have all of PEST's inversion features. (Though it has a few that PEST does not.)

At the time of writing, the most popular PEST++ programme is PESTPP-IES. PESTPP-IES can perform highly model-run-efficient history-matching and nonlinear uncertainty analysis. We talk more about PESTPP-IES in other pages. We also discuss programs of the PEST suite that can assist in PESTPP-IES setup, and that provide alternatives to certain aspects of its functionality.

Input files for PEST and PEST++ have much in common. So if you are set up to use PEST, then you are set up to use PEST++. (Depending on which input protocols you choose for PEST++, the reverse is not necessarily true.)

In contrast to the PEST suite, the PEST++ suite is not accompanied by a set of utility programs that assist in input dataset construction and creation of links to models. Instead, the PEST++ development team offer a different approach. Setup, as well as pre/postprocessing, is accomplished using the PyEMU Python library. This blends seamlessly with the FloPy Python library. This facilitates use of PEST++ in conjunction with members of the MODFLOW family.

There is no need to choose one or the other.

If you are good at Python, then use of FloPy and PyEMU may lead you naturally to PEST++. However you need to be aware of some of the parameterisation and model post-processing options that are offered by members of the PEST suite, particularly PLPROC. Some of this same functionality will soon be available through PyEMU as a fast-running Python-callable, FORTRAN-compiled library. However PEST utility software that can assist in regularised inversion and uncertainty analysis is under continuous development. You would be unwise to ignore opportunities for innovative decision-support modelling that it offers. It is an easy matter to incorporate PEST utilities into a Python workflow.

At the same time, if you use programs of the PEST suite for tasks such as regularised inversion and linear/nonlinear uncertainty analysis, there is nothing to prevent you from using members of the PEST++ suite to undertake tasks that are not supported by the PEST suite. Back-compatibility between PEST++ input files and PEST input files normally makes the transition easy. All that may be required to make the transition is the addition of a few extra lines to a PEST control file.