How can I find the spontaneous fission yields used in the Decay Engine++?

July 18th, 2019
by Joseph Magill

This question is only relevant if at least the parent nuclide or one of its daughter nuclides decays by spontaneous fission.
In the results data grid (in the Decay Engine tab) the decay modes of the nuclides are shown with the corresponding branching ratios. For spontaneous fission only the total branching ratio for all fission products is given.

In the Decay Tree tab in turn each produced nuclide is shown in the decay tree with the half-life, the number of atoms, the number of disintegrations and the branching ratio from the parent nuclide to the considered nuclide. If the nuclide is a fission product this branching ratio is calculated as the branching ratio of the SF decay mode from the parent nuclide times the independent fission yield of the fission product.

In the databases JEFF and ENDF databases used inside Nucleonica the spontaneous fission yields are reported for three nuclides Cm-242, Cm-244 and Cf-252. Many other nuclides however decay by SF in which case the yields of Cm-244 are used.

For example, consider the decay Cm-248 and the fission daughter nuclide Mo-104. In the Decay Tree tab, this nuclide can be highlighted. The decay tree can be collapsed to show only the branches leading to the nuclide of interest Mo-104 as shown below.
Cm248 Decay TreeFig.1: The collapsed decay tree computed by the Decay Engine++ showing the decay branches leading to the highlighted nuclide of interest Mo-104.

In the above figure, the first occurrence of Mo-104 is as a fission product of Pu-244. The SF branching ratio of Pu-244 can be found in the results grid as 0.00125 whereas the BR of Mo-104 is given in the above figure as 6.95e-5. It follows that the independent fission yield of Mo-144 (from parent Cm-244 since no date for Pu-244 is available) will be:
Yind(Mo-104) = BR(Mo-104) / BRsf(Pu-244) = 6.95e-5 / 0.00125 = 5.56%
This is exactly the Ind. Yield given in the Fission Yields app for the parent Cm-244.

The second occurrence of Mo-104 in figure 1 is as a fission product of Cm248. From the results grid BRsf(Cm-248) = 0.0839. Again
Yind(Mo-104) = BR(Mo-104) / BRsf(Cm-248) = 4.67e-3 / 0.0839 = 5.57%
This independent fission yield can be found in the Fission Yields app from the Cm-244 parent nuclide (because neither Pu-244 nor Cm-248 are in the database), using the JEFF-3.1 library and the spontaneous fission type for the given nuclide.

In the tree structure in fig. 1, further occurrences of Mo-104 as a daughter of fission products are shown.

Posted in FAQs | Comments

Nuclide ID in ZZAAA (or ZAID) format possible?

June 26th, 2019
by Joseph Magill

Qu. (from F. B. KIT-INE Karlsruhe, Germany):
Dear Nucleonica Team,
To import .csv files to Nuclide Mixtures ++ we have to give the Nuclide ID as e.g.
PU241, Pu-241 or Pu 241. However many programs use the ZZAAA notation (or ZAID notation): 94241. Hence it would be great to have the ZZAAA notation as .csv input accepted too. It this possible?

Further info: The MCNP6 suggestion for representing metastable isotopes seems to be a good idea: adjust the AAA value using the following convention:
AAA’=(AAA+300)+(m × 100), where m is the metastable level and m=1, 2, 3, or 4.
For naturally occurring elements, AAA=000 is suggested, for example 008000 represents the element oxygen.

Ans. (Nucleonica Team)
We now have the ZAID format working in the nuclide mixtures..

For example, you can upload a file with the data…
Nuclide, Activity(Bq)
95241, 1e6

This will then be interpreted as Am-241.
Further format options are shown in the figure below. The notation 92238 represents U-238.
Mixtures-formatsMore info…
ZAID format
Allowed file formats

Posted in FAQs | Comments

Application loading and running times

June 12th, 2019
by Joseph Magill

Working with Nucleonica the user may notice differences in the loading times not only between different applications but also for the same application loaded at different times. Analogously the execution time of a given application and for the same calculation may vary over time.

In particular, after a maintenance or new deployment operation on the server the different memory caches are empty and the first call to an application may take significantly longer than a second or further calls to that application issued from the same or another user. The same is true for calculations involving intensive database operations such as gamma spectrum modelling or calculation of a large decay trees with lots of fission products.

Clearly different applications use more or less data generally retrieved from the underlying databases. The CPU time needed to prepare the data depends on the activity level on the server but can generally be neglected except when extensive calculations are involved. The transmission time over the net is proportional to the data amount to be transmitted and depends on many factors like the location of the client, the quality of the connection or the time of day. The time needed to load the data from the database in turn depends on whether the data are read from the disk or retrieved from the memory cache which is much faster than a disk operation.

Posted in FAQs, Nucleonica | Comments

Uploading Nuclides with Metastable States in Nucleonica

June 5th, 2019
by Joseph Magill

Qu. (from M. R. KTE-Karlsruhe, Germany):
Dear Nucleonica Team,
We are expanding the usage of the decay engine in Nucleonica into more and more groups to make time corrections to nuclide mixtures. While doing so we encountered a difficulty that you might be able to help us with:
When uploading a mixture with many different nuclides, we sometimes get the data from our database „KADABRA“. For mostly historical reasons in this database the nuclides are written in a slightly different way than is common in Nucleonica. So we are having problems with the writing of the metastable nuclides such as „Am-242m“ or „Nb-93m“ which are written in big letters „AM-242M“ and „NB-93M“. When we upload these nuclides, the „M“ for the metastable state is ignored and the nuclides would be read as „Am-242“ and „Nb-93“. We just thought it might be possible on your side to accept also big letters for the metastable states in the code or throw an error message when that happens. This way it would be easier to identify the mistake, because otherwise we don’t see it and continue working with wrong mixtures.
Do you think it is possible to accept the big letters for metastable states in the code?

