Describe the bug

The problem appears when I manually set the path to the config file.
This means skprogs first reads the default skdef.hsd file and then reads another, let's say, my_skdef.hsd file.
The next step is an update of Skdef dictionary by another dictionary made from my_skdef.hsd.
However, during this update, only the atomparamters field is updating, but not OnecenterParameters and not TwocenterParameters.

All of the written above can be easily fixed below this line

If that was made on purpose, please, let me know why that was made in a such way.

To improve the flexibility of the pseudo-atom calculations, manually adjusting the required SCF convergence tolerance would be helpful to deal with cases that (for any reason) do not reach the extremely tight default tolerance of 1e-10 a.u.

Just a few notes on what I found out while working with conda on this, installing dependencies and building is quite straight-forward with the currently available libxc package on conda-forge (if the version is selected correctly):

mamba create -n libxc-4 'libxc=4.*' -c conda-forge
mamba activate libxc-4
export PKG_CONFIG_PATH=$CONDA_PREFIX/lib/pkgconfig/:$PKG_CONFIG_PATH
cmake -B _build -G Ninja
ninja -C _build

There is another potentially compatible version of libxc in the psi4 channel, which provides the CMake module files, but no Fortran interface.

Describe the bug

!!! [common] AtomParameters/ra:
Mismatch between specified total charge and occupations (0.00000000 vs. 2.00000000)

To Reproduce

Ra {
AtomConfig {
AtomicNumber = 88
Mass = 226
Occupations {
$OCCUPATIONS_Rn
6D = 0.0 0.0
7S = 1.0 1.0
7P = 0.0 0.0
}

skdef.hsd_Ra.txt

or

Ra {
AtomConfig {
AtomicNumber = 88
Mass = 226
Occupations {
$OCCUPATIONS_Xe
4F = 7.0 7.0
5D = 5.0 5.0
6S = 1.0 1.0
6P = 3.0 3.0
6D = 0.0 0.0
7S = 1.0 1.0
7P = 0.0 0.0
}

An error that may be related.
[skgen.compression] Processing compression for shell(s) 6d 7s 7d
[skgen.compression] Calculating compressed atom (build/th/comp.gkk28jl)
"!!! [common] Missing wave function file build/th/comp.gkk28jl/wave_07s_up.dat"

Th {
AtomConfig {
AtomicNumber = 90
Mass = 232.04
Occupations {
$OCCUPATIONS_Rn
6D = 2.0 2.0
7S = 0.0 0.0
7P = 0.0 0.0
}

skdef.hsd_Th.txt

I looked at "sktools/src/sktools/common.py" and "sktools/src/sktools/skdef.py" but I don't know where the problem is. I feel that the electrons in the orbit where the principal quantum number is 7 cannot be counted accurately.

Expected behaviour

I want to be able to calculate up to Pu.

Additional context

Hello,

I did the installation of skprogs to generate the parameter files. The installation was successful but when I'm calling skgen -h I got the below-given error:
(skprogs) ram123@LAPTOP-TH1ME530:~$ skgen -h
Traceback (most recent call last):
File "//opt/skprogs/bin/skgen", line 5, in
from sktools.scripts.skgen import main
ModuleNotFoundError: No module named 'sktools'

Any idea why this is happening?
Thanks in advance!
-Ram

Using entry_point rather than script for installing the sktools should be preferred.

At the moment, non-converged pseudo-atom calculations issue (slateratom output):

ERROR!
-> SCF is NOT converged, maximal SCF iterations exceeded.

Nevertheless this information is not processed by the sktools framework and the user will see:

.
.
File "/home/user/venvs/skprogs-devel/lib/python3.10/site-packages/sktools/calculators/slateratom.py", line 374, in __init__
  fp = open(os.path.join(self._workdir, "energies.tag"), "r")
FileNotFoundError: [Errno 2] No such file or directory: '_build/h/atom.0fo5fel_/atom0_spin/energies.tag'

It would be nice if we could provide a more useful error message in these situations, especially since MaxSCFIterations and SCFTolerance have been introduced by #43.

Some integrator settings are hard-coded right now (sktools), including:

• number of radial/angular integration points
• maximum angular momentum of Gaunt coefficients
• ...

Hi. Thanks for open sourcing the package.
I realized that linking against libxc 5.1.2 does not result in successfull build with following trimmed error log:

[ 64%] Building Fortran object slateratom/lib/CMakeFiles/skprogs-slateratom.dir/dft.f90.o
/home/pezhman/repos/dev/skprogs/slateratom/lib/dft.f90:67:27:

   67 |     type(xc_f90_pointer_t) :: xcfunc_x, xcfunc_c, xcinfo
      |                           1
Error: Derived type ‘xc_f90_pointer_t’ at (1) is being used before it is defined
/home/pezhman/repos/dev/skprogs/slateratom/lib/dft.f90:78:36:

   78 |       call xc_f90_func_init(xcfunc_c, xcinfo, XC_LDA_C_PW, XC_POLARIZED)
      |                                    1
Error: Symbol ‘xcfunc_c’ at (1) has no IMPLICIT type
/home/pezhman/repos/dev/skprogs/slateratom/lib/dft.f90:77:36:

   77 |       call xc_f90_func_init(xcfunc_x, xcinfo, XC_LDA_X, XC_POLARIZED)
      |                                    1
Error: Symbol ‘xcfunc_x’ at (1) has no IMPLICIT type
/home/pezhman/repos/dev/skprogs/slateratom/lib/dft.f90:77:44:

   77 |       call xc_f90_func_init(xcfunc_x, xcinfo, XC_LDA_X, XC_POLARIZED)
      |                                            1
Error: Symbol ‘xcinfo’ at (1) has no IMPLICIT type; did you mean ‘xcnr’?

I could successfully build the package using libxc 4.3.4. I thought to share it here if someone else also faced similar issue. Also, it could be nice to have a fix for this or warning in documentation at some point in future.

Installing sktools with pip install sktools/ for release 0.1 does install a broken collectwavecoeffs script:

+ collectwavecoeffs -h
Traceback (most recent call last):
  File "/home/conda/staged-recipes/build_artifacts/sktools_1654853532198/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/bin/collectwavecoeffs", line 84, in <module>
    main()
  File "/home/conda/staged-recipes/build_artifacts/sktools_1654853532198/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/bin/collectwavecoeffs", line 63, in main
    skdefs = Skdef.fromfile('skdefs.py')
  File "/home/conda/staged-recipes/build_artifacts/sktools_1654853532198/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/python3.10/site-packages/sktools/skdef.py", line 59, in fromfile
    fp = open(fileobj, "r")
FileNotFoundError: [Errno 2] No such file or directory: 'skdefs.py'

Should use fpm layout

Lacks testing

README.rst referenced but not present.

Currently, the following xc-functionals lack regression testing:

• LCY-PBE
• LCY-BNL

The sktools script export a date based version (22.1), while the skprogs binaries export a semantic version 0.9, both are inconsistent with the tagged version (see #33).

What is your suggested feature? Please describe.
More documentation for local compilation (particularly libXC)

Is your feature request related to a problem? Please describe.
Would be good to spell out:

• don't use debian libXC packages
• If using the libXM configure script, set a local install path (as the skprogs cmake needs it to be installed for the package files to work)

Describe the solution you'd like
Slight expansion of the README

I suggest adding topics such as density-functional-theory, tight-binding, quantum-chemistry, slater-koster in the About section.

What is your suggested feature? Please describe.
To achieve at least thread parallelization of sktwocnt, two problems should be addressed:

1. anglib is not thread-safe and its module structure is at least questionable
2. OMP will be unable to copy the derived integrator type in the loop over dimer distances
   (workaround for testing: initialize integrator within the loop --> results in overhead due to recalculated finite differences matrices)

The check_version attribute doesn't seem to exist in the common functionalities, see:

Description of the bug

The problem appears when I run collectspinw with a manually set path to the .hsd file.

Expected behavior

Adding one more keyword to the input parsing procedure

To improve the flexibility of the pseudo-atom calculations, manually adjusting the maximum number of SCF steps would be helpful to deal with cases that (for any reason) do not converge within 120 steps (default).

The latest tag exports version 0.1, however the binaries print version 0.9 with the --version option.

Needs updating and expanding

What is your suggested feature? Please describe.
Non-converged calculations should be marked accordingly and probably not used any further (sktools). Currently, slateratom runs bluntly into the iteration limit and is not really interested in convergence.
(E.g. CAM functionals sometimes refuse to converge to (admittedly very tight) 10^(-10) a.u. in the potential. We should probably make this option accessible to the user, maybe via skdef.hsd.)

Describe the bug

The cmake install copies over the binary components, then takes a very long time to eventually complete, but without copying the Python components into the install.

To Reproduce

cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local/ ..
popd
cmake --install _build

Expected behaviour

Local install of Python components into

~/.local/lib/python3.10/site-packages/

Additional context

Ubuntu 22.04 and current main

and possibly PRs

In case of ZORA relativistics, the calculated and printed total energy is wrong. Does not affect SK-file generation though.

(this is more of a question)

For fun I replaced the current LDA and PBE routines of sktwocnt by their libxc counterpart, resulting in:

  use, intrinsic :: iso_c_binding, only : c_size_t
  use xc_f90_lib_m, only : xc_f90_func_t, xc_f90_func_info_t, xc_f90_func_init,&
      & xc_f90_func_get_info, xc_f90_lda_vxc, xc_f90_gga_vxc, xc_f90_func_end, XC_LDA_X,&
      & XC_LDA_C_PW, XC_GGA_X_PBE, XC_GGA_C_PBE, XC_UNPOLARIZED

  subroutine getxcpot_ldapw91(rho4pi, xcpot)
    real(dp), intent(in) :: rho4pi(:)
    real(dp), intent(out) :: xcpot(:)

    !> libxc related objects
    type(xc_f90_func_t) :: xcfunc_x, xcfunc_c
    type(xc_f90_func_info_t) :: xcinfo

    !> density with libxc compatible normalization
    real(dp), allocatable :: rho(:)

    !> exchange and correlation potential on grid
    real(dp), allocatable :: vx(:), vc(:)

    !> number of density grid points
    integer(c_size_t) :: nn

    call xc_f90_func_init(xcfunc_x, XC_LDA_X, XC_UNPOLARIZED)
    xcinfo = xc_f90_func_get_info(xcfunc_x)
    call xc_f90_func_init(xcfunc_c, XC_LDA_C_PW, XC_UNPOLARIZED)
    xcinfo = xc_f90_func_get_info(xcfunc_x)

    nn = size(rho4pi)
    allocate(vx(nn), vc(nn))

    rho = rho4pi * rec4pi

    call xc_f90_lda_vxc(xcfunc_x, nn, rho, vx)
    call xc_f90_lda_vxc(xcfunc_c, nn, rho, vc)

    xcpot(:) = vx + vc

    call xc_f90_func_end(xcfunc_x)
    call xc_f90_func_end(xcfunc_c)

  end subroutine getxcpot_ldapw91


  subroutine getxcpot_ggapbe(rho4pi, absgr4pi, laplace4pi, gr_grabsgr4pi, xcpot)
    real(dp), intent(in) :: rho4pi(:)
    real(dp), intent(in) :: absgr4pi(:), laplace4pi(:), gr_grabsgr4pi(:)
    real(dp), intent(out) :: xcpot(:)

    !> libxc related objects
    type(xc_f90_func_t) :: xcfunc_x, xcfunc_c
    type(xc_f90_func_info_t) :: xcinfo

    !> density with libxc compatible normalization
    real(dp), allocatable :: rho(:)

    !> contracted gradients of the density
    real(dp), allocatable :: sigma(:)

    !> exchange and correlation potential on grid
    real(dp), allocatable :: vx(:), vc(:)

    !> first partial derivative of the energy per unit volume in terms of sigma
    real(dp), allocatable :: vxsigma(:), vcsigma(:)

    !> number of density grid points
    integer(c_size_t) :: nn

    nn = size(rho4pi)
    allocate(vx(nn), vc(nn), vxsigma(nn), vcsigma(nn))

    rho = rho4pi * rec4pi
    sigma = (absgr4pi * rec4pi)**2

    call xc_f90_func_init(xcfunc_x, XC_GGA_X_PBE, XC_UNPOLARIZED)
    xcinfo = xc_f90_func_get_info(xcfunc_x)
    call xc_f90_func_init(xcfunc_c, XC_GGA_C_PBE, XC_UNPOLARIZED)
    xcinfo = xc_f90_func_get_info(xcfunc_x)

    call xc_f90_gga_vxc(xcfunc_x, nn, rho, sigma, vx, vxsigma)
    call xc_f90_gga_vxc(xcfunc_c, nn, rho, sigma, vc, vcsigma)

    xcpot(:) = vx + vc

    call xc_f90_func_end(xcfunc_x)
    call xc_f90_func_end(xcfunc_c)

  end subroutine getxcpot_ggapbe

The values for vx(:) and vc(:) however are very different (resulting in deviations 1e-7 a.u. for LDA and 1e-2 a.u. for PBE Hamiltonian matrix elements). Maybe I screwed something up with the normalization of the density (-gradient) or is this a known issue due to possibly different implementations (Burke's Fortran implementation <--> libxc)?