The "parameter data" section of a PEST control file may have two parts. The first part must contain as many lines as there are parameters The variables which appear on each of these lines are depicted below.

The second part of the "parameter data" section of a PEST control file is required only if one or more parameters are tied to other parameters. Each line in this part of the section lists the name of a tied parameter followed by the name of the parameter to which it is tied.

Part of the "parameter data" section of a real PEST control file is shown below.

Parameter names must be 12 characters or less in length. Note, however, that programs of the PEST++ suite allow parameter names of up to 200 characters in length.

The PARTRANS variable pertaining to each parameter must be set to "none", "log", "tied", or "fixed".

If you declare that the transformation status of a parameter is "log", then PEST actually estimates the log of that parameter. This happens behind the scenes. You don't need to care about its transformation status unless you formulate prior information pertaining to the parameter, or unless you undertake uncertainty analysis.

If a parameter is neither tied nor fixed, then if in doubt, log-transform.

Why is log-transformation so beneficial? There are a couple of reasons for this.

Firstly, model outputs often have a more linear relationship with a parameter if that parameter is log transformed. A more linear relationship assists the inversion process. Secondly, calculation of sensitivities with respect to parameter logs involves an implicit normalisation by parameter value. This can make sensitivities more equal between parameters. This too assists the parameter estimation process.

There are, however, limits on the extent to which this strategy can be pursued. If a parameter has a lower bound which is zero or less, then PEST will not allow you to log transform that parameter for obvious reasons.

The initial value of a parameter (provided by the PARVAL1 variable) should be its preferred value from an expert knowledge point of view. This is especially important when attempting to solve an ill-posed inverse problem. Implied or explicit regularisation should encourage each parameter to retain its initial value unless there is information to the contrary in the observation dataset.

Parameter bounds are enforced by the PARLBND and PARUBND control variables.

It makes abundant sense to prevent parameters from adopting values that would cause a model to crash.

It also makes abundant sense to ensure that parameters are prevented from being adjusted to unrealistic values. However, if bounds comprise the primary line of defence against parameter value stupidity, this suggests that a modeller is using these bounds as a primitive regularisation device (especially if lower and upper bounds are relatively close together). Numerically, bounds are not a good regularisation device, for the collision of a parameter with its upper or lower bound makes an inverse problem harder to solve.

When parameters encounter their bounds, a modeller needs to ask why this is happening. He/she also needs to ask why other forms of regularisation (such as Tikhonov regularisation) are not preventing this from happening. If a parameter that hits its bound has a relatively low composite sensitivity (see the SEN file that is updated by PEST during every iteration of the inversion process), then regularisation is either non-existent, or is not working. In contrast, if a sensitive parameter encounters one of its bounds, this suggests that PEST has little choice but to take it there. Questions follow. Is expert knowledge that imposed the bound incorrect? Or is the parameter compensating for some model defect, or for some parameter that should be adjusted but is not part of the current inversion process? A parameter's encounter with its bound effectively poses this question. A modeller should attempt to answer it.

See the PARGP variable.

The variables which govern calculation of finite difference derivatives are assigned to parameter groups rather than to individual parameters. So assign parameters of the same type to the same group.

Parameter groups serve another purpose. When Tikhonov regularisation is added to a PEST control file by the ADDREG family of utilities, the prior information equations which embody Tikhonov constraints are assigned to observation groups whose names are derived from parameter groups. Where parameters represent pilot points, a covariance matrix may be assigned to each of these observation/prior information groups, this reflecting prior spatial correlation between these parameters. In general, spatial correlation is expressed only for parameters of the same type in the same model layer. Hence parameters of different types, or parameters of the same type that belong to different model layers, should be assigned to different parameter groups.

Set SCALE and OFFSET to 1.0 and 0.0 on most occasions.

However sometimes, if PEST encounters difficulties in solving an inverse problem, this may be an outcome of the fact that one or a small number of parameters are super-sensitive. This makes it difficult or impossible for PEST to "see" the other parameters. (Or, to put it another way, the singular value spectrum of the inverse problem is very narrow.) As long as it is not log-transformed, a hypersensitive parameter can be made less sensitive by multiplying its value by a large number (perhaps 1000, or even more), and then providing it with a SCALE which is the inverse of this number. (Adjust parameter bounds to accommodate this). The parameter that PEST "sees" (i.e. the multiplied parameter) then has to change by a larger amount to have an effect on model outcomes. So its sensitivity is reduced.

The opposite applies if a parameter is very insensitive, and you would like PEST to have a better view of it.

The OFFSET variable can be used to maintain positivity of a parameter, or to give it a more "natural" value (from the point of view of parameter adjustment). The later may apply to parameters that are topographic in nature.

This variable is rarely different from 1 (if it is supplied at all). It selects the model command that is used when finite-difference derivatives are calculated with respect to a particular parameter.