Incorrect ionisation stage for ADF11 rates

[mattngc]

@Mateasek believes CHERAB might be reading the wrong ionisation state from ADF11 files. He suggests the Z value in the files might mean the "recombining ion charge". i.e. Currently you can read an ionization rate for neon 10, which is impossible.Therefore the ionisation rate in OpenADAS for Z=10 might actually mean Z=9. @mattngc might have miss interpreted the ADAS ADF11 documentation. Assigning to @Mateasek for investigation.

[Mateasek]

I will check if openadas way of notation is correctly interpreted. I know I had some troubles sorting it out in my head :-D

Just to clarify notation to be used in cherab:

• cherab uses arabic number notation of ionisation stages i.e. 0 is neutral and 1 is singly ionised ion
• ionisation rate of a stage x causes depletion of stage x and population of stage x+1
• recombination rate of a stage x causes depletion of stage x and population of stage x-1

[mattngc]

Yes this notation is correct, thanks @Mateasek.

[Mateasek]

I would suggest changing word ionisation used to denote charge of the ion to charge or chargestate. Word ionisation is in my opinion the atomic process and could sometimes lead to confusion. Problem is it is used throughout quite some part of the code. What do you think?

[mattngc]

Yeah, I think we would need to think more about this kind of change. As you point out, the reason I used ionisation here is because its become a bit of a convention and used widely throughout the code. Changing it is certianly not out of the question but we should think carefully before doing it as we would need to change the convention everywhere. charge or charge_state is certainly just as clear as ionisation, and may indeed be clearer if we want to distinguish from the process of ionisation. I'll discuss with @CnlPepper and @jacklovell in person next week to see what the consensus opinion is. But this would be tracked in a different issue anyway, because its a bigger refactor.

[mattngc]

@Mateasek, see the example calculation from @jacklovell in cherab/mastu#6. Seems to confirm your hypothesis about the bug.

[Mateasek]

Just to keep track....
OpenAdas denotes charge states in data headers as recombining ion charge (viz documentation for each file and fortran reading routines)

• IZ1recombining ion charge (Z1 in data headers)
• IZ1MIN - lowest ion charge +1, IZ1MAX - highest ion charge

ADF11 stored rates and notes:

1. acd Effective Recombination Coefficients

   • recombination rate from charge n to n-1
   • Z1 e [1, Zmax]
   • electron recombination of charge 0 (neutral) is neglected (no negative ions)
   • correction from adas to cherab: charge = Z1

2. scd - Effective Ionisation Coefficients

   • ionization rate from charge n to n+1
   • Z1 e [1, Zmax]
   • ionisation of state charge=Zmax (absolutely stripped ion) is impossible
   • correction from adas to cherab: charge = Z1 -1

3. ccd - CX Cross Coupling Coefficients

   • CX Between neutra hydrogen species and charge n
   • Z e [1, Zmax]
   • CX of H with charge 0 (neutral) is neglected (no negative ions)
   • correction from adas to cherab: charge = Z1

4. plt - Line Emission from excitation

   • line radiated power by charge n by electron impact excitation
   • Z1 e [1, Zmax]
   • radiation by state charge=Zmax (absolutely stripped ion) is impossible
   • correction from adas to cherab: charge = Z1 -1

5. prb - Recombination and Bremsstrahlung

   • radiated power by bremsstrahlung and and line rdiation due to recombination of charge n
   • Z1 e [1, Zmax]
   • radiation by recombination of charge 0 (neutral) is neglected (no negative ions)
   • correction from adas to cherab: charge = Z1

6. prc - Charge exchange PLS - Specific line

   • line radiated power by CX of H with charge state
   • Z e [1, Zmax]
   • CX of H with charge 0 (neutral) is neglected (no negative ions)
   • correction from adas to cherab: charge = Z1

7. pls - Specific line

   • specific line radiated power by charge n by electron impact excitation
   • Z1 e [1, Zmax]
   • radiation by state charge=Zmax (absolutely stripped ion) is impossible
   • correction from adas to cherab: charge = Z1 -1

[CnlPepper]

Quick comment re the use of ionisation, when I originally used this it was because we tended to refer to the ion charge as ionisation level. I agree this is now causing an unfortunate clash between this attribute and the process. After some consideration, I think I'm leaning towards renaming the attribute to charge as @Mateasek suggests. Given how widely it is used, this would be a major API change... but this can be managed. We could make the change to charge and for the next few releases leave the ionisation attribute in place, but make it raises an exception that informs the user to update their code.

[Mateasek]

This commmit 47d8ef9 is a sketch of solution for the wrongly interpreted charge states. I added an additional function "rates_adf11" which does the remapping from adas to cherab charge notation and is supposed to be called during repository creation/updates instead of directly old parse_adf11 (which stayed). I chose this solution because it preserves the possibility to have adf11 files parsed and kept with original notation. It just has more versatility. Could @mattngc and @CnlPepper please look at it and tell me whether this is the right way to go?

The problem with the calculation of the ionisation balance wasn't fixed tho. I crosschecked the matrix with adas documentation and it seems correct now. I will check if the rates are correctly interpolated in next step.

[CnlPepper]

@Mateasek Thanks for the sketch. I'd move the conversion routine to the individual adf11 install functions, not place it inside the parse module. The parse module methods return the contents of the ADF files in a form consistent with the original files (baring the odd unit conversion). The data cherab writes via the update_* methods in the cherab repo are our own derived specification. The install methods are the point where any modification of representation or missing meta data should be added.

@mattngc btw when looking through the cherab repo update functions I found this method:

openadas/cherab/openadas/repository/radiated_power.py

Line 156 in 81b0eaa

def _update_and_write_adf11(species, rate_data, path):

Could you remove the _adf11 bit, these are cherab's derived/extended representations not the raw files. Given we will be modifying the ion charge value for some rates this is now even more of a misnomer.

When I designed the package the install section is essentially a "firewall" between the two representations: ADF rate representation -> install methods -> cherab rate representations
To keep the code maintainable it would be good if we can continue to be strict with the layer separation.

[Mateasek]

An update to the state of the ionization balance calculation. I comitted a few new changes in b271bce which can hopefully explain why there were some problems with the ionization balance calculations. File
ratescheck.py compares 3 different ways of interpolations. Please have in mind that if you want to run it you have to do a clear population of your rates repository.

There are three ways of interpolation shown using cherab 2d interpolators for consistency:

1. Interpolation on original openadas database temperature, density and rate data in their original log10 representation. The rates are then brought to correct units.
2. Interpolation on original openadas database temperature, density and rate data in normal (10 ** data) representation. The rates are then brought to correct units.
3. Interpolation using built-in cherab functions

The results are shown in these plots:

The balance matrix seems to be correct, but we could use some data calculated by adas codes to benchmark/compare with. Anyway, it can be seen that cherab interpolators fail to cope with adas data in normal (10 ** data) format. The rates chage by 50 orders of magnitude, the temperature and density data by a bit less. I hope I haven't overlooked any bug in my code, but I am afraid it would be better to store and interpolate data in log10 format and transform the results after interpolation. After all ADAS is probably storing it in log10 format for a reason, what do you think? Could @mattngc and @CnlPepper have a look? Cheers