G4PVDivision is a replicated volume (its override of G4VPhysicalVolume::IsReplicated returns true), but it does not override G4VPhysicalVolume::GetMultiplicity; so querying the multiplicity of a G4PVDivision with GetMultiplicity always gives 1. This is not the case for other replicated volumes, e.g. G4PVReplica, so I think this is a bug. By the way, the interface of G4VPhysicalVolume is messed up in this aspect. The IsReplicated method is pure virtual but GetMultiplicity is not pure, so concrete implementations are forced to define if they are replicated but not to define which is their multiplicity. If GetMultiplicity had been pure virtual then the bug I'm facing (assuming it is really a bug) would have been caught by the compiler.
Thanks for spotting this. The fix will be included in the next release/patches. I believe the original intention of the author was to intend the multiplicity of the divided volume itself, i.e. being then set to 1. But I agree it should be consistent with the fact that, although a special case, G4PVDivision is a parameterised volume at all effect, even if not inheriting from G4PVReplica or G4PVParameterised... therefore multiplicity should refer to the parameterised slice. The distinction in G4VPhysicalVolume for GetMultiplicity() not being pure virtual is intentional (i.e. no mess-up here).
