Add plots to EcalDigiVerify that checks positions

[tvami]

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.

[tomeichlersmith]

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.

ldmx-sw/SimCore/src/SimCore/SDs/EcalSD.cxx

Lines 79 to 110 in 34d43a5

	// fastest, but need to trust module number between GDML and EcalGeometry
	// match
	ldmx::EcalID id =
	geometry.getID(position[0], position[1], layerNumber, module_position);
	// medium, only need to trust z-layer positions in GDML and EcalGeometry match
	// helpful for debugging any issues where transverse position is not
	// matching between the GDML and EcalGeometry
	// ldmx::EcalID id = geometry.getID(position[0], position[1], layerNumber);
	// slowest, completely rely on EcalGeometry
	// this is helpful for validating the EcalGeometry implementation and
	// configuration since this will be called with any hit position that
	// is inside of the configured SD volumes from Geant4's point of view
	// ldmx::EcalID id = geometry.getID(position[0], position[1], position[2]);
	if (hits_.find(id) == hits_.end()) {
	// hit in empty cell
	auto& hit = hits_[id];
	hit.setID(id.raw());
	/**
	* convert position to center of cell position
	*
	* This is the behavior that has been done in the past,
	* although it is completely redundant with the ID information
	* already deduced. 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.
	*/
	auto [x, y, z] = geometry.getPosition(id);
	hit.setPosition(x, y, z);
	}

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.

ldmx-sw/SimCore/src/SimCore/SDs/EcalSD.cxx

Lines 120 to 134 in 34d43a5

	if (enableHitContribs_) {
	int contrib_i = hit.findContribIndex(track_id, pdg);
	if (compressHitContribs_ and contrib_i != -1) {
	hit.updateContrib(contrib_i, edep, time);
	} else {
	hit.addContrib(getTrackMap().findIncident(track_id), track_id, pdg, edep,
	time);
	}
	} else {
	// no hit contribs and hit already exists
	hit.setEdep(hit.getEdep() + edep);
	if (time < hit.getTime() or hit.getTime() == 0) {
	hit.setTime(time);
	}
	}

Description here: https://ldmx-software.github.io/using/sim/resim.html#no-merging-of-ecal-simulated-hits

[tvami]

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?

[tomeichlersmith]

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).

[tvami]

@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]);

[tvami]

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

[tvami]

(I can also make a separate issue about this)

[tvami]

(I can also make a separate issue about this)

Let's continue this in #1484

[tomeichlersmith]

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.