If MCNP tallies are normalized, shouldn't they be <1?

  • Thread starter Thread starter 19matthew89
  • Start date Start date
  • Tags Tags
    Mcnp Mcnp6
AI Thread Summary
The discussion centers on understanding the normalization of MCNP tallies, particularly in criticality calculations using kcode. Users express confusion about why F2 tallies, which count surface crossings, can exceed 1, as they expect these values to represent fractions of particles crossing a surface. It is noted that if the area is set to 1 and the number of particles is high, theoretically, F2 values could exceed 1, especially in scenarios with rapidly increasing power. The conversation also touches on the impact of periodic boundary conditions and the challenges of normalizing tallies in different calculation setups. Overall, the complexities of MCNP tallies and their interpretations in criticality scenarios are highlighted.
19matthew89
Messages
46
Reaction score
12
TL;DR Summary
I was expecting MCNP tallies, being normalized to number of particles, should always be <1
Hi everyone,

I'm really new to MCNP here and I'm "playing" around trying to understand what is going on.

I think I am having problems understanding
  • what, in a criticality calculation, the MCNP tallies are normalized to
  • consequently, how comes they can be >1.
I was thinking that, in a criticality calculation (kcode), the MCNP were normalized to the number of source particles N given by the other user. In other words, I thought that the tallies (specifically F2 and F4) represented the fraction of the N neutrons that performed a certain "action" (either crossing a surface or entering a volume). And so, to find the "real" values of the fluxes, I had to multiply by the total number of neutrons of my problems (normally set by the power). Is my understanding correct?

If so, I'm still not getting how comes that MCNP tallies can be larger >1. Aren't they supposed to be a fraction of all the particles and so, inherently <1? However, for some F2 tallies, I'm getting values way bigger than 1 (even 1 or so). How is that possible?

Thanks a lot in advance!
 
Engineering news on Phys.org
Flux tallies are particles/sqcm per source particle. They are normally below 1. Unless you are modeling the capsule they lost in Australia check MCNP has valid values for surface area and volume. You'll find a table of calculated values and if it failed for an object, why, in the output file.

You can attach an input file to a post by renaming it to have .txt, or paste the contents in code tags if you want us to look at something specific.
 
  • Like
Likes 19matthew89
Alex A said:
Flux tallies are particles/sqcm per source particle. They are normally below 1. Unless you are modeling the capsule they lost in Australia check MCNP has valid values for surface area and volume. You'll find a table of calculated values and if it failed for an object, why, in the output file.

You can attach an input file to a post by renaming it to have .txt, or paste the contents in code tags if you want us to look at something specific.
Thanks Alex.

I have artificially set the values of the areas via SD card to 1 because I prefer divide by the area during postprocessing. But still, even with this, I'd expect that tally were <1 becasue only some particles would cross specific cells or surfaces and not all of them.

But ok. Thanks a lot. I'll take a look at what happens with areas and volume cards.
 
F2 counts surface crossings and then divides by the area, F4 measures track length and then divides by the volume (This still feels like black magic to me). If you have used an F4 in a large cell and then set the divisor to 1, or the volume hasn't been calculated that could produce answers well above 1.

I've been known to work out the thickness of F4 flux measuring cells manually to make the volume unity in the input file. I like this level of 'belt and braces'.
 
Alex A said:
F2 counts surface crossings and then divides by the area, F4 measures track length and then divides by the volume (This still feels like black magic to me). If you have used an F4 in a large cell and then set the divisor to 1, or the volume hasn't been calculated that could produce answers well above 1.

I've been known to work out the thickness of F4 flux measuring cells manually to make the volume unity in the input file. I like this level of 'belt and braces'.

Hi Alex,

Actually I'm having this issue (so far at least) only with F2 type tallies.
I understand what F4 and F2 do but exactly for what you said for F2: "counts the surface crossing (and then divides by the area)" I'd always expect values <1. In fact, if I understood correctly, to normalize to the number of particles, F2 should also divide the number of crossings by the total number of particles, right? If so, independently of the area (so let's assume for the moment that the area is unitary, as I set) the tally should always be <1, i.e. the fraction of all the particles that crossed the surface you evaluate F2 on. Then, if the area were not unitary, the quantity should be further divided by the area to have the proper tally. But that is an extra aspect.

However, it has actually just come into my mind that the issue I have could be related to the periodic boundary conditions I have in my setup. I'll have to delve a bit more into that to check if that could explain the problem.

Thanks
 
In theory, if you juggled things just exactly, and if you had a huge keff, you could get F2 values bigger than 1. It would be an interesting situation from a physics point of view. It would mean that more than one neutron passed a given location for each neutron started.

It probably means you are modeling something with a rapidly increasing power. So, normalizing to real numbers is a bit of a challenge. But not for long. The euphemism is "spontaneous self-disassembly."

If I recall correctly, MCNP can deal with such situations in a KCODE calculation. But if you have an SDEF calculation you get problems. This is because the history that results from each neutron your SDEF produces is arbitrarily long.
 
  • Like
Likes Will_007 and Alex A
Hello everyone, I am currently working on a burnup calculation for a fuel assembly with repeated geometric structures using MCNP6. I have defined two materials (Material 1 and Material 2) which are actually the same material but located in different positions. However, after running the calculation with the BURN card, I am encountering an issue where all burnup information(power fraction(Initial input is 1,but output file is 0), burnup, mass, etc.) for Material 2 is zero, while Material 1...
Hi everyone, I'm a complete beginner with MCNP and trying to learn how to perform burnup calculations. Right now, I'm feeling a bit lost and not sure where to start. I found the OECD-NEA Burnup Credit Calculational Criticality Benchmark (Phase I-B) and was wondering if anyone has worked through this specific benchmark using MCNP6? If so, would you be willing to share your MCNP input file for it? Seeing an actual working example would be incredibly helpful for my learning. I'd be really...

Similar threads

Replies
4
Views
980
Replies
1
Views
2K
Replies
1
Views
2K
Replies
17
Views
3K
Replies
0
Views
781
Replies
1
Views
2K
Back
Top