Energy depo #154

Esmae · 2025-02-13T15:46:00Z

Implementation of mode 0 energy deposition tally as described in Tuominen, R., Valtavirta, V. and Leppänen, J., 2019. New energy deposition treatment in the Serpent 2 Monte Carlo transport code. Annals of Nuclear Energy, 129, pp.224-232. (Amongst other papers).

Works with macro or microResponse. Does not work with MG.

Documentation is also updated.

Merging Energy Deposition changes with most recent SCONE version

ChasingNeutrons · 2025-02-16T12:54:07Z

NuclearData/xsPackages/neutronXsPackages_class.f90

  !!   capture          -> sum of all reactions without secendary neutrons excluding fission [1/cm]
  !!   fission          -> total Fission MT=18 Cross-section [1/cm]
  !!   nuFission        -> total average neutron production Cross-section [1/cm]
+  !!   energyDepoZero   -> energy deposition, for mode zero.  [MeV/cm]


I would be inclined to rename this property. The reference to mode 0 is (I think) unique to Serpent, whereas the fission cross section * the Q value is commonly understood. Maybe qFission in analogy with nuFission would be more clear?

Actually kappaFission is probably the best understood term.

kappaXS or heating
We don't expect it to be limited to fission. It will be reused for neutron heating in non-fissile materials as well.

ChasingNeutrons · 2025-02-16T12:58:11Z

Tallies/TallyResponses/macroResponse_class.f90

    ! Return zero if particle is not neutron or if the particle is in void
    if (p % type /= P_NEUTRON) return
    if (p % matIdx() == VOID_MAT) return
+    if ((self % MT == macroEnergyDepoZero) .and. (p % isMG .eqv. .true.)) then


Perhaps for another PR (maybe an issue for now), but it is conceivable to have an MG equivalent. Basically this would mean giving the MG data one more input and it would be straightforward to compute qFission in a given material.

ChasingNeutrons · 2025-04-09T12:06:21Z

SharedModules/endfConstants.f90

                                  macroAbsorbtion = -21 ,&
                                  noInteraction   = -901
+  ! List of Macro Energy Deposition numbers for different energy deposition modes. Unique to SCONE
+  integer(shortInt), parameter :: macroEnergyDepoZero = -1100


I don't think there needs to be a number for mode 0 in particular at this stage. Rather, just energy deposition (or kappaFission) is fine, sitting with the other macros for consistency of style. Also, I might suggest making it -80 for consistency with Serpent. The micro would then be -301.
https://serpent.vtt.fi/mediawiki/index.php?title=ENDF_reaction_MT%27s_and_macroscopic_reaction_numbers

ChasingNeutrons · 2025-04-09T12:11:34Z

SharedModules/universalVariables.f90

                              lightSpeed  = 2.99792458e10_defReal, & ! Light speed in cm/s
                              kBoltzmann  = 1.380649e-23_defReal,  & ! Bolztmann constant in J/K
-                              energyPerFission = 200.0_defReal       ! MeV
+                              energyPerFission = 200.0_defReal,    &   ! MeV


I think this warrants some extra description. Is this supposed to be the estimated energy deposition of U235 for an LWR in particular? If so, I think its number is 202.27. Given that, what role does the scale factor below serve? I thought it wouldn't be necessary given Q235 is read from the ACE files?
I may be missing something though, I am not very knowledgeable on this.

The energyPerFission = 200 line already existed in SCONE, and energyDeposition doesn't use it. I don't think anything in main branch currently uses energyPerFission? So we could potentially change it anyway? Or delete it. Instead we only use the following line "energyDepoZeroScale = 1.04583_defReal ! Ratio of Energy Depos per Fiss in LWR, and Qfiss for U235". This scaling number is H(U235)/Q(U235)=202.27/193.406=1.04583. This scaling number is then multiplied by Q(nuclide) to get the energy deposited. Given I had to add (or change, in hindsight) a constant anyway, I combined them instead of reading Q(U235) from the ACE files, even when there is no U235 in the system. Another option would be to change energyPerFission to 202.27 and get SCONE to always read in U235 ACE data. If you have further thoughts please let me know.

Historical context:
The energyPerFission line was added ad hoc as a 'by yesterday' way to have 'some' heat deposition estimate for power normalisation. (speaking of which I think that it was you @ChasingNeutrons who has added it 😉 )

But I have to say that I am not really happy that the heat deposition scaling fudge factor (which it is really) lives as a constant. It should really be a user defined parameter which should be specified at least per database basis. (maybe even per material? ).

This shouldn't be too bad to refactor I think. We just need to add a entry for database dictionary to read it and fudge the heating number in the database? But I didn't look to carefully to see if there are any problems that could arise, so I might have missed something major.

ChasingNeutrons · 2025-04-09T12:23:54Z

Tallies/TallyResponses/Tests/macroResponse_test.f90

    real(defReal), parameter :: TOL = 1.0E-9

    p % type = P_NEUTRON
