1-e σpVσp

[JonathonMisiewicz]

Active Todo List for pVp Integrals:

• [ ] Figure out how CR interacts with engine.impl.h::compute_1

[loriab]

Alas, the sigmas appear in filenames in the export. Windows couldn't handle * in basis set filenames, so I'm not surprised it's balking on the non-ascii.

files

_sphemultipole_S_S_prereq.cc
_σpVσp_D_D.cc
_σpVσp_D_D_prereq.cc
_σpVσp_D_P.cc
_σpVσp_D_P_prereq.cc
_σpVσp_D_S.cc
_σpVσp_D_S_prereq.cc
_σpVσp_P_D.cc
_σpVσp_P_D_prereq.cc
_σpVσp_P_P.cc
_σpVσp_P_P_prereq.cc
_σpVσp_P_S.cc
_σpVσp_P_S_prereq.cc
_σpVσp_S_D.cc
_σpVσp_S_D_prereq.cc
_σpVσp_S_P.cc
_σpVσp_S_P_prereq.cc
_σpVσp_S_S.cc
_σpVσp_S_S_prereq.cc
configuration.cc.cmake.in

lines

_σpVσp_D_D.cc:#include <_σpVσp_D_D_prereq.h>
_σpVσp_D_D.cc:void _σpVσp_D_D(const Libint_t* inteval) {
_σpVσp_D_D.cc:_σpVσp_D_D_prereq(inteval+c, inteval->stack);
_σpVσp_D_D_prereq.cc:void _σpVσp_D_D_prereq(const Libint_t* inteval, LIBINT2_REALTYPE* parent_stack) {
libint2_static_init.cc:libint2_build_σpVσp[2][2] = _σpVσp_D_D;

[evaleev]

@loriab is this something that the compiler does when interpreting the source? or is this something that cmake does when making a unity source? trying to disable unity build to see if this has any effect ...

[evaleev]

I don't think unicode characters in file names should be a problem ... * is a different story: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions

[loriab]

Longshot (why would the basis fn be called?) but easy to try if removing https://github.com/evaleev/libint/blob/master/include/libint2/basis.h.in#L348-L350 helps. Also note that if you want a shorter time to failure for GHA, can do https://github.com/evaleev/libint/blob/master/.github/workflows/cmake.yml#L161-L165 . Sorry for all the trouble Wiindows is causing.

[JonathonMisiewicz]

And with the latest commit, Mathematica and L2 and my-script-using-L2-V-ints all match in Cartesians.

AFAIK, what remains on this PR is:

• [x] Check signs against MPQC
• [x] Write test case
• [x] Fix Windows export
• [x] Final cleanup

[evaleev]

Nice, was thereva real issue with D integrals then?

[JonathonMisiewicz]

Nice, was thereva real issue with D integrals then?

An issue with me forgetting to mark an intermediate in compute_primdata as needed for D integrals, yes.

[JonathonMisiewicz]

Longshot (why would the basis fn be called?) but easy to try if removing https://github.com/evaleev/libint/blob/master/include/libint2/basis.h.in#L348-L350 helps. Also note that if you want a shorter time to failure for GHA, can do https://github.com/evaleev/libint/blob/master/.github/workflows/cmake.yml#L161-L165 . Sorry for all the trouble Wiindows is causing.

Removing the lines doesn't help. The issue is elsewhere. I'll look at this again tomorrow.

[evaleev]

SUMMARY of UTF-8 issues on Windows:

• after switching from include(srclist.cmake) to file(STRINGS srclist.cmake ENCODING UTF-8) CMake sees correct file names: https://github.com/evaleev/libint/actions/runs/7038208595/job/19156047711#step:7:6302
• But Ninja does not: https://github.com/evaleev/libint/actions/runs/7038208595/job/19156047711#step:7:7264 ... Ninja 1.11+ supports UTF-8 on Windows, and it appears that CMake 3.21+ should work correctly with Ninja UTF-8: https://gitlab.kitware.com/cmake/cmake/-/issues/21866
• Printing out contents of build.ninja indeed suggests that CMake produces non-UTF-8 file for Ninja: https://github.com/evaleev/libint/actions/runs/7046928670/job/19180201690#step:7:8684
• Perhaps Conda's ninja is not built correctly? Checking per https://github.com/ninja-build/ninja/pull/1918 produces this output: https://github.com/evaleev/libint/actions/runs/7047253278/job/19181202397#step:7:17744 ... it's not consistent with https://github.com/ninja-build/ninja/pull/1918#issuecomment-786700355

[JonathonMisiewicz]

FWIW, formatting of the wincodepage output was condensed into the form we have now.

Other fact:

cmake asks Ninja if it's at least 1.11. If so (raw logs say we're on 1.11.1), it then runs and parses ninja -t wincodepage to determine what Ninja expects. So in this case, the question is why Ninja is asking for ANSI in the first place...

[evaleev]

FWIW, formatting of the wincodepage output was condensed into the form we have now.

Thank you, v useful!

cmake asks Ninja if it's at least 1.11. If so (raw logs say we're on 1.11.1), it then runs and parses ninja -t wincodepage to determine what Ninja expects. So in this case, the question is why Ninja is asking for ANSI in the first place...

