We are using AUTOIMBS to estimate the dose rate from a point ⁶⁰Co source at large distances (a skyshine-type problem). The source sits at the centre of a temporary radioactive waste deposit, itself at the centre of a ~600 m × 600 m × 600 m air/ground environment. We score the ambient dose equivalent with region USRBINs at 8 spherical detectors placed between 1 m and 250 m from the source (RADDECAY in semi-analogue mode). I have many doubts about AUTOIMBS and its features.
The AUTOIMBS CONFIG card triggers a warning in Flair (red highlight) on WHAT(3)=1 — Flair’s tooltip states the valid range as -1≤x≤0. Is the algorithm still running correctly with WHAT(3)=1, or is this value actually invalid and silently reinterpreted?
Our AUTOIMBS RPP currently spans the whole 600 m cube. Would you recommend shrinking it to a box enclosing just the deposit and the dose points? Is WHAT(4)=20 (default 100) reasonable given ~40 cm concrete shielding (mfp ≈ 7–8 cm) plus long air paths (mfp ≈ 100–150 m for ~1.25 MeV photons)? I need to better optimise the settings because my simulation didn’t pass the last statistical check (PDF-tail-slope) and I obtain a large relative error for the farthest detector.
We ran the simulation over 10 sequential cycles (10×10^7 primaries) to get meaningful statistics, and AUTOIMBS produced one *_AUTOIMBS_statistical_checks_1.dat file per cycle. The manual mentions a mergestats tool in the bin/ folder to merge these into a single global statistical check, but we cannot find it anywhere in our fluka4-5.2 installation. Is this tool available through a different distribution channel, or is there another supported way to obtain the merged/global statistical check across cycles?
The AUTOIMBS_biasing_maps.bnn file that gets written — does it capture a snapshot of the importance map at the start of the run (before any learning), or the final, converged map at the end?
Does AIB’s learned importance map persist and keep improving across sequential cycles within one run, or only within a single spawn? Should independent parallel spawns be avoided if we want AIB to converge as well as possible?
With multiple dose points in a single AUTOIMBS ROI list, does the printed statistical check (mean, RE, VOV, PDF tail slope) represent an aggregate/average over all regions, or the worst one? Is there a way to get a per-region breakdown?
Thank you very much for your time and help, and apologies for the length of this message.
1.) Silent reinterpretation is the source of all evil No worries, there is non in the case of new features like the AIB. This is rather related to the fact that this feature was added more recently and the setting is not yet correctly checked in FLAIR’s grammar of the FLUKA syntax. Thus, the warning is triggered incorrectly.
2.) It is perfectly fine like this. Yet, you might not necessarily need to include the complete soil region. This one could safely be made smaller so that includes only a first layer of the soil close to the air region from which you would really expect scattering towards the detectors. Yet, I would include the complete air region.
3.) To be investigated. In principle it should be there - it is in my release. If you send me a PM I can provide you with mine.
4.) It captures lots of things, but only a few of them are meaningful for the end-user. What is interesting is the distance biasing map & the cumulative density map. Via the color coding & gradients the first one should show you if the biasing through shielding is going in the right direction and the second one should show the same for streaming contributions. The other maps are only interesting for development as the values shown are not comparable to classical importance biasing and require in-depth knowledge of the algorithm to be interpreted correctly. Yet, to answer your question - those values are the ones at the end of the cycle.
5.) Every cycle restarts without memory. This guarantees independence of the schemes between the cycles. At first glance this might look sub-optimal, but it has an impact when evaluating statistical quantities.
6.) The merge stats should be provided per region of interest.
Let me add a general comment related to your setup. If you look at the ROIs then they are rather small in comparison to the whole air volume as they are identical with your detector volumes. This might actually be counter-productive because adjacent ROIs might be “fighting” against each other to get particles and you might slow down or even prohibit the system to find a balance.
What you would like is to get sufficient particles from higher layers down to the bottom where your detectors are in comparison to those that would continue upwards and never return. So I would rather create a ROI that looks like such a layer. For example you could create one RPP (Z = -200 to 200) that includes all your detectors. At first this would be the only ROI that I would set. As a consequence the system will try to bring particles back down into this layer and then geometry and physics will do the rest. If you still do not see sufficient statistics then you could in addition include ROIs that are located around your scoring detectors. But I would only do this in a second step when I am sure that the first approach is not sufficient.
Please note that with skyshine problems even with a biasing scheme you might need to invest some CPU time to get good statistics, as no biasing scheme is a miracle solution for these rather intricate statistical problems.
Thank you very much for your detailed reply on the AUTOIMBS thread — it clarified a great deal, especially the point about the ROI design and the fact that each cycle restarts without memory. I will try following your advice and let you know.
Following up on your offer regarding point 3: I could not find mergestats anywhere in my installation (which, ls bin/, and a full recursive find all came back empty).
I would gladly take you up on your offer regarding mergestats, but when I try to send you a private message the forum returns “Sorry, you cannot send a personal message to that user”.
Would you mind writing to me instead? For reference, my setup is FLUKA 4-5.2 on macOS 15.5, Apple M4.
unfortunately I don’t have a Mac binary for the tool. But I am checking with a colleague to see if he has one that might work for you. Some other colleagues are also checking if there was a hickup in the packaging of the distribution which might have caused this tool to go awol.
Dear Chris,
a short update, since your suggestions solved the problem.
Following your reply, I redesigned the ROI: instead of eight small spheres around the individual detectors, I now use a single extended layer covering the whole region of interest. I also increased the number of primaries per cycle (10x10⁸): with 10⁷ per cycle the statistical checks didn’t pass the PDF tail slope check but with 10⁸ per cycle the PDF tail slope check pass in nine cycles out of ten. In addition, I obtained acceptable errors (8.2 %) even for the most distant detector (DET8).
As a cross-check I am now repeating the same geometry with a manual region-importance scheme, to compare the two approaches in terms of figure of merit. I will report the outcome.
I couldn’t fix the mergestats issue, so I inspect the checks files and biasing maps cycle by cycle.
I have a few additional questions.
Regarding the biasing maps: with SDUM = PRINT and WHAT(1) = 0 I only get a single map, the SurfDens one, which does not tell me much about how well the algorithm is performing. Should I also enable the average and maximum weight per voxel, with WHAT(2) and WHAT(3) of the PRINT card, to get a better picture of the applied biasing scheme?
I would very much appreciate your opinion on whether the scheme itself can be optimised further. I use the whole 300 m domain as the spatial limits of AUTOIMBS (I reduced the depth of the soil as you suggested), and FLUKA sizes it automatically to 99×99×50 voxels of 606 cm. That is a reasonable resolution for air, where the photon mean free path at 1.25 MeV is about 100 m, but it corresponds to roughly 80 mean free paths inside the 40 cm concrete walls. Is the scheme still able to build a meaningful biasing map there, or should I set a finer voxel size with WHAT(2) of the blank-SDUM card — possibly as a second scheme restricted to a small RPP around the building?
Is 20 mean free paths a sensible limit for this geometry, or would you keep the default of 100?
the mergestats issue has been fixed by my colleagues. So in the future packages the binary will be available. Maybe the current download packages have already been updated as well, but to be honest I don’t really know. Unfortunately I don’t have a Mac at my disposition to provide you with a fitting binary.
The slope test deserves probably a bit more information. What it does is to monitor the distribution of the weights in the ROI. If you imagine a graph where on the X axis you have the weights and on the Y axis you have the number of occurences, then for a perfectly converged case you will expect something like a Gaussian according to the CLT. In an ideal world the slope of the distribution towards higher weights should go down with about ~1/3 or less. We rarely see perfectly converged cases, so this distribution might still be a bit asymmetric and still be acceptable if the slope is not too far from that 1/3. 1/3 or lower actually means that the second order momentum exists and that you can infer reliable confidence intervals for your estimator. If you have values that are considerably higher than 1/3 it indicates that rare events have occurred but they are clearly undersampled. In that case the mean, despite the fact that it might look converged because the variance is small, is very probably wrong and underestimating the real value. The ideas behind this come from EVT (Extreme Value Theory) and are based on fitting a generalized pareto distribution to the tail of the weight pdf.
So don’t be afraid if this test does not pass, as long as the slope value is still not too far off from ~1/3 and as long as the other tests pass. We are currently considering sizing down the info of those tests that we output by default to make them more digestible to a user who is not necessarily a statistician or MC theorist.
Now to your questions:
1.) The SurfDens map gives you a gradient image that should show all “open” pathways in your geometry (e.g. streaming ducts etc.). As long as they are shown in this map, your resolution is perfectly fine. If you do not see your ducts in those maps, then you might consider using a higher map resolution to ensure that those small holes & ducts are well considered for potential streaming contributions. Dumping the other maps is useful for the developers but not really for the end user.
2.) IMO the system should handle your case quite well with the defaults. By default it uses the dimension of the biasing domain and distributes a fixed default number of voxels adapting the respective cell sizes. However, if you want to give it a try you can increase the number of voxels - it is a question of memory and initialization time. Also computing time will slightly be impacted but you can give it a try to bump that number up, though I don’t really expect that this will be necessary.
3.) Go with the defaults wherever you can. They were established by scrutinizing a battery of different use scenarios, including various particle types, energies etc. As a general guideline I would say that one should only optimize based on hard evidence and otherwise stick with the defaults.
As a small addition: indeed, as Chris mentioned, the issue has been fixed and mergestats will be available in the next release for MacOs.
The current packages have not been patched, but I created that executable on a MacOS machine, so I have just sent it to you directly by email together with the processor and library compatibility requirements.
Now I am able to report the results of the cross-check: the manual region-importance scheme and AUTOIMBS agree on all ten detectors, from 1 m to 500 m, with a maximum deviation of 2.0 σ. For the present study I have chosen the manual scheme, so I will not pursue the optimisation questions further for now but they will be useful for any future use of AUTOIMBS.
On mergestats, good news that the fix is in. Gabrielle has already been in touch about a macOS build, and I am following that up with her directly.
No worries, there is non in the case of new features like the AIB. This is rather related to the fact that this feature was added more recently and the setting is not yet correctly checked in FLAIR’s grammar of the FLUKA syntax. Thus, the warning is triggered incorrectly.