Tallying activation in big geometry

I am trying to run a full dose simulation including prompt neutrons, prompt photons and delayed photons (through R2S) to estimate the real dose received by workers during operations of an ICF plant.

The issue I have is that my plant is so big (outer radius: 26m) that my results are not statistically relevant. I tried implementing MAGIC weight window but it takes very long to converge to a relevant weight window mesh. I already reduced my simulation space to a 1/40th fold thanks to symmetries. Do you think of any other way of reducing my figure of merit FOM= \frac{1}{σ^2⋅t}.

Or do I have to brute force and request some cluster time?

Longer term

Perhaps Random Ray + FW Cadis Weight windows instead of MAGIC. There is an effort to get MGXS working and then the Random Ray method working for photons, extra help there could help bring this to a stable release sooner.

Shorter term

  • More compute
  • If axially symmetrical perhaps you can even use a cylindrical mesh instead of a regular mesh.
  • break up the simulation perhaps prompt and delayed can be done separately

Thank you @Shimwell. I am already using a spherical mesh. I’ll also trying breaking up the simulation.

I also reckon the meshing I choose for the activation mesh is super important for computational cost. Do you have any advice on this ? I was thinking about a spherical mesh layered radially. My main question is on how should I space the layers ? One mean free path in the material ?

With spherical mesh I guess the most accurate result is to increase the mesh size up to your RAM limits and unfortunately this will slow down the simulation and this non linear slow down varies from computer to computer.

Other meshes like rectilinear are also interesting as you can have fine mesh over the bioshield and course mesh in the air and super fine mesh on the machine.

You could also go down the unstructured mesh route, libmesh supports quads for example so these could be sized differently for your different parts of your geometry.

The mean free path does sound like nice, I like it when the arbitrary choice is somewhat physics based. I do some mean free path based mesh sizing for the random ray mesh and I’m quite happy with that, exactly why I added the convenient material.mean_free_path to the API

Longer term we need an adaptive mesh for this sort of simulation to get both fine where it is needed and course where detail is not needed and efficient RAM usage.