[clas12_rgk] draft of response letter to CCC from run group K
burkert
burkert at jlab.org
Sat Oct 27 14:47:24 EDT 2018
Francois, Maxime, and folks,
There is no question that running everything in one run period with a
perfectly understood detector would be ideal, in principle. But that is
just not going to happen unless we want to wait until after the year
202x (x=3, 4,..?). There is just no way of scheduling 100 PAC days for
RG-K or 140 PAC days for RG-A in one string. The best realistic option
will be to run RG-K in 2 periods with two different energies. That means
we still have to understand the systematic for the two energies
independently as we will be taking data year(s) apart, and the detector
performance will have changed, background will be different, etc.,etc.
(Knowing that I ask why everyone agreed to use the 28 days of RG-K (now
down to 18days) at these two odd energies. Noone forced us to do it, we
could have just sat these 4 weeks out. )
Now we should make best use of this opportunity to better define our
running conditions, triggers, etc,. and this is what we is currently
going on. In my view these few days are actually not lost time for RG-K.
If we can take at least some decent amount of data at two different
energies, and under very similar detector condition, we may be able to
test the systematics under these close to ideal conditions.
All the best,
Volker
On 10/27/18 10:36 AM, mdefurne wrote:
>
> Dear Volker,
>
> I could not agree more with F-X again. Although we indeed consider
> going for an unbinned analysis for the current RG-A, I am absolutely
> no expert yet to know how robust it is with merging two data sets with
> different beam energy: But I sincerely doubt that it can be completely
> blind. Moreover it is the very purpose of this proposal to study the
> beam energy dependence: Increasing systematics on the beam energy that
> will give us the largest lever arm with the 10.6 GeV data is taking a
> terrible risk. I stand with F-X to argue that the very success of our
> proposal lies on our control of systematics. Therefore it is our duty
> as spokesperson of this proposal to stand against this splitting of
> our data taking resulting most likely in the highest source of
> systematic uncertainty (if we split the data taking).
>
> Kind regards,
>
> Maxime
>
> On 27/10/2018 01:04, Francois-Xavier Girod wrote:
>> Dear Volker
>>
>> I completely agree with this suggestion. We did some tests in the
>> past with event by event likelihood. Assigning negative likelihood to
>> background events we were able to cross check asymmetries. It would
>> be even better to do this at the level of amplitudes and CFFs. This
>> is not something that can be demonstrated in a couple days however.
>> It will requires time to move in this direction.
>>
>> Nevertheless, even with the best possible analysis, it still remains
>> true that combining short amounts of data taken months or years apart
>> will be detrimental to our systematics. During our PAC presentation
>> we were challenged in our supposed aggressive estimation of
>> systematics, on the basis of the published systematics from e1dvcs.
>> It was always clear to me that we should aim to improve the
>> systematics we had in the past, and I think we have reasons to
>> believe we can do so. This public challenge in front of the PAC from
>> the very people in charge of scheduling now puts us naturally in a
>> position to be reluctant to agree to increased systematics. Our
>> proposal already has the most challenging analysis of the approved
>> exclusive program. I think our proposal deserves to be scheduled in
>> full and not as convenience to fill in between other experiments.
>>
>> Best regards
>> FX
>>
>> On Fri, Oct 26, 2018 at 6:42 PM burkert <burkert at jlab.org
>> <mailto:burkert at jlab.org>> wrote:
>>
>> Hi Maxime,
>>
>> I can understand that if we keep working with binned data sets
>> that changing the energy can create such issues. However, is this
>> the way we want to continue, instead of moving towards non-binned
>> data analysis, which I think will not have these same issues and
>> allows more flexibility in the final physics analysis? We should
>> explore this possibility more.
>>
>> Volker
>>
>>
>>
>> On 10/26/18 12:03 PM, mdefurne wrote:
>>>
>>> Dear Volker,
>>>
>>> I completely agree with F-X about the recommendation of keeping
>>> the beam energy as stable as possible. And I agree that
>>> combining this two "data set" might significantly increase the
>>> systematics. This kind of exercise is extremely complicated and
>>> the final results tends to be extremely sensitive to the overall
>>> systematics. (You can trust me on this for having done it in
>>> Hall A and it was with a much simpler experimental setup.)
>>>
>>> Kind regards,
>>>
>>> Maxime
>>>
>>> On 25/10/2018 19:37, Francois-Xavier Girod wrote:
>>>> Dear Volker
>>>>
>>>> The DVCS group has some experience combining datasets at 6.75
>>>> and 6.88 GeV. It does actually require caution and should be
>>>> evaluated carefully before stating that we can accept such
>>>> differences of 100 MeV or more. The issue is not simply that
>>>> the cross-section changes, which can affect the real part of
>>>> the amplitude, but the issue is also that the kinematics
>>>> change. Q2 is not the same in xB and theta bins. Of course we
>>>> can attempt to correct for this by changing the binning in
>>>> theta to keep Q2 fixed, but then we also change xB... And in
>>>> the end, even if we somehow manage to keep xB and Q2 both
>>>> fixed, we will still have a change in epsilon which enters the
>>>> Rosenbluth separation when combining beam enegies.
>>>>
>>>> In writing our proposal we do not have strong constraints on
>>>> the absolute beam energy, but we do have an expectation that
>>>> the energy will be fixed at better than the MeV level.
>>>> Combining beam energies as far as 100 MeV will for certain
>>>> affect our systematical uncertainties. If we really have to
>>>> work with this, then we must do our homework and put a number
>>>> on this. I do not think it is a straightforward exercise however.
>>>>
>>>> Best regards
>>>> FX
>>>>
>>>> On Thu, Oct 25, 2018 at 1:15 PM burkert <burkert at jlab.org
>>>> <mailto:burkert at jlab.org>> wrote:
>>>>
>>>> All,
>>>>
>>>> I agree with intention of the text. However, I suggest to
>>>> downplay the 6.5 vs 6.4 GeV. I don't think it is such a big
>>>> deal and we have to deal with that later again as the
>>>> machine energy will never be exactly the same as in
>>>> previous run periods. We have to learn how to deal with
>>>> slight energy variations in an effective way.
>>>>
>>>> Typo: In the next to last paragraph please delete the first
>>>> "during" in the string " during as soon as possible during
>>>> the November RG..
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On 10/25/18 7:41 AM, Annalisa D'Angelo wrote:
>>>>> Dear All,
>>>>>
>>>>> after last RGK meeting, some additional thinking and
>>>>> exchange of information with Raffaella, I have put
>>>>> together a draft letter to answer the CCC request
>>>>> information, which you may find at:
>>>>>
>>>>> https://userweb.jlab.org/~annalisa/hybrid_baryons/RGK_response_to_CCC.docx
>>>>> <https://userweb.jlab.org/%7Eannalisa/hybrid_baryons/RGK_response_to_CCC.docx>
>>>>>
>>>>>
>>>>> In a nut shell I would like to propose that the new
>>>>> trigger requiring a central hadron could be implemented
>>>>> and commissioned as soon as possible during RGA, not to
>>>>> loose time during our assigned RGK data taking. RGA could
>>>>> take all the Spring data taking in return.
>>>>>
>>>>> This would optimize the overall efficiency.
>>>>>
>>>>> Please let me know your opinion on the matter.
>>>>>
>>>>> Any comment/correction/suggestion is highly appreciated
>>>>>
>>>>> All the best
>>>>>
>>>>> Annalisa
>>>>>
>>>>> p.s. we may discuss the matter tomorrow at the RGK weekly
>>>>> meeting.
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> clas12_rgk mailing list
>>>> clas12_rgk at jlab.org <mailto:clas12_rgk at jlab.org>
>>>> https://mailman.jlab.org/mailman/listinfo/clas12_rgk
>>>>
>>>>
>>>> _______________________________________________
>>>> clas12_rgk mailing list
>>>> clas12_rgk at jlab.org <mailto:clas12_rgk at jlab.org>
>>>> https://mailman.jlab.org/mailman/listinfo/clas12_rgk
>>>
>>>
>>> _______________________________________________
>>> clas12_rgk mailing list
>>> clas12_rgk at jlab.org <mailto:clas12_rgk at jlab.org>
>>> https://mailman.jlab.org/mailman/listinfo/clas12_rgk
>>
>>
>> _______________________________________________
>> clas12_rgk mailing list
>> clas12_rgk at jlab.org <mailto:clas12_rgk at jlab.org>
>> https://mailman.jlab.org/mailman/listinfo/clas12_rgk
>>
>>
>> _______________________________________________
>> clas12_rgk mailing list
>> clas12_rgk at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/clas12_rgk
>
>
> _______________________________________________
> clas12_rgk mailing list
> clas12_rgk at jlab.org
> https://mailman.jlab.org/mailman/listinfo/clas12_rgk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/clas12_rgk/attachments/20181027/8116380b/attachment-0001.html>
More information about the clas12_rgk
mailing list