+    p % isMG = .false.


Why did this have to be added? Perhaps I missed something. Is there a reason why energy deposition can't be included with MG? Perhaps for a second PR, but it would be nice to have a kappa value in the MG input that could be used.

ChasingNeutrons · 2025-04-09T12:25:27Z

Tallies/TallyResponses/microResponse_class.f90

    ! Return zero if particle is not neutron or if the particle is in void
    if (p % type /= P_NEUTRON) return
    if (p % matIdx() == VOID_MAT) return
+    if ((self % MT == macroEnergyDepoZero) .and. (p % isMG .eqv. .true.)) then


Suggested change

if ((self % MT == macroEnergyDepoZero) .and. (p % isMG .eqv. .true.)) then

if ((self % MT == macroEnergyDepoZero) .and. (p % isMG)) then

ChasingNeutrons

This all looks good to me. The only thing is the mentioned naming style. Something like kappaFission would be more appropriate I think as it is more generally understood.

Mikolaj-A-Kowalski · 2025-05-09T12:43:11Z

NuclearData/xsPackages/neutronXsPackages_class.f90

  !!   capture          -> sum of all reactions without secendary neutrons excluding fission [1/cm]
  !!   fission          -> total Fission MT=18 Cross-section [1/cm]
  !!   nuFission        -> total average neutron production Cross-section [1/cm]
+  !!   energyDepoZero   -> energy deposition, for mode zero.  [MeV/cm]


kappaXS or heating
We don't expect it to be limited to fission. It will be reused for neutron heating in non-fissile materials as well.

Mikolaj-A-Kowalski · 2025-05-09T12:47:16Z

SharedModules/endfConstants.f90

-                                  N_N_SPLIT       = 1005
+                                  N_N_SPLIT       = 1005 ,&
+                                  ! SCONE's fake MT for energy deposition
+                                  N_ENERGYDEPO_ZERO = 1100


Do we need to go with the fake MT here?
From my reading of ENDF manual MT=301 feels appropriate, right?

Mikolaj-A-Kowalski · 2025-05-09T12:50:16Z

NuclearData/ceNeutronData/aceDatabase/aceNeutronNuclide_class.f90

    type(thermalData), dimension(:), allocatable :: thData

+    ! Energy Deposition for fission
+    real(defReal)               :: Qfiss = ZERO


I'm afraid I will be annoying a bit... 😉

I'm just thinking this should be perhaps moved and stored in the fission reaction object since it is a fission related quantity and is a bit ill-defined if the nuclide is not fissile.

I would just read this quantity as a part of fission reaction initialisation.

I know it was done like this in this case to avoid adding the heating number to the mainData cross-section table (do I get it right?), but I think that this will have to happen sooner or later so maybe we can just do it now while we are at it?

Then basically for fissile isotopes we would just need to compute heating number as a preprocessing step?

Mikolaj-A-Kowalski · 2025-05-09T13:05:39Z

SharedModules/universalVariables.f90

                              lightSpeed  = 2.99792458e10_defReal, & ! Light speed in cm/s
                              kBoltzmann  = 1.380649e-23_defReal,  & ! Bolztmann constant in J/K
-                              energyPerFission = 200.0_defReal       ! MeV
+                              energyPerFission = 200.0_defReal,    &   ! MeV


Historical context:
The energyPerFission line was added ad hoc as a 'by yesterday' way to have 'some' heat deposition estimate for power normalisation. (speaking of which I think that it was you @ChasingNeutrons who has added it 😉 )

But I have to say that I am not really happy that the heat deposition scaling fudge factor (which it is really) lives as a constant. It should really be a user defined parameter which should be specified at least per database basis. (maybe even per material? ).

This shouldn't be too bad to refactor I think. We just need to add a entry for database dictionary to read it and fudge the heating number in the database? But I didn't look to carefully to see if there are any problems that could arise, so I might have missed something major.

E.J. Woods added 3 commits December 7, 2024 14:02

Energy Deposition Changes

1d182ea

Merge branch 'Energy' into energy_depo #

5e1882a

Merging Energy Deposition changes with most recent SCONE version

Neatening Energy Deposition

81f7617

ChasingNeutrons reviewed Feb 16, 2025

View reviewed changes

ChasingNeutrons reviewed Apr 9, 2025

View reviewed changes

ChasingNeutrons requested changes Apr 9, 2025

View reviewed changes

Mikolaj-A-Kowalski reviewed May 9, 2025

View reviewed changes

	if ((self % MT == macroEnergyDepoZero) .and. (p % isMG .eqv. .true.)) then
	if ((self % MT == macroEnergyDepoZero) .and. (p % isMG)) then

Energy depo #154

Are you sure you want to change the base?

Energy depo #154

Uh oh!

Conversation

Esmae commented Feb 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChasingNeutrons left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants