[G12] gsim feedback study
Craig Bookwalter
craigb at jlab.org
Mon Jul 26 08:53:13 EDT 2010
I ran this again with DCAY and MULS set to 0 and got about 200 more events
back. The 50-event sample I'm using now carries 11 incorrectly
reconstructed events, a significantly better fraction than the ratio for
the overall sample. Now the breakdown in the sample is the following:
* 5 events where hit-based tracking fails. Two of these events failed
during the last pass, two are brand-new failures, and one event previously
had the SCRC clustering problem and now has a HBT problem. I am using the
RNDM card to seed the random number generator, so these comparisons are
valid.
* 2 events where GSIM registers hits in multiple paddles in the TOF
although the real data has only a single hit (in the SCRC bank, at least).
These distributed hits have larger times than the real data, resulting in
bad PID (one pi- to a K-, and one pi- to an antiproton).
* 2 events where GSIM does not create a hit in the TOF where there ought
to be one, and thus time-based tracking fails for that track.
* One event where TBT fails completely and independently of the TOF (this
event has been lost in all previous passes as well).
* One event where the SCRC clustering algorithm screws up the time such
that a good track is assigned a PID of 0.
I have a couple of generally unfounded suspicions:
- Somehow the thing that creates mulitple hits in adjacent paddles in the
TOF needs to be turned off. The real data does not contain this garbage,
at least at the SCRC level, which has already (supposedly) gathered
associated hits into clusters.
- Something is wrong with the magnetic field. Regarding the two events
where GSIM gets the TOF time wrong, the following occurs:
* in the first event, the TOF hit in the real data is in paddle 7,
whereas in the GSIM data it is in paddle 6.
* in the other event, the TOF hit in the real data is in paddle 11,
where in GSIM data it is distributed between paddles 9, 10, and 11,
with most of the energy in paddle 9.
If the magnetic field was a bit too strong in GSIM, it could pull
these hits down into the lower angles (both of these tracks were pi-).
However, all of the failed hit-based tracks were for positive
particles, and I'm basing these conclusions off of two events, so it's
not worth much. I double-checked and I am running with a MAGSCALE of
0.500 and with the "-ct1930" option to a1c, which I believe is the
correct pairing.
I remain open to suggestions.
--cb
> 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
>
More information about the G12
mailing list