Author Archive

e-Ship++ now with Transport Security Thresholds

October 17th, 2019

The e-Ship++ application has been extended to monitor the transport security threshold of high consequence dangerous goods. A warning is generated in the transport report when the threshod is exceeded.
The transport of high consequence dangerous goods needs special attention as described in the ADR section 1.10.3 (pp. 100 – 103)
High consequence dangerous goods are those which have the potential for misuse in a terrorist event and which may, as a result, produce serious consequences … particularly for goods in Class 7
For Class 7 goods, high consequence radioactive material is that with an activity equal to or greater than a transport security threshold of 3000 A2 per single package except for specific radionuclides.
TST5Example of the warning shown when a package reaches the threshold for high consequence radioactive material.

More information…
High consequence dangerous goods
– e-Ship++ wiki page on Transport Security Threshold

Posted in Nucleonica | Comments (0)

Gamma Spectrum Generator for large nuclide inventories?

October 15th, 2019

(Qu.) AM, Linköping University, Sweden
Dear Nucleonica Team,
We work with a mixture of about 900 radionuclides. We would like to generate corresponding gamma spectra using the Gamma Spectrum Generator++, but the generator allows to work with no more than 20 nuclides in the mixture. Is there a way how to increase this number? Would a standalone application help? It would be a bit laborious to split the 900 nuclides to 45 groups, process each group individually and then combine the results.

(Ans. Nucleonica Team)
Depending on your requirements, it may not be necessary to use the Gamma Spectrum Generator, GSG (which is as you say restricted to 20 nuclides). A spectrum can be obtained using the Gamma Dosimetry & Shielding, D&S H*(10) application. This line spectrum is obtained using the activities, emission probabilities and the energies of the emitted radiation. This may be sufficient for your purposes. It does not include peak broadening, Compton scattering and background scattering as in the GSG. The advantage of using the D&S H*(10) is that it is can handle 900 nuclides with a reasonable calculation time (typically a few seconds).
If you require the full GSG spectrum with line broadening, Compton scattering etc. You will need to use one of our test servers for this purpose. There a GSG spectrum for approx. 900 nuclides (with around 28000 gamma lines) will require a calculation time of approx. 20 mins. The Nucleonica Team can provide more information on our test servers.

Once you have the GSG spectrum for the 900 nuclides, you can save this in XML format. This xml file can then be uploaded into the webGraph application. Using the xml files in webGraph provides therefore an “Active” graph which can be used for later viewing and examination. With the Active graph the user can zoom in and out and use the mouse cursor to identify the underlying nuclides.

Posted in FAQs | Comments (0)

Some questions concerning Shielding calculations in Nucleonica using Cm244 and W

September 16th, 2019

(Qu.) LH JRC, Karlsurhe, Germany
Dear Nucleonica Team,
May I ask you some question about shielding calculation using Nucleonica?
I want to shield a Cm244 source using Tungsten. Unfortunately I get some strange results, using both the older Dosimetry & Shielding calculation and the newer Dosimetry & Shielding H*(10) apps. The Tenth value shield thickness of these 2 methods do not match: They are a factor 10 different, which I consider far too much.

(Ans. Nucleonica Team)
Please note that the newer D&S H(10) includes the high energy prompt gammas.
The older D&S does not. You can see this in the graph at the bottom of the page. The D&S H(10) contains groups of gammas in the range 1-10 MeV. You can also see this is more detail in the datasheets.
Cm244Although the BR for SF is low (1e-6), the emission probabilities for the low energy gammas is also low. Hence these high energy gammas need to be accounted for in the calculations.

Note also that the high energy gammas are included only in the JEFF3.1 database. Other databases (e.g. ENDF/B) do not have these high energy gammas. The database can be changed in the D&S H(10) Options menu.
The contribution of individual gamma energies can be investigated using the “photons/s” in the source strength drop-down menu. There one can see that it is the higher energy gammas which make the difference.

