[Rivet] Rivet beta experience?

[Andy Buckley]

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