[Halld-physics] new Bethe Heitler event generator

[Marie Boer]

Dear Richard, 

Thank you very much for providing your generator. 

However, I have several comments following your presentation on last
dilepton meeting when you explained its content: 

- Generating over a phase space weighted by the amplitude will have for
consequence that >99% of generated events will fall out of acceptance.
Indeed, BH angular distributions present sharp peaks (terms ∝ ~1/m_e^2).
Next to these limits, either the electron or positron is emitted through
the beam direction, and thus fall out of acceptance, while the other
lepton will not pass momentum threshold of calorimeter. The difficulty
here, is that cross sections are over 2 order of magnitude larger, when
not more, than in other regions. It is therefore important to maximize
the number of generated events in regions where we can make the
measurement and have physics interpretations. Some solutions are to
generate flat in theta and phi (my solution, adapted for BH or  BH+TCS
studies) or flat in cos(theta) and phi (Rafo's solution, ideal for TCS
studies). A completly flat phase space present advantages for the
normalization and for studies involving polarization. For unpolarized
cross sections, alternatively, log(Q'2) and log(t) can be generated to
take account the steep  decrease in these variables. But after trying
that, I decided not to do so, and my public version is completly flat in
all 5 or 6 variables.On his side, Rafo is reweighting the phase space
after calculating t_min which makes the generation of t distribution a
bit faster.
Of course, if the goal is to perform theory calculations, it may worth
that number of generated events follow  the cross section, but I don't
think it is the goal here, and there are already models and published
articles with these studies for reference. 

- Phase space cuts have to be applied, for all above reasons, but also
for numeric treatment of the process.
m_e is very small compared to the scale of the problem, which is
actually a minor issue after cuts (and can be neglected). But even after
applying angular cuts, the numerical precision is important in the
region next to t_min (majority of events). Double vs float precision can
already completly mess the results next to t_min. A good solution to
this problem is using interpolations at generator level.

- Additional phase space cuts will certainly need to be applied after
systematic studies comparing to the      data. I refer for that to DVCS
studies in other experiments. Also, we need to talk to specialists for
questions related to higher order corrections which may be important in
this energy range.

- I am not sure to well understand your notations, but for leading twist
dilepton photoproduction, the M--      amplitude is the dominant one. 

- TCS diagrams should not be included for performing fits of BH cross
sections.This process is at its earlier studies on experimental side and
has never been measured (the 2 diagram we call BH has not been measured
either, it makes me also worry about the relevance of using it for
normalization). Including these diagrams, even suppressed, is raising
too many questions. Furthermore, GPDs have to be included in the proton
vertex parametrization. Not including GPDs will overestimate the
interference term, plus not take into account part of the kinematic
dependence of the cross section.However, including GPDs is also not a
solution due to huge uncertainties and discrepencies between models, in 
particular for the part TCS unpolarized cross section is sensitive too.
I think that treating TCS as a systematic error in BH estimations is the
only option, even thought I think     using BH for normalization is not
ideal neither. For doing that, the only way is to perform a mapping of
the phase-space accounting detector acceptance and calculate a kinematic
dependent value of BH/(BH+TCS) using a TCS+GPDs model. I proposed to use
2x the expected TCS rate as a systematic to take account our lack of
knowledge on GPDs and TCS (NLO, higher twist contribution...). 

Best regards, 

Marie 

Le 16/03/2018 18:09, Richard Jones a écrit :

> Sean, 
> 
> I developed Dirac++ in the context of the second GlueX Conceptual Design Report back in 2002. Its purpose was to demonstrate progress towards readiness to analyze data from GlueX, from processes like this, thinking that we might see 12 GeV photons by 2008 or 2009. Great Expectations. That was 2002 or so, if I recall correctly, so the package is anything but new! However c++ is still around, and QED has not changed all that much, and I continue to develop it so it remains useful. Some of the internal beam generators (eg. simulations to give the TPOL asymmetry as a function of energy) in HDGeant4 depend on it, although that functionality can be disabled using a CPP macro. I believe that Mark has so far avoided dependency in the build of HDGeant4 on Dirac++ by setting this #define to false. 
> 
> My own development repo is maintained under /rjones30/Diracxx. Why don't you or Mark make a fork of it under JeffersonLab/Diracxx and that way you can coordinate the tagged releases together with the other packages that depend on it, eg. HDGeant4. Will that work? 
> 
> -Richard Jones 
> 
> On Fri, Mar 16, 2018 at 1:05 PM, Sean Dobbs <sdobbs at fsu.edu> wrote:
> 
> Richard, 
> 
> Thanks a lot for doing this.  Can you remind us, is Dirac++ a new library which is needed for building this new program? 
> 
> ---Sean 
> 
> On Fri, Mar 16, 2018 at 11:09 AM Richard Jones <richard.t.jones at uconn.edu> wrote: 
> 
> Hello Lubomir and all, 
> 
> I have written a new Bethe Heitler generator for GlueX. It is presently housed under the HDGeant4 repo since it depends on several other generator classes that are distributed with HDGeant4. The update is found in a recent pull request that I posted to HDGeant4 on github. If someone outside GlueX wants to use it, I can extract it from this environment, but for the moment it is right at home where it is. 
> 
> The new program is found in HDGeant4/src/utils and is called genBH. To build it, you need to do "make utils" at the top level in the HDGeant directory. It is not built by default using "make". This prevents automatic build scripts from crashing if they do not have Dirac++ set up in their environment. 
> 
> Invoking it without arguments generates the following usage message. 
> 
> Usage: genBH -n <#> [options] <output_file.hddm> 
> where options may include any of the following 
> -t <#> : number of threads to run, default 1 
> -E <val> : energy of incident photon (GeV), default 9.0 
> -e <val> : use bremsstrahlung spectrum with endpoint e (GeV) 
> 
> The output is in hddm format, suitable for reading into a simulation, either hdgeant or hdgeant4. 
> 
> -Richard Jones 
> _______________________________________________
> Halld-physics mailing list
> Halld-physics at jlab.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld-2Dphysics&d=DwICAg&c=HPMtquzZjKY31rtkyGRFnQ&r=bxTPW7N21WY8eJ2MkW85CQ&m=ihMBUZ9X9irTOEKa2JDvi07SCKi9KvYzAt8tXH9HfZI&s=ixnmUrMUaSoneYTgbihLQ9snR8XQ6douHXDr2Bx1bMU&e= [1]

_______________________________________________
Halld-physics mailing list
Halld-physics at jlab.org
https://mailman.jlab.org/mailman/listinfo/halld-physics 

Links:
------
[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld-2Dphysics&d=DwICAg&c=HPMtquzZjKY31rtkyGRFnQ&r=bxTPW7N21WY8eJ2MkW85CQ&m=ihMBUZ9X9irTOEKa2JDvi07SCKi9KvYzAt8tXH9HfZI&s=ixnmUrMUaSoneYTgbihLQ9snR8XQ6douHXDr2Bx1bMU&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-physics/attachments/20180319/79f730d1/attachment.html>