[Clas_offline] more fun with GSIM

Thu Sep 2 12:27:34 EDT 2010

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/clas_offline/attachments/20100902/442f905b/attachment-0001.html 