Generate XCKernel from LibXC string

[dmejiar]

• Allows to define a functional using a string like "xc_gga_x_ncap" when LibXC is used as backend.
• Updates LibXC version to 6.1.0.
  Note that LibXC 5.0 was buggy (see ChangeLog.md) and should not be taken as reference.

[wavefunction91]

Sorry for not seeing this until now, must have slipped through my inbox. Moving to LibXC 6 is more involved than what is here, see the open PR. If you'd like to update the test data, I'd be more than happy to merge the PR.

[dmejiar]

@wavefunction91 I have updated the reference test data. Seems that only three values were off. PR #8 should work with the current master branch of LibXC, but I will double check that

[wavefunction91]

Thanks for the corrections. However, the main problem was not in the reference values, but in the comparison of Libxc/Bulitin backends. Recall, the fact that ExchCXX can act as a Libxc wrapper is convenient, but not a necessity - all changes must be propagated to the Builtin backend to allow for their evaluation on GPUs (which is primary purpose for this project).

I tried to regenerate the Builtin interfaces from Libxc 6.0.0, but the've changed there backend function structure, so it will take me a bit to update my scripts.

I've enabled this PR to run through the CI pipeline, the errors should be apparent now.

[wavefunction91]

@dmejiar please merge with current master for CI pipeline fixes

[dmejiar]

I started updating the built-in kernels, but there is another issue that can lead to some test failures. Libxc corrects some unphysical sigma values before evaluating the functional. These corrections are not present in ExchCXX.

The last three sigma values (1.3, 1.5, 1.5) in Line 56 will lead to an unphysical situation. Libxc will instead use sigma_aa = 1.3, sigma_ab = 1.4, and sigma_bb = 1.5.

Do you want to have the same checks on sigma as in LibXC? If you do, then I can leave the values of the sigma_polarized as they are. But if you do not want those checks, then I will change the values to (1.3, 1.4, 1.5) so there is really a one-to-one comparison in the tests.

[wavefunction91]

@dmejiar Thanks for taking a look. I think we ideally want both - the checks are clearly necessary, but we also want to have sane values to test with. Does LibXC error out with unphysical sigma?

[dmejiar]

No, Libxc will correct the unphysical value

      s_ave = 0.5*(my_sigma[0] + my_sigma[2]);
      /* | grad n |^2 = |grad n_up + grad n_down|^2 > 0 */
      my_sigma[1] = (my_sigma[1] >= -s_ave ? my_sigma[1] : -s_ave);
      /* Since |grad n_up - grad n_down|^2 > 0 we also have */
      my_sigma[1] = (my_sigma[1] <= +s_ave ? my_sigma[1] : +s_ave);

[dmejiar]

@wavefunction91

Tests already pass with 4c92dda see here.

Commit 044b12a updates the generation script to handle the new structure in Libxc 6

[ajaypanyala]

@dmejiar Are the changes in here (reg. set_ext_params) also supposed to go into this PR ?

[dmejiar]

@ajaypanyala Only a handful of specialized functionals need external parameters to be set, so they are not really necessary, but I can include them as well. What do you think?

[wavefunction91]

I'm fine exposing the functionality, but none of the builtin kernels support this functionality. Recalling that Libxc-wrapping is a convenient (but extra) feature for this project, it should be expected that all publicly exposed APIs should be useful to any of the implemented functions.

That being said, if you want to expose it, that's fine, just make sure we throw and error / warning if the function is called from the builtin backend.

[ajaypanyala]

@dmejiar I am unable to even compile the application (qed-hf) code without these changes. I have a PR here that I used to make the code compile. Is there an alternate way to handle these functionals ? If not, we can go with what @wavefunction91 suggested (i.e expose it, but throw error with builtin backend)

[dmejiar]

@ajaypanyala The qed-hf application does need to set external parameters. If I remember correctly, it might be possible to pass those parameters to Libxc by writing a file inside the running directory. Let me check if this is indeed possible. In this way, we would not need to expose set_ext_params