|
| 1 | +------------------------------- |
| 2 | +Running a geometry optimization |
| 3 | +------------------------------- |
| 4 | +In the following we will assume to have a valid user input file for the water |
| 5 | +molecule called ``h2o.inp``, e.g. like this |
| 6 | + |
| 7 | +.. include:: h2o_geopt.inp |
| 8 | + :literal: |
| 9 | + |
| 10 | +A geometry optimization can be run by adding ``GeometryOptimizer`` section to any normal ``.inp`` file and setting the run keyword to ``true``: |
| 11 | + |
| 12 | +.. include:: geopt_section.inp |
| 13 | + :literal: |
| 14 | + |
| 15 | +This will start a geometry optimization with the default settings. |
| 16 | + |
| 17 | +Obtaining accurate forces |
| 18 | +------------------------- |
| 19 | + |
| 20 | +In the above H_2O input example the ``world_prec`` parameter is chosen really small. This is necessary to get accurate forces. |
| 21 | +If a looser precision it is chosen, the geometry optimization may not converge. Pay attention to the warning:: |
| 22 | + |
| 23 | + WARNING: Noise in force is larger than 0.2 times the larges force component!!! |
| 24 | + |
| 25 | + Geometry optimization onvergence cannot be guaranteed!!! |
| 26 | + |
| 27 | +This is printed when the noise level is too high. Usually, geometry optimizations will not converge when this warning is printed. |
| 28 | +In that case, either tighten the ``world_prec``, ``orb_thrs`` (or both) _or_ loosen the convergence criterion of the geometry optimization. |
| 29 | + |
| 30 | + |
| 31 | +Pre-relax input geometries |
| 32 | +-------------------------- |
| 33 | + |
| 34 | +Running high precision multi resolution wavelet calculations is computationally expensive. |
| 35 | +It is therefore not advisable to use an input geometry with high forces, a small ``world_prec`` and start the simulation. |
| 36 | +An optimized workflow would look something like this: |
| 37 | + |
| 38 | +1. Optimize the geometry with a gaussian basis set. This can be done with a number of gaussian basis set codes |
| 39 | +2. Use inaccurate forces (``world_prec`` ~ 1e-4) and a rather loose convergence criterion (``max_force_component`` ~ 1e-2) for the |
| 40 | + geometry optimization for a pre-relaxation with MRChem. |
| 41 | +3. Do a tight geometry optimization (``max_force_component`` ~ 5e-4) and with an accurate MRChem calculation (``world_prec`` ~ 1e-6) |
| 42 | + |
| 43 | + |
| 44 | +Reuse orbitals |
| 45 | +-------------- |
| 46 | + |
| 47 | +For tight geometry optimizations where the input structure is already close to the local minimum (using cheaper pre-relaxations), it makes sense |
| 48 | +to use the orbitals from the geometry optimization iteration *i* for the start of iteration *i+1*. This feature can be enabled by setting:: |
| 49 | + |
| 50 | + use_previous_guess = true |
| 51 | + |
| 52 | + |
| 53 | +Choosing an initial step size |
| 54 | +----------------------------- |
| 55 | + |
| 56 | +If there are some problems in the first couple of geometry optimization iterations (energy and force norm increasing) the initial step size should be chosen |
| 57 | +manually. If a conservative choice (``init_step_size`` ~ 0.8 ) does not solve the problem, the problem is usually in the input |
| 58 | +geometry (wrong units, unphysical, ...) or in the potential energy surface (too much noise, error in the DFT input section, ...). |
| 59 | + |
| 60 | +Convergence problem can be analyzed by visualizing the optimization trajectory and plots of the energy and force norm versus the geometry optimization iterations. |
0 commit comments