LDMX-Software
Add plots to EcalDigiVerify that checks positions
Is your feature request related to a problem? Please describe.
How to ensure that the GDML description on the Ecal is the same as the reconstructed positions?
Describe the solution you'd like
I'd like to add plots to EcalDigiVerify that compares simhit z vs rechit / digi z, and possibly with the other coordinates too. This could be a 2D histo, similar to what we already do with the energies.
We also have to agree what it means to have simhit position in x,y since there will be several hits. If we had the merging this would be obvious, but for now maybe just take the average x,y (or energy weighted avg)? I expect the z to be an easier case
Describe alternatives you've considered
I could also imagine residuals (simhit z - rechit z) vs layer plots, that certainly makes the binning easier. And then do the same for (simhit x - rechit x) vs layer plots and (simhit y - rechit y) vs layer plots.
So, we actually won't see a difference between sim and rec hit z positions even if there is a difference between the GDML and EcalGeometry.
https://github.com/LDMX-Software/ldmx-sw/blob/34d43a553320a549b81a9dd30f31ab7c826a0d93/SimCore/src/SimCore/SDs/EcalSD.cxx#L79-L110
EcalGeometry is used to "condense" the simulated hit positions in Geant4 into the cells and then the sim hit positions are just the center of the cell according to EcalGeometry. To be very clear, we do currently have merging. Its just complicated and not very helpful.
https://github.com/LDMX-Software/ldmx-sw/blob/34d43a553320a549b81a9dd30f31ab7c826a0d93/SimCore/src/SimCore/SDs/EcalSD.cxx#L120-L134
Description here: https://ldmx-software.github.io/using/sim/resim.html#no-merging-of-ecal-simulated-hits
I need to digest this a bit more, are you saying that it doesnt actually matter what's in the GDML, if the GDML has z =10 but the geometry has z = 12, it (the simhit [as well as the rechit]) will always be at z = 12? If that's true does that mean that we have some part of the shower lost in the simhit to rechit transition?
So the good news is that I'm very confident we are not losing hits.
The bad news is that we are choosing to use the EcalGeometry definition so if the GDML has z=10 and EcalGeometry has z=12, the entire pipeline after Geant4 will use z=12 even though Geant4 is using z=10. This is probably why we have never observed this GDML-EcalGeometry divergence since its effectively as if our ECal software model is misaligned along z with the "true detector" (in this case Geant4's model).
@tomeichlersmith can you give me the historic reasoning on why we wouldn't just have
G4ThreeVector position = 0.5 * (prePoint->GetPosition() + postPoint->GetPosition());
hit.setPosition(position[0], position[1], position[2]);
it's even in the comments "It would probably help us more if we persisted the actual simulated position of the hit rather than the cell center; however, that is up for more discussion."
So maybe it's time to have that discussion again? I feel like it would make more sense to have the real position saved and then the rechits are the reconstructed position
(I can also make a separate issue about this)
Let's continue this in https://github.com/LDMX-Software/ldmx-sw/issues/1484
As you mention, we have to choose a position. Even the "simple" case you give then opens the door to the question of which Geant4 hit do we use to define the position of our merged hit.
Instead of making a choice, we just said
The cells are small enough, let's just use the cell center since it is within 3ish mm of all the Geant4 contributors.
I genuinely think the position within a cell is not important enough to persist (we can never observe it in real data), but the blame information (what caused a hit?) is (while it isn't observable in real data, it is very helpful for studying the physics of a sim). This is why I've never really bothered with thinking of fancier merging techniques for the position.