I am attempting to run a simulation using a moderately complex geometry. I have created the input file using FLAIR and it’s geometry debugger which shows no errors in the geometry. Additionally, when the input file is ran on my personal computer, there are no problems and everything works fine. However, when running on a cluster, with an identical source file and number of primaries, the simulation fails with the .log file reporting:
STOP TOO MANY ERRORS IN GEOMETRY: STOP
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
STOP STOP: FLUKA ABORTED
I followed the advice given in the topic “Erros leading to a run stop without any geometry error shown” and I reduced the GEOBEGIN accuracy parameter with no effect. The location of the error appears to be in one of the scintillator screens however FLAIR shows no errors at this location.
I am a little confused as to why it would work on my own laptop but not on a cluster (which is needed to run a much higher number of primaries eventually.) Both my laptop and the cluster have the same version of FLUKA (4-2.0) installed; my laptop is Ubuntu20.04 and the cluster is CentOS7.
I have attached my input file and the error file generated. Any help/advice would be greatly appreciated.
Hi Kyle,
your geometry looks indeed defined in a formally correct way, such as no error can be attributed to it. Nevertheless, your VOID0000 region, consisting of a single zone, turns out to be quite complex, including many bodies and several parentheses, which challenge the runtime evaluation by the FLUKA geometry kernel and may lead to the reported crash. My suggestion is to split it in different zones (still belonging to the same region), with each of them naturally involving less bodies and parentheses. Such an effort will hopefully pay, certainly more than playing with the GEOBEGIN accuracy parameter. Let us know if the proposed way is effectively viable.
Thank you for your reply. I have tried dividing VOID0000 into different zones as suggested but this seems to have had no effect and the same error occurs without any geometry errors being flagged in FLAIR. I am also seeing the effect of turning off the runtime parenthesis expansion however I do not think this will have any effect either.
I’ve uploaded the updated input file with the segmented VOID0000 region.
I also had to include two blackbodies behind the scintillators to prevent an error during the propagation of the optical photons (only the amount produced are needed anyway) however the same geometry error results inside the scintillators.
Dear Kyle,
the problem turned out to be induced by a novelty introduced in the fresh 4.2.0 release, namely the optical photon generation by local sub-threshold energy deposition events, indicated in the release notes. This triggered the geometry tracking errors you experienced with optical photons. The respective bug fix will be included - together with others - in the upcoming minor release. Thanks a lot for your prompt report and sorry for the wasted time.
On a parallel note, your .err file displays at the top repeated messages questioning the soundness of the Sternheimer parameters you input for your Gd2O2S material. In fact, they yield a density effect correction with the wrong sign, which is then zeroed by FLUKA as calculating the stopping power. I’d advise to avoid overwriting those parameters as well as the average ionisation potential (just drop the respective STERNHEI and MAT-PROP cards).
I see that you took them from the Flair material database. Nevertheless, as importing into the input the optional STERNHEI and MAT-PROP cards, one is in fact overwriting the default values already available in FLUKA. This should be better avoided, unless one has good reasons to do otherwise.