Does Geant4 Account for Internal Structures within a Sensitive Detector Volume?

Greetings,

I am currently working on a project involving the sterilisation of materials using X-ray and electron beam (e-beam) irradiation. As part of this study, I have constructed a sample target package comprising various materials (such as air, plastic, wood, and paper), resembling a typical heterogeneous shipment or product container.

To evaluate the energy deposition and absorbed dose within the package, I defined a cubic volume of air to serve as the mother volume, and designated this volume as a sensitive detector. The entire sample package—containing all the aforementioned materials—is placed entirely within this cubic air mother volume.

My question is the following:

When I retrieve the energy deposition and absorbed dose values associated with this mother volume (i.e., the cubic air volume designated as the sensitive detector), does Geant4 correctly account for the presence of the complex internal structure (i.e., the different materials of the sample target) within this volume? Or is the reported energy deposition only associated with interactions occurring within the air of the mother volume, ignoring what happens within the embedded materials?

I would appreciate clarification on whether Geant4’s sensitive detector mechanism in this context captures the full physical interactions within the contained geometries.


Basically this - the SD will only be triggered by steps in the LV to which it is attached. Steps in any daughter volumes of an LV are in separate LVs.

Thank you for your reply. I also think this is the case because when I shoot a 7 MeV electron in the package and all of it gets absorbed, I am supposed to get 7 MeV energy deposition, but I get a lower amount like 0.08 MeV. That because electron beam gets absorbed by the plastic materials I have in my package not the actual mother volume which is air.

Is there any simple and straight forward way to consider the whole package as sensitive detector by wrapping a virtual detector around it?

You can’t just make “the whole package” an SD.

  • If you don’t care where the absorption happens, maybe you want to use a simpler command-line (macro based) scorer instead?
  • You could attach an SD (even the same SD code, but you’ll have to extend it to record volume info!) to each volume in your geometry.
  • You could use SteppingAction instead of an SD, which gets called on every step, regardless of volume.

So, I preserved my previous SensitiveDetector codes but in my DetectorConstruction.cc, I did the following,

void DetectorConstruction::ConstructSDandField()
{
    SensitiveDetector *detector = new SensitiveDetector("Virtual Senstivive Detector");
    G4SDManager::GetSDMpointer()->AddNewDetector(detector);
//These are logical volumes elements inside of my package, I removed my mother volume container which was wrapped around it.
    sampleLogic->SetSensitiveDetector(detector);
    foamLogic  ->SetSensitiveDetector(detector);
    shellLogic ->SetSensitiveDetector(detector);
}

Below is my previous code,

void DetectorConstruction::ConstructSDandField()
{
    SensitiveDetector *detector = new SensitiveDetector("Virtual Senstivive Detector");
    G4SDManager::GetSDMpointer()->AddNewDetector(detector);
//This was the air mother volume wrapped around my package..
    containerLV->SetSensitiveDetector(detector);
}

So, as you see, I assigned all logical elements inside of my package instead of the mother volume container.

Now for a 7 MeV electron exiting from a titanium exit-window, I get a 6.5 MeV absorption which is reasonable. Now I just want to make sure, is this approach correct?

This will come down to preference. One thing to consider is that G4Regions can include any number of possibly dissimilar volumes including of dissimilar materials. So you could also include all the active elements in a “DetectorRegion” region (and exclude the container LV). Then in your sensitive detector you can check if you are in that region, being careful to handle the null case, and just return early if you are not.

Considering that your container is air it is unlikely you will get many interactions but that method above would do it and not require adding additional ntuple fields.

It’s not incorrect :slight_smile: Having the separate SD registrations very marginally increases CPU time, because the SteppingManager has to check the volume and pass the step into the (same) SD each time. With SteppingAction, you’d avoid that, but since it’s basically nothing but an if-call statement, it’s tiny compared to everything else going on.

One advantage to this construction is that if you decide, in the future, to have different SD’s (maybe storing different information) for each of your volumes, you already have the scaffolding in place.