jasory/iridium

Atomic Physics Library

Things I work on

• Primality testing
• Fermat base selection
• gnome applications
• Debian

iridium's Issues

Deriving nuclear data from source data

Hi @JASory, I have been doing some research to find a package that could meet our needs on terrapower/armi#460 as a general nuclide library that can be imported across different languages, mainly Python at this time. I am learning Rust and came across this package and thought that it might be nice to collaborate!

After looking through your codebase, I am curious if we could work on the following functionalities:

• Derive nuclide data from a given decay library, like ENSDF (https://www.nndc.bnl.gov/ensdfarchivals/). A python package called nudel (https://github.com/op3/nudel) can read ENSDF data already, but there would need to be some transcription to a database structure (possibly hdf5?) to use this within the program. I see that right now all the data is set / hard coded in library files, but it might be nice to have a database that can be updated from new evaluations.
• Add functionalities to traverse the decay chain for the purposes of plotting the chart of nuclides as well as derive complete or truncated decay/depletion chains for the purposes of supporting generalized nuclear analyses.
• Adding unit testing to the nuclear data library so that users can be confident that the implementation is well tested and verified.

I'd love to set up some discussions if you are interested and see if there is a way that we could develop requirements, documentation, and further testing! Please let me know 🙂

Improve Decay accuracy

Implement partial decay, and Bateman's equation to accurately model the probability of the individual atom's identity.

Bohrium Decay

Bh-276 and Bh-277 are recorded as Alpha decay; however the daughters are not recorded to exist.

Decay Chain Errors

During auditing, the following errors were found in the decaychain lookuptable, compromising a total of 119 errors out of 3585. Most errors are incorrect ratios due to parsing or unsupported decay modes.

B-17 63% β− + n; 22.1% β−; 11% β− + 3n; 3.50% β− + 3n; 0.4% β− + 3n;// correction B-2n B-3 and b-4n
N-23 50% β−; 42% β− + n; 8% β− + 2n;// correction and 3.4 b-3
Ne-17 96% β+ + p; 2.7% β+ + α; 1.3% β+; //correction B+p+A 0.014
Ne-31 50% β−; 50% β− + n; //correction unknown for Ne-31 and ne-32
Mg-21 50.2% β+; 24.4% β+ + p; 25.3% β+ + α; //correction Bp =20.1 B+a=0.0116 B +p+a
Mg-34 70% β− + n; 30% β−; //correction B-n =21 B-2n = 0.1
Mg-37 50% β−; 50% β− + n; // unknown evaluation
Al-26 85% β+; 15% EC; //correction B+=100
K-31 100% 2p; //correction 3p=100%
Cr-43 71% β+; 23% β+ + p; 5.89% β+ + 2p; 0.1% β+ + α; //correction b+p = 79.3 b+2p = 11.6 b+3p=0.13
Mn-46 76% β+; 22% β+ + p; 1% β+ + α; 1% β+ + 2p; //correction b+2p = 18 b+p=57.0 b+p 7194230188746725130, 3320413933267719291
Co-58 100% EC;// correction Ec=85.21 e+=14.79
Se-63 87% β+ + p; 13% β+; //correction 2p = 0.5
Kr-67 94% β+ + p; 6% β+; // correction 2p = 37
Rb-92 98.9% β−; 1.06% β− + n; //correction b-n 0.0107
Ba-114 79.0% β+; 20% β+ + p; 0.89% α; 0.00% C-14; //correction c-12
Ac-225 99.9% EC; 0.00% C-14; // correction Ec=Alpha
Th-226 99.9% α; // correction 18O 3.2E-12
Th-228 99.9% α; //correction 20O 1.13E-11
Th-230 99.9% α; //correction Sf4E-12 24Ne=5.8E-11
Th-232 99.9% α; 0.00% SF; 0.00% 2β−;//correction SF 1.1E-9 24Ne+26Ne2.78E-10
Pa-230 91.5% β+; 2.97% β−; //Correction 92.2B+ 7.8B- 0.0032 Alpha
Pa-231 99.9% α; 0.00% SF; 0.00% Ne-24; //correction 23F
Pa-236 99.9% β−; //correction b-sf 6e-8
Pa-238 99.9% β−; 0.00% α; //correction b-sf 2.6e-6 remove alpha
U-228 95% α; 5% EC; //correction 97.5 a EC 2.5
U-230 99.9% α; 0.00% 2β+; //correction 22Ne 4.8e-12
U-232 99.9% α; //correction 24Ne8.9e-10 sf2.7e-12 28mg 5e-12
U-233 99.9% α; //correction sf6e-11 24ne7.2e-11 28mg1.3e-13
U-234 99.9% α; //correction verify
U-235 100% α; //correction
U-236 100% α; //correction s-f9.4e-8
U-238 99.9% α; 0.00% 2β−; //correction sf5.44e-5
Np-229 51% α; 49% β+; //correction 68alpha
Np-236 87.3% EC; 12.5% β−; 0.16% α;//correction 86.3,13.5,0.16
Np-237 99.9% α; 0.00% SF;//correction 30Mg 4e-12
Pu-229 100% α; //correction 50a 43b+ sf7
Pu-235 99.9% β+; 0.02% α; //correction 0.0028 a
Pu-236 99.9% α; 0.00% SF; // correction 28mg 2e-12
Pu-237 99.9% EC; 0.04% α; //correction 0.0042a
Pu-238 99.9% α; 0.00% SF; 0.00% Ne-20 + NE-24; //correction 32si 1.4e-14 28mg+30mg6e
Pu-240 99.9% α; 0.00% SF; 0.00% Ne-24; //correction 34si 1.3e-11

Remove x86_64 dependency

It'd be great if the hard dependency on x86_64 was removed, and a cross-platform alternative is used instead, to allow the library to be used in other architectures

It's used in these two instances:

Iridium/Nuclide/src/nuclidedata/nuclidestruct.rs

Line 24 in 413c32a

unsafe { core::arch::x86_64::_rdrand64_step(&mut x) };

Iridium/Nuclide/src/nuclidedata/decaymodes.rs

Line 43 in 413c32a

unsafe { core::arch::x86_64::_rdrand64_step(&mut x) };

Implement DZ10 or better mass model

Replace the Bethe-Weizacker mass model with one that meets or exceeds the accuracy of the DZ10 model.

Interest in an `Element` class

I'd like to expand the available functionality in this library by an Element class that averages over isotopes so that I can use this library for chemical molecules, where atoms are most commonly represented as 'averages' over their isotopes.

This library already stores a lot of chemically relevant properties, such as electron affinity, ionization energies, electronegativities, etc. which are dependent on the atomic number only. I am aware I could write my own abstraction layer over the available data, but I would prefer to expand the scope of this library a little, so that the data is centralized and accessible for others.

Are you open to receiving a PR adding an Element class implementing some or all of Atom?

Open questions

• I haven't looked too closely yet if Element can implement the full interface of Atom. I've noticed that some functions, e.g. Nuclide::ionization_energies will return f64::NAN instead of None for unavailable data. Is that intentional? Is that an escape hatch I could use?
• The docs explicitly state abundancies are purposely out of scope, but the mass of an element is the abundance-weighted average of its isotopes. Should I avoid adding isotope abundancies to the Element interface?
• Is there interest in strongly typing units? Having Atom implement mass_deficit/_kg/_j,_ev and similar for binding energy, electron affinity, ionization energies, etc. could be made less redundant, e.g. with the crate uom, which would also remove conversion constants from this library. I think this could be nice to have, but would probably be a different PR.