[G12] gsim feedback study

Fri Jul 23 12:32:39 EDT 2010

HI, Craig,

For this study, did you turn off decay and multiple scattering? If you do 
not set the ffread card keys DCAY and MULS to be 0, they are set to 1 by 
default. In this 
study that you put real data back to gsim, these two needs to be OFF (0). 
Also, depends on how you get the data 4 vectors, i.e., with or without 
eloss and momentum correction, you also might need to turn eloss (KEY is 
LOSS) off.

I think your study is very important. It can be used to identify many 
potential pitfalls.

As for the previous study, I belive many people have done similar studies. 
In particular, Matt bellis did a very comprehensive one, and I will try to 
locate one of his talk or note. At this point, 5300 out of 8000 seems way 
too small. Even the 95% paul is quoting seems low compared with what I 
rememeber. When it was first done, it was quite a big deal, concluding 
that the GSIM is very trustworthy.

I'm sure what you are doing will be saving you and everybody else a lot of 
future headache had you not been doing this.

Cheers!

Lei

**************************************
        @
       /    *
      /  ___  ___  Lei Guo      ________________________
      L_ O _/ ____ Los Alamos National Lab _________ /_/
        \ |        MS H846, B112      /             / /
      /  \|        Los Alamos, NM 87545            / /
     / I_/ \  ____ USA _____/_______/_____________/ /
    / /     L      /       /       /             / /
   / /            /       /       /             / /
  /_/____________/_______/_______/_____________/_/
/_/____________/_______/_______/_____________/_/
505-665-2618(o)

**************************************

On Fri, 23 Jul 2010, Craig Bookwalter wrote:

>  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
>>
>>
>>
>
> _______________________________________________
> G12 mailing list
> G12 at jlab.org
> https://mailman.jlab.org/mailman/listinfo/g12
>