[gpaw-users] DFT+U

[Ask Hjorth Larsen]

Hello

Some of this looks like the old --gpaw=fprojectors=True thing.  I.e.
that flag "fixes" it.

But it could be because the default basis sets include polarization
functions with higher angular momentum than what would be considered
wise.  In that case the --lpol=2 when generating a basis set may be a
better fix.  But of course the Real fix would be to fix the basis sets
and basis set generator, *and* always allow f "projectors".  The
former won't be done (by me) before generator2 comes along though (and
even then it might last a while).

Regards
Ask

2013/6/3 Jens Jørgen Mortensen <jensj at fysik.dtu.dk>:
> Hi!
>
> See my comments below;
>
> Den 30-05-2013 17:07, Glenn Jones skrev:
>
> Hi,
>
>
>
> I am experimenting with +U for metal oxide systems and have come across a
> couple of issues.
>
>
>
> The first is with CeO2 in LCAO mode, I am able to run single point
> calculations and optimise cells of CeO2 in PW mode and fd mode, but get an
> error related to my basis set in LCAO mode, the last couple of lines are :
>
>
>
> File "/home/gjones/modulefiles/gpaw_lib/lib64/python/gpaw/lcao/overlap.py",
> line 525, in calculate_expansions
>
>     tsoe = calc.calculate_expansions(l1_j, f1_jq, l2_j, f2_jq)
>
>   File
> "/home/gjones/modulefiles/gpaw_lib/lib64/python/gpaw/lcao/overlap.py", line
> 488, in calculate_expansions
>
>     oe = self.transformer.calculate_overlap_expansion(a_q, la, lb)
>
>   File
> "/home/gjones/modulefiles/gpaw_lib/lib64/python/gpaw/lcao/overlap.py", line
> 456, in calculate_overlap_expansion
>
>     a_g = (8 * fbt(l, a_q * k1**(-2 - lmax - l), self.k_q, R) /
>
>   File
> "/home/gjones/modulefiles/gpaw_lib/lib64/python/gpaw/lcao/overlap.py", line
> 99, in fbt
>
>     ifft(C[l][n] * f * r**(1 + l - n), 2 * m)[:m].real)
>
> IndexError: list index out of range
>
>
> Could you send us a simple example that shows this error?
>
>
>
>
> The second is regarding bulk optimisations, I am able to optimise the bulk
> of my crystals using a series of single point calculations and fitting an
> equation of state. However I have tried to use PW mode with the strain
> filter and it seems that after setting U, the calculation reverts back to
> standard DFT and optimises with U at 0. Is there some way to ensure the
> calculation continues to apply the U value when looping through the
> optimisation:
>
>
> That's not easy to do at the moment.  We should fix that.  What would be the
> nice user interface to do a DFT+U calculation be?
>
> Something like:
>
>   GPAW(..., setups={'Ce':{'U': 5.5, 'l': 2}}, ...)
>
> But there is another problem:  I don't think the DFT+U contributions to the
> forces and stress tensor have been implemented.  Anybody know if those are
> simple to do?
>
>
>
>
> #extract of PW mode optimisation script:
>
>
>
> atoms.set_calculator(calc)
>
> l = 2
>
> U_eV = 5.5
>
> U_au = U_eV / Hartree
>
> scale = 1
>
> store = 0
>
> atoms.get_potential_energy()
>
> for at in Ce_list:
>
>      calc.hamiltonian.setups[at].set_hubbard_u(U_au, l, scale, store) #
> Apply U
>
> calc.scf.reset()
>
>
>
> #define bulk optim
>
> sf = StrainFilter(atoms)
>
> lat_opt = BFGS(sf, logfile = 'lat.log')
>
> traj = PickleTrajectory('lat.traj', 'w', atoms)
>
> lat_opt.attach(traj)
>
> #opt.run(0.005)
>
>
>
> #define atomic optim
>
> at_opt = BFGS(atoms,logfile = 'at.log', trajectory='at.traj')
>
> at_opt.run(0.1)
>
>
>
> def converged(atoms,smax,fmax):
>
>     maxstress = max(atoms.get_stress().ravel())
>
>     rmsforces = np.sum(atoms.get_forces()**2,axis=1)**0.5
>
>     maxforce = max(rmsforces)
>
>
>
>     if maxforce < fmax and maxstress < smax:
>
>         return True
>
>     return False
>
>
>
> #we run this loop until both the atoms and cell are converged  # should I
> reset the U value each time here?
>
> while not converged(atoms,smax=0.005,fmax=0.05):
>
>     #first relax internal degrees of freedom
>
>     lat_opt.run(0.005)
>
>     #take a step on the cell
>
>     at_opt.run(0.05)
>
>
>
>
>
> #extract of script using series of single points (this works, I guess
> because U is reapplied before each step):
>
> for a in a0 * np.linspace(1 - eps, 1 + eps, 14):
>
>         atoms.set_cell((a,a,a),scale_atoms=True)
>
>         atoms.set_calculator(calc)
>
>         l = 2
>
>         U_eV = 0
>
>         U_au = U_eV / Hartree
>
>         scale = 1
>
>         store = 0
>
>         atoms.get_potential_energy()
>
>         for at in arange(2):
>
>             calc.hamiltonian.setups[at].set_hubbard_u(U_au, l, scale, store)
> # Apply U
>
>         calc.scf.reset()
>
>         atoms.get_potential_energy()
>
>         traj.write(atoms)
>
>
>
>
>
> I would like to optimise using stress as I plan to look at more complex
> structures of oxides, whilst using U, which is easier ( and more efficient)
> than using a set of single point energies and fitting EOS.
>
>
>
> The final issue I am having is with the plane-wave mode, which is great for
> small cells –alloys primitive oxides etc. However, when tackling larger
> cells it appears to be very memory hungry, is this because the feature is
> relatively new and not optimised or are there some ‘tricks’ to limit memory
> usage
>
>
> We have done some memory optimization and that is only in the trunk version
> of GPAW, so make sure you are using that.  I would like to look at examples
> where memory usage is still too large - so if you have such cases then
> please send them to me.
>
> Jens Jørgen
>
>  Thanks,
>
>
>
> Glenn
>
>
>
>
>
>
>
>
>
> If the reader of this email is not the intended recipient(s), please be
> advised that any dissemination, distribution or copying of this information
> is strictly prohibited. Johnson Matthey PLC has its main place of business
> at 5th Floor, 25 Farringdon Street, London (0207269 8400).
>
> Johnson Matthey Public Limited Company Registered Office: 5th Floor, 25
> Farringdon Street, London EC4A 4AB.Registered in England No 33774
>
> Whilst Johnson Matthey aims to keep its network free from viruses you should
> note that we are unable to scan certain emails, particularly if any part is
> encrypted or password-protected, and accordingly you are strongly advised to
> check this email and any attachments for viruses. The company shall NOT
> ACCEPT any liability with regard to computer viruses transferred by way of
> email.
>
> Please note that your communication may be monitored in accordance with
> Johnson Matthey internal policy documentation.
>
>
>
> _______________________________________________
> gpaw-users mailing list
> gpaw-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users
>
>
>
> _______________________________________________
> gpaw-users mailing list
> gpaw-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users