| Summary: | Small voxel sizes (1mm) lead to stuck tracks which severely degrade the simulation performance | ||
|---|---|---|---|
| Product: | Examples/Extended | Reporter: | alexander.howard |
| Component: | medical/DICOM | Assignee: | Pedro.Arce |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 11.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | tar-ball of a modified version of the DICOM extended example with fixed and simple geometry | ||
I should add that this has been tested against the 11.2 candidate tag and with very recent fixes to the DICOM example (i.e. will be present in the next public release). |
Created attachment 839 [details] tar-ball of a modified version of the DICOM extended example with fixed and simple geometry If the DICOM example is run with geometries with voxels around 1mm tracks become stuck on the boundaries in multi-threaded mode. In sequential the problem is not present, so I presume it's a data race. The process which limits the step directly after the stuck track is multiple scattering, so that might be a hint. I attach a modified version of the example which reads in a simple water phantom with 6x8x10 voxels of 1mm side. The phantom is read from water-stuck.g4dm which is hard-coded to be loaded as the geometry (i.e. ignoring the dicom reader). To see the problem with default settings simply run: ./DICOM run-stuck.mac which generates 10 events of which one should be stuck.