Emission probability mismatch

[nicola...@gmail.com]

Dear all,

I found some defferences between the data about the gamma emission probability that I extract from PyNE and the ones that I found on the site of Laboratoire National Henri Becquerel (http://www.lnhb.fr/nuclear-data/nuclear-data-table/)

Here an example for Ba133 (en=energy, prob=probability, typ=g:gamma,X*:xrays):

- PyNE (I used data.gamma_xrays and data.gamma_photon_intensity methods)

          en        prob typ
1    30.9728   23.892328   X
2    30.6251   12.932917   X
3    35.0000    8.683393   X
4     4.2900    5.532502   X
5    53.1622    3.450000   g
6    79.6142    4.270000   g
7    80.9979   53.100000   g
8   160.6120    1.028000   g
9   223.2368    0.730000   g
10  276.3989   11.540000   g
11  302.8508   29.550000   g
12  356.0129  100.000000   g
13  383.8485   14.410000   g

- LNHB

             en    prob    typ
1092    4.67355  15.870     XL
1093   30.62540  33.800   XKa2
1094   30.97310  62.400   XKa1
1095   35.05300  18.240  XK'b1
1096   35.90030   4.450  XK'b2
1097   53.16220   2.140      g
1098   79.61420   2.630      g
1099   80.99790  33.310      g
1100  160.61210   0.638      g
1101  223.23680   0.450      g
1102  276.39890   7.130      g
1103  302.85080  18.310      g
1104  356.01290  62.050      g
1105  383.84850   8.940      g

As I'm a PyNE newbie maybe I'm not takink into account something...

[Will Walters]

Hi,

I also have had some issues with the photon intensities (I posted yesterday about it).

In this case, the data.gamma_photon_intensity() and the Material.photons() give different results, with the Materials method giving the correct values for the gamma rays (though the x-rays still seem to be different). There does appear to be something going on that I don't exactly understand... the method gives identical (and correct) results for a lot of decays (e.g., Cs137, Co60).

nuc='Ba133'

mat=material.Material()    

mat.from_atom_frac({nuc : 1.0})

g=mat.photons()

lam=data.decay_const(nuc)

for g in g:

    print("%6.1f %10.4f" %(g[0],g[1]/lam))

>>

Material photon method

   E        Prob

  53.2     2.1407

  79.6     2.6495

  81.0    32.9486

 160.6     0.6379

 223.2     0.4530

 276.4     7.1606

 302.9    18.3358

 356.0    62.0500

 383.8     8.9414

  31.0    23.8923

  30.6    12.9329

  35.0     8.6834

   4.3     5.5325

[dbrown]

The issue here is the different conventions between the two data projects.  In ENSDF, Ig is relative to the strongest gamma and that gamma has Ig=100.  In the DDEP, Ig is absolute. 

If one includes the normalization factor in ENSDF to convert from relative to absolute - in this case 0.62 - the numbers are consistent.  

Good luck,

Dave

On Friday, May 21, 2021 at 6:32:05 AM UTC-4 nicola...@gmail.com wrote:

[Will Walters]

Thanks Dave! It looks like you can get the ratio from data.decay_photon_branch_ratio_byparent()

print(data.decay_photon_branch_ratio_byparent(nucname.id('Ba133')))

[(0.6205, nan)]

This is complicated when there are multiple decay pathways, as I saw some in some discussion earlier. The solution seems to be to use the Material.gammas() method, which does all of that. This was my solution, but then was foiled when some of the nuclides gave an error with the material method (namely, As82M).

--
You received this message because you are subscribed to a topic in the Google Groups "PyNE Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pyne-users/MIEEVyAXIBg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pyne-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pyne-users/0f30ef54-a9b7-486a-8375-d254a689818en%40googlegroups.com.

[Paul Wilson]

Hi all,

Thanks for this great dialog.  One of my own students has been trying to wade through all of this recently, as well.

Can someone add an issue on the Github page that describes the problem - at least the symptoms, but better-still the cause - and we can use that do capture and discuss solutions?

If you think you have a solution, we welcome pull requests to the PyNE repo.

Paul

You received this message because you are subscribed to the Google Groups "PyNE Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyne-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pyne-users/CA%2B0i0jjLdLuDeuEkEwHrqyaMZyL25gkyO%2BBG5y4Q30ktpS9zwA%40mail.gmail.com.

--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul P.H. Wilson (he/him/his)
Grainger Professor of Nuclear Engineering
Chair, Department of Engineering Physics
o: 608-263-0807, c: 608-469-9615
paul....@wisc.edu
153 Engineering Research Bldg
1500 Engineering Dr, Madison, WI 53706
Zoom Meeting Room: https://uwmadison.zoom.us/j/6082630807
Zoom Phone Access: +1-929-205-6099, Access code: 6082630807

Computational Nuclear Engineering Research Group

[nicola...@gmail.com]

Thank you for the explication and solution for this issue.

Using data.decay_smatch photon_branch_ratio_byparent() fix nicely the probability mismatch.

The material.gammas() doesn't work smoothly often...

EX.

mat=Material({'mo99':  1})

mat.gammas()
Out[15]:
[(2.1726, nan),
 (40.58323, 3.105611842193945e-06),
 (140.511, nan),
 (142.675, nan),
 (158.782, 5.5815143707633125e-08),
 (162.37, 3.5063359508641326e-08),
 (181.068, 1.7925248075336022e-05),
 (242.29, 7.513577037565998e-09),
 (249.03, 1.1449260247719615e-08),
 (366.421, 3.513491738518957e-06),
 (380.13, 3.0769886915746464e-08),
 (391.7, 9.302523951272188e-09),
 (410.27, 5.7246301238598076e-09),
 (411.491, 4.293472592894855e-08),
 (457.6, 2.3971888643662946e-08),
 (469.63, 7.871366420307234e-09),
 (528.788, 1.6816100988838184e-07),
 (537.79, 9.660313334013424e-09),
 (580.51, 9.302523951272188e-09),
 (620.03, 6.7979982720835206e-09),
 (621.771, 5.3668407411185694e-08),
 (689.6, 1.2522628395943329e-09),
 (739.5, 3.57789382741238e-05),
 (761.77, 1.1807049630460852e-09),
 (777.921, 1.2558407334217453e-05),
 (822.972, 3.935683210153618e-07),
 (861.2, 2.1467362964474276e-08),
 (960.754, 2.790757185381656e-07),
 (986.44, 4.293472592894855e-09),
 (1001.343, 1.610052222335571e-08),
 (1017.0, 1.7889469137061898e-09),
 (1056.2, 3.1843255063970175e-09)] WARNING: You have indicated a metastable state of 17. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 10. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 19. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 17. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 27. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 29. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 17. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 25. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 19. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 10. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 22. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 15. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 25. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 15. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 31. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 17. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 15. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 17. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 19. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 19. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 27. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 25. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 27. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 31. Metastable state above 5, possibly unphysical.
 WARNING: You have indicated a metastable state of 31. Metastable state above 5, possibly unphysical.

I have still some doubts about the xray probability anyway...

Any help pls?

[Arrielle Opotowsky]

Hi,

Sorry I missed this! I'm the student Paul mentioned also struggling with this. I actually started to create an issue awhile back but thought it better to diagnose it more thoroughly first...which of course I didn't do. I think the remaining problem with the materials method is linked to the insertion of negative nuclides. I found them upon closer analysis of data.gamma_from_to_byparent(). Below is Paul's/Cameron Bates' response about this from another thread:

We were able to confirm that Cameron inserted the negative in his processing of the ENSDF data when he wrote the code:

I’m pretty rusty on this, but my recollection is that ENSDF data declares energy levels in two different places, one is in “level data” and the other is in “decay data”. I’m pretty sure the negatives come about when a level declared in “decay data” does not match closely to any level in “level data”. The connotation is “this is the closest level I could find, but it doesn’t match within reason”. From git blame, it looks like ”reason” was defined arbitrarily by me as 3 keV to get U transition states to come up as valid . At the time I think Anthony and I had a few conversation with the nuclear data community about feeding this back to update ENSDF files (or as an additional check that could be run for new decay data files), but it never went anywhere.

So I can confirm that it doesn't come from the original data.  Sorry that this response did not include the list.

I didn't have time to submit any fixes (and am not sure my personal solution is the solution that would work for PyNE), but I just recreated the steps the material gammas() method takes in python, filtering out these negative nuclides:

def manual_gammas(nuclide):
    parent = nucname.id(nuclide)
    decay_c = data.decay_const(parent)
    energies = data.gamma_energy(parent)
    intensities = data.gamma_photon_intensity(parent)
    children = data.gamma_from_to_byparent(parent)
    decay_children = data.decay_data_children(parent)
    decay_branches = data.decay_photon_branch_ratio_byparent(parent)
    
    gammas_result = []
    for i, c in enumerate(children):
        for j, dc in enumerate(decay_children):
            # here is where we skip negative nuclides
            if c[0] > 0:
                if nucname.zzzaaa(c[0]) == nucname.zzzaaa(dc):
                    gammas_result.append((energies[i][0], decay_c*intensities[i][0]*decay_branches[j][0]))
    return gammas_result

Since it looks like the mismatch has been resolved, I created an issue that solely discusses the material gammas() failure, using the feedback from these emails.

Best,

Arrielle

To view this discussion on the web visit https://groups.google.com/d/msgid/pyne-users/853bf1f7-ff04-439a-8c2d-2f1dcb28a3e2n%40googlegroups.com.

--

---

Arrielle Opotowsky

Computational Nuclear Engineering Research Group | CNERG

University of Wisconsin - Madison