1-e σpVσp

[evaleev]

No description provided.

[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:

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

[evaleev]

Nice, was thereva real issue with D integrals then?

[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

[JonathonMisiewicz]

Lori suggested turning this OFF if we're still having problems even after this latest version.

[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.

[loriab]

Suggested change

	UNITY_BUILD FALSE
	UNITY_BUILD TRUE

avoids too many files for high AM

[evaleev]

r2g