-
Notifications
You must be signed in to change notification settings - Fork 24
Add references for functionals #49
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
base: master
Are you sure you want to change the base?
Conversation
awvwgk
commented
Jan 25, 2026
- add literature references for each functional
- add libxc name and id for each functional
|
David @wavefunction91 could you have a look at this patch? |
|
Susi @susilehtola is there a good way to link to specific libxc identifiers in the documentation for libxc? |
|
I'm not opposed to this, but I feel like this is not really a solution to any problem I'm aware of. Libxc already manages its own set of references, I'd prefer that we have one source of truth here. |
|
The references are coded up in the Libxc implementation. I agree they shouldn't be duplicated and hardcoded in ExchCXX. If you have the functional keywords, you can get the references either from Libxc's |
I added those because it was not clear to me which enum corresponds to which combination of exchange and correlation functional. Having a reference point like libxc names or papers helped me to understand what is exposed via which enum. For example the B97D and B97D3ZERO value are effectively the same functional, but this can only be inferred from the actual implementation. Also, some names deviate from the ones in libxc, like revPBE vs PBE_R, which was not immediately clear to me. Eventually, I would like to setup GitHub Pages to provide the description provided here in an accessible and searchable way for the users of this library. |
|
The plan we had with @wavefunction91 years ago was to eventually merge ExchCXX with Libxc, but I guess we both got too busy to act on it. I still think Libxc would benefit from a higher-level interface in addition to what it has at present. |
|
Yes @susilehtola, the plan always was (and still is) to merge the projects. I personally don't have the cycles for it at the moment, but it's likely becoming a lower-and-lower lift every year. @awvwgk I understand the desire to have the mapping, and I'd even be fine with this being well documented, but I'm not sure that the code is the right place to do that. I would propose the following:
|