key4hep / k4GeneratorsConfig

0 stars 1 forks source link

Photon process #13

Open dirkzerwas opened 2 months ago

dirkzerwas commented 2 months ago

Hi @apricePhy,

I added PhotonProduction to the examples for Sherpa and gave Babayaga a try (runs awkwardly).

One thing I noticed:

Babayaga provides an lhe file, but the line for cross sections is empty, I will check with Fulvio if he knows,.....

There is a problem in the definition of the finalstate for whizard.py:

dirkzerwas commented 2 months ago

After some work on the Selectors (need to add units and a conversion from deg->rad->eta etc:

Photon91.0 sqrts= 91: Madgraph 51.941 +- 0.027225 pb Babayaga 0 +- 0 pb Sherpa 52.1944 +- 0.00260813 pb

Correcting by had the .sin for whizard: Whizard: 51.9975302 +- 0.0890507272 pb

Running by hand Babayaga (with the script): ::::::>>>>>> weighted events <<<<<<:::::: 2 photons: 8.31194160 +- 0.19358241 ( 16.9165 %) 3 photons: 40.82313177 +- 1.12056181 ( 83.0835 %) total: 49.13507337 +- 1.10691870 pb

Not bad, I would say :)

-> it could be that only the "unweighted" cross section is transmitted to LHE, however even requesting only 100 events unweighted (changed as the only parameter) leads to a minutes long processing without result.

I will check with Fulvio?

apricePhy commented 2 months ago

Hi @dirkzerwas,

Regarding the choice of deg or rad, I would follow the experimental convention i.e if they set the resolution of the detector in degrees we use degrees. I am not aware if this is universal though between the experiments. I would vote for radians and if people complain we can always add an option to specify

dirkzerwas commented 2 months ago

Hi @apricePhy,

sounds good in LHC world it's eta, in ALEPH it was degrees in analysis (mostly for 180. and avoiding to rounding effects due to pi in analyses), but also rad for the angular acceptance of forward lumi-cals.

I tried to do something (see main branch) for angles: -> if "deg", "rad" or "eta" (the last does not have a unit) -> at object creation all three alternatives are calculated and saved as attribute "min"+"unit" (mineta, mindeg, minrad) -> get_Min gets an optional argument (default), so that min+unit is returned, either the original or the derived ones. -> I adapted it through in the "one_particle_selector"

I have used it in Whizard, Madgraph, Babyaga to ensure a consistent setting according to the generator (Babayaga needs degrees, Whizard accepts degrees, but the default is rad, so we would need to write out the unit as well, breaking the nice logic you implemented. Could you have a look?

One thing I noticed: current the "name" in the selector class is the process name, it could be helpful to add the name of the selector key (currently not transmitted), then it is easier to steer the unit (eg if "selector name == theta or rap or pseudorapidity or..... do the "deg,rad,eta" conversion. Just a thought....

Dirk

Hi @dirkzerwas,

Regarding the choice of deg or rad, I would follow the experimental convention i.e if they set the resolution of the detector in degrees we use degrees. I am not aware if this is universal though between the experiments. I would vote for radians and if people complain we can always add an option to specify

dirkzerwas commented 2 months ago

Carlo provided an upgrade to Babayaga to write the cross section to the LHEF. The two files are now in the hands of Gerri and Juan to update the KEY4HEP version. Once it's in the nightlies and we have checked, we can close this issue.

dirkzerwas commented 1 month ago

Juan implemented Carlo's changes, the fix works (tested on alma). Rounding issue: need to implement a fixed format in conversions f16.8 (inspired by SLHA)