search

eic / afterburner

Monte Carlo Afterburner for Crossing Angle and Beam Effects
0 stars 1 forks source link

Add option to persist particles at different stages of the afterburner #12

Open simonge opened 7 months ago

simonge commented 7 months ago

Following on from the discussion from @ajentsch in the ePIC Physics, Software, and Computing Discussion it sounds like there is a desire to be able to keep truth MC particles and particles which have all beam effects other than the crossing angle applied in the input HepMC3 file.

HepMC Table 5 has particle status codes 11-200 available for generator use. So for instance,

4,14,24 for beam particles 1,11,21 for final state particles

could be used where 10 is added for MC truth and 20 for beam divergence effects.

A flag could be used to turn this on/off. At very least this could be used to easily verify the proposed "post-burner" in EICrecon.

DraTeots commented 7 months ago

Do I undrstand correctly, that what you want is to copy all beam and final state particles at their vertexes prior to applying beam effects and store them with custom codes (like 14 and 11 in your example)?

A bit of a problem I am seeing here is that we should not only care about 4 and 1 codes as depending on generators in the very general case we have to care about everything to keep HepMC event consistent and openable. HepMC presents event as a connected graph. Unfortunately, if you break the structure of the graph in a non intended by HepMC way (with ZERO documentation about it) you may have problems. When something is broken that way, HepMC may save the resulting event without any warnings, but eventually one would have problem reading the event or, what is even worse, it will be read, but particles and vertexes will not match with what was written.

DraTeots commented 7 months ago

Maybe @kkauder can comment on this as I know he had also pretty extensive experience on HepMC and its pitfalls.

DraTeots commented 7 months ago

If we assume that we shouldn't break the graph and copy everything. Hm... Adding 100 may look more natural. Having 100 as unstable particle, 101 as stable, 104 as beam etc.

kkauder commented 7 months ago

Simon actually suggested exactly what I had suggested at the reconstruction meeting :) Including the number 10 to add. Great minds and all that. I'll say, if we go this route, let's brainstorm just a tad bit more to see if there's anything else we'd like to encode in this number. All generators I'm aware of stay well below 100, so something like orig + 10 + 100 * (some code) + 10000 * (some other code) could work. Could allow something like identifying background sources without having to use the vertex status code

kkauder commented 7 months ago

Oh, and yes, 100 as the base offset is better and more easily interpreted. Thinking a bit more about my previous comment, 1000+ may or may not work. It's not legal HepMC-wise, but may work anyway. Best not to depend on it though and if we want to encode more, make a less readable but legal construction that squeezes status codes somewhere below 200

simonge commented 7 months ago

Simon actually suggested exactly what I had suggested at the reconstruction meeting :) Including the number 10 to add. Great minds and all that.

Not a coincidence, just decided to write the github issue before you!

We will have to develop tests alongside this to make sure it works as expected for various generators and maybe request some changes to the HepMC code too.