Static path

[theonov13]

Hi,

I tried to install the PWDFT.jl code and wanted to run the simple example

Si_fcc/

julia run.jl

but it does not run out of the box.
It failed because of a static path
in

/home/schwalbe/.julia/packages/PWDFT/QCXtJ/src/Libxrc_old.jl

--> const LIBXC5 = "/home/efefer/mysoftwares/libxc-4.3.4/lib/libxc.so.5

I adjusted the path to an existing libxc version on my pc.

I don't know if this is by attention, a bug, or because I have done a mistake while installing the code.
If it is not a bug one should mention somewhere that this path needs to be adjusted.

Best,
Sebastian

[f-fathurrahman]

Hi, thank you very much for your interest and this report.

I am sorry for this problem. I think I have messed up during the Libxc metaGGA testing. I tried to test SCAN and TPSS but the results were some large numbers or NaN. As a quick hack I hardcoded the links to various several Libxc versions. If it were using Libxc.jl package it should be enough to replace it with Libxc.libxc.
Hopefully the implementation of various metaGGA will become better and we can simply use Libxc.jl provided library.

The version of Libxc with working SCAN (but it has problem with TPSS if I'm not mistaken) is version 4.3.4 which is also the version I used in Quantum Espresso (for total energy comparison).
The calculation for kinetic energy density also contain hardcoded factor of two to account for doubly occupied orbitals. This also should be changed to Ham.electrons.Focc for generalities, however I have not checked the total energy result when the orbitals are not double occupied.

By the way, this kind of problem is one reason PWDFT.jl has not been registered yet 😅 .

[theonov13]

Thank you for your quick response.

Maybe you should deside for a brunching/release way.
If the master e.g. stays stable and you bush your newest developments from a specific development e.g. dev_libxc brunch only to the master if you are sure that everything works correctly.

You should use more recent versions of libxc.
The libxc master e.g. is way more stable for SCAN and functionals of that kind.
SCAN is a numerical very demanding functional the regularized versions rSCAN and r2SCAN may be better
for testing the MGGA interface to libxc.

Also the usage of pseudopotentials may effect the convergence of SCAN. You should try not to use LDA or PBE HGH/GTH setups.

https://github.com/juerghutter/GTH

I would guess that unrestricted calculations (focc!=2) will be more difficult to converge with SCAN.

Anyway, You have done great work with your code.
Its one of the codes which go in a better direction for a future of more educational useable codes.
I'm actually not familiar with Julia and can read most parts of the code quite fluent and was actually able to run some of your routines to debug my code.

[f-fathurrahman]

Maybe you should deside for a brunching/release way.

I will do this when I finally get some interested and dedicated students for helping me. For the time being I prefer to use the current way.

You should use more recent versions of libxc. The libxc master e.g. is way more stable for SCAN and functionals of that kind. SCAN is a numerical very demanding functional the regularized versions rSCAN and r2SCAN may be better for testing the MGGA interface to libxc.

I'm glad that these functionals are implemented.

Also the usage of pseudopotentials may effect the convergence of SCAN. You should try not to use LDA or PBE HGH/GTH setups.
https://github.com/juerghutter/GTH

Thank you for the links. I will check this out.

Anyway, You have done great work with your code.
Its one of the codes which go in a better direction for a future of more educational useable codes.
I'm actually not familiar with Julia and can read most parts of the code quite fluent and was actually able to run some of your routines to debug my code.

Thank you very much for your comment.
My code is originally ported from my old Fortran codes and mainly intended for educational purpose. In my book draft, I tried to write similar code, but using finite difference method. I am still trying to get time to finish the draft.

If you are interested in another plane wave DFT code in Julia, I would suggest to look at DFTK.jl. The developers are more experienced, their code is more structured, and the documentation is also better. Their SCF solver are very good, IMHO.

[theonov13]

This is a problem many of us have; too much work for one alone.

I found the GTH repo during my search about GTHs
as I'm currently trying to implement them myself.
From playtesting SCAN in GPAW or QE I know that for standard
LDA or PBE setups (UPF etc.) SCAN is nearly never converging.
Also not for unreasonable large cutoffs.
And from my official work, I know that for GTOs you need very dense numerical grids
and unpractical large basis sets to get a reproducible/numerical more stable answer
from standard SCAN.

Yeah, I had partially a look at your other projects as well.
This remembers me that I wanted also to post an issue there.

I started to have a look at your code at the same time I went through DFTK.jl.
From my viewpoint, DFTK.jl is already too optimized at some points from
educational perspective paper equations vs. source code.

[antoine-levitt]

Hi, I hope you don't mind the intrusion, DFTK developer here, I found this thread during an unrelated search. @f-fathurrahman thanks for the kind words! PWDFT is still ahead of DFTK for a number of features, we hope to catch up eventually :-)

I started to have a look at your code at the same time I went through DFTK.jl.
From my viewpoint, DFTK.jl is already too optimized at some points from
educational perspective paper equations vs. source code.

Could you expand on what you mean by that? Our explicit goal with DFTK was to make something that could be used as an educational tool, so we're be very keen on feedback on where you think DFTK is hard to understand/use. In particular the only places where optimization hurts readability should be relatively isolated from the rest, and hopefully sufficiently commented that the intention is clear. Feel free to open issues in the DFTK repo!

SCAN looks interesting, I never took a close look at it but it looks relatively OK to implement.

From playtesting SCAN in GPAW or QE I know that for standard
LDA or PBE setups (UPF etc.) SCAN is nearly never converging.
Also not for unreasonable large cutoffs.

We are currently working with @mfherbst on more robust SCF algorithms so any example of non-convergence is very interesting to us. Can you expand a little bit - what doesn't converge, in what setups?