Skip to content

Conversation

@awvwgk
Copy link

@awvwgk awvwgk commented Jan 25, 2026

  • add literature references for each functional
  • add libxc name and id for each functional

@awvwgk
Copy link
Author

awvwgk commented Jan 30, 2026

David @wavefunction91 could you have a look at this patch?

@awvwgk
Copy link
Author

awvwgk commented Jan 30, 2026

Susi @susilehtola is there a good way to link to specific libxc identifiers in the documentation for libxc?

@wavefunction91
Copy link
Owner

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.

@susilehtola
Copy link
Contributor

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 func->info or from the website list of functionals.

@awvwgk
Copy link
Author

awvwgk commented Jan 30, 2026

I'm not opposed to this, but I feel like this is not really a solution to any problem I'm aware of.

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.

@susilehtola
Copy link
Contributor

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.

@wavefunction91
Copy link
Owner

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:

  1. To resolve List of functionals in README is incomplete #50, one can either flesh out the existing table or stand-up a prettier / more scalable solution (my guess is the latter is better, as we've added a ton of functionals since that table was originally written).
  2. We can add an API (implemented based on Libxc availability) to return the Libxc code from a Kernel instance. We can then delegate the "single-source-of-truth" to Libxc. We already have a map that goes one way on this, we just need to make it reversable.
  3. We can add an example showing the user how to extract the citation information from Libxc given this code.

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

Successfully merging this pull request may close these issues.

3 participants