TMS

[valeriaRaffuzzi]

Here is the basic implementation of TMS. The main modifications are:

• in aceNeutronDatabase routines to get the material temperature majorant and relative energy macroscopic xss
• few entries were added to the nuclide and material cache: nuclide -> store total temperature majorant xs and parameters at which it was calculated. material -> energy relative to which the relative macroxss are calculated, and anther set of xss for the relative energy ones
• in ceNeutronMaterial, the routine to sample the nuclide now needs to check whether to accept the sampled nuclide or not
• in collisionProcessor_inter, the outcome of the nuclide sampling can be MT = noInteraction (rejection)
• in the collision processors the relative energy for which a nuclide is accepted is stored and used to sample reaction, to calculate number of fission neutrons and to sample inelastic scattering MT. QUESTION: should the sampled energy be used for scatterInLab and ScatterFromFixed too????????
• routines in scatteringKernels to sample the relative energy and calculate the DOppler correction factor for low energies
• in ceNeutronMaterial, sampleFission also had to be adapted
• the benchmarks were adaped to run with TMS
• in all the clerks that support reportInColl, virtual collisions are on by default (this is written in the User Manual)

NOTE: TMS is applied to the materials where 'temp' is specified in the input file, and outside S(a,b) and ures energy range with a margin such that the relative energy doesn't fall into those ranges
NOTE2: in aceDB % init, there's a check with FatalError if the material temperature specified is smaller or equal a nuclide temperature

Other modifications:

• initMajorant was slightly simplified
• routines in aceNeutronNuclide to verify the ranges of Sab and Ures

NOTE3: This implementation might still be suboptimal in terms of speed. For example, trying to use TMS on water (silly anyway), when deltaT > 50K the code slows down a lot because of the massive thermal temprature majorant and lots of rejections. Hopefully this can be fixed in the future.

[ChasingNeutrons]

One initial comment: do we want having a temperature in a material definition to activate TMS? I think there is something to be said for having a separate TMS flag in addition to temperature, as we essentially have for S(a,b). When we come to doing multiphysics etc, temperature seems like a natural variable to have around even if there are places we don't want to apply TMS.

[ChasingNeutrons]

Can this be given a more descriptive name? I suppose for me Temp has an annoying double connotation. Reading the comments, it isn't clear how the name relates to the function other than TMS - maybe updateTotalTMSNucXS?

[valeriaRaffuzzi]

I think calling it temperature majorant is quite standard terminology. Also in aceNeutronNuclide we have a function to calculate a temperature majorant used by both TMS and DBRC. I would say it is clear enough.

[ChasingNeutrons]

What happened that make tallies need to do the extra call to mat? Or rather, why does xsData % getTotalMatXS no longer work? Is there any way to preserve it?

[valeriaRaffuzzi]

Not really, because in TMS getTotalMatXS gets you the material temperature majorant, while getMacroXSs retrieves the material macroscopic xss at the relative energy. I should probably comment the code better to emphasize this.

[Mikolaj-A-Kowalski]

I think this point should be elaborated in the doc comment of the getTotalMatXS and getMacroXSs. It is a bit difficult to understand what cross-sections are obtained bu which call... however I am not sure how to make it cleaner at this moment.

[Mikolaj-A-Kowalski]

Perhaps there is no way around introducing some kind of getTrackingMatXs? This double meaning between the getMacroXS and getTotalMatXS is going to cause confusion and bug down the line I fear.

All of this obviously gets a bit confusing since the cross-sections have now become random variables. However, this confusion is not specific to TMS since it appears in URR as well. Basically we need to somehow separate the 'sampled' XSs at a particular state of the flight from a deterministic supremum on their values (TrackingXS?)

[valeriaRaffuzzi]

Yeah I agree that it should be made more clear. I tried to keep the code as simple as possible but clearly it's not an easy task and I might have overcomplicated interpretation.
The fact that colling getTotalMatXS is not safe is not great. I'll have a look.

[valeriaRaffuzzi]

I don't think separating deterministic vs random xss is a good way to do it. When using URR there is no point in asking for the deterministic xss. Same with TMS, one either wants the temperature majorant or the relative energy xss. What I am thinking for now is:

updateTrackingMatXS:
if TMS -> get Temperature majorant
else   -> get Total

updateTotal: 
if TMS -> get relative energy xss (when doing the relative energy sampling one might as well get the whole package) and return total
else   -> get Total as always

updateMacroXSS:
if TMS -> get relative energy xss
else   -> get Macro as always 

So as far as TMS is concerned, updateTrackingMatXS gets the deterministic majorant and updateTotal and updateMacro give the relative energy xss. When TMS is not used, there is no difference between updateTracking and updateTotal.

[ChasingNeutrons]

Thanks for this. My most major comment is just on keeping temperature as a separate variable which I think we would like to distinguish without demanding TMS (e.g., for multigroup calculations where we might eventually have multiphysics).

[valeriaRaffuzzi]

Thanks for this. My most major comment is just on keeping temperature as a separate variable which I think we would like to distinguish without demanding TMS (e.g., for multigroup calculations where we might eventually have multiphysics).

Thanks for reviewing! I am ok with changing keyword to, say, 'tms' instead of 'temp'. But I don't think we can easily skip the materialMenu step, not I think it is really an issue to go through it!

[Mikolaj-A-Kowalski]

Submitting the review but I didn't manage to finish before the changes.
Will go over it again.

[Mikolaj-A-Kowalski]

I think the biggest problem to address is to clarify the nuclear data interface in the presence of random cross-sections.
Basically we need to say clearly which functions return maximum value of the cross-section and which return a value obtained by a sample. I have a suspicion that we can call the maxima 'tracking' cross-section and in all other contexts functions would return sampled values? But I might be missing some problems.

I also believe having a paragraph to describe how we handle the random cross-sections (in the docs) would be really helpful, because I have a feeling it is difficult to make sense of what is going on from the code alone.

[Mikolaj-A-Kowalski]

Suggested change

! Return if collision is virtual but virtual collision handling is off

The comment seems to be dead. This handling was moved up the function?

[Mikolaj-A-Kowalski]

I think this point should be elaborated in the doc comment of the getTotalMatXS and getMacroXSs. It is a bit difficult to understand what cross-sections are obtained bu which call... however I am not sure how to make it cleaner at this moment.

[Mikolaj-A-Kowalski]

Perhaps there is no way around introducing some kind of getTrackingMatXs? This double meaning between the getMacroXS and getTotalMatXS is going to cause confusion and bug down the line I fear.

All of this obviously gets a bit confusing since the cross-sections have now become random variables. However, this confusion is not specific to TMS since it appears in URR as well. Basically we need to somehow separate the 'sampled' XSs at a particular state of the flight from a deterministic supremum on their values (TrackingXS?)

[valeriaRaffuzzi]

• QUESTION: should the sampled energy be used for scatterInLab and ScatterFromFixed too????????

@Mikolaj-A-Kowalski @ChasingNeutrons I can see you didn't read the PR description!!! Does anyone have an intuition on this?

[Mikolaj-A-Kowalski]

• QUESTION: should the sampled energy be used for scatterInLab and ScatterFromFixed too????????

@Mikolaj-A-Kowalski @ChasingNeutrons I can see you didn't read the PR description!!! Does anyone have an intuition on this?

Sorry. It does appear that I have missed this point in the description. The functions should use the LAB frame incident energy, not the relative energy. Basically the sampled energy is 'kind off' an energy in the CoM frame of the collision. If it was used weird things might appear.

[valeriaRaffuzzi]

Apologies for adding yet more stuff! I implemented all of the reviews:

• A lot of them were typos, aesthetic stuff and some docs.
• I removed collisionE from the particle. Now the collision energy is stored in collDat.
• I changed slightly the nuclear data interface (sorry!!). I added a function to the nuclearDatabase: getTrackMatXS.
  - This will be equal to the total material xs normally; when TMS is used, this is the material temperature majorant.
  - This function is mostly called by the transportOperators and in ceNeutronMaterial % sampleNuclide. It is also called when building the majorant in the case of DT.
  - The material tracking xs is now stored in ceNeutronCache for each material with the corresponding energy.
  - Now getTotalMatXS and getMacroXSs give consistent results: they give the regular xss OR the relative energy xss in the case of TMS.

Let me know if this works for you!

[Mikolaj-A-Kowalski]

I guess the only thing left to do is integrate and perhaps open an issue about trying to rework cache so it is clearer when we have time/ideas.