TGeoManager destructor problem

ROOT
1

Hello,

I have a geometry with more than 100,000 volumes, when I try to quit root it is taking more than 2 minutes to return, because gGeoManager destructor gets busy.

Any idea why my gGeoManager destructor is so slow?
How can I optimize that?

Luciano

2

Hmm, 100K is a big number. Much too big for a detector geometry. In ALICE we have ~5K volumes for 4 million objects. Don’t you use replication ? What is the size in memory/file of this ? Can you send me the geometry file ?

Regards,

3

I dont use replication because I need to change visibility to each primitive depending if it has a hit or not.
I am using this geometry to visualize events in atlas calorimeters, so I want to visualize only cells with energy deposition.
I have tried replication once. The size file is 64 times smaller and the destructor execute faster, but when I change the visibility of one of the primitives, all the other for the same type get visible too.
I think the best approach would be to put a visibility state to each replica.
Do you know if it is possible to do that?

I am sending the macro to generate the geometry.

cheers,
Luciano
CaloBuild.C (22 KB)

4

OK, I remember the issue - this is obviously not the way to go when you have to describe 100 K volumes. There is no way to add any different attributes to replicas by definition: a replica is the same object but having a different matrix.

What you could do is to use polymarkers for your hits: when generating a hit you have access to the global matrix of the touched volume: just add a polymarker point in the origin of the local frame…

Regards,

5

I did not understand this polymaker thing.
Could you point me any documentation about that or explain in more details how to proceed?

How this approach will make replicas from the same primitive get different visibilities?

6

  1. Use replicas instead of defining separately each volume. You do not draw with a different color replicas - draw them all with the same color and make them transparent using TGeoVolume::SetTransparency(50)

  2. Create a polymarker: fPoly = new TPolyMarker3D(). Set it to your prefered color/style (see TPolyMarker3D class)

  3. During simulation, in the method that generates a hit:
    const Double_t *point = gGeoManager->GetCurrentPoint(); // current tracking point
    I don’t know if you have such a tracking point or how you access the “hit” volume. If not having such point you need at least the matrix of the current hit volume, then:
    Double_t local[3] = {0,0,0};
    Double_t point[3];
    matrix->LocalToMaster(local, point);

fPoly->SetNextPoint(point[0], point[1], point[2]);

  1. At the end, draw the polymarker on top of geometry:
    gGeoManager->GetTopVolume()->Draw()
    fPoly->Draw(“SAME”)

You will see just points for your hits, but at O(100K) you don’t want to see more details, believe me…

Good luck,

7

Thanks for the detailed explanation.

I see a big problem already: I DO need to draw the replicas with different colors. The colors depend on the energy deposited in each calorimeter cell (each primitive).

If I can not draw with different colors, I will keep the Geometry like that, without replicas.

Any other suggestion?

thanks again,
Luciano

8

You can define as many polymarkers as colors you need and draw them on top :
poly1->Draw(“SAME”); poly2->Draw(“SAME”), …