search

openmicroanalysis / pyxray

Definitions and properties of X-ray transitions
MIT License
6 stars 4 forks source link

DTSA x-ray subshell and line data #13

Closed drix00 closed 5 years ago

drix00 commented 5 years ago

I have added the original DTSA x-ray data. The reference is: C.E. Fiori and C.R. Swyt and R.L. Myklebust, NIST/NIH Desk Top Spectrum Analyzer, 1992, https://www.cstl.nist.gov/div837/Division/outputs/DTSA/oldDTSA.htm. The download links are not working, but it is from these files I have extracted the data into csv file.

The line is only given in Siegbahn notation, so I use the IUPAC Jerkins reference already implemented in the project to convert the line label to IUPAC notation. But I have to make this choice of conversion as they are not defined in Jerkins reference. I use the table 5 in J. A. BEARDEN Rev. Mod. Phys. 39, 78 (1967) as a guide to do the conversion. For the line with two initial subshells, I use the lowest energy subshell (higher subshell number). i.e., for O4,5 I use L3-O5. I did check the energy different between the two initial subshells and they are less than 100 eV in all cases.

Two main issues remain with the DTSA data:

For me the last issues need to be resolve before merging with the master branch. The first one can be resolve after merging.

drix00 commented 5 years ago

I found and correct why the Travis build fail on dtsa branch. I try on linux and all test pass, but I did need to rebuild the project, i.e., python3 setup.py build. I try to delete the cache on Travis and restart the build, but it still fail. I add a explicit build command in the install section of the Travis configuration and now the build pass. See commit 1e7d715.

codecov-io commented 5 years ago

Codecov Report

Merging #13 into master will increase coverage by 0.25%. The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master     #13      +/-   ##
=========================================
+ Coverage   93.24%   93.5%   +0.25%     
=========================================
  Files          34      38       +4     
  Lines        3466    3619     +153     
=========================================
+ Hits         3232    3384     +152     
- Misses        234     235       +1
Impacted Files Coverage Δ
pyxray/parser/test_bearden1967.py 100% <100%> (ø)
pyxray/parser/bearden1967.py 100% <100%> (ø)
pyxray/parser/test_dtsa.py 100% <100%> (ø)
pyxray/parser/dtsa.py 100% <100%> (ø)
pyxray/data.py 91.22% <0%> (-1.76%) :arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 499b1a6...6098b3e. Read the comment docs.

ppinard commented 5 years ago

The fraction is relative to the main peak in each family: Ka1 is 1 for the K lines, La1 is 1 for the L lines. I use the XrayTransitionProbability, but we should create a new property these values.

There is the property XrayTransitionRelativeWeight. I think this corresponds to the value in the DTSA table. I updated the code to use this property in commit d5e5baf7ad3597927a606d8b438187624b3e25e2.

Another thing is that the parsers should not rely on the database functions to find X-ray transition, elements, etc. This is a limitation at the moment because nothing guarantees the order the parsers are executed. It can also be a problem because it involves reading and writing the database at the same time. Similarly as the JEOL parser, I added a lookup table in DTSA that converts the Siegbahn notation in the DTSA csv to a tuple of atomic subshells. See commit 6098b3e6413e5fc4e6122a0e0a70183e4bb8dc77

Note I also merged changes where the descriptors and properties are now dataclasses which were introduced in Python 3.7 with a backport to Python 3.6.

@drix00 if you agree with the changes, I agree with the pull request.

ppinard commented 5 years ago

How to include satellite line data in the pyxray database? The notation is a little strange and not uniform.

Yes this is an issue. How is the physics describing satellite emission?

drix00 commented 5 years ago

The fraction is relative to the main peak in each family: Ka1 is 1 for the K lines, La1 is 1 for the L lines. I use the XrayTransitionProbability, but we should create a new property these values.

There is the property XrayTransitionRelativeWeight. I think this corresponds to the value in the DTSA table. I updated the code to use this property in commit d5e5baf.

Another thing is that the parsers should not rely on the database functions to find X-ray transition, elements, etc. This is a limitation at the moment because nothing guarantees the order the parsers are executed. It can also be a problem because it involves reading and writing the database at the same time. Similarly as the JEOL parser, I added a lookup table in DTSA that converts the Siegbahn notation in the DTSA csv to a tuple of atomic subshells. See commit 6098b3e

Note I also merged changes where the descriptors and properties are now dataclasses which were introduced in Python 3.7 with a backport to Python 3.6.

@drix00 if you agree with the changes, I agree with the pull request.

I agree with the changes. I should have check in more detail all properties.

drix00 commented 5 years ago

How to include satellite line data in the pyxray database? The notation is a little strange and not uniform.

Yes this is an issue. How is the physics describing satellite emission?

I did not work with satellite line in practice. But in reference book like Reed green book (1993), the satellite line are defined as "doubly ionized atoms". Double ionization is produced by electron bombardment or Auger effect (maybe also from Coster-Kronig transition). However, they seem to include line affected by bounding effect as satellite line. So a more general definition of "satellite line" is lines not corresponding to any transition identifiable in the energy level diagram. From the point of view of pyxray, we need to have a way to define a line with an energy and label, but without clear transition from two atomic subshells.

drix00 commented 5 years ago

Another thing is that the parsers should not rely on the database functions to find X-ray transition, elements, etc. This is a limitation at the moment because nothing guarantees the order the parsers are executed. It can also be a problem because it involves reading and writing the database at the same time. Similarly as the JEOL parser, I added a lookup table in DTSA that converts the Siegbahn notation in the DTSA csv to a tuple of atomic subshells. See commit 6098b3e

When I started planing different library related to x-ray microanalysis, I separate the notation like Siegbahn and IUPAC and the x-ray line property in two projects. Maybe it could help the parsers code to have either two projects or two databases.

ppinard commented 5 years ago

I created two issues to cover the remaining tasks: