[Gate-users] Bug in GateDeadTime.cc
jan at shfj.cea.fr
Thu Jun 8 18:20:40 CEST 2006
The bug report from spencer was correct. This bug impacted your results
when you defined a system with a specific hierarchy, for example :
cylindricalPET + rsector + module + crystal +... with the dead time
applied on the "module".
If you used a hierarchy as follow :
cylindricalPET + rsector + crystal + ...with the dead time applied on
the "rsector", your data are correct.
This bug is now fixed in the release (on the gate web site) and you can
find a patch attached to this email.
Sorry for troubles and thank's to Spencer for his collaboration.
Spencer Bowen wrote:
> I'm writing to report a potential bug for the singles dead time
> implementation in Gate versions 2.1.0 and 2.2.0 found in the source file
> GateDeadTime.cc. In the for-loop at lines 134-137 it appears as though
> a unique ID for each component is not assigned to m_generalDetId. For
> instance, for a cyldricalPET system I have been simulating that contains
> 6 modules per an rsector (total of 22 rsectors), with the deadtime
> attached to the module volume, the variable m_generalDetId goes from 0
> to 26, when it should go from 0 to 131. Indeed the array
> m_deadTimeTable is declared with length numberTotalOfComponentInSystem =
> 132, in this instance (line 286). Consequently, with duplicate
> m_generalDetId values the dead time experienced for each module can be
> significantly greater than if unique IDs were issued. Below I have
> posted a simple fix to this potential bug:
> G4int multFactor = 1;
> for(G4int i = 1 ; i < numberOfHigherLevels + 1; i++)
> multFactor *= numberOfComponentForLevel[i-1];
> m_generalDetId += aVolumeID->GetCopyNo(m_depth-i)*multFactor;
> I'm interested to know if others have noticed this error in their own
> simulation results?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9344 bytes
Desc: not available
More information about the Gate-users