Merge lp:~nickpapior/siesta/4.1-scf-first into lp:siesta/4.1
Status: | Merged |
---|---|
Approved by: | Alberto Garcia |
Approved revision: | 1086 |
Merged at revision: | 1096 |
Proposed branch: | lp:~nickpapior/siesta/4.1-scf-first |
Merge into: | lp:siesta/4.1 |
Diff against target: |
244 lines (+95/-17) (has conflicts) 5 files modified
Docs/siesta.tex (+39/-4) Src/m_new_dm.F90 (+44/-12) Src/read_options.F90 (+7/-1) Src/siesta_options.F90 (+1/-0) version.info (+4/-0) Text conflict in version.info |
To merge this branch: | bzr merge lp:~nickpapior/siesta/4.1-scf-first |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alberto Garcia | Approve | ||
Review via email: mp+370711@code.launchpad.net |
This proposal supersedes a proposal from 2019-07-29.
Commit message
Fixing SCF-first for re-reading DM files
Previously one could not restart and perform mixing for the
first SCF step. This helps for big systems when needing restart
effects.
In some cases (for really large systems) it *could* be advantegeous
to also allow mixing in the first SCF step since any perturbation
cause huge dDmax/dHmax. In those cases we probably need some kind
of handler to allow mixing first step anyhow.
SCF.Mix.First.MD <T|F> ?
Description of the change
This is a result of https:/
Initially we had disabled scf.mix.first for all simulations which did a restart. This commit fixes this in the sense that iff the sparsity pattern is exactly the same, it will allow one to do mixing in the first iteration, otherwise not.
However, this *could* potentially still be a problem for very large systems where minor displacements are present. In that case it could still be viable to do small linear mixing for a few steps using the final DM from a different geometry.
Perhaps we need to introduce a new keyword (see above).
The issue is complex enough that in-program heuristics might not be able to treat it in all cases. I think it is better to allow the user to request explicitly the behavior desired, and keeping the current (including this patch) heuristics as default behaviour.
So I would introduce a new flag, something like "SCF.Force. Mix.First. Iter" and let it override all the internal heuristics (even for "dangerous" cases), with proper warnings for the user.
But:
-- Do the worries about non-idempotency or memory effects in the mixed DM apply when one is really mixing the hamiltonian?
-- I missed the orginal discussion of the above bug report, but what I can gather now is that the dH found by the user was unavoidable, and other features (reading H, re-reading more mixing history) would be more helpful.