[G12] versions of mc tools

[mpaolone at jlab.org]

Paul,

I still think we're not on the same page.  If my thinking is flawed then
your thinking is also flawed, because I've agreed with everything you've
said on this; except for the "not worry and gamble" part, I never
suggested anything of the sort!  The worry I have goes beyond WHAT version
of a1c we are using into WHY that version is different than the current
one, and what to do about it.

To clarify what I'm thinking:

1) If the current a1c and pass1 a1c produce indistinguishable cooking
results it doesn't matter which one you use for cooking MC (of course, you
have to check the two versions against each other to know this).

2) If there is a difference between the two a1c's which is large enough to
significantly affect publishable results, we should investigate where the
difference comes from, and then we should discuss whether to use:
   a) pass1-a1c cooked data with pass1-a1c cooked MC.
   b) current-a1c cooked data with current-a1c cooked MC.

And of course we should keep a tagged version of the code we use to cook,
so we can always reproduce our results in the future.  Anyway, I'm
cluttering up the g12 email list and not really answering Craig's original
question.  If you still think this is a bad approach and my thinking is
flawed, we can discuss it during the next g12 meeting.

-Michael



> 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
>>>
>>
>>
>