segfault & bus error, and mismatched population in CRM involving multiple ions about fac HOT 9 CLOSED

I dump the data in one test involving 3 ions. k=67. It looks clearer.
DumpRates(fn, 67, 0 ,-1, 1):

67      0     30      0  7   -1  501 -1.61161047E+04  6.730E-01  1.203E+01  1.000E+00
...

DumpRates(fn, 68, 0 ,-1, 1):

...
67   3403     35      0  7   -1  501 -1.61161047E+04  2.584E-08  6.548E+06  1.000E+00
...
67   4192     30      0  7   -1  502 -1.61124411E+04  6.730E-01  1.203E+01  1.000E+00
...

level 0 in the first table and level 3403 in the second table should be the same energy level 4f13. Their energies are the same. However, their populations and decay rates are different.
level 4192 is 4f13.5s1.5d1 and its energy is higher. But its population and decay rate equal to level 0's data.

from fac.

from fac.

from fac.

I checked the result of CRM module. All energy levels' population change depending on time, dN/dt, should equal to 0.
For the 3 ions model, relative to using the "right" population, if I used the mismatched pupulation when sumed the RR rates, more levels' dN/dt were far from 0, but the the sum of the total CI, AI and RR rates was closer to 0.

The FAC I used seems to be earlier than 2019.05. And, though all the CX data could be read successfully, only the first ion's CX data could be involved in the CRM calculation.
Considering a lot of fix during the last year, I install the lastest version in a vmware workstation. However,
If NormalizeMode=2, the model i used above would fail.

Population Iteration:
    0  1.0000E+00  1.1271E-01  1.1271E-01  3.0101E+08
    1        -NAN  1.0728E-01  2.1998E-01  3.0101E+08

If NormalizeMode=1, though the model runs successfully, the result is wrong. There's no process between different ions, i.e, CI, AI and RR process. And the coresponding dump file is empty.
But the demo FeL goes well. I don't know what's wrong.

from fac.

I'm finally having some time to check on this. But I cannot find your scripts that you said you attached.

from fac.

I will send that old script again by e-mail. Or maybe you can find that in rubbish bin.
Emm...Is the script can't be attached by reply-email? This time I mail to the personal email, too.

And I have tried to fix the problem.
The first one is the segfault. In line 5890, crm.c, the subscript should be jb, not ib, or the script would return segfault if the data block is larger than NRTB. I find that this has been fixed days ago. #463

The second one is the mismatched population. It happens in the function FindLevelBlock according to the debug. But my version is before 2019.05. This function changed a lot after several updates. But it seems that there is still some mistakes in the new one.

Debug on old version fisrt.

1. OLD VERSION

  if (k < n) {
    FSEEK(f, sfh, SEEK_SET);
    nr = ReadENHeader(f, &h, swp);
    j = h.nlevels;
    for (i = 0; i < h.nlevels; i++) {
      nr = ReadENRecord(f, &r1[k], swp);
      if (strcmp(r1[k].ncomplex, r0[0].ncomplex) != 0) j--;
      if (j < n) {
	k++;
	if (k == n) break;
      }
    }
  }

  if (k != n) return k;

The conditional statement if (j < n) doesn't limit enough since j = h.nlevels and n = h.nlevels in my scripts. Once a level whose complex is different from the 'ground' level's comes, j will smaller than n. Then all the levels coming later will be imported. Since some levels whose complex are the same as the 'ground' level's have been imported before this code, part of the data to be sorted may be duplicate. This causes the mismatching.
So I modified a little like below. It works well, though it looks rough and redundant. At least the CRM can finally run successfully.
In my script, each ion is optimized before calculating the level table. So the levels can be matched relatively good according to their level indexs. Therefore, I don't think it is universally applicable. Some relativistic configurations whose energy are high may mismatch.

  if (k < n) {
    FSEEK(f, sfh, SEEK_SET);
    nr = ReadENHeader(f, &h, swp);
    j = h.nlevels;
    for (i = 0; i < h.nlevels; i++) {
      nr = ReadENRecord(f, &r1[k], swp);
      if (strcmp(r1[k].ncomplex, r0[0].ncomplex) != 0) {
      j--;
      if (j < n) {
	k++;
	if (k == n) break;
      }
      }
    }
  }

2. NEW VERSION
   In fact i can't understand the new function FindLevelBlock. Anyway, i try the new one for my script. The result is rather strange. I am sorry that I don't take much effort on the new code, so i can't ensure the accuracy of description. Here are the new problem.

level 3121~3123 are missing

NELE    = 67
NTRANS  = 1
TYPE    = 0000000
IBLK    = 1
ICOMP   = 4*31.5*8
FBLK    = 0
FCOMP   =
  3120      0  1.214322E+02  5.8814E-02  6.0000E+00  1.7743E+02

NELE    = 67
NTRANS  = 1
TYPE    = 0000000
IBLK    = 2
ICOMP   = 4*31.5*8
FBLK    = 0
FCOMP   =
  3124      0  1.616338E+02  1.1538E-07  8.0000E+00  6.8607E+06

one level has different population

NELE    = 67
NTRANS  = 1
TYPE    = 0000505
IBLK    = 2
ICOMP   = 4*31.5*8
FBLK    = 0
FCOMP   = 4*31.5*8
     5      0  4.236129E+01  7.8772E-01  6.8606E+06  5.2315E+01

NELE    = 67
NTRANS  = 1
TYPE    = 0000505
IBLK    = 2
ICOMP   = 4*31.5*8
FBLK    = 1
FCOMP   = 4*31.5*8
     5      1  4.020158E+01  3.8439E-03  6.8607E+06  5.3086E+01

from fac.

from fac.

the level mismatch is due to the assumption I made that the levels in the same block have the same distribution over the principal quantum numbers, or the n-complexes as I had called them. I have now relaxed this restriction. try the new version to see if it fixes your problem.

from fac.

almost there. In a 2-ions model, level's population is the same as the result of the modified old code. So is the light emissivity. But the TR rates seem to be strange. While the data in dump files are the same despite that there're more information with the new code.
version around 2019.05

#.sp file
NELE	= 67
NTRANS	= 1
TYPE	= 0000505
IBLK	= 5
ICOMP	= 4*31.5*8
FBLK	= 0
FCOMP	= 4*31.5*8
     5      0  4.236129E+01  7.7388E-01  6.8273E+06  6.8607E+06
...
     5      1  4.020158E+01  3.7763E-03  3.3315E+04  6.8607E+06

#.d0 file
 67   3124      5      0  7   -1  502 -1.61145467E+04 1.1335E-07 6.8607E+06 1.0000E+00

#.d1 file
 3124    3119  6.827E+06  0.000E+00
 3124    3120  3.332E+04  0.000E+00

the lastest version

NELE    = 67
NTRANS  = 1
TYPE    = 0000505
IBLK    = 5
ICOMP   = 4*31.5*8
FBLK    = 0
FCOMP   = 4*31.5*8
     5      0  4.236129E+01  7.7388E-01  6.8606E+06  6.4688E+01
...
     5      1  4.020158E+01  3.7763E-03  6.8607E+06  6.4730E+01

#.d0 file
 67   3124      5      0  7   -1  502 -1.61145467E+04 1.1335E-07 6.8607E+06 1.0000E+00 6.8606E+06 3.8042E+01

#.d1 file
 68    3124    3119  6.827E+06  0.000E+00
 68    3124    3120  3.332E+04  0.000E+00

from fac.