General Particle Source - Events outside of Max/Min Theta

Good day @All,

i modified the TestEm5 Example and integrated the GPS. I let electrons with a certain angle and energy hit an absorber. To make sure everything is as intendend i also record the energy and angle (theta) of the primary electrons. Strangely i found that the /maxtheta and /mintheta did’nt work as intended. In principle the distribution is there but <1% of all events are outside of the angular window i specified with matheta/mintheta.
In this example i used:
/gps/ang/mintheta 23.0739 deg
/gps/ang/maxtheta 28.3576 deg

And i recorded the primary events in TrackingAction.cc:

void TrackingAction::PreUserTrackingAction(const G4Track* aTrack )
{
  // few initialisations
  //
  if (aTrack->GetTrackID() == 1) {
    fXstartAbs = fDetector->GetxstartAbs();
    fXendAbs   = fDetector->GetxendAbs();
    fPrimaryCharge = aTrack->GetDefinition()->GetPDGCharge();
    fDirX = aTrack->GetMomentumDirection().x();
    fEnergy = aTrack->GetKineticEnergy();
    G4ThreeVector direction = aTrack->GetMomentumDirection();
    fTheta =(direction.x()/std::sqrt((direction.x()*direction.x())+(direction.y()*direction.y())+(direction.z()*direction.z())));
    G4AnalysisManager* analysisManager = G4AnalysisManager::Instance();
    analysisManager->FillH2(0,fTheta,fEnergy*1000000);  //energy over cos(theta) matrix
    analysisManager->FillH1(70,std::acos(fDirX));    //record angular distribution
  }
}

As you can see in the matrix enclosed and in the zoomed in histogramm, there are events outside of the specified angle range. Is the way i record the events somehow wrong or does the GPS actually produce an output like this? Strangely, all the events are within the specified energy range. So this seems to be okay.

Thanks for any hints where to find the problem here!



I put a circle around the outliers, since i am not sure they are visible otherwise.

Hello,

I haven’t had a close look at the full code you posted but on top of checking the trackID being 1 (correctly a primary) you might want to check that it is indeed the first step of the track.

aTrack->GetCurrentStepNumber() == 1

I can only assume that is the case since it happens in the PreUserTrackingAction but one never know. It could be something.

Also, Given that G4ThreeVector is ultimately a CLHEP::Hep3Vector I think you have access to methods like getPhi() so you do not have to do it yourself.

… my two cents …

Hello,

thank for the helpful hints. I looked deeper into this and checked the following:
1.) Primary Particle is in Step 0
2.) Step 0 is in World Volume not inside the Absorber

if(tet_deg>28.3576 || tet_deg<23.0739) G4cout << "Angle Exception in PreUserTracking: " << tet_deg << " TrackID: " << aTrack->GetTrackID() << " Step Number PreUserTracking: " <<aTrack->GetCurrentStepNumber() << " Definition: " << aTrack->GetDefinition() << " Volume:" <<  aTrack->GetVolume()->GetName() << " StepLength: " << aTrack->GetStepLength() / CLHEP::mm << G4endl;

The angle is specified as above:

/gps/ang/mintheta 23.0739 deg
/gps/ang/maxtheta 28.3576 deg

If there is a deviation from the specified angle it produces the following Output:

Angle Exception in PreUserTracking: 33.1364 TrackID: 1 Step Number PreUserTracking: 0 Definition: 0x55b76d8f2110 Volume:World StepLength: 0

The interesting thing is, this does not seem too happen with a single thread but only with multi threads and the number of particles outside of the specified angle scales with the number of threads.
I tested with 100000 primary events, number of primary events outside of the specified angle:
Single Thread: 0
8 Threads: 4
48 Threads: 29
96 Threads: 54

For any tipps how to further diagnose this problem i would be thankful!

Best wishes,
Marco