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

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.

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:

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.