[G12] gsim feedback study

[Craig Bookwalter]

  For clarification:

"Incorrect number of tracks" == either too small (5 events with <3 
tracks) or too large (4 events with >3 tracks)

"much later time" == 200 ns later. I don't know why this happens unless 
it's something from multiple scattering. This happens maybe 15-20 % of 
the time, with the SCRC reconstruction screwing up the time for half of 
those occurences

What causes a given TOF paddle to not fire in GSIM? The real track could 
have hit the edge of a live paddle in real life and then GSIM nudged it 
into a dead paddle. I don't know if GSIM knows anything about 
efficiencies (I doubt it) but it could be a factor.

I'm not sure what you mean by "the TOF time must be consistent with 
PID". The tracks go in as they were measured, hits are created, and they 
we reconstruct them again. If you have a track close to the limit of 
what PID calls a pion, and it goes in and ends up with a slightly longer 
time-of-flight and a slightly lower momentum, it could be nudged into a 
different PID (or the no-pid-at-all region).

In truth I am just guessing. I have no idea why any of these things 
happen. Seems to me that a man could spend his life looking for answers 
in GSIM and he would die unfulfilled. Or he would emerge wild-haired and 
babbling, claiming to understand it but everyone would think he had just 
gone mad from staring for so long into the void...

Hopefully that answers your efficacy question.

Also, Paul said that something like this was done in g6c and 95% of 
events were reconstructed correctly.

--cb


Il 07/23/2010 02:45 PM, Dennis Weygand ha scritto:
> On Jul 23, 2010, at 8:34 AM, Craig Bookwalter wrote:
>
>>   g12ers,
>>      This is an update on the
>> taking-real-CLAS-data-and-feeding-it-through-GSIM study. I've fixed my
>> previous error with the vertex for events going into GSIM--they now go
>> into GSIM with the PART sector 0 vertex for each track set to the MVRT
>> vertex from the real data. I also correct by hand the ttag and tpho of
>> the input TAGR bank to the event vertex. I do not smear with GPP. These
>> changes combine to give only about a 10% return. Before the vertex fix I
>> was getting 4500/8100 events or so reconstructed, now I am getting about
>> 5300/8100. I looked at 50 events with bosdump and CED and found 20 out
>> of these 50 were not identified as p pi+ pi- events. From these 20, the
>> following problems were identified:
>>
>> * 9 events where an incorrect number of hit-based tracks were found.
>> This happens for various reasons--multiple scattering in the target
>> (most cases), or a lack of in-time DC hits (happened a few times), or a
>> lack of DC hits at all (happened a few times). Also, R1 hits seem to be
>> almost always marked as out-of-time by ced.
>
> An 'incorrect' number? Too small or too large?
>
>
>
>> * 5 events where a track struck the TOF with a reasonable time, but an
>> adjacent paddle was hit at a much later time, and the SCRC bank
>> reconstructs it into a "cluster" with some weighted average between
>> those two times. The average pulls the once-reasonable time of the
>> primary TOF hit up, resulting in pi's being cast adrift in the mass
>> region between pions and kaons (PID == 0) or shifted all the way to
>> being called K's. Protons get shifted into the deuteron region.
>
>
> How can GSIM ever ever ever get a paddle struck at 'a much later time'? Everything must be in-time, no? What exactly does 'much later' mean?
>
>
>
>> * 4 events with missing time-based tracks, usually because there is no
>> good TOF hit to associate with the track (ie the paddle didn't fire).
>
> What caused the TOF to be missed? Remember, these are 'real' events!!!
>
>
>> * 2 events where the TOF times were just too large to give the correct
>> PID--perhaps the track hits a dead paddle and produces a secondary that
>> fires the adjacent paddle.
>
> How did this happen??? The TOF time must be consistent with the pid!
>
>
>> Draw what conclusions ye will. I think it would be foolish to pursue
>> this 95% number without more information on the study that got this
>> number, ie what ffread cards were being passed to GSIM, whether or not
>> GPP was used and if so how, etc.
>
> What is the 95% number you are alluding to?
>
>> I welcome any comments.
>>
>> --cb
> Good work Craig, but right now it appears we are raising more questions than we are answering.
> Is there efficacy in putting accepted simulated events back into GSIM?
>
> Dennis
>
>
>
>> _______________________________________________
>> G12 mailing list
>> G12 at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/g12
> --
> Dennis Weygand
> weygand at jlab.org
> (757) 269-5926
>
>
>