Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • fleur fleur
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 46
    • Issues 46
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • fleur
  • fleurfleur
  • Issues
  • #439
Closed
Open
Issue created Apr 29, 2020 by Henning Janssen@janssenDeveloper

LDA+U mixing ambiguity

Summary

Edit: I found the reason for this behaviour (mentioned in the comments), but like this it's easier to see. 
The spinf factors for general and LDA+U mixing are defined with different sign conventions. 
As they are named the same this should be cleared up

A while ago I mentioned that Anderson mixing with LDA+U is unstable. Now Johanna encountered a case where the normal straight mixing produces unreasonable results.

This input inp.xmlkpts.xmlsym.xml runs into the check I put in to catch the unstable runs after only a few iterations. To see what's going on I raised the cutoff for the error message and gave the outDen density matrix and inDen density matrix after mixing as additional output. I only output the first LDA+U element and spin up matrix j.out

The output shows, that the outDen density matrix is perfectly reasonable with occupations almost exactly 1 on the diagonal over all iterations. However, if we look at the inDen density matrix the elements slowly get bigger unitl they hit the cutoff for the error message. This is of course wrong because the input specifies straight mixing. So in my understanding the input density matrix should be between the last input density matrix and the output density matrix.

If you use the linmix argument, effectively uncoupling the density matrix from the mixer this problem does not occur

I also tried running the program on one mpi rank and the behaviour does not change. I will check if this is also the case for a serial compiled version.

Edited Sep 16, 2020 by Henning Janssen
Assignee
Assign to
Time tracking