Message: Re: Scintillators array Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Feedback Re: Scintillators array 

Forum: Processes Involving Optical Photons
Re: Question Scintillators array
Re: Feedback Re: Scintillators array (Gumplinger Peter)
Re: None Re: Scintillators array
Date: 03 Jul, 2014
From: Gumplinger Peter <Gumplinger Peter>

> Ok. If I want to begin with only 3 detectors side-by-side without
> bothering with a bigger array, is it an efficient way to do it like this
> :
> G4Box* Crystal_box = new G4Box("Crystal",crystal_x,crystal_y,crystal_z);
> Crystal_logic = new G4LogicalVolume(Crystal_box,ScMaterial,"Crystal");
> for(G4int i=0; i<3; i++){
>    Crystal_phys = new G4PVPlacement(0,
>                                     G4ThreeVector(2.0*crystal_x*i,0,0),
>                                     Crystal_logic,
>                                     "Crystal",
>                                     expHall_logic,
>                                     false,
>                                     i);}
> and something similar for my sensitives photodetectors

No, this is not how I'd do it. You place your scintillator AND your sensitive photodetector's volume inside an (new) envelope - together - just like you did when you placed them inside the world-volume. You then use your above logic to place the envelope multiple time inside expHall_logic.

> construct arrays Crystal_phys[i] and PMT_phys[i] in order to keep track
> of which PMT was hit?

What you need to do is write a G4Hit class that keeps track of the copy-number at each geometry hierarchy level. In my scheme, the copy numbers of the deepest level when a sensitive volume is hit, will always be one, and so it is not very helpful. However, the copy number one level up, at the envelope-level, will have the copy number you need to destinguish which PMT was actually hit. You obtain this with, see:

In fact, you'd want to emulate what is done in this example:

> If I understand correctly, I have to define an air (or glue) gap at
> crystal/reflector interface to avoid short-cuts for
> dielectric_dielectric? Is an interface like this :
> | Crystal1 | Glue | Reflector | Reflector | Glue | Crystal2 |
> would be correct?

If you have reflector around and between crystals, then the crystals are not in optical contact. In that case, you can define a dielectric_metal or dielectric_dielectric (backpainted) surface for all of the crystal's surfaces except the one that has the PMT attached. In that case, the light sharing between crystals comes only from the EM shower when it's not contained to just one crystal.

(Also, in this case, simply ignore my caution about 'same material' because you definitely have to define a reflector (volume) or the 'painted' option.)

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 None: Re: Scintillators array   (Cab - 09 Jul, 2014)
(_ Feedback: Re: Scintillators array   (Gumplinger Peter - 09 Jul, 2014)
(_ None: Re: Scintillators array   (Cab - 11 Jul, 2014)
(_ More: Re: Scintillators array   (Gumplinger Peter - 11 Jul, 2014)
 Add Message Add Message
to: "Re: Scintillators array"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews