IOLPCK .LT. nvecmx, search too many levels

[karol-koziol]

Last months I am testing program GRASPG. However, recently I reached an issue I cannot address it. In some cases the code produces error "STOP Error, IOLPCK .LT. nvecmx, search too many levels" - the minimal working example is attached. The GRASP code runs fine in such case.

GRASPG_issue.zip

[maj-mas]

During the past two weeks I've been trying to find the root cause of this. The problem is that the variable ncsfDF1 which seems to count the number of labelling CSFs in the .g file can sometimes be zero, namely when there is no labelling CSF in the file for a symmetry block. This causes the crash in MANEIG.

I've tried circumventing the problem by accepting ncsfDF1 == 0, making sure the value of NMAX passed to the various versions of INIEST downstream is sufficiently enlarged. This in turn caused problems with the striding of array accesses in e.g. INIESTmpi, for which I separately found a fix.

While the CI calculation can finish successfully with these modifications and the energies look okay, it causes a crash in jj2lsj because ncsfDF1 == 0 or rather scfDF1(IBLKNUM) == 0 leads to key parts of the jj2lsj subroutine being skipped. Similarly, rbiotransform and rtransition don't work correctly.

An example for input to rcsfggenerate_csfg that causes a CSFG file with no labelling CSFs is the following for the 4f13 5s1 state with a [Kr] 4d core:

$ rcsfggenerate_csfg <<EOF
0
1s(2,c)2s(2,c)2p(6,c)3s(2,c)3p(6,c)3d(10,c)4s(2,c)4p(6,c)4d(10,c)4f(13,*)5s(1,*)

5s,4p,4d,4f
0,12
0
y
1s(2,c)2s(2,c)2p(6,c)3s(2,c)3p(6,c)3d(10,c)4s(2,c)4p(6,c)4d(10,c)4f(13,*)5s(1,*)

6s,6p,6d,6f,6g
0,12
2
n
EOF

The head of rcsfg.out is

Core subshells:
  1s   2s   2p-  2p   3s   3p-  3p   3d-  3d   4s   4p-  4p   4d-  4d
Peel subshells:
  4f-  4f   5s   6s   5p-  6p-  5p   6p   5d-  6d-  5d   6d   5f-  6f-  5f   6f   5g-  6g-  5g   6g
CSF(s):
  4f-( 5)  4f ( 8)  6d ( 1)
      5/2               5/2
                           0-
  4f-( 6)  4f ( 7)  6g-( 1)
               7/2      7/2
                           0-
  4f-( 4)  4f ( 8)  5s ( 1)  6p ( 1)
        2               1/2      3/2
                           3/2      0-
  4f-( 4)  4f ( 8)  5s ( 1)  6p-( 1)
        0               1/2      1/2
                           1/2      0-
  4f-( 4)  4f ( 8)  5s ( 1)  6f ( 1)
        4               1/2      7/2
                           7/2      0-

where already the first CSF contains subshells outside the labelling space:

          17   = nonsym
  1s   2s   2p-  2p   3s   3p-  3p   3d-  3d   4s   4p-  4p   4d-  4d   4f-  4f   5s

I'm beginning to suspect that I've misunderstood how to choose the labelling space for this system and that that may explain the problems I'm facing. Any guidance would be greatly appreciated!

[maj-mas]

@karol-koziol yes, I can report that changing how I choose the labelling space from

5s,4p,4d,4f to 5s,5p,5d,5f,5g

fixes the problem and also the behaviour reported by @mchatzikos in #4 for my case

perhaps it would be useful to point users to the criticality of choosing the labelling space sensibly somewhere, since if no labelling csfs end up in the csfg file, all kinds of problems can occur :) but with hindsight, the mistake is obvious when re-reading the graspg paper

I hope this helps you Karol! :)