restG4: no energy deposition

RestG4
1

Hello,

I’m running restG4 for the simulation of µp elastics w/ p detected in an hydrogen-filled TPC.
I successfully ran the simulation on a simplified setup.
Now I’m trying to use a detailed description, in gdml form, of the TPC.
Problem: as told in the title of this ticket, energy deposit is zero, see (excerpted for restG4 stdout, same for all 10 events in my simulation):

Event Deposited energy in sensitive volume:  0

Has anybody an idea about the reason for this?
My guess is that my sensitive volume turns out to not sit on the path of the particles. This,
event though I proceed just as before w/ my simplified geometry.
Then how can I check this? Or any other possible explanation you can think of…

Yann

2

Hi Yann,

could you share your RML file and geometry to reproduce the problem?

On the other hand, you may set your <TRestG4Metadata definition to veboseLevel="extreme">.

But the amount of output in this mode might need some polishing, adding few more output lines to get better hints.

3

Hello again,

I put my files both at cern

/afs/cern.ch/user/y/ybedfer/public/mup

and at Lyon:

/pbs/home/y/ybedfer/public/mup

I can add that the rml file must be OK: it’s an almost exact copy of the file which I used, successfully, on my simplified geometry.

I am trying extreme verbosity…

Yann

4

Hi,

I launched the simulation using your setup. It seems that the proton particle you launch does never deposit energy on the sensitive volume.

If the event does not deposit any energy on the “sensitive volume” it will not be registered at all. Even if the particle is going through an activeVolume.

I have just committed a fix on the extreme output message to v2.2.10_dev. Once updated I find the particle is only traveling through the volume h2_0.

If you define h2_0 as your sensitive volume the event will be registered, and hits on all the active volumes listed will be written to disk. Therefore, you also need to add h2_0 to your active volume list.

I imagine h2_0 is the volume where you are interested to register your hits.

5

Nice! That’s precisely what I was looking for… It’s available in v2.2.10_dev. Right?

I has understood that the sensitive volume is the named “gas”. Does not seem to be correct. Anyway “gas” is indeed the volume I want to be sensitive.

6

In fact, I have the following in my rml file:

    <storage sensitiveVolume="gas">
      <parameter name="energyRange" value="(0,1000)MeV" />
      <activeVolume name="gas" chance="1" />
    </storage>

From from I concluded that “gas” is indeed my active volume.
Or is there a distinction between “active” and “sensitive” volumes?

7

The sensitive volume is the trigger volume in the sense that the event will be stored only if an energy deposit took place on that volume.

However, no hits will be stored unless you specify activeVolumes. Therefore, activeVolume is/are the volumes where you will be registering G4hits (x,y,z,En,pcs,volId). Only 1 sensitive volume is allowed, but any number of activeVolumes can be added.

Perhaps there is a problem of overlap? When I open the geometry using TGeoManager it looks like gasVolume is inside h2.

TGeoManager *geo = TGeoManager::Import("Setup_World.gdml");
geo->GetVolume("gasVolume")->Draw("ogl");
geo->GetVolume("h2")->Draw("same");

The following <storage> section does the job, although not sure if that is what it should be.

    <storage sensitiveVolume="h2_0">
      <parameter name="energyRange" value="(0,1000)MeV" />
      <activeVolume name="h2_0" chance="1" />
    </storage>

Note that the lectures are a bit old. There was a limitation in fact, the sensitive volume had to be named “gas”, but now there is no limitation to use any volume in the geometry as sensitive volume.

9

Yes, it is available at v2.2.10_dev. It is only a minor output fix, by error it was not printing out the extreme message.

10

OK. I found the error: a stupid unit (cm instead of mm) mistake while setting the input point in the specification of the generator.

Btw, concerning the GL viewer:

In fact, when you Draw(“same”), you superimpose the volume that you successively draw in the local reference frame => everything turns out to be occupying the same range of space…

Thanks for your help. Extreme debugging is very useful…

1 Like