Posted in FAQs | Comments (0)

Build up factor interpolation

August 21st, 2019

(Qu.) SG SCK-CEN, Belgium
Dear Nucleonica Team,
As shown below is the buildup factor equal to 1 at a distance of 15 m in air for gammas with an energy of 1 MeV.
My assumption would be that for a number of mean free paths of 0 the buildup factor would be 1. If this is the case, the buildup factor at 15 meters (mfp = 0.1107) should be interpolated between 1 (the buildup factor at mfp=0) and 1.47 (the buildup factor at mfp=0.5). If I do this I get a buildup factor of 1.104.
Am I wrong in my assumption or does Nucleonica interpolate differently? (Logarithmic or spline interpolation instead of linear interpolation what is shown in the help menu).

Buildup factor interpolation

(Ans. Nucleonica Team)
Until now the buildup factor was extrapolated for a given energy from the two last tabulated values µd=0.5 and µd = 1 when µd < 0.5. But since BU = 1 for µd = 0 interpolating between µd = 0 and µd = 0.5 is a better approach and will be realised by the next deployment. Thanks again for your observations.

Posted in FAQs | Comments (0)

Nucleonica Physical Constants updated to 2018 CODATA recommended values

August 13th, 2019

The values of the physical constants used in Nucleonica are recommended by CODATA and are the latest available. Termed the “2018 CODATA recommended values” they are recognized worldwide for use in science and technology. The values became available on 20 May 2019 and replaced the 2014 CODATA set. They are based on all data available until 31 December 2018.NewPCs-2019Of particular important to the Nucleonica applications, IUPAC is recommending a new definition of the mole based on a specified number of elementary entities:
The mole, symbol mol, is the SI unit of amount of substance. One mole contains exactly 6.022 140 76 × 1023 elementary entities. This number is the fixed numerical value of the Avogadro constant, NA, when expressed in mol−1, and is called the Avogadro number.
More information
2019 redefinition of the SI base units
A new definition for the mole based on the Avogadro constant
A NEW DEFINITION OF THE MOLE HAS ARRIVED (IUPAC)

Posted in Karlsruhe Nuclide Chart, Nucleonica | Comments (0)

Metastable states in the Karslruhe Nuclide Chart

July 24th, 2019

Qu. (from M. R. KTE Karlsruhe, Germany):
Dear Nucleonica Team,
I have always wondered what the criteria are to show the metastable state of a nuclide on the chart. The first guess would be the half life of the state. But I found for example the nuclide Rn-214 which shows a metastable state of only 0,69 ns. Is there an arbitrary threshold just below that number where you show the state on the chart if it is above? If the threshold depends on the half life, is there a scientific reason for that threshold? Are all states shown that are above that threshold?
Rn214Ans. (Nucleonica Team)
Metastable states, which do not undergo alpha or beta decays or spontaneous fission, i.e. decay only by isomeric transition are shown (usually) only if their half-life is larger than 1 s (to save space).

Rn 214 excited states Rn 214m and Rn 214n have been observed, both with alpha decay to Po 210. Although their half-lives are less than 1s they are shown in KNC. In this way the users of KNC can know that the alpha emission is not from the ground state of Rn 214 and can have higher energy than the Q-value of ground state to ground state decay.
In some particular cases when the metastable state has an important role in a decay chain or in nuclear physics theory, it is presented even it decays only with isomeric transition and has a half-life shorter than 1s.
There is an interesting article on wikipedia.

Posted in FAQs, Karlsruhe Nuclide Chart | Comments (0)

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

July 18th, 2019

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 (0)

Nuclide ID in ZZAAA (or ZAID) format possible?

June 26th, 2019

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 (0)

Application loading and running times

June 12th, 2019

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 (0)

Uploading Nuclides with Metastable States in Nucleonica

June 5th, 2019

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 (0)

More from this blog