RootLogicalVolume with Garfield/Geant4 interface

[Khalil_Alashy]

Hello,

I am working on Garfield and Geant4 Interface. I am defining a bunch of Air Cylinders enclosed in a slab of PlexiGlass. I am adding the logicVolume of the Air Cylinders as the RootLogicalVolume, and looping over the physical volume of the air cylinders to write it to the GDML file. The problem is when I do this, the initial positions that GarfieldPhysics gets from the DoIt() function are very wrong. When I simplify the geometry to let’s say a slab of air, it works perfectly and it takes the correct initial coordinates. What I want is for the code to not consider any protons that pass through the PlexiGlass. I can do that in the GarfieldPhysics class where I define initial SolidTube but I’d rather figure out how to add the appropriate G4LogicalVolume and G4PVPlacement to regionGarfield and GarfieldG4FastSimulationModel so it can know the right geometry.

Here is the part of the code for DetectorConstruction. If there is no proper way to point correctly to the Cylinders and ignore the PlexiGlass, I’ll just create SolidTube in GarfieldPhysics. I have attached a picture of the geometry. The Cylinders are the active region.

    G4Material* shape2_mat = nist->FindOrBuildMaterial("G4_PLEXIGLASS");
    G4ThreeVector pos2 = G4ThreeVector(0, 0, 0);
    
    // Trapezoid shape
    G4double shape2_XY = 0.5* 5.2*cm;
    G4double shape2_Z =0.5*2*mm;
    
    G4Box* solidShape2 = new G4Box("Shape2", shape2_XY,shape2_Z,shape2_XY);
    auto logicShape2 = new G4LogicalVolume(solidShape2,  // its solid
                                                       shape2_mat,  // its material
                                                       "Shape2"); // its name

    auto physShape2 = new G4PVPlacement(nullptr,  // no rotation
                      pos2,                     // at position
                      logicShape2,              // its logical volume
                      "Shape2",                 // its name
                        logicEnv,                 // its mother  volume
                      false,                    // no boolean operation
                      1,                        // copy number
                      checkOverlaps);           // overlaps checking

    G4double nbTubes =  8;
    G4double width = 0.65;
    G4cout << "The width is: " << width << G4endl;
    G4Material* air = nist->FindOrBuildMaterial("G4_AIR");

    G4double innerRadius = 0.0*cm ;
    G4double outerRadius = 0.25*0.65 *cm;
    G4double hz = 0.5 * 0.8 * cm;
    G4double startAngle = 0.0 * deg;
    G4double spanningAngle = 360.0 * deg;

    G4Tubs* airCylinder = new G4Tubs("AirCylinder",
                                     innerRadius,
                                     outerRadius,
                                     0.11*cm,
                                     startAngle,
                                     spanningAngle);
    
    auto logicCylinder = new G4LogicalVolume(airCylinder,air,"AirCylinder");
    G4RotationMatrix* rotm  = new G4RotationMatrix();
    rotm->rotateX(-90*deg);
    std::vector<G4PVPlacement*> physCylinders;
    for (int j=0; j<nbTubes; j++) {
        for (int i=0; i<nbTubes; i++) {
            auto physCylinder = new G4PVPlacement(rotm,
                                                  G4ThreeVector((-2.6+width/2.0 + i*width)*cm,
                                                                0,(-2.6+width/2.0+ j*width)*cm),
                                                  logicCylinder,
                                                  "AirCylinder",
                                                  logicShape2,
                                                  false,
                                                  j+i*nbTubes,
                                                  checkOverlaps);
            physCylinders.push_back(physCylinder);
        }
    }
    
  G4Region* regionGarfield = new G4Region("RegionGarfield");
  regionGarfield->AddRootLogicalVolume(logicCylinder);

  fGarfieldG4FastSimulationModel = new GarfieldG4FastSimulationModel(
      "GarfieldG4FastSimulationModel", regionGarfield);

    for (auto& physCylinder : physCylinders) {
        fGarfieldG4FastSimulationModel->WriteGeometryToGDML(physCylinder);
    }
    

[devajith]

Hello @Khalil_Alashy,

Pinging @hschindl

Cheers,
Devajith

[hschindl]

Hi,
sorry for the late reply! I’m not 100% sure I understand the question (sorry, it’s been a while since I’ve looked into the G4/Garfield interface example). In what sense are the positions wrong?
Are the air cylinders drift tubes? And you are using ComponentAnalyticField to compute the electric field in the tube? In ComponentAnalyticField, the tube is along the z axis and entered at (x, y) = (0, 0). You’ll have to make sure that the local coordinates you pass to the DoIt function of GarfieldPhysics are consistent with this coordinate system.

[Khalil_Alashy]

Hello, thank you for the reply.
The thing is, I don’t define the tubes in GarfieldPhysics. I define them as G4Tubs in DetectorConstruction, Then I send a random beam. If the particle enters in one of the G4Tubs, i.e. in the ROOTLogicalVolume assigned to regionGarfield, GarfieldPhysics::DoIt() is called a proton at that specific location of the G4Tub is sent by TrackHeed. The problem is when I assign the RootLogicalVolume to regionGarfield and loop over the physical volume to write it to the GDML file, I get inconsistencies in the initial position outputted in GarfieldPhysics::DoIt function to start a new track via TrackHeed. When I simplify the geometry and make just a slab of air and omit the G4Tubs in DetectorConstruction, the initial positions are identical to that of PrimaryGenerationAction, which is the correct one.
Concerning COmponentAnalyticField, I lay the tubs oriented along the Y-Axis so I can place a Pixel on PlaneY. And the beam goes through the y-axis as well.

Since the post, I was able to define the tubes as a SolidTube in GarfieldPhysics and that seemed to work well. And the logicalvolume, I assigned the mother volume of the plexiglass enclosure as the regionGarfield and GDML geometry. It is weird but it worked well, super slow but works for now. I just wanted to ask if there is a better logic in assigning the RootLogicalVolume to regionGarfield and the physical volume to the GDML file to avoid getting errors in initial location in the GarfieldPhysics::DoIt function. It is redundant, to define the Tubes twice but it works well.
Hope that makes it clear.

[hschindl]

Sorry, I’m still a bit confused… Whether you define a tube as SolidTube in the function GarfieldPhysics or not should not affect the G4 part of the code. Are you referring to the coordinates that you pass to the DoIt function of GarfieldPhysics (i. e. the coordinates you are getting from G4) or some coordinates (e. g. of the drift electrons) inside the DoIt function?

[Khalil_Alashy]

Yes the coordinates that I get from GarfieldPhysics::DoIt() in this part:

void GarfieldPhysics::DoIt(std::string particleName, double ekin_MeV,
                           double time, double x_cm, double y_cm, double z_cm,
                           double dx, double dy, double dz) { ... }

Are not correct when I assign the air Cylinders in G4 as the root logical volume and physical volume to be written to the GDML file. Thus the coordinates that will be used for TrackHeed.NewTrak(…) will be wrong.
So for now I am adding the mother volume (the entire slab of Plexiglass) to the root logical volume and defining again the air cylinders in GarfieldPhysics::InitializePhysics(). It is redundant but works for now.