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

[19matthew89]

TL;DR

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!

 

[Alex A]

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.

 

[19matthew89]

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.

 

[Alex A]

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'.

 

[19matthew89]

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

 

[Grelbr42]

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.