Repository navigation
Feature Request: Support simultaneous ion-cell BFGS for cell relaxation #7970
Description
Currently, BFGS is only used as an ionic optimizer in cell-relax. The cell itself is still optimized through the separate lattice-CG path.
In Ions_Move_Methods, the BFGS optimization space is explicitly limited to
Ions_Move_Basic::dim = natom * 3;and both BFGS variants operate on ionic forces only. In contrast, lattice relaxation is handled separately by Lattice_Change_Methods, which uses Lattice_Change_CG with the stress tensor.
Therefore, cell-relax + bfgs currently behaves approximately as:
fixed-cell ionic BFGS
↓
lattice CG update
↓
reset ionic BFGS history
↓
repeat
rather than as a genuine variable-cell BFGS optimization over both ionic and cell degrees of freedom.
Current limitation
PR #7507 correctly fixed #4140 by resetting the ionic BFGS state after a cell change. Reusing the old ionic positions, gradients, Hessian/inverse-Hessian and trust-radius state after changing the lattice was inconsistent and could cause BFGS to break down.
However, this also indicates a structural limitation of the current implementation: the BFGS approximation only contains ionic curvature,
instead of a joint variable-cell Hessian such as
Consequently:
- ion-cell curvature coupling is not learned;
- cell curvature is handled by a separate CG optimizer;
- all accumulated BFGS information has to be discarded after every accepted cell update;
- ionic curvature has to be learned again for the new cell.
This affects both bfgs 1 and bfgs 2; their difference is how the Hessian/inverse Hessian is represented, not which degrees of freedom are optimized.
Proposed direction
I suggest adding a simultaneous ion-cell BFGS path for cell-relax, conceptually similar to the current cg 2 implementation.
The optimization state could contain the ionic coordinates together with the active cell degrees of freedom:
with appropriate scaling/preconditioning between ionic and cell components.
The optimizer would then:
- construct a joint gradient from forces and stress;
- update ions and cell within the same quasi-Newton step;
- learn ion-ion, ion-cell and cell-cell curvature together;
- apply the existing cell constraints (
fixed_axes,fixed_ibrav, etc.) in the joint optimization space; - no longer reset BFGS history after an ordinary cell step, since the cell change would itself be part of the BFGS trajectory.
The existing simultaneous cg 2 infrastructure may provide a useful basis, since it already maintains both ionic and cell gradients/search directions and updates them together.
Expected benefits
- avoid repeatedly rebuilding the ionic BFGS history after every cell change;
- include ion-cell coupling in the quasi-Newton model;
- potentially reduce the number of force/stress evaluations for strongly coupled variable-cell relaxations;
- make
relax_method = bfgsduringcell-relaxa genuine BFGS optimization of the full variable-cell problem rather than a nested BFGS/CG procedure.
Activity
Growl1234 commentedon Sep 15, 2026
CP2K can serve as a useful reference here. Its$x=(R,h)$ , and provides a common evaluator that maps this vector to the physical structure and returns the corresponding energy and joint gradient from forces and stress. BFGS, L-BFGS, and CG then operate on exactly the same generalized optimization problem. As a result, cell changes are ordinary optimizer steps rather than external events, and the quasi-Newton Hessian naturally contains ion-ion, ion-cell, and cell-cell curvature without requiring a BFGS reset after each lattice update.
CELL_OPTformulates ions and cell degrees of freedom as a single optimization vector, e.g.I believe, extracting the relevant parts from the CG implementation should be the first step we take. And as part of the overall work we could consider deprecating
cg 1.mohanchen commentedon Oct 5, 2026
It's a good idea. Since the source_relax directory is almost independent of other source codes, and it does not involve much physics knowledge. Do you guys have interests to implement these featurs? @QuantumMisaka @Growl1234
Growl1234 commentedon Oct 5, 2026
I can take this job if no other one is working on it, from my mind of implementation most likely it takes about 2-3 seperate steps.