openmc-dev / openmc

OpenMC Monte Carlo Code
https://docs.openmc.org
Other
765 stars 491 forks source link

Incorrect photon heating with TTB, proposed fix #1453

Closed paulromano closed 4 years ago

paulromano commented 4 years ago

I recently discovered that tallying photon heating in an infinite medium problem doesn't produce what you'd expect. If I start with a monoenergetic photon source of energy E and there is no leakage, all its energy should be deposited. Thus, you'd expect that the total heating should be E. Well, that's not what I observed -- as one example, if I start a 5 MeV photon source in uranium, I end up with ~5.5 MeV of energy deposition. If I turn off thick-target bremsstrahlung, the issue goes away and I get exactly 5 MeV of deposition.

After some digging, I was able to figure out that the issue is as follows:

So, there is effectively a double counting going on. It's important to note that the "transport" of electrons of positrons (they don't really move but do create photons through bremsstrahlung or annihilation) doesn't actually deposit energy currently.

Proposed solution

The solution is to allow electrons and positrons to deposit their energy and to not assume during photon collisions that the electron/positron energy is deposited. This enables for a complete, consistent, and accurate accounting of where energy is deposited.

I plan on submitting a PR to fix this, but first I wanted to get some opinions on what we should do with the non-analog photon heating score. Right now, our openmc.data API calculates heating numbers for photons, but these heating numbers have a built-in assumption that electrons/positrons are deposited locally. I don't see any obvious way to fix that, so I'm thinking that perhaps we should just remove the non-analog score (along with the heating numbers in the data files) because 1) they are not accurate when TTB is on, 2) they require storing extra data, and 3) they require extra computation when producing photon libraries. There doesn't seem to be a clear benefit. @liangjg I mostly wanted to get your opinion on this since you originally put together this capability (#1203).

paulromano commented 4 years ago

Resolved with the merging of #1462