-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Precision in interface with FastJet #108
Comments
To be checked later, from the raw reconstructedParticle collection, sqrt(px^2+py&2+pz^2+m^2) does not match the energy for part of the collection. Could come from Delphes interface, needs some investigations
|
Salut Clément,
When you compute sqrt(RP_px^2+RP_py^2+RP_pz^2+RP_m^2-RP_e^2) instead of sqrt(RP_px^2+RP_py^2+RP_pz^2+RP_m^2)-RP_e, at least for the first two line, you obtain 0.139570 (i.e., the charged pion mass). It seems that RP_e = RP_p in DELPHES for all particles.
Patrick
On 20 Sep 2021, at 20:42, Clement Helsens ***@***.******@***.***>> wrote:
To be checked later, from the raw reconstructedParticle collection, sqrt(px^2+py&2+pz^2+m^2) does not match the energy for part of the collection. Could come from Delphes interface, needs some investigations
root [8] events->Scan("sqrt(RP_px^2+RP_py^2+RP_pz^2+RP_m^2):RP_e:sqrt(RP_px^2+RP_py^2+RP_pz^2+RP_m^2)-RP_e")
***********************************************************
* Row * Instance * sqrt(RP_p * RP_e * sqrt(RP_p *
***********************************************************
* 0 * 0 * 1.3572080 * 1.3500125 * 0.0071955 *
* 0 * 1 * 0.4067147 * 0.3820170 * 0.0246977 *
* 0 * 2 * 0.9756593 * 0.9656247 * 0.0100345 *
* 0 * 3 * 2.3657328 * 2.3616120 * 0.0041207 *
* 0 * 4 * 2.7254972 * 2.7219212 * 0.0035760 *
* 0 * 5 * 0.8448534 * 0.8332451 * 0.0116083 *
* 0 * 6 * 5.3700246 * 5.3682103 * 0.0018143 *
* 0 * 7 * 5.5412582 * 5.5395002 * 0.0017579 *
* 0 * 8 * 1.0097689 * 1.0000767 * 0.0096922 *
* 0 * 9 * 1.4921318 * 1.4855899 * 0.0065418 *
* 0 * 10 * 9.1755610 * 9.1744995 * 0.0010615 *
* 0 * 11 * 8.0808394 * 8.0796337 * 0.0012057 *
* 0 * 12 * 0.3990841 * 0.3738826 * 0.0252014 *
* 0 * 13 * 1.4127064 * 1.4127063 * 4.992e-08 *
* 0 * 14 * 1.1802264 * 1.1802263 * 6.909e-08 *
* 0 * 15 * 1.8873737 * 1.8873739 * -1.72e-07 *
* 0 * 16 * 0.8118204 * 0.8118203 * 2.433e-08 *
* 0 * 17 * 2.7451751 * 2.7451751 * 5.101e-08 *
* 0 * 18 * 1.1429564 * 1.1429565 * -1.19e-08 *
* 0 * 19 * 0.5041071 * 0.5041071 * -8.98e-09 *
* 0 * 20 * 7.8634692 * 7.8634691 * 1.190e-07 *
* 0 * 21 * 1.8220118 * 1.8220118 * 3.545e-09 *
* 0 * 22 * 2.0057414 * 2.0057413 * 4.370e-08 *
* 0 * 23 * 0.8879450 * 0.8879450 * -3.14e-08 *
* 0 * 24 * 0.9413895 * 0.9413895 * -5.87e-09 *
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#108 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABWI4QP45EO26446YL77UQLUC56BZANCNFSM5EMLUUNA>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
salut @pjanot , welcome back on github!
|
Much of the software uses floats. However FastJet uses doubles. Rounding errors can be non-negligible if one sends the float px,py,pz,E directly to FastJet (the problem is relevant mainly for the mass of PseudoJets). Better in communicating with FastJet to take the floats for px,py,pz,m, convert these to double, calculate E in double and then use the new double precision px,py,pz,E values to create the Pseudojets.
The communication to FastJet is illustrated in PR #107, though one might also want to think about how the two-way communication works.
The text was updated successfully, but these errors were encountered: