This input file:

GEOMETRY
O 6-311G 0.000000 0.000000 -0.066575
e-[H] 6-311G 0.000000 0.754175 0.528381
e-[H] 6-311G 0.000000 -0.754174 0.528382
O dirac 0.000000 0.000000 -0.066575
H-a_1 Nakai-5-spd 0.000000 0.754175 0.528381
H-b_1 Nakai-5-spd 0.000000 -0.754174 0.528382
END GEOMETRY

TASKS
method = "RHF"
END TASKS

Results in an infinite loop of prints of

!!! WARNING !!!
Debug description: In ConstantsOfCoupling at load function.
Description: Elemental particle: O NOT found!!
!!!

Running this input with two heliums works fine, but crashes with three

SYSTEM_DESCRIPTION='H'

GEOMETRY
N0 dirac 0.0 0.0 0.0 rotationPoint=1
HEA3 HE-1S 1.8510585086564235 0.0 0.0 rotateAround=1
HEA3 HE-1S 0.0 1.8510585086564235 0.0 rotateAround=1
HEB3 HE-1S 0.0 0.0 1.8510585086564235 rotateAround=1
END GEOMETRY

TASKS
method = "UHF"
nonOrthogonalConfigurationInteraction=.T.
END TASKS

CONTROL
units="BOHRS"
rotationalScanGrid=6
END CONTROL

EXTERPOTENTIAL
HEA3 HE2C60-IH-1P
HEB3 HE2C60-IH-1P
END EXTERPOTENTIAL

INTERPOTENTIAL
HEA3 HEA3 HE2C60-IH-2P
HEA3 HEB3 HE2C60-IH-2P
HEB3 HEB3 HE2C60-IH-2P
END INTERPOTENTIAL

The error is:

At line 864 of file NonOrthogonalCI.f90
Fortran runtime error: End of record

Error termination. Backtrace:
#0 0x7f029f3bbd21 in ???
#1 0x7f029f3bc869 in ???
#2 0x7f029f3bd54f in ???
#3 0x7f029f5ffe10 in ???
#4 0x7f029f60ceab in ???
#5 0x7f029f6036f4 in ???
#6 0x7f029f6039d3 in ???
#7 0x55d93f65eaab in __nonorthogonalci__MOD_nonorthogonalci_runhfs
at /home/felix/desarrollo/lowdin2/src/NOCI/NonOrthogonalCI.f90:864
#8 0x55d93f63c86c in noci
at /home/felix/desarrollo/lowdin2/src/NOCI/NOCI.f90:72
#9 0x55d93f61d83e in main
at /home/felix/desarrollo/lowdin2/src/NOCI/NOCI.f90:30

Add warning or error messages when incompatible methods are selected. For example

RHF with third order propagator
RHF with full CI

Change openLOWDIN's compilation system to create one executable. Maintain the folder structure to separate the source code by method.

When we were running calculations with ^3He we noticed that the default mass (5494.8926 a.u.) is not exactly the mass of the isotope minus two electrons (5495.88509 a.u.).
The mass for this isotope in the lib/databases/atomicElements.lib is the correct one.
Are we still calculating the mass of the nucleus as the sum of the number of protons and electrons? (This is not an exact estimate)
We should update the default mass for the nucleus to first read the atomicElements.lib file and then if the mass is not found estimate it from the number of protons and neutrons

Some parts of the input are lowercase/uppercase sensitive, and I don't think they should be.

For instance, replacing ionizeSpecie="POSITRON" with ionizeSpecie="Positron" in the following input results in an error.

GEOMETRY
e-(F) DEF2-TZVPPD 0.0 0.0 0.0 addParticles=1 multiplicity=1
F dirac 0.0 0.0 0.0
E+ PSX-TZ 0.0 0.0 0.0
END GEOMETRY

TASKS
method = "UHF"
propagatorTheoryCorrection = 3
END TASKS

CONTROL
ptP3Method = "REN-P3"
!This line gives error
! ionizeSpecie = "Positron"
!This line works fine
ionizeSpecie = "POSITRON"
ionizeMO= 1
ptJustOneOrbital=.T.
END CONTROL

openLOWDIN is invoked using the lowdin2 binary file. Should we rename it to openLOWDIN?

My last commit didn't work because numpy was not in the packages installed

Also, I've not been very wise and started to mix python2 with python3 in the tests

Change source files header.

We can start by adding briefly commented inputs with the different methods implemented in Lowdin

The Erkale software that I use for the orbital localization is open-source with GPL license, so I can include it in our utilities folder
https://github.com/susilehtola/erkale

(This one is a reminder for myself)

Replace the JADAMILU diagonalization interface for an efficient open source or in-house code based on the Jacobi-Davidson method to compute selected eigenvectors of large sparse symmetric matrices (N = 10^9)

One of the tests fails, but it looks ok. The epsilon may be too strict. Should we change it to 1.0e-7?

HF energy [-92.903413350633, 1e-08] -92.90341333695 1.368300672766054e-08
HCN.e+.gribakin.uhf ... NOT OK

It would be nice to have custom basis sets read directly from the input.
I'm thinking of something like

GEOMETRY
E-(H) CC-PVQZ 0.0 0.0 0.0 multiplicity=2
H_1 CUSTOM 0.0 0.0 0.0
END GEOMETRY

TASKS
method = "UHF"
END TASKS

CONTROL
readCustomBasis=.T.
END CONTROL

BASIS
O-HYDROGEN H_1 (1S1P) BASIS TYPE: 2

this is the custom basis in deMon2k format

2
1 0 1
19.31300000 1.00000000
2 1 1
20.84390000 1.00000000
END BASIS

CISD- is Tachikawa CI method with only mixed electron+positron doubles excitation
CISD+ includes all the doubles plus mixed electron+positron triples

Need a couple tests of these calculations because they probably broke in apmo-nc-2 and master merge

Just like the density cube routine, but also for selected orbitals

Hi all
When trying to run the calculation in the input file

GEOMETRY
e-(F) aug-cc-pvtz 0.0 0.0 0.0 addParticles=2 multiplicity=1
e-(F) aug-cc-pvtz 0.0 0.0 1.9
e-(F) aug-cc-pvtz 6.0 0.0 0.0
e-(F) aug-cc-pvtz 6.0 0.0 1.9
F dirac 0.0 0.0 0.0
F dirac 0.0 0.0 1.9
F dirac 6.0 0.0 0.0
F dirac 6.0 0.0 1.9
E+ PSX-TZ 0.0 0.0 0.0
E+ PSX-TZ 0.0 0.0 1.9 addParticles=-1
E+ PSX-TZ 6.0 0.0 0.0 addParticles=-1
E+ PSX-TZ 6.0 0.0 1.9 addParticles=-1
END GEOMETRY

TASKS
method= "RHF"
mollerPlessetCorrection = 2
END TASKS

CONTROL
ionizeMO=1
ionizeSpecie ="Positron"
END CONTROL

I get this message :

Terminated
At line 211 of file ReadTransformedIntegrals.f90 (unit = 8)
Fortran runtime error: Cannot open file 'POSITRONmoint.dat': No such file or directory

Error termination. Backtrace:
#0 0x1514c5023960 in ???
#1 0x1514c50244d9 in ???
#2 0x1514c502510f in ???
#3 0x1514c5273ee6 in ???
#4 0x1514c52741dd in ???
#5 0x565050e965fe in __readtransformedintegrals__MOD_readtransformedintegrals_readonespecies
at /home/andres/programs/openLOWDIN-master/src/core/ReadTransformedIntegrals.f90:211
#6 0x565050e46011 in mollerplesset_secondordercorrection
at /home/andres/programs/openLOWDIN-master/src/MBPT/MPFunctions.f90:442
#7 0x565050e46011 in __mpfunctions__MOD_mollerplesset_run
at /home/andres/programs/openLOWDIN-master/src/MBPT/MPFunctions.f90:238
#8 0x565050e44fc0 in mbpt
at /home/andres/programs/openLOWDIN-master/src/MBPT/MBPT.f90:71
#9 0x565050e3f55e in main
at /home/andres/programs/openLOWDIN-master/src/MBPT/MBPT.f90:36

Any suggestions?

https://www.maqao.org/

• iteration scheme
• convergence method

In lib/potentials there are a lot of .xml files that are no longer supported. These should be cleaned

From what I see in the CI code, we no longer use larpack to diagonalize

When writing a molden output, we call the MolecularSystem_changeOrbitalOrder routine

This routine for the G functions seems not to be working properly. For example, when we load the molden file produced by this input

SYSTEM_DESCRIPTION='Molecula de H2O'

GEOMETRY
e-[O] CC-PVQZ 0.000000 0.000000 -0.066575
e-[H] 6-31G 0.000000 0.754175 0.528381
e-[H] 6-31G 0.000000 -0.754174 0.528382
O dirac 0.000000 0.000000 -0.066575
H_1 dirac 0.000000 0.754175 0.528381
H_1 dirac 0.000000 -0.754174 0.528382
END GEOMETRY

TASKS
method = "RHF"
END TASKS

OUTPUTS
moldenFile
END OUTPUTS

