Strange Particle Definitions in Hit Collection

[LEley22]

Hi!

I’ve implemented a method to extract particle definitions of particles in my hit collections, but they are coming out slightly strange. Some of them are coming out as null pointers, and when I add the check:

if (particleType == opticalphoton)

defining both particleType and opticalphoton as the corresponding particle definitions, it acts as if there are no optical photons but as my system is using a scintillator and producing photons I can see when I use the UI, I’m certain there are optical photons hitting the detector that the hit collection is attached to. Am I missing something about particle definitions in hit collections?

[mkelsey]

That line is in the same job execution as when you fill the hit collection in the first place? You’re not trying to write pointers to an output file (I hope!)?

Storing the const G4ParticleDefinition* in your hit data object should be perfectly fine. I do it in my own simulation. But you can’t save the pointer to a data file. If you want to do an offline analysis of your HitCollection, you should save the particle name (particleType->GetParticleName()) to the output n-tuple.

[LEley22]

Haha, thankfully not! I’m accessing the hit collection and looping through hits, and using my GetParticle function for each as below, and then trying to use the equality (though not shown in the snippet below, I’ve defined my opticalphoton definition). Is there anything clearly wrong here - I’m brand new to getting my head around hit collections!

void SensitiveDetector::EndOfEvent(G4HCofThisEvent*) {

		G4int nofHits = fHitsCollection->entries();
for (G4int i = 0; i < nofHits; i++){
		MyHit* hit = static_cast<MyHit*>((*fHitsCollection)[i]);
		G4ParticleDefinition* particleType = hit->GetParticle();
etc..

[LEley22]

For reference, this is what the particle defs print as which I think look weird? And trying to access PIDs/names using type->GetParticleName(); for example causes a seg fault so its just a bit strange!

[mkelsey]

You’re printing the pointer values, which I think are probably reasonable. There’s no way for you to interpret them as a human – those are the addresses in memory where the G4ParticleDefinition instances are stored. The low numbered ones (like 0x10f011fa0) are the basic particles which G4 instantiates on the master thread. The others (0x3000…) are per-thread pointers, which are typically G4Ions that get created on the fly.

In your code, one thing you can do is test whether the pointer is null, with a statement like

  if (particleType)
    G4cout << " Got particle  " << particleType->GetParticleName() << G4endl;
  else
    G4cerr << " AUGH!  particleType is null!" << G4endl;

Beyond that, run in your debugger, and see what the variables contain when it segfaults.

[mkelsey]

Some basic things to check: In your MyHit class, does your constructor explicitly initialize all of the data member to zero (good practice!)?

Are you sure that all of the data members (including particleType) get filled with valid quantities each time one of them is created?

Do you ever delete one of your MyHit objects in your own code (you shouldn’t, they become owned by the HitsCollection when you register them)?

[LEley22]

Hi!

Thank you for all your help - it turns out I had 2 different references to particle type (one being a null pointer!) and this was causing the issue. All your comments have been super helpful & I think I have a good understanding of hits collections now, thank you again

Lauryn