We are currently working on the missing channel simulation. We want to reconstruct the missing hits and missing channels in cut strips, but we are not able to locate the missing channels in the 2D track events. For instance, a 2D hit has only XZ coordinates but in the readout plane, we have many modules in the same X, so we can never tell which certain channel does this hit come from. However, we know the channelID and moduleID in signal events but throw such information in SignalToHits Process by using TRestHitsEvent::AddHit method. We guess there’s some method to modify the TRestHitsEvent and TRestTrackEvent to keep such information, which will make it possible to locate the cut strip in 2D tracks. Furthermore, it may help with the track reconstruction, especially when the angle between the readout plane and the track is small since we can distinguish two hits who are close in XZ but from two distant modules.
Yes, somehow you fully lose the Y-information of an XZ-hit when applying the actual SignalToHits transformation. This is because inside the TRestHits structure (X,Y,Z,Energy) the value of Y will be assigned to a value of NaN (i.e. Not A Number) in the actual SignalToHits processing.
In the SignalToHits when we assign NaN to the Y-component, is not true that the value is completely undetermined. In fact, we could attribute the Y-component of every XZ-hit the value of the center of the module. That way, we restrict the space where the Y-hit is placed to Ymodule_center ± Ymodele_size/2.
Before, assigning NaN to a component was used to identify if the hit was XZ, YZ, XY, etc.
Now, it seems that if fType is different of unknown it will do the job. Not sure when fType is assigned, but I imagine it was introduced by @nkx.
In summary, I believe updating the SignalToHitsProcess to assign the center of the module when the coordinate is NaN, and assigning the value of fType in TRestHits would be the solution, to avoid updating the structure of TRestHits.
fType is introduced in order to improve the performance of TRestHits::areXY()/areXZ()/areYZ()/areXYZ(). It is auto assigned in those methods and not saved to event data. I agree that we can change the logic, i.e., assign fType value during SignalToHitsProcess. This will make it possible to keep Y information in an XZ event. Then we also need to add three additional data: fXPrecision, fYPrecision, fZPrecision. For example in an XZ event, Y is the module center Y, fYPrecision is half the module size.
The only thing is I imagine we should assign fType to every hit? Since in a TRestHitsEent both XZ and YZ hits may live together.
I understand the point, but should not be doing that to overload too much the Hits structure (in size)? This information could be after all extracted from the TRestReadout definition.
So, what is the strategy now? If a coordinate X (or Y) is undetermined it will get the value of the centre of the module position? Then, we will use GetType to identify the coordinate is actually just undetermined inside the module?
Yes, as in TRestSignalToHitsProcess. “undetermined” means that TRestReadoutPlane::GetX/GetY is returning nan value.
No, we don’t use GetType in any data processes. For TRestHitsToSignalProcess, it was used to convert geant4 data, so it is not influenced. For track analysis processes, they were using TRestTrack::isXZ/isYZ to identify the type before reading the coordinates, so GetType is not used either.
