Created attachment 823 [details] Example code reproducing the nans. I have had this question active on the forums for a while and additionally have reached out to group affiliations who work on geant4 so I feel I have done due diligence before submitting this report. I have uploaded my code for this issue in the attachments. It is modified from example RE02 to use G4phantomparameterisation instead of nested parameterisation. I did this to try and isolate the cause of my issue which is that nans (not a number)s are produced in the sensitive detector when setregularstructureID(1) is used. When it is not used the simulations run correctly but are horrifically slow for any large voxelised object (order of one event per second). The intent of my code is to measure dosimetry in low energy x-ray imaging, around 40keV. The nans seem to be produced primarily in low density materials as a result of secondary particle (ionised electron) interactions. Given the issue only occurs when using the navigation with setregularstructureiD(1) it makes me think the problem is there. The test case in the is just a plane of air voxels. Cut values do no seem to affect the presence of nans, unless by completely stopping all electron secondaries being produced. Additionally when I tried rolling back to version 10.6.3 I found that nans were no longer produced but instead I got navigation errors occurring from stuck tracks. Given all these points I feel my last option is some kind of bug in the code, or in the very least some kind of obscurity not known to me or the many I have tried contacting. I really appreciate this being looked into. Kind regards, James
Not sure how many tickets there are in the queue but I'd be very interested to hear if this problem has been looked at / validated.
I am running your code. Where do you produce the nans? I do not see it. Maybe is in your output files? I cannot reproduce that because I do not have your G4THitsMap.hh or H5C.hh files
Created attachment 825 [details] G4THitsMap.hh
Created attachment 826 [details] G4THitsMap.hh
Hi Pedro, Thank you for getting back to me. I just downloaded the zip files and confirmed to myself they reproduce the error immediately on running. The nans are produced during the event action, I have a print statement during EndOfEventAction that will print most of the time when nans occur. They also save into a hdf5 file during the EndOfRunAction into the same directory the executable is in. I use the same G4THitsMap.hh file that make in the include directory of the Geant4-11.1 installation. There are no modifications made to it from there but I have attached it as well. The hdf5 files I have used are from the hdf5cpp package. They are most easily opened using imagej free software, if for whatever reason you cannot install that package I will see about removing that dependency. Note that these nans have occurred for me on both linux and windows installations.
Created attachment 827 [details] Geant4 Installation excluding data I have attached a copy of my geant4 installation excluding the data files. Please update with any progress made in reproducing the problem.
Hope all is well, let me know if I should resubmit my report.
Sorry to answer so late. I found your problem. It is just adding a safeguard: G4int G4EnergySplitter::SplitEnergyInVolumes(const G4Step* aStep ) { theEnergies.clear(); G4double edep = aStep->GetTotalEnergyDeposit(); if( edep == 0. ) { return 0; }
Hey Pedro, Apologies but I'm not quite across how to implement this, what should this safeguard go and what is it doing?
Disregard the previous comment sorry, I realised the if-return statement should be added to the G4EnergySplitter.cc source file and my geant4 installation recompiled. Would this change also be in future editions of geant4 or would I need to changed it each time I redownload? I'd still be curious to hear about what was happening here if you have time. I understand that the new if statement just exits out of the SplitEnergyInVolumes function if no energy was deposited in that step but I'm not sure how the rest of that function could create nans otherwise. Regardless though thank you very much for looking into it, I really appreciate it.
