[gpaw-users] DFT+U
Glenn Jones
gjones at matthey.com
Tue Jun 4 09:24:30 CEST 2013
Hi Ask,
Thanks, for the suggestions I already had --gpaw=fprojectors=True , so that wasn't the problem.
However, setting "--lpol=2 when generating a basis set" has got the calculation running - its crashed for another reason
"raise RuntimeError('Could not locate the Fermi level!')
RuntimeError: Could not locate the Fermi level!"
, but I am a step closer and can now work on the settings.
I have just checked a calculation involving Sn, which was also giving the same basis error as Ce - it seems I need both --gpaw=fprojectors=True when running the job and --lpol=2 when generating a basis.
Thanks
Glenn
Note. Jens - I will send some examples through later today of pw jobs that crashed - presumably because of memory because no error was reported - I will also install the trunk GPAW and see how that works.
-----Original Message-----
From: Ask Hjorth Larsen [mailto:asklarsen at gmail.com]
Sent: 04 June 2013 03:20 AM
To: Jens Jørgen Mortensen
Cc: Glenn Jones; gpaw-users at listserv.fysik.dtu.dk
Subject: Re: [gpaw-users] DFT+U
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
This message has been scanned for viruses by MailControl - www.mailcontrol.com
Click https://www.mailcontrol.com/sr/1+R898djPMrGX2PQPOmvUu4DI0fUfdodvGBIPY0L7aUcgf1Hx+n0lUW+95YJ+NRt6xcz45HF7BXX405xsHCs!A== to report this email as spam
More information about the gpaw-users
mailing list