Improve bound-bound collisions

[jhmatthews]

Our treatment of bound-bound collisions should be improved, for a few reasons.

• no treatment of collisions along radiatively forbidden transition paths.
• Van Reg is accurate to about 1dex: there is good enough data to not need to make this kind of approximation anymore, but we may still need to make some (e.g. evaluate collision strength at one temp)
• alternatively, even if using something like Van Reg / other functional forms, effective gaunt factors can be improved.

In commit agnwinds/python@263aa81 I have modified the gaunt factor from 1 to either 0.1*(kT/hnu) for neutrals when kT/hnu<2, and 0.2 otherwise. I chose 2 to avoid discontinuities in a gaunt factor, so it's somewhat arbitrary. I am looking into how good this is, but again, we are probably only within a factor of a few here. It will probably do for the QSO paper as it doesn't affect results

[ssim]

SS will pick this up (Belfast 2018).

Issue is around understanding how bb collisions come into macro atom treatment.

Of the original list on this report, the main one I want to think about it how to bring in collisional data when we currently don't have any radiative data.

[kslong]

Part of the issue here is the way we read data in. At present, one can only read data in for a line that exists, even if there are levels defined, because we use the line data to match the line. It seems to me we should modify the format of the collision data so that it refers to levels and not lines that exist. For Chianti, there is certainly collision data even when there are no lines in Chianti. @jhmatthews @ssim is the problem deeper than this, if we had collision data between levels where there was not line data, will the macro atom software handle this properly. Or does dummy line data need to be added.

I suspect we are being defeated by history here, where the macro atom approach came later than simple atoms and we might already have incorporated the collisions into the simple approach. Or possibly it is just that we were and continue to create lines from sources other than Chianti.

At any rate, as I have been trying over the holidays to understand how to generate macro-atom data files from Chianti, I would like us to pick this up.

[ssim]

Hi Knox, Currently I don’t think the machinery would quite handle the use where there is collisional data but no “line” because the way the bb jumps/transitions are set up is based on the lines (the bb_jumps are indices into the line list). Without a rewrite, the easiest way is to add a line to the list with an A value of 0 - then it will pick it up and if the collisional data flows through it will appear as a process everywhere I think. To avoid that - i.e. to have bb collisions that and indexed separately from the line list - would require a bit of a rewrite - it wouldn’t be very hard to do it in a clunky sort of way (just add another class of transition and put appropriate looks in matom), but to do it elegantly might require some thought. Stuart

[kslong]

Thanks, @ssim I thought making this modification were something you had signed up to do following Belfast (See early comments on this issue). But I guess you are now saying you don't think it is worthwhile.

I do understand that one can create a "fake radiative transition" to do this as part of the input data. This complicates though attempts to automate generating workable macro atom input files, which was what I have been trying to do.

[ssim]

Hi Knox Yes, I think that when we went through this before it was my impression that currently the collisional data is really linked up at quite a deep level with the line list of radiative transitions - i.e. the q_12 and q_21 routines (that lie at the heart of things for bb collisions) were always written with reference to the line pointer. That choice predates anything to do with macro atoms but the macro atom machinery has always piggy backed off that choice. So the pragmatic way to handle it all would be read in the collisional data for macro atom lines just like for any other - using the method that I believe Nick implemented -this uses the “coll_index” part of the line list. To activate that, I believe, one would just need to supplement the radiative macro atom data files with suitable lines in the collision data input. I’m not 100% familiar with that format - but it’s explained at line 2489 of get_atomicdata.c. I think our guess was that that would work just fine so long as (i) there was a line read in already - hence the need for a dummy line in the macro atom read in and (ii) the indices for the levels are correctly set (iii) the format provided in the collision file was correct. Last time we thought about this, I think I advocated that - at least for now - it would probably be best to try just handling things this way, rather than first trying to re-write things to avoid a correspondence of collisions with the line list. This is partly pragmatism, but it’s also worth noting that the number of “redundant” radiative lines should be modest: the only truly redundant lines I think will be between strictly forbidden radiative transitions (things like 2s-1s) and between J-substates of given terms (after all, we probably want to include intersystem/semi-forbidden lines - and potentially even quadruplos - in some low-density circumstances). Of these, the transitions between J-substates will always be very long wavelength and so will not interfere with the regions we simulate - so I think it’s arguable (at least so long as we’re talking about things like H, He, C, N, O etc.) that it’s not that wasteful (in terms of CPU time) to use dummy lines, given that it ought not to require any significant code alterations. There might be an issue with the memory size of the estimator structures at some point - but this might already be an issue if we want to use a lot of detailed macro atoms even with only the E-dipoles… so we might in any case need to find a strategy for those structures: but it would be best, in my view, to see what the real issues are first before solving those (probably high-level) problems. …however, I think we never got round to trying it out - the issues of why Ciara’s atomic models didn’t behave robustly distracted us from trying that out so far, I think. Stuart On 27 Dec 2019, at 15:28, Knox S. Long <[email protected]<mailto:[email protected]>> wrote: This message is from an external sender. Please take care when responding, clicking links or opening attachments. Thanks, @ssim<https://github.com/ssim> I thought making this modification were something you had signed up to do following Belfast (See early comments on this issue). But I guess you are now saying you don't think it is worthwhile. I do understand that one can create a "fake radiative transition" to do this as part of the input data. This complicates though attempts to automate generating workable macro atom input files, which was what I have been trying to do. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://github.com/agnwinds/python/issues/188?email_source=notifications&email_token=AAGA6LP2HLSJ54DR7FHHTADQ2YNIDA5CNFSM4BT3DAL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHXLDZY#issuecomment-569291239>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAGA6LJLM7WGK4J7FS54TY3Q2YNIDANCNFSM4BT3DALQ>.

[kslong]

Here are some statistics. If you use the Chianti data and ask for all the lines that connect levels up to and including 10 for C_IV, you find There were 24 (of 606) collision x-sections with nlev <= 10, and 12 that matched 19 lines So if you want to add these x-sections, you would need to add 12 fake lines If you increase the number of energy levels to 20, then There were 54 (of 606) collision x-sections with nlev <= 20, and 23 that matched 65 lines So you would need to add 54-23 or 31 fake lines to the 65 real lines. For He I There were 36 (of 268) collision x-sections with nlev <= 10, and 12 that matched 14 lines This is not necessarily and argument that we should not massage the data before putting it into Python, as it already seems to me get_atomic_data is too complex, but it does suggest to me, we do need to better understand what is in the Chianti database and why. (As an aside, I note that we/you combined a number of levels in the H macro atom model, compared to those in Chianti. As a result, your 10 level model includes higher principle quantum number levels than does a model taken directly from Chianti. There may be rules we should enact in extracting data from that would help minimize the number of “necessary” energy levels for a macro-atom. I am suspicions that not taking account of levels that should be combined is an issues in Keara’s macro-atom models and the ones I am currently making from Chianti as well.) Cheers, Knox

[kslong]

At the present time:

• Information about bb collisions is part of the line structure
• Partly for this reason, one cannot read in collisional information about transition with having a line already in for transitions between two bb levels.
• If you do not have such transitions, one can get stuck in macro atom mode, where there is no available downward transition for a level (as can happen for example in He I)
• This means that one needs to "manufacture" a fake line for situations where one wants to have a transition that is strictly forbidden (oscillator strength 0).
• However, in reading lines in, we currently do some checks on what has been read in, and one of those checks is for whether the oscillator strength is 0. If it is, we currently throw the line out, and hence we don't put the line into the data structure. This is a problem for macro atom transitions.
• One possibility is to give such transitions very low oscillator strengths in which case the current code will work.
• A second possibility is to change the requirements (at least for macro-atoms) to allow lines with zero oscillator strengths. This seems a reasonable approach, but if on does this, then one needs to check somewhere that we don't have a line with 0 oscillator strength and without a Burgess style collision strength.

Aside: It is not really obvious that having a line with oscillator strength 0 would cause a problem in simple atom mode. We do have some in our standard files, though it's not clear exactly where thy came from

Line  8  4  158.218002  0.000000   4   4     0.047852    78.420937    1   39
Line  8  4  158.175003  0.000000   4   2     0.047852    78.442139    1   40
Line  8  4  158.121002  0.000000   2   4     0.000000    78.420937    0   39
Line  8  4  158.078995  0.000000   2   2     0.000000    78.442139    0   40
Line 26  2  930.580994  0.000000  10   8     0.000000    13.325027    0   81
Line 26  3  487.799011  0.000000   9   7     0.000000    25.420341    0   67
Line 26  7  117.311996  0.000000   9   7     0.289106   105.990387    2   65

However, we can get rid of these by only allow lines with 0 oscillator strength to pass for macro atom lines.

[jhmatthews]

I think I've managed to catch up with this. I broadly agree with everything that has been said and definitely think that preserving there being a "line" for every collisional transition makes sense.

One method which might be a bit clearer than simply setting f to 0, would be to have a flag for forbidden transitions. e.g., one could read them in as FLine, and then have a flag in the line structure that records if it is forbidden or permitted/semi-forbidden. Not that I have a particular objection to the f=0 approach, but this might make catching mistakes easier.

Also, regarding your observation about Chianti Knox - I think this was one of the reasons for not always using Chianti data, because for H and He you generally want level information up to some relatively high principal quantum number, and Chianti doesn't always give you this.

And finally, I do agree that there is the potential for issues when using levels have the same n but different J/L/S, if they are extremely close in energy - for example, in high densities these levels should become J-mixed or L-mixed, which essentially means very fast collisions between them - in such a case one could spend ages bouncing around between the levels just to establish populations close to the statistical weights.

Also, an apology, because I think I said I would work on this a few months back and I have not.

[kslong]

I have merged various changes associated with trying to generate MacroAtom data from Chianti and Topbase data into dev. This includes a new routine MakeMacro.py that generates syntactically correct levels, lines, collision and photoionization files.

I elected not to create yet another line format for forbidden lines, but put a check that we do have a TopBase (Burgess) set of x-sections into get_atomicdata. (For the non-macro atom case the old rules still apply and if one had an oscillatior strength of 0, the line would be ignored by Python).

It would be very useful, if @jhmatthews and @ssim would try out MakeMacro.py for some cases, and see if they think modifications need to be made, or could be make, while I remember what I did. It would be very useful if we had a plausible set of MacroAtom files for not only C 3 - C5, but also N 4-6 and O 5 - 7.

[kslong]

It would be a good idea to rediscuss this in terms of a general reviison of the atomic data, but no action is imminent, so I am labelling this a zombile issue and closing it.