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

  • Thread starter 19matthew89
  • Start date
  • Tags
    Mcnp Mcnp6
In summary, Alex is trying to understand why flux tallies can be larger than 1 in a criticality calculation, and wonders if the tallies are supposed to be a fraction of all the particles or not. He also mentions that this could be related to the periodic boundary conditions in his setup.
  • #1
19matthew89
47
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
  • #2
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
  • #3
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.
 
  • Like
Likes Alex A
  • #4
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'.
 
  • #5
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
 
  • #6
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

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

1. What does it mean for MCNP tallies to be normalized?

In MCNP (Monte Carlo N-Particle) simulations, normalization refers to adjusting the tally results to account for the number of source particles simulated. This process ensures that the results are representative of a single source particle, making them easier to interpret and compare.

2. Should normalized MCNP tallies always be less than 1?

No, normalized MCNP tallies are not necessarily less than 1. The value of a normalized tally depends on the physical quantity being measured and the specific problem setup. For example, flux tallies can be greater than 1 if the flux is high in certain regions.

3. Why might a normalized MCNP tally exceed 1?

A normalized tally might exceed 1 if the quantity being measured is large relative to the number of source particles. This can occur in scenarios with high flux, high energy deposition, or in regions where particles are concentrated.

4. How can I verify if my MCNP tally normalization is correct?

To verify the correctness of your tally normalization, you should check the problem setup, including the source definition and tally specifications. Additionally, comparing the results with analytical solutions, benchmark data, or other simulation codes can provide validation.

5. What steps should I take if my normalized tally values seem incorrect?

If your normalized tally values seem incorrect, you should first review the input file for any errors in the source definition, tally cards, and normalization factors. Ensure that the number of source particles and the geometry are correctly specified. Running a simpler, well-understood problem can help identify potential issues in the setup.

Similar threads

Replies
1
Views
2K
Replies
17
Views
2K
Replies
2
Views
2K
Replies
2
Views
1K
Replies
1
Views
4K
Back
Top