Bdsimsampler bunch distrType causing infinite while loop with mismatching file & build precisions.
A bdsimsampler distrType reading of a single precision file with a double precision build causes BDSIM to indefinitely print out the following:
BDSROOTSamplerReader::GeneratePrimaryVertex> End of file reached. Return to beginning of file for next event.
I only noticed this when running ctest with a double precision build; tests e.g. bunch-bdsimsampler timeout after 1500s rather than taking the ~5 seconds normally.
Looking into it, the while loop on line 80 of BDSROOTSamplerReader.cc
never breaks as there are no vertices to loop over in BDSROOTSamplerReader::ReadSingleEvent
. Two things I’ve discovered while trying to debug:
- The
doublePrecision
member of the reader (aBDSOutputLoaderSampler
instance) is always false (initialised value), so the double precision method will never be called. This is only determined by the precision of the build I think, but setting to true for my double build doesn’t fix this issue (haven’t pushed this fix in case I’ve misunderstood). - The
BDSROOTSamplerReader::ReadPrimaryParticles
methods, either float or double, will always find sampler->n returns zero, so no vertices are found, triggering the infinite while loop.
Clearly the sampler data read in BDSOutputLoaderSampler
is trying to load a single precision file with a double precision build, causing this issue, but I don’t know how to fix sensibly beyond there.
My instinct is that we should check the precision of the file against the precision of the build long before the event is read and then either cast to the correct precision later if possible or exit safely.
This issue can be recreated with the file examples/features/beam/bdsimsampler/bdsimsampler.gmad in the repository.
Comments (2)
-
-
- changed status to resolved
Fix Issue
#328. While loop for sampler loading as a beam distribution is fixed. BDSIM will exit and complain if in 1 pass of the file, no suitable particles were found. Add a test to cover this.→ <<cset 45b865dcb5a0>>
- Log in to comment
Thanks for reporting!
The member variable (bool)doublePrecision wasn’t every assigned it’s correct value as you noticed. Also, a subtlety in the output loader base class is that the beam and options are dynamically loaded when accessed (no GetEntry(0) until that call from a function, so accessing the inherited member localOptions just gives default options. So the option denoting whether the file was written with double precision isn’t read correctly.
There’s no need for it to be dynamic / delayed like that, that I can see so I’ve fixed that.
The while loop should also be strictly bounded and this case gets around it. Conceptually, we could have this scenario if a file is used where no particles in any events in that sampler meet the criteria. Therefore, we should exit saying there were no particles to simulate any events (we can’t run an empty event). I’ve fixed this so if we get through a file without ever having any suitable particles, an error is thrown.
I’ll test this and report back.