[G12] versions of mc tools

[Paul Eugenio]

Mike,

Your thinking is still flawed.

Of course with a substantial fix in tracking, we would likely recook if justified.

But to say that because a1c pass 1 is near current now, we should not worry,  is gambling.  Like I stated, the current code is incompatible with the g11/g12 cooked data( but it was compatible then!!)   Folks will be processing g12 data for years to come.  The current tracking code will evolve.    
--
Paul Eugenio
Physics Department
Florida State University
Tallahassee, FL 32306


(850) 644-2585
eugenio at fsu.edu

On Jul 15, 2010, at 11:46 AM, mpaolone at jlab.org wrote:

> Paul,
> 
> I think you misunderstood.  If the change between the current and pass1
> a1c is only a matter of acceptance or recovering more events, then I agree
> completely that 10% is not worth recooking.  If the latest a1c is giving
> us a better tracking... and what I mean here is: if the reconstructed
> momentum, timing, and consequently the PID is 10% better, it would be
> completely unacceptable to publish pass1 cooked data that we know is just
> plain incorrect.
> 
> Now, I'm not saying that anything has changed in a1c to that effect.  I
> really don't know what reconstruction libraries have been changed, or if
> current-a1c reconstructed g12 data is different in any way from pass1.  I
> actually believe there is very little different between pass1 a1c and now.
> And like I tried to say in my prior email, if you cook your MC with pass1
> a1c and then again with the current a1c, and there is no real difference
> then why are we even worried about this?  If they are significantly
> different, I would like to know why, and if the differences would give us
> better g12 cooked data.  I personally think questioning if we are
> analyzing our data the best we can is never a bad approach.
> 
> -Michael
> 
> 
>> Mike,
>> 
>> This is clearly a bad approach.
>> 
>> CLAS software changes for the good and sometimes for the bad.  This was
>> clearly seen early on in the run, when we were fixing the tracking code.
>> We fixed a bug put in by g11/g10 which while wrong, went unnoticed.
>> Because we have the target back more, it was noticeable.   It would be
>> wrong for anyone analyzing g11/g10 data to use the current tracking code
>> without reprocessing all raw data too.  Would you reprocess all raw data
>> for a 10% improvement?  I would not, but I also don't want my acceptance
>> shifted by 10%.  So for g11, using the current code would be wrong.
>> 
>> 
>> --
>> Paul Eugenio
>> Physics Department
>> Florida State University
>> Tallahassee, FL 32306
>> 
>> 
>> (850) 644-2585
>> eugenio at fsu.edu
>> 
>> On Jul 15, 2010, at 9:31 AM, mpaolone at jlab.org wrote:
>> 
>>> Craig and everyone,
>>> 
>>> I'm looking at this the other other way.  We are still in the analysis
>>> stage, and if the current version of a1c is giving us a better
>>> reconstruction (occasional bugs aside, it should never be worse) than
>>> the pass1 a1c, then we should instead consider cooking another pass.
>>> Has a1c changed significantly since pass1?  Have we touched the detector
>>> libraries since then?  If there have been no significant changes that
>>> affect your analysis channel, then it should be fine to compare
>>> current-a1c cooked MC calculations with pass1-a1c reconstructed data.
>>> 
>>> -Michael
>>> 
>>> 
>>> 
>>>> g12ers,
>>>>    Last night I forgot to ask about which version of a1c one should
>>>> use when processing MC. I remember hearing that we should use the pass1
>>>> branch of the SVN repository so we're using the same code to cook real
>>>> data and MC data. However, do we want all MC-related tools to be built
>>>> from the pass1 branch, or just a1c? It seems strange to me to generate
>>>> detector responses with a GSIM linked against one version of detector
>>>> libraries and then reconstruct them with a1c linked against a different
>>>> version of the detector libraries. Perhaps all that matters is that the
>>>> detector libraries themselves are from pass1, since a1c mostly just
>>>> organizes input and output and sets up calls to those libraries. I have
>>>> no idea what GSIM might use the detector libraries for--I just know I
>>>> have to link them to get it to compile.
>>>> 
>>>> At present, ~clasg12/local/scripts/sample_gsim_desktop.sh uses tools
>>>> from the clas6 STABLE 32-bit build, which is not what was used for g12
>>>> pass1.
>>>> 
>>>> Any thoughts?
>>>> 
>>>> --cb
>>>> 
>>>> _______________________________________________
>>>> G12 mailing list
>>>> G12 at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/g12
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> G12 mailing list
>>> G12 at jlab.org
>>> https://mailman.jlab.org/mailman/listinfo/g12
>> 
> 
>