Separating interaction and pixel data within the same events

Simulation / Configuration Questions
1

Hi everyone… I’m back :grinning:

Now that the simulation seems to be working, and I do seem to get reasonable induced currents, see figure below, I am wondering about the specifics about the storage of the data.

Induced current example
Induced current example1977×1198 25.7 KB

As far as I can understand, since I am firing xrays and have number_of_particles = 1 in [DepositionGeant4], every event contains one particle, which can interact several times within the sensor volume. What I am interested in is the following:

  • the induced current curve (and subsequently the total induced charge to get the interaction energy)
  • interaction position
  • interaction type
    for each interaction as well as for each event.

The part for each event is fairly simple and I can use the PixelCharge object to get the total induced charge, induced current curve (given PropagatedCharge is included in [ROOTObjectWriter]), and pixel index. And for the interaction position (and interaction type?) I guess I should be able to use the MCTrack object.

But is there any way to get the same data for each individual interaction within each event?
That is, if the xray first interacts with a Compton interaction and then gets absorbed in a photoelectric interaction, can I get the desired data above separated for the two interactions?

I should add that the pulse information is not necessary all the time, and the induced total charge, interaction position, and interaction type should suffice most of the time.

Again, thank you for any help!

Best,
Rickard

2

Hi @rickard ,

I hope that I understand this correctly. If so, I’d argue yes, filtering information is possible.

From any PropagatedCharge object, you can dive through the history and e.g. query the process type. To do so, you can call e.g. …
prop_charge->getMCParticle()->getTrack()->getCreationProcessName() to obtain this information. You can also get the starting point of this particle similarly, using the method getStartPoint() of the MCTrack object.

The filtered pulse you could indeed still restore by obtaining the individual pulses of the propagated charge objects and superimposing them.

I hope this helps!

Cheers
Paul

3

Hi @pschutze,

Thank you for the reply!

I see, I also came up with the same solution, I had just hoped there was a way to not have to store all pulse objects. But then I know what I need to do there!

Thanks,
Rickard

4

Yeah, I’m afraid this becomes a bit “expensive” in terms of storage indeed, but separating these properties “online” would create quite an overhead for serving a very specific (though interesting!) study…
I hope this works for you, I think it’s the most straight forward and generic way.

Cheers
Paul

5

It should work, though my ssd might get upset!

All the best,
Rickard