Coordinates Systems Used in Geometry Optimizations

Dear Sir/ Madam,

I would like to ask about the coordinate system used in geometry optimizations with the BFGS and LBFGS optimizers implemented in ASE. Is it Cartesian coordinates or internal coordinates? Additionally, when using atoms.get_positions(), the atom positions are returned in Cartesian coordinates, right?

Yours faithfully,

get_positions() is cartesian, get_scaled_positions() returns fractional coordinates relative to atoms.cell.

ASE’s optimisers usually operate on Cartesian coordinates, but “filters” can be used to modify the degrees of freedom that the optimiser works on to e.g. include lattice vectors or account for symmetry constraints. In principle a Filter could be developed and used with any optimiser to have it work on internal coordinates - but this is not currently available.

Hi @ajjackson ,

Thank you very much for your reply! The problem I’m facing is that the optimizations are taking hundreds of steps to reach the minimum. Is there a specific optimizer in ASE that performs best for these types of molecules? Would you have any other suggestions on how to reduce the number of steps in large molecule geometry optimizations?

Yours sincerely,

You didn’t specify what “these types of molecules” are, but perhaps you will find the preconditioned optimisers useful? The FF preconditioner is intended for non-periodic molecule calculations.

In general I find that if optimising a system which is far away from its energy minimum it can be effective to begin with the very robust FIRE optimiser, and switch to a “smarter” Quasi-Newton method (such as LBFGS or BFGSLineSearch) when the forces are below around 0.1 eV/Ang.

In the development version of ASE there are some recent improvements to FIRE: FIRE2 and ABCFire methods are available in the ase.optimize.fire2.Fire2 class. I don’t have hands-on experience with this.

Another cause of slow geometry optimisations (when close to the minimum) can be underconverged forces e.g. from an aggressive SCF criterion, poor k-point sampling, or single-precision GPU evaluation. In these cases the potential-energy surface becomes noisy and the Quasi-Newton assumption of a quadratic landscape is ineffective.