G4Tet with G4VPVParameterisation in 10.6

Evan-de · 2019-12-10T08:50:22.584Z

Hello.
I am handling about 8 million tetrahedrons in my detector construction class.
Until Geant4 10.5, the tetrahedrons have placed by G4PVParameterised class.

However, I found that this approach does not allowed in 10.6 with the error as below:

--------- EEEE -------- G4Exception-START ------- EEEE -------
*** G4Exception : GeomSolids0001
issued by : G4Tet::ComputeDimensions()
G4Tet does not support Parameterisation.
*** Fatal Exception *** core dump ***
**** Track information is not available at this moment
**** Step information is not available at this moment
--------- EEEE ---------- G4Exception-END ------- EEEE -------

From this, I also found that the source code of G4Tet.cc has been modified.
At 10.5, G4Tet::ComputeDimensions() function had no functionality.
void G4Tet::ComputeDimensions(G4VPVParameterisation* , const G4int , const G4VPhysicalVolume* )
{
}
On the other hand, at 10.6, G4Tet::ComputeDimensions() function generates a fatal error without any functionality.
void G4Tet::ComputeDimensions(G4VPVParameterisation* , const G4int , const G4VPhysicalVolume* )
{
G4Exception(“G4Tet::ComputeDimensions()”, “GeomSolids0001”, FatalException, “G4Tet does not support Parameterisation.”);
}

I cannot find any related notice in realese note.

I do know I can use loop statements with G4PVPlacement, but it took two-three times overhead compared to use of G4PVParameterised in memory usage and geometry initialization time (tested in 10.5).

Does it have problems to use G4Tet with G4VPVParameterisation?
If so, what is the alternative method to place a number of tetrahedrons?

gcosmo · 2019-12-10T09:09:42.743Z

Hi, can you please file a problem report:
https://bugzilla-geant4.kek.jp/enter_bug.cgi?product=Geant4
for this, so it can be properly tracked?
Thanks.

allison · 2019-12-10T10:31:11.150Z

I have found there can be huge speed penalties with parameterised volumes, especially if scoring. I mean huge - like a factor 1,000. Have you made a run comparison? I would take the memory and initialisation penalties of G4PVPlacement.

allison · 2019-12-10T13:43:52.642Z

Sorry if my post was alarmist. It refers to a specific use case involving primitive scorers that is nothing to do with parameterisation of volumes as such. G4PVParameterised is an excellent way to go with a large number of volumes, for example implementing a 3D meshing of a volume with G4Tet which are parameterised by material… as it is the use case for most
medical applications on phantoms.

Evan-de · 2019-12-12T04:01:24.266Z

Thanks for the advice.

I compared the simulation time in G4 v10.5.
My code includes 8 million G4Tets, and all of the G4Tets-based logical volumes have sensitivity (inherited class of G4VPrimitiveScorer).

The results are as below:
Condition

CPU: Intel Xeon E5-2650 @2.00GHz
Threads used: 10 (w/o hyper-threading)
OS: CentOS7

G4Tet with Parameterisation

initialization time: 150 s
run time (1e7 primaries): 103s

G4Tet with Placement

initialization time: 4367 s
run time (1e7 primaries): 175s

At least for my case, I should use Param.

evc · 2020-01-13T10:05:22.036Z

Hi, a new version of G4Tet has just been merged to the master of the gitlab repository. Could you take new G4Tet.hh and G4Tet.cc and re-run your code with them. We are interested to compare the performance. Thank you in advance!