KPP solvers FAQ

Current KPP documentation

We have migrated our KPP-for-GEOS-Chem documentation to https://kpp.readthedocs.io.

How do I choose the absolute and relative tolerance?

The tolerances used by solvers to check convergence are set differently for SMVGEAR and the KPP solvers.

For SMVGEAR, the range of absolute tolerance (ATOL) is defined in the mglob.dat file by YLOWU and YHIU. The relative tolerance (RTOL) is also set in mglob.dat with ERRMAXU, but it is overwritten in the code if you set it above 1d-3 (this is its max value, in other words).

For KPP-derived solvers, the tolerance are set in the GCKPP_DRIVER routine (in chemistry_mod.f). The code is distributed with the suggested values of:

• RTOL = 2d-1
• ATOL = 1d-2

which give a solution slightly more accurate but ~8% faster than SMVGEAR.

For the Rodas-3 Rosenbrock solver, runtime and accuracy of the solution for various set of tolerances are described in this pdf. Some results are reproduced in the section How does the default Rodas-3 Rosenbrock integrator compare with the SMVGEAR? below.

If you switch to Livermore solver (LSODE), you do need to set ATOL between 1d4 and 1d6, to have a performance similar to SMVGEAR.

For an accurate solution with Radau5, you need small tolerances: RTOL=1d-8 for example.

Example: Tightening tolerances for SOA simulations

Here is an instance in which the relative error tolerance RTOL had to be tightened when performing a GEOS-Chem simulation with the secondary organic aerosol tracers:

Amos P.K. Tai wrote:

I've performed a few 3-month 4x5 GEOS-5 runs with the new v8-02-03 KPP solver with two different relative tolerance levels (RTOL) in the GCKPP_DRIVER subroutine in the chemistry_mod.f module. Then I counted the number of times I got the following error:

   Forced exit from Rosenbrock due to the following error:
   --> Step size too small: T + 10*H = T or H < Roundoff
   T=   2690.36541862269      and H=  6.025073049527794E-013

When this error occurs once in a row, the run would continue; but if it occurs twice in a row, the run crashes. I counted the number of this error in each of my 3-month runs that went without crashing.

• For RTOL = 2d-1 (recommended), I've done four 3-month runs; the number of error ranges from 92 to 114.
• For RTOL = 5d-2 (reduced), I've done two 3-month runs (otherwise all the same as before); no errors were detected in both runs.

So, reducing the tolerance level, as you have suggested before, appears to solve the problem of KPP solver leading to a crash.

--Bob Y. 10:22, 10 November 2009 (EST)

More about tolerances

Tao Zeng wrote:

By reducing RTOL from 0.2 to 0.05, you were able to run the model for longer time without errors.

I tried your method and found it works. But I am quite confused with the setting. To my understanding, we enlarge the tolerance to make it not so strict, it's like to open the door a little wider. But why does it work in the opposite way in the KPP case?

Claire Carouge wrote:

I am not sure of what is happening but I think I have an idea.

The errors occur because the system arrives to a state too far from the truth to be able to converge. By tightening the tolerances, you make sure the system stays closer to the truth at every time step. Then, the problematic time steps start the chemistry with a system closer to the true state, enabling the chemistry to converge even with a tighter tolerance.

Typically, if the first time step of chemistry couldn't converge, tightening the tolerances wouldn't work but loosening the tolerance would. Since here it is not the first time step, tightening the tolerances can work by keeping the system errors smaller before.

--Bob Y. 10:35, 11 March 2010 (EST)