☰
Navigation :

Geometry Optimization

To perform a geometry optimization with Octopus one should set the CalculationMode to go:


 CalculationMode = go

At every step of the minimization, Octopus performs a full self-consistent calculation for the current geometry and uses the resulting forces (and, for cell relaxation, the stress tensor) as the gradient of the objective function. Several algorithms are available, and several quantities can be optimized.

What can be optimized

The variable GOType selects which degrees of freedom are allowed to change:

Several options can be combined with a + sign, so that ions and cell are relaxed simultaneously:


 GOType = ion_positions + cell_shape
 SCFCalculateStress = yes

For periodic systems an external hydrostatic pressure can be applied during the relaxation with HydrostaticPressure.

Periodic systems, and cell relaxation in particular, come with a few restrictions:

Constrains

Individual atoms can be kept fixed through the coordinate blocks (see Physical System). Finer, per-coordinate constraints are read from the GOConstrains block, or from an external file with XYZGOConstrains, XSFGOConstrains or PDBGOConstrains. A constraint value of zero means that the coordinate is optimized, while any non-zero value keeps it fixed:


 %GOConstrains
  'C' | 1 | 0 | 0
  'O' | 1 | 0 | 0
 %

In this example the x coordinates of both atoms remain fixed, so the distance between the two atoms along the x axis is constant. The constraints must be given in the same order in which the atoms were defined in the coordinates block.

Finally, GOCenter = yes recenters the geometry at every step and removes the translational degrees of freedom from the minimization. It cannot be used together with constraints.

Choosing a method

The minimization algorithm is selected with GOMethod. Most of the available methods use the multidimensional minimization routines from GSL: steep (steepest descent), the conjugate-gradient family cg_fr, cg_pr, cg_bfgs and cg_bfgs2, and the gradient-free simplex. An experimental, non-GSL implementation of steepest descent is also available as steep_native.

The default is GOMethod = FIRE1, which is implemented natively in Octopus. It is the default method and is found to be more robust and faster to converge than the GSL method discussed above.

The FIRE algorithm propagates the ions with a molecular-dynamics integrator, and is controlled by three additional variables:

For the GSL methods that use the forces, GOLineTol sets the tolerance of the line minimization.

The quantity being minimized is normally the total energy, but GOObjective = minimize_forces minimizes the norm of the forces instead. This is inconsistent, since the forces are still used as the gradient, and may lead to very strange behavior.

Stopping criteria

The stopping criteria are set with GOTolerance and GOMinimumMove. The minimization is stopped when all forces on the ions are smaller than GOTolerance, or when the coordinates of all species change by less than GOMinimumMove during one minimization step. Setting either variable to a negative value disables that criterion; by default only the force criterion is active, except for GOMethod = simplex, which does not use the forces and therefore requires a non-zero GOMinimumMove.

If none of the criteria is matched after GOMaxIter minimization steps (200 by default), the minimization is stopped with an error message.

Output files

File Content
geom/go.XXXX.xyz The geometry at iteration XXXX. As extra information, the title of the xyz file (second line) contains the total energy.
geom/go.XXXX.xyz_red , geom/go.XXXX.xsf For periodic systems only: the same geometry in reduced coordinates, and in XCrySDen format.
geom/optimization.log One line per iteration, with the energy, the maximum force and the maximum displacement. When the cell is relaxed, the lattice parameters, the angles and the cell volume are appended.
work-geom.xyz Every geometry for which the energy and the forces have been evaluated, appended. This includes the intermediate points of a line minimization, and is therefore longer than the list of accepted iterations.
last.xyz The geometry of the last accepted iteration, rewritten at every step. It is used to restart the optimization when FromScratch = no.
min.xyz The final geometry, written once the minimizer returns.
forces/forces.XXXX.xsf Only with Output = forces: the forces at iteration XXXX.

Machine-learned force fields

If Octopus has been compiled with support for MatterSim (using -DOCTOPUS_MATTERSIM=On), this machine-learned universal interatomic potential can take part in the geometry optimization, either as a cheap pre-optimizer or as a full replacement for the density-functional calculation.

Pre-optimization of the geometry

GOMLPreoptimize relaxes the geometry with the machine-learned force field before the actual optimization starts. On a build that includes MatterSim this is enabled by default, so a plain go run is first pre-relaxed by MatterSim, and only the resulting geometry is handed over to the density-functional optimization. To deactivate the pre-optimizer, simply set


 GOMLPreoptimize = no

The pre-optimization is performed once, before the first self-consistent cycle, and not at every iteration. It follows GOType, so it relaxes the cell as well when asked to, and it applies HydrostaticPressure. When KPointsUseSymmetries or SymmetrizeDensity is set, the symmetry of the crystal is constrained during the pre-optimization; the space group is printed before and after, so that the effect can be checked. If the cell has changed, the mesh is regenerated before the density-functional part begins.

The pre-optimization uses its own, hard-coded convergence criteria (a maximum force of 10-4 eV/Å and at most 5000 steps) and is therefore not affected by GOTolerance or GOMaxIter. Its trajectory is written to geom/ml.traj , and every frame is also dumped as an extended xyz file geom/ml_frame_N.xyz , with N counting from zero.

The default is no, rather than yes, in two cases: when MatterSim is already used as the calculator (see below), and when a cell relaxation is requested for a system that is not periodic along all three directions.

MatterSim as the calculator

Alternatively, GOCalculator = mattersim replaces Octopus entirely for the duration of the optimization: the energy, the forces and the stress tensor are evaluated by the machine-learned model at every step, and no self-consistent calculation is performed. The minimization itself, and all the variables described above, work exactly as before.


 CalculationMode = go
 GOCalculator = mattersim
 GOType = ion_positions

This is useful to relax large systems at negligible cost, or to generate a good starting point for a subsequent density-functional optimization. It is mutually exclusive with the pre-optimization described above.

A machine-learned force field is only an approximation to the true potential energy surface, and it has no knowledge of the electronic structure of your particular system. Whenever the geometry matters, the optimization should be finished with GOCalculator = internal, that is, with Octopus itself.

Requirements

MatterSim support has to be selected at compile time, with -DOCTOPUS_MATTERSIM=On, and Octopus must then be installed: the Python virtual environment holding MatterSim and its dependencies, together with the pretrained model, is created during the installation step and requires network access. See Installing Octopus with CMake for the details.

Whether a given executable includes MatterSim can be checked with


octopus -c

which lists mattersim among the optional libraries. Asking for either of the two features without such a build stops the run with

Octopus was not compiled with support for MatterSim

while a build that was configured with MatterSim but never installed fails at run time with

Unable to find the MatterSim Python environment.

The model runs on the GPU automatically whenever a CUDA-capable device is visible to PyTorch, and on the CPU otherwise; the device actually used is reported in the standard output.

Tutorials

  1. Erik Bitzek, Pekka Koskinen, Franz Gähler, Michael Moseler, and Peter Gumbsch, Structural relaxation made simple, Phys. Rev. Lett. 97 170201 (2006);  ↩︎