Molden computes:
Sum of Mulliken Charges: 0.0201

This number should be zero!

The sum of Mulliken Charges becomes zero if we replace the CC-PVQZ with CC-PVTZ basis. That's why I think the order of the G functions may be incorrect

Not only examples but include tutorials as well.

In DFT calculations right now we write to disk the grid points and the orbital basis values at those points. This can lead to writing/reading bottlenecks and low CPU usage

Like we did with libint2, To speed up Actions

When compiled openLOWDIN with the latest gcc12, gcc13, and clang on MacOS the NOCI tests fail.

Check orbital energies for example

Add the possibility of transforming cartesian orbitals to spherical or cubic harmonic orbitals.

Advantages:
i) Reduced number of AO, thus faster MO integral transformation
ii) Easier interface to other codes

openLOWDIN uses a bash script to parse the command line options and input files. The idea of this issue is to update it to use Python instead.

The SCF of an input like this converges fine, but the ionized orbital coefficients and the energy become NaN

GEOMETRY
e-(Li) cc-pVTZ 0.0000 0.0000 1.5949 multiplicity=1
e-(H) cc-pVTZ 0.0000 0.0000 0.00000
Li dirac 0.0000 0.0000 1.5949
H_1 dirac 0.0000 0.0000 0.0000
END GEOMETRY

TASKS
method = "UHF"
END TASKS

CONTROL
readCoefficients=F
ionizeSpecies="E-ALPHA"
IonizeMO=2
MOfractionOccupation=0.0
!works fine with any other number such as MOfractionOccupation=0.00000001
END CONTROL

Merge workflow steps with the readme

Update GSL library and test optimizer

If we write the wavefunctions coefficients in .plainvec file

GEOMETRY
e-(H) CC-PVDZ 0.00 0.00 0.00 multiplicity=2
H_1 dirac 0.00 0.00 0.00
END GEOMETRY

TASKS
method = "UHF"
END TASKS

CONTROL
writeCoefficientsInBinary=.F.
END CONTROL

Then, if we try to read those coefficients

GEOMETRY
e-(H) CC-PVDZ 0.00 0.00 0.00 multiplicity=2
H_1 dirac 0.00 0.00 0.00
END GEOMETRY

TASKS
method = "UHF"
END TASKS

CONTROL
readCoefficients=.T.
writeCoefficientsInBinary=.F.
END CONTROL

It seems that the program deletes the file before reading it.

NonOrthogonalCI.f90(43): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [DENSITYFUNCTIONALTHEORY_]
use MultiSCF_

As discussed in the last meeting, it would be nice to have a script similar to the github workflow that installs and compiles lowdin and its dependencies simultaneously. This script could have two compilation options, "regular" and "fast", relevant for the Libint2 flags for max angular momentum and G12 integrals.

2D densityPlots and orbitalPlots receive the end points information as
point1=0.0 0.0 -3.0 point2=0.0 0.0 3.0
It may be more intuitive to add something like
axis="z" initial=-3.0 end=3.0

and for the 3D plots
go from
point1=-3.0 0.0 -3.0 point2=-3.0 0.0 3.0 point2=3.0 0.0 -3.0
to
plane="xz" initial1=-3.0 end1=3.0 initial2=-3.0 end2=3.0

LAPACK might not be fully safe-thread. High energy unoccupied MO coefficents seems to give different numbers for different numbers of OMP threads. Check needed.
Check effect and performance of MKL_NUM_THREADS env option

Request made by Marcio: Some basis sets have changed compared to https://www.basissetexchange.org/

Error:

#3 0x7f5772af7410 in xc_func_info_get_name
at /home/felix/Dropbox/desarrollo/lowdin2/dependencies/libxc/src/func_info.c:24

Input:

GEOMETRY
e-(F) CC-PVDZ 0.00 0.00 -2.18021
e-(F) CC-PVDZ 0.00 0.00 2.18021
e-(H) NAKAI-CC-PVTZ 0.00 0.00 0.00 addParticles=1
F dirac 0.00 0.00 -2.18021
F dirac 0.00 0.00 2.18021
H_1 DZSPDN 0.00 0.00 0.00
END GEOMETRY

TASKS
method = "RKS"
END TASKS

CONTROL
electronExchangeCorrelationFunctional="NONE"
units="BOHRS"
integralStorage="MEMORY"
END CONTROL

It would be a nice extension to have different state wavefunctions on the same geometry of NOCI. For this I need the extended Slater rules of 10.1063/1.3236841

and fix spelling mistakes

invalid memory reference in some parallel calculations in tetralith (trying to reproduce this error)

Format error in coords file
Skipping system with same charge particle separation********************