Failing to match lines in simple atoms with the config structure

[jhmatthews]

I first ran into this problem when testing #583 and its fix #597. It appears that python allows lines to be included in the database even when there is no upper level identified. This happens 897 times in Knox's flat_rwtri.pf file from #583, and 927 times if I change the dataset to standard79 - so it is not associated with having macro-atoms in the dataset.

The problem can be seen clearly here:

  for (n = 0; n < nlines; n++)
  {
    if (ion[line[n].nion].macro_info == 0)      // not a macro atom (SS)
    {
      mstart = ion[line[n].nion].firstlevel;
      mstop = mstart + ion[line[n].nion].nlevels;

      m = mstart;
      while (config[m].ilv != line[n].levl && m < mstop)
        m++;
      if (m < mstop)
        line[n].nconfigl = m;
      else
        line[n].nconfigl = -9999;

      m = mstart;
      while (config[m].ilv != line[n].levu && m < mstop)
        m++;
      if (m < mstop)
      {
        line[n].nconfigu = m;
        config[m].rad_rate += a21 (&line[n]);
      }
      else 
          line[n].nconfigu = -9999;
    }
  }

The code looks for levels associated with line[n].levu in the ion associated with the line, but if it doesn't find any it just sets it to -9999 and carries on. This is causing segfaults when one tries to look at nden for simple ions.

It's possible this isn't actually a big issue in the sense that the two level atom scheme does a sort of on the fly calculation of approximate level populations and so doesn't use nconfigu - in fact nconfigu is rarely used by non-macro atom code. However, I would have thought that the partition functions won't be accurate in such a case (will they?), and I would worry about whether the right levels are included for the bound-free opacities. Part of the issue is I don't really understand what we mean by "nlte_levels" in the code, and how one controls this. In any case, it clearly needs a bit of thinking about.

[jhmatthews]

I've renamed this so it refers to a more general issue. In the above code in get_atomicdata.c, we make an attempt to match entries in the linelist with entries in the config structure. This is done using the ilv variable in config, and the levu and levl entries in the line structure.

If you use standard78 data then the ilv variables in the topbase levels (look at e.g. data/atomic78/topbase_levels_cno.py) are not meaningful compared to the linelist - for example, the first 10 levels can have ilv = 1 in that file, so the matching between lines and config is somewhat arbitrary. This causes big problems if you want to access the levden array for the line in question. I think this may not matter for photionization cross-sections because when they are topbase cross-sections they check that the ISLP and ilv values both match.

It looks like Nick updated things a bit for standard80, the file data/atomic80/topbase_all_levels.py has different ilv entires although I don't know if they match entries in the line list (do you know @Higginbottom ?). Note also that standard80 has different elem_ions files with different numbers of maximum nlte_levels in that file.

I don't think this is a huge problem in terms of the operation of the code because we are doing an on the fly calculation of the levels for simple ions. However, in which case it's not really clear why the "NLTE" levels really exist other than for bound-free. The documentation in the code sort of implies that ions with specified "NLTE" levels should have their level populations calculated from the dilute approximation for line transfer, but I'm not sure.

It might be good if @kslong and @Higginbottom could have a quick look at this and see if they agree with me and comment on whether anything should be changed. Perhaps we can discuss on Monday.

[Higginbottom]

inline:

On 6 Sep 2019, at 09:31, James Matthews ***@***.***> wrote: I've renamed this so it refers to a more general issue. In the above code in get_atomicdata.c, we make an attempt to match entries in the linelist with entries in the config structure. This is done using the ilv variable in config, and the levu and levl entries in the line structure. If you use standard78 data then the ilv variables in the topbase levels (look at e.g. data/atomic78/topbase_levels_cno.py) are not meaningful compared to the linelist - for example, the first 10 levels can have ilv = 1 in that file, so the matching between lines and config is somewhat arbitrary. This causes big problems if you want to access the levden array for the line in question. I think this may not matter for photionization cross-sections because when they are topbase cross-sections they check that the ISLP and ilv values both match. It looks like Nick updated things a bit for standard80, the file data/atomic80/topbase_all_levels.py has different ilv entires although I don't know if they match entries in the line list (do you know @Higginbottom <https://github.com/Higginbottom> ?). Note also that standard80 has different elem_ions files with different numbers of maximum nlte_levels in that file.

I did this years ago - it was all to do with trying to improve agreement of PI heating between cloudy and python. I don't think that it worked - but I didn't think it made any odds either so I just never changed it back. This is however exactly the sort of thing we need to thrash out as part of a dedicated atomic data cleanup - there are lots of experimental files in there!!

…

I don't think this is a huge problem in terms of the operation of the code because we are doing an on the fly calculation of the levels for simple ions. However, in which case it's not really clear why the "NLTE" levels really exist other than for bound-free. The documentation in the code sort of implies that ions with specified "NLTE" levels should have their level populations calculated from the dilute approximation for line transfer, but I'm not sure. It might be good if @kslong <https://github.com/kslong> and @Higginbottom <https://github.com/Higginbottom> could have a quick look at this and see if they agree with me and comment on whether anything should be changed. Perhaps we can discuss on Monday. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/agnwinds/python/issues/601?email_source=notifications&email_token=AAZMZPMZS7Y2HBI772AUOQ3QIIIMJA5CNFSM4IS3QUPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6CE4TA#issuecomment-528764492>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZMZPMSSTPPSWT7TH3W6YDQIIIMJANCNFSM4IS3QUPA>.

[kslong]

I regard this as a bug, if it can happen. get_atomic_data should be modified so that we check for this on input and throw an error, with enough detail to figure out the problem level. The alternative, but it seems to me more effort would be to design a stand-alone python script to vet the files.