[Rivet] Rivet beta experience?

Andy Buckley andy.buckley at cern.ch
Wed Dec 14 11:51:02 GMT 2016


Hi Felix,

That's fantastic, thanks! I didn't have time to get this one into the 
release that we just made, but it will be in the next one. No time 
limits at all -- we're happy to have anything, anytime ;-) I'll let you 
know if I spot any "above threshold" style issues, or ways that you can 
do things more easily.

Thanks again and merry Christmas!
Andy


On 09/12/16 21:46, Riehn, Felix (IKP) wrote:
> Hi Andy, Hi Rivet developers,
>
> sorry for the delay. Had to deal with the aftermath of the MPI workshop.
> If I recall correctly all the Rivet features for FT work nicely.
> Concerning the analyses we will gladly share them.
> I attached one analysis from EHS/NA22 that I would consider complete, in
> the sense that .plot and .info file contain useful information.
> For the others we would need some time to complete. Is there a time limit.
> Also, please let me know if there are issues with style, coding
> conventions etc.
>
> Cheers, felix
>
>
> On 11/30/2016 07:36 AM, Andy Buckley wrote:
>> Hi again Felix and Tanguy,
>>
>> A long time since we've been in touch, but I was wondering if you've
>> sorted out the issues you were having with nucleon beam definitions
>> and if the "new" (not so new anymore!) Rivet features we added are now
>> working for you?
>>
>> You had mentioned that you have analyses which could be usefully added
>> to the "official" Rivet collection. We'd be *very* grateful to receive
>> these -- please let us know if there's anything we can help with. I've
>> CC'd the rest of the Rivet developers now, to give better support and
>> a wider range of expertise than I can provide individually!
>>
>> Best wishes,
>> Andy
>>
>>
>> On 30/05/16 16:02, Riehn, Felix (IKP) wrote:
>>> Hi,
>>> concerning the definition of nuclear momentum: in the tool we use to
>>> generate hepmc files the input of beam momenta are interpreted as
>>> per-nucleon.
>>> The configuration that is put into the hepmc file is per-nucleus so A
>>> times the input momentum. In between there are various boosts between
>>> the frames performed during one of which the wrong masses / beta is
>>> used. This then leads to the deviation from zero momentum even if the
>>> input was nucleon at rest. So it is not a problem in rivet..
>>>
>>> the definition of asqrtS on the other hand is.
>>> The definition I find is:
>>>
>>>   double asqrtS(const FourMomentum& pa, const FourMomentum& pb)
>>> {
>>>
>>>     const static double MNUCLEON = 939*MeV; //< nominal nucleon
>>> mass
>>>
>>>     return sqrtS(pa, pb) / (pa.mass()/MNUCLEON +
>>> pb.mass()/MNUCLEON);
>>>
>>>   }
>>>
>>> This does not work if the four momentum is pa= (A*Ea , A*vecPa)
>>> I have to admit that I can't see when this ever works, since it does not
>>> reduce to sqrtS when called with protons.
>>>
>>> sqrtS(pa, pb) / (pa.mass()/MNUCLEON *** pb.mass()/MNUCLEON)
>>>
>>> approximately works if mass is neglected.
>>>
>>> The definition that would work for the definition of nuclear momenta in
>>> our case is
>>>
>>> sqrtS(pa / pa.mass()/MNUCLEON , pb /** pb.mass()/MNUCLEON ).
>>>
>>> concerning the boost routine:
>>> "using the per-nucleon momenta in the boost expression rather than the
>>> actual beam particle momenta? That can be done, as a complement to the
>>> asqrtS() function"
>>>
>>> that is exactly what we need. In addition a routine going from CM to Lab
>>> would be great. It could be defined through the existing cmsBoost
>>> routine via
>>> -cmsBoost(pa, 0. ).
>>>
>>> Cheers,
>>> felix
>>>
>>>
>>> On 05/27/2016 04:30 PM, Andy Buckley wrote:
>>>> Hi again,
>>>>
>>>> Apologies for the silence -- it's exam-marking time in addition to the
>>>> usual things taking up my time!
>>>>
>>>> First, I think you're right that we should discuss the definition of
>>>> nucleus 4-momentum. The definition that I used for the boost beta
>>>> factor was this, from src/Projections/Beam.cc:
>>>>
>>>>   Vector3 cmsBoost(const FourMomentum& pa, const FourMomentum& pb) {
>>>>     Vector3 rtn = (pa.p3() + pb.p3()) / (pa.E() + pb.E());
>>>>     return rtn;
>>>>   }
>>>>
>>>> The Particle::E() calls on the denominator include the mass,
>>>> obviously, so I'm assuming that the whole nucleus is given as the beam
>>>> particle: is that correct? If only a nucleon is given as the beam,
>>>> then we get a boost with the wrong mass factor. Is that what's going
>>>> wrong for you?
>>>>
>>>> By the way, is my new asqrtS() function giving you the correct
>>>> per-nucleon sqrts?
>>>>
>>>> Secondly, the precision of the boost. Agreed that beta is not a nice
>>>> variable to parameterise that... but while gamma would be far more
>>>> stable I'm not sure how to calculate it without encountering the same
>>>> instablity as involved in beta. The boost definition above is beta =
>>>> (|p|_a + |p|_b) / (E_a + E_b), so is very close to 1 -- dangerously so
>>>> from a floating-point perspective. But unless I'm missing something
>>>> obvious -- fully possible! -- expressing gamma from the same
>>>> quantities just introduces more numerical problems: gamma =
>>>> 1/sqrt(1-beta^2). Do you know of a numerically safe expansion for
>>>> large boost factors, or ideally applicable everywhere? A bit of Google
>>>> searching has not found anything particularly obvious for me, but this
>>>> feels like it should be a standard problem with standard solution!
>>>>
>>>> Cheers,
>>>> Andy
>>>>
>>>>
>>>>
>>>> On 18/05/16 09:18, Riehn, Felix (IKP) wrote:
>>>>> Hello Andy, Hi Tanguy,
>>>>>
>>>>> I hacked the 'CM boost problem' by resetting the target momentum
>>>>> (second
>>>>> beam) in the analysis to (m_nuc, 0,0,0).
>>>>> After this the boost to CM is correct and the analysis gives the same
>>>>> results as before.
>>>>> I guess now we have to discuss the definition of the 4momentum of a
>>>>> nucleus.
>>>>>
>>>>> What worries me a bit is that the z component of the intial
>>>>> momentum is
>>>>> also wrong or at least the 'zero' is large.
>>>>>
>>>>> Rivet.Analysis.TPC_2006_I694016: INFO  original target 4momentum in
>>>>> Lab:
>>>>> (11.2671; 0, 0, 0.00769471)
>>>>>
>>>>> Its a bit much for precision loss.
>>>>>
>>>>> Here is the same for a p-p:
>>>>> Rivet.Analysis.TPC_2006_I694016: INFO  original target 4momentum in
>>>>> Lab:
>>>>> (0.93828; 0, 0, -1.34795e-07)
>>>>>
>>>>> Apart from this, is there any other new feature I should test?
>>>>>
>>>>> Cheers,
>>>>> felix
>>>>>
>>>>> On 05/17/2016 09:35 PM, Pierog, Tanguy (IKP) wrote:
>>>>>>        Hi Andy,
>>>>>>
>>>>>>          My colleague Felix (CC) had some problems trying the new
>>>>>> Rivet features. He is the one who has some real experience for the
>>>>>> moment so probably you should see with him directly. Here is his
>>>>>> email :
>>>>>> "The formula in principle should be good. Only two problems:
>>>>>> 1) it shows they boost with beta, which is not very stable. but ok.
>>>>>> 2) It has the same problem with nuclei as sqrtS :D
>>>>>> at least in the definition in CRMC, i.e. p_A = A*p_lab
>>>>>> I adjusted the NA49 analysis to use the new features et voilà, it
>>>>>> fails
>>>>>> for p-C :)
>>>>>> Curiously I still have not found the actual definition in the
>>>>>> rivet-src
>>>>>> so I could not try fixing it."
>>>>>>
>>>>>> thanks and cheers
>>>>>>
>>>>>> Tanguy
>>>>>>
>>>>>>
>>>>>> ________________________________________
>>>>>> De : Andy Buckley <andy.buckley at cern.ch>
>>>>>> Envoyé : jeudi 12 mai 2016 16:15
>>>>>> À : Pierog, Tanguy (IKP)
>>>>>> Objet : Rivet beta experience?
>>>>>>
>>>>>> Hi Tanguy,
>>>>>>
>>>>>> Did you and your colleagues get a chance to try out the new Rivet 2.5
>>>>>> beta yet? I hope the new features are convenient enough for what you
>>>>>> need -- let me know either way.
>>>>>>
>>>>>> And please also let me know if I derived the right formula for the
>>>>>> general beam-boost with different types of incoming particle -- it
>>>>>> would
>>>>>> be embarrassing to put out a full release with a dumb arithmetic
>>>>>> error!
>>>>>> For beams (Ep, p) and (Eq, q), I calculated that the centre-of-mass
>>>>>> boost should be beta = (p+q) / (Ep + Eq), which looks convincing and
>>>>>> has
>>>>>> the right scaling behaviours... but it's worth checking for
>>>>>> consistency
>>>>>> with what you have been doing.
>>>>>>
>>>>>> Cheers,
>>>>>> Andy
>>>>>>
>>>>>> --
>>>>>> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
>>>>>> Particle Physics Expt Group, University of Glasgow
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow


More information about the Rivet mailing list