Conversation
…evels are described in the database than are populated in the model
|
I find this logic a bit confusing. Is it not sufficient to just take the min between |
|
Two additional requests:
|
|
I took the max between n_levels_scups and n_levels_wgfa assuming that if at least one file refered to an energy level, it should be included in the model. This only really matters for Ar 18, where if you took the minimum, level 25 would be excluded. Maybe it should be ... I find two cases (updated from original post) where n_levels_elvlc is > n_levels_scups and n_levels_wgfa: N 4 Ar 6 I find one case where n_levels_scups > n_levels_wgfa: And a few cases where there is now scups or wgfa file: Cr 24 Zn 30 |
|
The cases where there are no scups or wgfa files are fine. In those cases, there is effectively no model and so you can't compute a contribution function anyway. |
|
Ok I'm now confused again about what the logic behind choosing the number of levels for the model is. This is what is in the IDL code: which is consistent with what we wrote above except for the inclusion of the autoionization rates. I think this is included to make sure that in the case of the two-ion model, those rates don't get cut off. In practice, I don't find any ions where the max scups level is less than the autoionizing levels and the max autoionizing level isn't also equal to the max elvlc or wgfa level. In other words, However, I'm guessing we should still safeguard against this possibility and just implement the IDL logic here. I'll push a commit to make this change. |
|
Oh no. Something has gone horribly wrong. The example gallery is failing because not enough levels are getting included to account for the necessary rates. The contribution function example works fine locally. I think this may be due to the fact that some of the |
|
Ok the Ar XVIII case you flagged earlier is now the latest problem. By the logic that is now implemented, the number of levels in the model can be less than the number of levels in the scups. In v11, this happens in the case of Ar XVIII. Because the rate matrix is not big enough to include the 25th level, when it tries to add that rate it throws an I'm not quite sure how to deal with this yet. |
|
I went through and did some additional checks on the number of levels included in each ion. Here are some useful findings broken down by ion and version: |
|
Ok this has become way more complex than I thought. I think only a few remaining fixes though (which I'm documenting here for myself):
|
Fixes #425
Fixes #345
The main purpose of this PR is to fix the definition of the number of levels used by the CHIANTI atomic model. Previously, it was assumed that this was just equal to the number of energy levels in the
elvlcfile. However, this logic fails in certain cases (e.g. N IV) where there are not radiative decay rates available for all levels given in theelvlcfile.As such, the number of levels is now calculated as the minimum across the highest level available in the
elvlc,wgfa, andscupsfiles. This ensures that there is enough information to fully describe the atomic model. This is consistent with what is done in CHIANTI IDL. There is an additional correction ifautofiles are present to ensure that a sufficient number of levels are included to capture the autoionization rates.As part of this refactor, the number of transitions in
Ion.transitionsis now truncated to include only those transitions between levels in the atomic model.Ion.levelsstill includes all information in theelvlcfile, i.e. even those levels which are not included in the atomic model.This also includes a minor fix to the two-photon calculation which takes advantage of the label/configuration properties added in #427.
Other misc. changes:
autofiles to test database to ensure the number of levels is always calculated appropriately.pyproject.toml)