Ans. (Nucleonica Team)
This problem has now been resolved. The nuclide mixtures app now accepts capital letters.

The image below shows the Nuclide Mixtures upload tab with the nuclide names in capital letters.
TestM

More info…
Nuclide Mixtures wiki page

Posted in FAQs | Comments

New publication on the Karlsruhe Nuclide Chart

May 27th, 2019
by Joseph Magill

Obtaining nuclear data is an international activity with new and updated data constantly being determined by thousands of scientists at major research centres worldwide. Because of the large amounts of data generated and the formats used to store these data, the field of nuclear data is highly specialised. To make the most important key data more accessible to a wider audience, nuclide charts have been developed. In this publication, we present the scientific highlights of the new 10th Edition of the Karlsruhe Nuclide Chart.
Fig1epjn The main focus of this Chart is to provide structured, accurate information on the half-lives and decay modes, as well as energies of the emitted radiation for over 4000 experimentally observed ground states and isomer nuclides to an interdisciplinary audience.

More information…
Karlsruhe Nuclide Chart – New 10th edition 2018, EPJ Nuclear Sci. Technol.
Volume 5, 2019
(pdf)
New 10th Edition (2018) of the Karlsruhe Nuclide Chart
Karlsruhe Nuclide Chart Online Shop

Posted in Karlsruhe Nuclide Chart, Nucleonica | Comments

New Short Names for Nucleonica Apps

April 30th, 2019
by Joseph Magill

Nucleonica applications are represented as “tiles” in the App Portal. For every application there is a tile consisting of a header “Short Name” and a body “Full Name”. As an example, in the image below, the short name GSG refers to the application Gamma Spectrum Generator++.
To make the tile names more intuitive, new “Short Names” have been introduced for many Apps. These are shown in the image below for the filter category “last used”.
NewShortNames2As can be seen the new short names are more intuitive than the older names e.g. Datasheet (old name NuDat++), Explorer (Expl++), decay (DE++), Search (NuS/RaS). It should be noted that the Radiological Converter and Mass Activity Converter new short names are Conv. Pro and Conv. respectively. The gamma library apps have also been renamed to gLib Pro and gLib. The gamma dosimetry and shielding apps have the new short names gH*(10) and gD&S.

More info…
App Portal wiki page

Posted in Nucleonica | Comments

Nuclear Security Exercises now available to all Nucleonica users

March 28th, 2019
by Joseph Magill

In Nucleonica’s e-Learning center (e-Learn app), a series of nuclear security exercises has been released for all Nucleonica users.
eL-NSENucleonica’s e-Learning Centre showing the nuclear security exercises.

These exercises have been developed jointly with Dr. Emily Alice Kröger from the Federal Office for Radiation Protection (Bundesamt für Strahlenschutz) and the Nucleonica Team. The exercises were developed for use in BfS training courses on Nucleonica held on a regular basis. Because of the general interest in these presentations, we have released them for general use by Nucleonica users.

More info…
Nucleonica’s e-Learing Centre

Posted in Nucleonica | Comments

webKORIGEN and DELNuS updates

March 26th, 2019
by Joseph Magill

WebKORIGEN is a Nucleonica application for the simulation of the time evolution of a nuclide inventory in power reactors. A related application, DELNuS (Decay Engine for Large Nuclide Sets), allows the user to make decay calculations for a large number of nuclides (typically present in a reactor).
Following a new compilation (2019), a number of updates and improvements in the webKORIGEN and DELNuS applications have been made:
webKORIGEN:
– it is now possible to make Ra226 irradations in the flux mode.
– new tabs show the cross section data (also burnup dependent ) and decay data used in the calculations for the various reactor types.
– in the results grid, nuclide half-lives have been added
wKOwebKORIGEN user interface

DELNuS
– a problem with using mixtures in DELNuS has been resolved.
– in the results grid, the nuclide half-lives have been added
– decay data used in the calculations are displayed
DELNuSDELNuS user interface

More info…
webKORIGEN
Neutron irradiation with webKORIGEN
DELNuS

Posted in Nucleonica | Comments

Ra-226 irradiations now possilbe with webKORIGEN

March 22nd, 2019
by Joseph Magill

Qu. (from D. B. Garching, Germany):
Dear Nucleonica Team, if I let Ra-226 irradiate in a certain flux for a certain time, why I do not get nuclides with mass numbers higher than 226?

Ans. (Nucleonica Team)
This problem has now been resolved.

Results are shown below for an irradiation of Ra-226 (2g) in a dedicated facility with a thermal neutron flux of 2e14 neutrons per cm2 per s for a period of 100 days.
Ra226 Irrad

More info…
– webKORIGEN++ neutron activation wiki page

Posted in FAQs | Comments

Problem with using mixtures in DELNuS++

February 25th, 2019
by Joseph Magill

Some of our users have reported that the results of a decay calculation using DELNuS++ for a mixture does not give the same result as the sum of the results for the single nuclide calculations.
As an example, the activity of Cs137 or Kr85 produced from a mixture of Cf252 and Cf250 is almost a factor two higher that from the sum of the results using the single nuclides Cf252 and then Cf250.
The problem has now been identified and resolved.
The results obtained using DELNuS++ for the mixture are now consistent with the sum of the results for the individual component nuclides. The results also agree with those obtained using the Decay Engine++ (which can also account for fission products).

Posted in FAQs | Comments

More from this blog