Hints & Tips

Q: What choices of numerical methods are available in ATLAS? When should each type of method be used?

A: The latest release of ATLAS features more choices of numerical methods for users. It also has a new more logical syntax that clears up some of the previously confusing issues with the choice of numerical method for ATLAS solutions.

ATLAS has the ability to solve up to six equations on the simulation mesh. These are the poisson equation, two carrier continuity equations, two carrier energy balance equations and the lattice heat flow equation. The choice of numerical technique in solving these equations can strongly affect both the convergence and CPU time required to complete a simulation run.

In general equations can either be solved in a coupled manner with all equations solved at once or a decoupled manner with a subset of the equation solved whilst others are held constant. The coupled solutions are best when the interactions between the equations is strong (eg. high current producing significant local heating). However they require a good initial guess to the solution variables for reliable convergence. Unless special techniques such as projection are used for calculating initial guesses this would mean that the voltage step size during a bias ramp might have to be rather small.

Decoupled methods can have advantages when the interaction between the equations is small (typically low current and voltage levels). They do not require such good initial guesses for convergence. They tend to either not converge or take excessive CPU time once the interactions become stronger.


ATLAS uses the METHOD only statement to define numerical methods. The older SYMBOLIC statement is no longer required although existing input files will run as before. To select the decoupled method for two carriers use:

method gummel carriers=2

To select the coupled method for two carriers use:

method newton carriers=2

This is the default. In fact users do not need to specify a METHOD statement at all for this case. For the majority of isothermal drift-diffusion simulations this choice of numerics is the recommended one.

ATLAS has the ability to switch automatically between different numerical methods. The syntax

method gummel newton

would start each bias point using a decoupled method and then switch to a coupled solution. This technique is extremely useful when the initial guess is not good. Typically this happens for devices with floating body effects (eg SOI).

For more complex simulation with energy balance or lattice heating other techniques are also available in ATLAS. A mixed technique where the poisson and continuity equations are solved coupled and then the other equations are decoupled can be applied. The syntax for this is:

method block

Typically this mixed technique is quicker and more robust at low lattice and carrier temperatures, whereas the fully coupled technique is better for high lattice and carrier temperatures. The mixed method can be combined very effectively with the fully coupled technique to provide improved speed and convergence for all ranges using:

method block newton

As an example of this Figure 1 shows the CPU time taken for individual biasing points for a non-isothermal energy balance simulation of second breakdown of a sub-micron MOSFET. The device was constructed using ATHENA and the mesh contains a low number of obtuse triangles (not zero). The graph clearly shows that at initially the coupled method takes much longer to converge. This is because the initial guess is not good until two bias points are solved so that projection can be used. As the voltage is increased the block method has increasing convergence difficulty whereas the time taken for the newton method is flat. The time for the mixed method has the advantages of block at lower currents, but without the severe increases of block.

The ideal solution for most problems is the use of the mixed "block newton" method initially switching to the fully coupled "newton" method as the simulation proceeds. Of course the cross-over point, which is at x=2.5 in Figure 1, varies from case to case. To avoid excessive user-interaction the "block newton" could be used throughout the simulation without a very excessive hit in terms of CPU time.

Figure 1