[Clas_offline] more fun with GSIM
Craig Bookwalter
craigb at jlab.org
Thu Sep 2 14:37:05 EDT 2010
Thanks to everyone for the input -- I found that the tracks that had no
DC hits were actually bouncing off of superstructure somewhere in the
detector. I turned off hadronic interactions (HADR 0 in the ffread file)
and recovered these tracks.
Another useful tidbit from Will Brooks -- GSIM writes out an MCEV bank
into the output data stream for each event, and this bank contains the
random seeds necessary to examine the event outside of the data stream.
Thanks again!
--cb
Maurik Holtrop wrote:
> Paul,
>
> I don't remember what it takes to "turn off all interactions", but
> that would indeed be what you would want to do. According to the
> FFREAD table, setting the following to 0 would turn off all (most?)
> physics.
>
> HADR 1 I IHADR hadronic process /GCPHYS/ 1
> LABS 1 I ILABS Cerenkov light absorbtion /GCPHYS/ 0
> LOSS 1 I ILOSS energy loss /GCPHYS/ 2
> MULS 1 I IMULS multiple scattering /GCPHYS/ 1
> MUNU 1 I IMUNU muon nuclear interaction /GCPHYS/ 1
> PAIR 1 I IPAIR pair production /GCPHYS/ 1
> PFIS 1 I IPFIS photofission /GCPHYS/ 0
> PHOT 1 I IPHOT photo electric effect /GCPHYS/ 1
> RAYL 1 I IRAYL Rayleigh scattering /GCPHYS/ 0
> STRA 1 I ISTRA energy fluctuation model /GCPHYS/ 0
> SYNC 1 I ISYNC synchrotron radiationgeneration /GCPHYS/ 0
>
>
> You can then test this by running some events through GSIM with the
> track debugging on: either "swit 3 1" or "swit 1 3" for two different
> style track debuggers.
>
> Best,
> Maurik
>
>
> On Sep 2, 2010, at 12:27 PM, Paul Eugenio wrote:
>
>> Dear Maurik,
>>
>> One issue we have is that we turned off all multiple scattering in
>> gsim, but it appears that some interactions remain. Do we need a
>> collection of gsim cards to turn off all interactions? If so, what
>> would they all be? I would hate to invest much time into this just
>> to find that "XXX" was our problem.
>>
>> Paul
>>
>>
>> --
>> Prof. Paul Eugenio
>> Florida State University
>> Department of Physics
>> Tallahassee, Florida, USA 32306
>>
>> (850) 644-2585
>> eugenio at fsu.edu <mailto:eugenio at fsu.edu>
>>
>>
>>
>> On Sep 2, 2010, at 11:57 AM, Maurik Holtrop wrote:
>>
>>> Dear Craig,
>>>
>>> You may need to take a closer look at the processes that are part of
>>> the GSIM run, which may tell you why that 1% of tracks is lost. It
>>> could very simply be one of the normal processes, such as multiple
>>> scattering in the target or any other part of the detector, that
>>> causes you to loose these tracks. Depending on the setting that you
>>> use for the simulation, I do quite agree with the statement: "since
>>> these tracks have already been detected by CLAS in real life, after
>>> passing through GSIM and reconstruction I should recover close to
>>> 100% of them. "
>>> This statement would only be correct for a geometrical acceptance,
>>> and not for one that includes multiple scattering, nuclear
>>> processes, and less than 100% efficient detector elements. Add to
>>> that a less than 100% efficient tracking algorithm ( due to
>>> smearing, timing fluctuations etc) and I can easily see a loss of 1%.
>>>
>>> How does the 99% efficiency of your GSIM run compare with the
>>> expected detector efficiency in the phase space you are studying?
>>>
>>> Best regards,
>>>
>>> Maurik
>>>
>>>
>>> On Sep 2, 2010, at 11:19 AM, Craig Bookwalter wrote:
>>>
>>>> GPP knocking out a track due to holes in the DC is a possibility,
>>>> except
>>>> for two things:
>>>> * I run gpp with a process flag of 0x20 which only processes the
>>>> tagger--there should be no DC efficiency stuff done.
>>>> * The events that I am feeding in were already detected by CLAS in
>>>> real
>>>> life, which means that if the track went through a DC hole in real
>>>> life,
>>>> it wouldn't be reconstructed and thus wouldn't be in my event sample.
>>>> And if the real-life track has been reconstructed, then it must not
>>>> have
>>>> gone through an area of low efficiency in the DC, and thus GPP should
>>>> not knock it out. Of course the efficiency map could be messed up in
>>>> this case as well. In any case, when I look at the GSIM output before
>>>> going into GPP, I don't see hits, so this isn't the problem...thank
>>>> you
>>>> though!!
>>>>
>>>>
>>>>
>>>> Zhiwen Zhao wrote:
>>>>> If you use gpp with DC efficiency ON, would some inefficient DC wires
>>>>> lose tracks?
>>>>>
>>>>> Zhiwen
>>>>>
>>>>> On 09/01/2010 04:53 PM, Craig Bookwalter wrote:
>>>>>
>>>>>> No problem man, this is a hard problem to explain. g12 had the target
>>>>>> centered at -90 cm, that's why the vertices are so far back. A better
>>>>>> way to understand it is with the pictures I attached--"input.png"
>>>>>> is an
>>>>>> event that goes in, and "output.png" is what it looks like after
>>>>>> going
>>>>>> through GSIM and a1c. As you can see, one of the tracks just
>>>>>> disappears,
>>>>>> GSIM generates no hits for it. Not sure how that happens.
>>>>>>
>>>>>> Kijun Park wrote:
>>>>>>
>>>>>>> Craig Bookwalter wrote:
>>>>>>>
>>>>>>>> I'm not clear on what you mean by trigger time--for MC the event
>>>>>>>> start time is always 0 minus the photon propogation time to the
>>>>>>>> event
>>>>>>>> vertex, and it's useful to keep it that way for debugging stuff
>>>>>>>> like
>>>>>>>> this. Along with times from the ST and and TOF, that is the
>>>>>>>> only time
>>>>>>>> I need for reconstruction. I think, at least.
>>>>>>>>
>>>>>>>> Kijun Park wrote:
>>>>>>>>
>>>>>>>>> Craig Bookwalter wrote:
>>>>>>>>>
>>>>>>>>>> Hi offliners,
>>>>>>>>>> I am in the middle of a study where I take real events from
>>>>>>>>>> reconstructed g12 data and feed those four-vectors back through
>>>>>>>>>> GSIM, with the hypothesis that since these tracks have
>>>>>>>>>> already been
>>>>>>>>>> detected by CLAS in real life, after passing through GSIM and
>>>>>>>>>> reconstruction I should recover close to 100% of them.
>>>>>>>>>> Currently I
>>>>>>>>>> am having a problem with GSIM not generating DC hits for some
>>>>>>>>>> tracks which pass through the DC volumes. When I look at these
>>>>>>>>>> events in gsim_int, I see that GSIM propogates them along strange
>>>>>>>>>> trajectories--strange because I have decays and multiple
>>>>>>>>>> scattering
>>>>>>>>>> turned off. I have a PART file with a few events exhibiting this
>>>>>>>>>> problem located here:
>>>>>>>>>>
>>>>>>>>>> /work/clas/clasg12/craigb/tmp/gsim_feedback/clas_offline/dc_no_hits.part
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Only the first seven events in this file are examples of what
>>>>>>>>>> I am
>>>>>>>>>> having trouble with; I had to add more events to the end to get
>>>>>>>>>> some BOS buffer to flush and actually write the events to file.
>>>>>>>>>>
>>>>>>>>>> Also, I created this file to try and get a concentrated sample of
>>>>>>>>>> my troublesome events, but now when I run my gsim script on this
>>>>>>>>>> file, some of them have successfully-generated hits, even
>>>>>>>>>> though I
>>>>>>>>>> have the RNDM card set. I am guessing this is because RNDM just
>>>>>>>>>> sets the random seed, which means changing an event's position
>>>>>>>>>> within a file changes your position within the random number
>>>>>>>>>> sequence. If there's a more intelligent/convenient way to share
>>>>>>>>>> this information with everyone, please let me know.
>>>>>>>>>> So in short, I would appreciate it if you all might take a
>>>>>>>>>> look at
>>>>>>>>>> this with me and offer any suggestions as to why GSIM would just
>>>>>>>>>> not produce DC hits for what looks like 1% of tracks. Also, if I
>>>>>>>>>> use the "NOSEC 'ALL'" card this no-DC-hits behavior is
>>>>>>>>>> enhanced by
>>>>>>>>>> a factor of 2 or so. Thanks in advance.
>>>>>>>>>>
>>>>>>>>>> --cb
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Hi Craig.
>>>>>>>>> I saw you didn't use the -T in your gpp. waht is the "trigbit:
>>>>>>>>> 0xffff" at HEAD bank in your dc_no_hits.gpp ?
>>>>>>>>> How do you know trigger time ?
>>>>>>>>> Kijun
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> Well, I thought your problem is out of scale of z-vertex (since I am
>>>>>>> not g12 guy) from you first seven event in that file.
>>>>>>> If not, could you point out your trouble from your file. Sorry for
>>>>>>> slow understanding.
>>>>>>> Kijun
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Clas_offline mailing list
>>>>>> Clas_offline at jlab.org <mailto:Clas_offline at jlab.org>
>>>>>> https://mailman.jlab.org/mailman/listinfo/clas_offline
>>>>>>
>>>>> _______________________________________________
>>>>> Clas_offline mailing list
>>>>> Clas_offline at jlab.org <mailto:Clas_offline at jlab.org>
>>>>> https://mailman.jlab.org/mailman/listinfo/clas_offline
>>>>>
>>>>
>>>>
>>>> --
>>>> -------------------------------------------------------------------------
>>>> Craig Bookwalter FSU Office: (850) 644 3808
>>>> Department of Physics JLab Office: (757) 269 5465
>>>> Florida State University craigb at hadron.physics.fsu.edu
>>>> <mailto:craigb at hadron.physics.fsu.edu>
>>>> Tallahasse, FL 32306 craigb at jlab.org <mailto:craigb at jlab.org>
>>>>
>>>>
>>>> "One toke? You poor fool. Just wait till you see those (expletive)
>>>> bats."
>>>> -------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Clas_offline mailing list
>>>> Clas_offline at jlab.org <mailto:Clas_offline at jlab.org>
>>>> https://mailman.jlab.org/mailman/listinfo/clas_offline
>>>
>>> _______________________________________________
>>> Clas_offline mailing list
>>> Clas_offline at jlab.org <mailto:Clas_offline at jlab.org>
>>> https://mailman.jlab.org/mailman/listinfo/clas_offline
>>
>
--
-------------------------------------------------------------------------
Craig Bookwalter FSU Office: (850) 644 3808
Department of Physics JLab Office: (757) 269 5465
Florida State University craigb at hadron.physics.fsu.edu
Tallahasse, FL 32306 craigb at jlab.org
"One toke? You poor fool. Just wait till you see those (expletive) bats."
-------------------------------------------------------------------------
More information about the Clas_offline
mailing list