Bulk potential energy by different methods

[Sebastian Hütter]

Hi,

well, that would be far more than 1 vacancy per "infinite" volume. For 
these I use a coordinate list corresponding to 5x5x5 unit cells (that is, 
500 atoms in 20.25 angstroms³), compute the energy (E1), remove one atom, 
compute again (E2), then calculate Evf = E2 - (499/500) * E1.
With the exact same parameters, all EAM potentials I compared are already 
well converged (i.e. larger replications change less than 1% of the 
absolute value, so we're out of the self-interaction range), and get within 
30% of the experimental value (~0.66eV) (depending on their construction of 
course).

Reducing EPS_DEFAULT helped in that regard and I now get somewhat plausible 
results there. However that never really was my objective, I just chose 
vacancy formation energy to test because I it was the first concrete 
physical quantity that came to mind with a simple computation method.

What I was really looking for is a way to compare the energies over things 
like structural changes, but that doesn't appear to be possible... I do 
note that every energy I have compared so far has been different by the 
same constant factor (15.8). If there was any physical reason for that, 
there's an obvious solution to my problem, but I can't think of one.

I've since found some articles that compared DFT to EAM for PdAu 
<https://journals.aps.org/prb/abstract/10.1103/PhysRevB.80.035404> and NiAl 
<http://iopscience.iop.org/article/10.1088/0965-0393/24/4/045012> systems 
and where it worked well (both with VASP though).
Checking with the JARVIS-FF <http://www.ctcms.nist.gov/~knc6/periodic.html> 
repository shows a cohesive energy of on average -3.37eV/atom and which was 
confirmed by DFT, so I am now under the impression that the method should 
work and something in my attempt to do the same with cp2k is wrong.


Sebastian



Am Freitag, 2. Juni 2017 12:45:15 UTC+2 schrieb Matt W:
>
> How do you do the vacancy calculation? Are you still using multiple unit 
> cell and just removing an atom?
>
> Matt
>
> On Friday, June 2, 2017 at 11:25:48 AM UTC+1, Sebastian Hütter wrote:
>>
>> Hi Matt, Matthias,
>>
>> thank you for your replies.
>>
>> The input file is basically identical to a similar question about Nickel 
>> posted here some time ago 
>> <https://groups.google.com/d/msg/cp2k/llUH48_Y3vY/GPrPXaaXZJIJ>. I did 
>> convergence studies on EPS_SCF and cell replication count NREP; the 
>> parameters posted are the fastest in terms of simulation time. For the Evf 
>> calculations, I used 5x5x5 unit cells (500/499 atoms) for both methods.
>>
>> individual total energy are almost always meaningless, especially when 
>> comparing different levels of theory.
>> I'm still new to this, but... why? Shouldn't the total energy be a direct 
>> consequence of the cohesive energy, especially in such simple systems?
>>
>>
>> a gamma point calculation for Al metal using a model system consisting of 
>> only 3x3x3 unit cells won't provide converged results. You need a much 
>> larger model system in the order of 10x10x10 unit cells or you have to 
>> employ an equivalent k point sampling. Besides that major issue, there are 
>> further shortcomings in your CP2K input: (1) an SCF convergence threshold 
>> of 1.0E-4 (EPS_SCF) is too large: 1.0E-6 (or smaller), (2) a general 
>> threshold of 1.0E-10 (EPS_DEFAULT) is also too large: 1.0E-12 (or smaller)
>> I have redone the calculation with your suggested thresholds and 6x6x6 
>> unit cells which is about the largest I can run on our local compute server 
>> because of memory constraints, if that showed any change at all I would 
>> have to post to the HPC cluster. However: no change. Still -8.38Ha/UC.
>>
>> Is LDA a good enough density functional. Is a DZVP basis set good enough?
>> I don't know? How do I find out?
>>
>> Did you relax the structures?
>> A CELL_OPT run changed the total energy by just a few percent (for this 
>> setup, a=4.05 is a bit on the high side), not the order of magnitude that's 
>> missing here.
>>
>>
>> Kind regards,
>>
>> Sebastian
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20170602/49966a62/attachment.htm>