This topic relates to how we handle simulated events embedded into zerobias events.

For pile-up effects studies, one assumes a zerobias event is near all pileup. The embedded event can then be placed in and reconstructed as if we would reconstruct a normal event. Possibly, a beamLine cnstraints may exists.

In the below (embedding request You do not have access to view this node), we clearly see the resolution of the vertex in Z (actually as input with VSIG) and a shifted X,Y vertex (Z=0) with possibly associated resolution in both dimension (gaussian) due to the use of the beamLine constraint option in reconstruction.

Furthermore, we also see in the plots below that the line of the beam is tilted (i.e. not aligned with STAR's geometry) in Vx,Vz consistent with the above pictures. The spread along that line is constant.

What embedder do is to parametrize this and get a random position (throwing a random pick, from gaussian and a parametrized line, etc ...) and re-injecting this as a x,y,z vertex position to Geant for one job. BUT

1. A more consistent approach would be to allow starsim / geant to accept such standard parametrization and move the event within the same chain (hence making a more uniform sampling than what is done now)
2. Well ... is what is being done really consistent with what happens?
   • Ideally, the geometry is miss-aligned
   • If we chose the approach to "move" the event, isn't it true that the event should also be rotated according to the slope Vx,Vz?

Proposed:

For now to at least implement the parametrization of the vertex along a beamLine. General flow: leave the VTRIG and posiiton in Z, pick a Z as before, get the X,Y posiiton based on the parametrization of VX/VZ (slope in the 3rd plot) and VY,VZ (4th plot) with some gaussian smearing in both dimension. Use parametrized (+smeared) new X,Y,Z for the vertex poisiton. This will be no worst than what is done now and help embedders in consolidating their workflow into a one pass.