Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for libxc #237

Open
giovannipizzi opened this issue Oct 19, 2021 · 0 comments
Open

Support for libxc #237

giovannipizzi opened this issue Oct 19, 2021 · 0 comments

Comments

@giovannipizzi
Copy link
Member

We're defining in #236 an Enum with a few known XC functionals (LDA, PBE, PBEsol). There is a suggestion to use libxc. However, maybe we should keep the simple Enum for the most commonly used names (like the ones above and maybe a few more that can be added in the future) for simplicity (otherwise one hast to remember that "PBE" is "gga_x_pbe gga_c_pbe", not immediately obvious from the long libxc list.

A few things to discuss:

  • should we keep an Enum, add a value LIBXC, and if this is provided, there is an additional 'string' input where the actual functional is specified?
  • Should we use the names (e.g. gga_x_pbe gga_c_pbe) or the integer IDs from libxc (101 - 130)? And how to separate the exchange and correlation parts when both are provided? (space or other)
  • Who's in charge for converting between the two in the plugin? (Practical example: QE wants the string, Abinit the integers).
  • Specifying libxc means we want actually to use the libxc implementation, or a plugin could e.g. detect that gga_x_pbe gga_c_pbe is PBE and switch to the internal PBE implementation (that should always be there, even if the code was compiled without libxc support)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant