Problem 1634

Summary: Negative CopyNo is given to NestedParametrisation in ParallelWorld geometry.
Product: Geant4 Reporter: aso
Component: geometry/managementAssignee: Gabriele Cosmo <Gabriele.Cosmo>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P5    
Version: 10.0   
Hardware: All   
OS: Linux   
Attachments: Example code for reproducing the negative copyNo in NestedParameterisation of layered geometry.

Description aso 2014-06-02 07:12:08 CEST 
Created attachment 272 [details]
Example code for reproducing the negative copyNo in NestedParameterisation of layered geometry.

When the NestedParameterisation volume is used in a parallel world geometry, the CopyNo given to ComputeTransform/ComputeMaterial methods sometimes become negative (e.g. -1). It happens in both geant4 version 9.6.p03 and 10.00.p01.
 
 I attached the modified version of RE04 example (tested in 10.00.p01), which uses NestedParameteriation geometry for a layered mass geometry. I inserted G4cout in ComputeTransform/ComputeMaterial methods if the copyNo was -1. It shows the total counts of the error too.

For example,
--- snipped ---
**** ComputeTransformation:: Nagative CopyNo -1
**** ComputeMaterial:: Nagative CopyNo Total: 351
>>> Summary of Event 9991
--- snipped ---

 The attached file is the tar ball of RE04Nested code for reproducing the problem.
1)  $ tar zxf  RE04Nested.tgz
2)  $ mkdir RE04Nested-build
3)  $ cd RE04Nested-build
4)  $ cmake  ../RE04Nested
5)  $ make
6)  $ ./RE04
7)  Idle> /run/beamOn 10000
Comment 1 John Apostolakis 2014-06-28 16:12:35 CEST 
We are investigating the problem.  ( Gabriele and I have worked on it.)

We have been able to reproduce it, and to identify the condition that triggers it.
At the moment we are not able to identify a problem in either the user code which creates the geometry or in the navigation code in Geant4.

There is clearly an abnormal condition.  A volume which has a nested parameterisation appears to be misidentified at some stage of Navigation (occasionally) as a replica - and the replica number is set to -1.

It is not yet clear what causes this problem.
Comment 2 Gabriele Cosmo 2016-01-29 14:46:53 CET 
The problem has been finally identified in G4ReplicaNavigation::ComputeStep(), where the copy-number of the current volume for entering particles in replicas was occasionally wrongly set to -1.
The fix is included in tag "geomnav-V10-02-01" and will be included in future patches to 10.1 and 10.2 series.