I think Ninja provided by Conda was not built to support UTF ... perhaps it was built by configure.py instead of cmake: https://github.com/ninja-build/ninja/pull/1918#issuecomment-786700355

[evaleev]

indeed: this suggests condo builds ninja using configure.py but looks like one must use CMake and MSVC to build ninja to support UTF!

So, indeed, UTF-8 support is not possible on Windows without requiring properly built ninja. P.S. What is wrong with anyone choosing to use Windows?

[evaleev]

@loriab the library now builds but python module does not ... https://github.com/evaleev/libint/actions/runs/7049909124/job/19189926846#step:7:13369

[JonathonMisiewicz]

exec-charset is Linux. execution-charset is Windows. 🙃

[loriab]

It might be worth disabling Win / Python in extract+build+install to ensure that the units tests and the HF are still good for windows with the symlink. It'll still fail on the Build& Test Python bindings where it builds pylibint again.

[loriab]

https://github.com/evaleev/libint/pull/287/files#diff-cdd48abbd3eb8d1c54077449fc74a8de1f29805d2be5d8e5232b7aab76ea7a6fL121-R125 can cut another 7 min off time-to-failure

[evaleev]

looks like the linking always fails ... https://github.com/evaleev/libint/actions/runs/7052599388/job/19198357371#step:8:78

guys, feel free to try but I'm ready to give up. This is extremely annoying.

[loriab]

looks like the linking always fails ... https://github.com/evaleev/libint/actions/runs/7052599388/job/19198357371#step:8:78

guys, feel free to try but I'm ready to give up. This is extremely annoying.

Definitely annoying. Best suggestion I have is having eye-friendly and file-friendly versions of the operator strings -- former for the code one looks at and latter for anything generated, for any OS, though the offender is Windows.

[JonathonMisiewicz]

The only other idea I have at this point is to try conda from pip rather than conda - the pip version goes through cmake and should behave correctly without symlink trickery. I don't know if that's acceptable for Lori's purposes.

[evaleev]

The only other idea I have at this point is to try conda from pip rather than conda - the pip version goes through cmake and should behave correctly without symlink trickery. I don't know if that's acceptable for Lori's purposes.

you mean pip can provide ninja built with cmake?

[loriab]

The only other idea I have at this point is to try conda from pip rather than conda - the pip version goes through cmake and should behave correctly without symlink trickery. I don't know if that's acceptable for Lori's purposes.

you mean pip can provide ninja built with cmake?

That's what I glean from https://github.com/ninja-build/ninja/blob/master/.github/workflows/windows.yml

The reservation Jonathon mentioned is that for c-f I need to be able to build the libint recipe from a controlled environment. They're not going to care for pinning consistency about a tool that gets consumed (like the ninja generator), but it may be tricky to get ahold of the software not from the c-f channel. But in terms of figuring out will-cmake-built-win-ninja fix this problem, worth a try.

[evaleev]

bye Operator::σpVσp 😭 hope to see you back soon

[JonathonMisiewicz]

This is needed to agree with the MPQC formulas.

Presumably need to update unit tests?

[JonathonMisiewicz]

I'm pretty sure you meant to start a new post rather than edit mine. But yes, I'm working on generating the test data now.