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! :)

[karol-koziol]

Dear @maj-mas Thank you very much for taking care of my case.

choose the labelling space from 5s,4p,4d,4f to 5s,5p,5d,5f,5g

Thank you for pointing that out. But if GRASPG requires all subshells for a given shell (not only occupied ones) for labeling space, the good idea is to do that automatically I think.

I have tested GRASPG for other atomic systems and “IOLPCK .LT. nvecmx, search too many levels” occured too. Please see attached files - for that case GRASP rci works fine, but GRASPG one is not. Labeling space looks OK, I guess.

GRASPG_issue_Al_He-like.tar.gz

[maj-mas]

I have tested GRASPG for other atomic systems and “IOLPCK .LT. nvecmx, search too many levels” occured too. Please see attached files - for that case GRASP rci works fine, but GRASPG one is not. Labeling space looks OK, I guess.

GRASPG_issue_Al_He-like.tar.gz

@karol-koziol I can't run your example, it crashes at the CI step, presumably due to the wavefunction file supplied:

INTRPQ: Grid of insufficient extent:
 Present grid has R(N) =  9.485476128378D+05 Bohr radii
          Require R(N) =  1.346053135674D+06 Bohr radii
 N =         590 MA =         597

did you compile for a non-default grid?

But if GRASPG requires all subshells for a given shell (not only occupied ones) for labeling space, the good idea is to do that automatically I think.

I'm inclined to agree.

[karol-koziol]

did you compile for a non-default grid?

Yes, it was compiled with NNNP = 1990 and NNN1 = 2000 in parameter_def_M.f90.

[maj-mas]

did you compile for a non-default grid?

Yes, it was compiled with NNNP = 1990 and NNN1 = 2000 in parameter_def_M.f90.

@karol-koziol okay, with this change I was able to run it and could reproduce your error. you're trying to find the 9th through 11th eigenvector, which seems to be what's causing trouble because there are only 6 labelling csfs in the labelling space, which is the limit for the number of evecs you can ask graspg to find:

Now perform rcsfgexpand ...
 block           1  NCSF(L) =           6  NCSF(G) =          47  NCSF =         328

this causes the following crash:

ncsfDF1=           6
 NVECMX=          11
STOP Error, IOLPCK .LT. nvecmx, search too many levels ...

if I try to find the 1st through 3rd eigenvector instead, it works fine. alternatively, you may increase the labelling space to 4s,4p,4d,4f, which increases NCSF(L) = 34, allowing you to search for evecs # 9-11 no problem.

does this help? :)

[karol-koziol]

@maj-mas Increasing the labelling space to 4s,4p,4d,4f helps in this case. Thank you - I will use that way. But, in my opinion, that trick is an ugly hack to override computer program design, having no physical meaning. I work often with core excited states - these are usually not the lowest states for given symmetry. Moreover, when I am increasing the active space of virtual orbitals, they go higher and higher on the level's list (being e.g. 20...50...100... in sequence) - that complicates everything.

[maj-mas]

@karol-koziol I'd just like to point out that I'm neither a developer nor maintainer of graspg, so if you have feedback that you think should reach them, please send it their way too (they don't seem very active on here)! if you want to call this a hack, sure. definitely I agree that the program could do a better job of educating its users as to how to make these critical parameter choices correctly. it seems that your use case was not at the front of the developers' minds when they designed graspg. I hope you can find out how to make it work for you! :)

[karol-koziol]

@maj-mas

it seems that your use case was not at the front of the developers' minds when they designed graspg

I guess you are right :-) Thank you for your help.

[maj-mas]

Thank you for your help.

anytime!