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:
After a photon collision, we assume that the energy of any electrons/positrons created is deposited at the collision site. In our heating score, we only subtract off the energy of photons/neutrons created.
With TTB on, those electrons create photons which are transported elsewhere, depositing more energy.
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).
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).