VGHGH Not implemented in SoaSphericalTensor

[anbenali]

Describe the bug
Calling Force estimator from Legacy code leads to an error which was not present in the past. This is an attempt at reproducing the Paper on MDF using the input files in the MDF repo.
I call the Legacy code explicitly

<?xml version="1.0"?>
<simulation>
   <project id="vmc" series="0">
      <parameter name="driver_version"      >    legacy          </parameter>
      <application name="qmcpack" role="molecu" class="serial" version="1.0"/>
   </project>

Forces are Invoked in the hamiltonian using
<estimator type="Force" name="ac" mode="acforce" source="ion0" target="e"/>
I get the following error:

terminate called after throwing an instance of 'std::runtime_error'
  what():  SoaSphericalTensor<T>::evaluateVGHGH(x,y,z):  Not implemented

Aborted (core dumped)

To Reproduce
Steps to reproduce the behavior:

1. release version or git commit hash being built
   Git branch: develop
   Last git commit: 81ba5c2-dirty
   Last git commit date: Thu Oct 17 18:24:39 2024 -0500
   Last git commit subject: Merge pull request Block the density cell and corner keywords in qdens #5202 from aannabe/qdens_corner

I added all files needed

Expected behavior
Reproduce results in the MDF repo "Dataset for Towards Quantum Monte Carlo Forces on Heavier Ions: Scaling Properties
Tiihonen, Juha; Clay III, Raymond C.; Krogel, Jaron T."

System:

• system name [e.g. fusiont5, summit]: Endymion (AMD Epyc Rome 64 cores. Anouar's Server)

Additional context
This is the Forces test I promised to run. System is the CO molecule.
vmc.tar.gz

[rcclay]

Thanks for documenting this. To summarize status for those not getting their hands dirty with calculations.

Cause of problem: For spherical representation of spherical harmonics in LCAO code, VGHGH is not implemented. They are implemented for the cartesian representation. This is because doing high order x,y,z derivatives in cartesian was much more straightforward.

Short term workaround: For codes like pyscf that write orbitals in spherical form by default, use the converter given in PR#4354 to convert the spherical LCAO's to cartesian. Or use a code like GAMESS that works with cartesian already.

Possible longer term solutions:
1.) Convert spherical LCAO's to cartesian internally in QMCPACK, and work with the cartesian tensors objects throughout the calculation.
2.) Implement VGHGH in SphericalTensor by performing a cartesian->spherical basis set transformation.

[anbenali]

I updated the converter tool to comply with numpy 2 and @kgasperich updated it the PR and removed the [WIP], that PR should be able to be merged as I confirmed results between cartesian and spherical are identical. #4364

To me this is an acceptable solution (to convert the coordinates) for the foreseeable future.

[prckent]

For spherical representation of spherical harmonics in LCAO code, VGHGH is not implemented.

Was code generation ever tried for this? e.g. Some sympy + simple templating to generate the C++ code as we have elsewhere?

(Ultimately we need to get completely away from writing derivatives by hand in all parts of the code. It seems like this should be one of the easier cases.)

[prckent]

It is not clear from the above discussion what actually changed here. Why was the force scaling properties paper possible to run before?

[anbenali]

It is not clear from the above discussion what actually changed here. Why was the force scaling properties paper possible to run before?

What change is moving from Gamess to pyscf. Gamess could generate Cartesian orbitals while pyscf either cannot or is not tested for that. (There is an option to do it but I never really tested it as it was "broken" for a while, and since we never really needed it I did not push further.)

[prckent]

Thanks for clarifying.

[github-actions]

This issue is stale because it has been open for 365 days with no activity. It will be closed in 28 days if there is no fresh activity. Please comment within 28 days if this issue is still important to you and it should be kept open.

[prckent]

@rcclay @anbenali In the years since this issue was created, AI and LLMs have come to the fore: it is reasonable to assume that this code generation could be handled nearly automatically now. However, is the issue still relevant? Do we have test cases? Logically not having to transform PySCF output would be ideal...