Merge lp:~nickpapior/siesta/4.1-init-DM into lp:siesta/4.1
Status: | Merged |
---|---|
Merge reported by: | Nick Papior |
Merged at revision: | not available |
Proposed branch: | lp:~nickpapior/siesta/4.1-init-DM |
Merge into: | lp:siesta/4.1 |
Diff against target: |
278 lines (+189/-19) (has conflicts) 3 files modified
Docs/siesta.tex (+41/-0) Src/m_new_dm.F90 (+144/-19) version.info (+4/-0) Text conflict in version.info |
To merge this branch: | bzr merge lp:~nickpapior/siesta/4.1-init-DM |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alberto Garcia | Pending | ||
Review via email: mp+372254@code.launchpad.net |
Commit message
Added a new initialization method for DM
The current DM initialization *only* specifies the charge
on the truly diagonal DM entries. I.e. io == col(ind).
However, if one considers that atomic charges are actually
atomic *states* i.e. a state-vector with element in the
diagonal one will also get DM entries in off-diagonal
but io - 1 == col(ind) % no_u which is probably more correct.
I have added two new methods for DM initialization:
1. The DM.Init flag determines one of these methods:
a) atomic
the default on-site only atomic density
b) expand to a state with on-site density
This enables small auxiliary cell calculations
to have the density spread amongst overlapping
orbitals.
In some systems this seem to behave better
(
(si64).
2. Added DM.Init.
N electrons from the initial density matrix
and add N electrons using a randomized state.
This state is ensured to be in the non-orthogonal
basis but is not necessarily orthogonal to any
other state generated (nor will it be orthogonal
to the atomic states).
Currently this method scales orbital coefficients with
the atomic charges. This will match the atomic charges to
some degree.
This is done to limit randoized states with charge in
high-lying shells which seems dubious in many cases.
Generally this does not work too good, but may be good
in some cases I don't know off.
Currently the defaults are as they have always been, but
perhaps the atomic-state would be good in the future?
This needs more heuristics.
Description of the change
I have tried atomic vs. atomic-state on the following tests:
The numbers shows the number of SCF steps needed to converge and the first step dDmax, dHmax
graphite_c6:
atomic: 9, 1.879391, 1.748376
atomic-state: 7, 1.568393, 0.207440
batio3:
atomic: 19, 1.961004, 22.268878
atomic-state: 21, 2.144922, 20.791337
sic-slab:
COMMENT: fun-fact, the SCF cycle indicates that atomic-states is better, but then suddenly atomic converges faster at iSCF 46! History has lots to say here since there is an electric field in this example.
atomic: 69, 1.746005, 13.382736
atomic-state: 144, 2.007246, 13.363516
nanotube-c-5-0:
atomic: 11, 0.741924, 4.242417
atomic-state: 11, 2.037193, 4.270371
I am trying to understand this a bit better.
The initial DM is used to compute the first H, but *only* the charge density computed from that DM is relevant (H0 does not use the DM, and dhscf only uses rho(r)). The initial charge density then
is the key for initialization. Currently the heuristic is that a superposition of atomic charges is an appropriate method. To improve on that we would need some extra heuristics about how bonding effects in that particular system might influence the charge density. But this cannot be guessed simply from manipulation of 'atomic' concepts.
Does your alternate method give as starting rho(r) the same atomic-charges superposition? I guess not, since the convergence results are different. So you are changing the charge heuristic, but not in a physical way, so I think that the results will be erratic and depend very much on whether your trick leads to a "closer" rho(r) for a particular system.
Besides this, the initial DM will indeed have an influence on the delta_DM found after the first scf step. For example, the 'diagonal' method disregards the nzeta-1 orbitals beyond the first in DM_in, and these are likely to be occupied in DM_out. But delta_DM(scf=1) should be discarded anyway if we are not mixing in the first scf step, as is the case when using atomic initialization.
There are other possibilites for a more targeted initialization: one could extract from a set of calculations in the same or similar system some kind of "deformation charge" estimate and add it to the initial charge density. Note that this is already implemented, but not really well explored.
Or a "physically motivated" initial H could be read. Maybe an extended-Hückel form.