<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt'>
<p>Dear Richard, </p>
<p>Thank you very much for providing your generator.</p>
<p>However, I have several comments following your presentation on last dilepton meeting when you explained its content:</p>
<p>- 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.<br />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. <br /><br />- Phase space cuts have to be applied, for all above reasons, but also for numeric treatment of the process.<br />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.<br /><br />- 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.<br /><br />- I am not sure to well understand your notations, but for leading twist dilepton photoproduction, the M-- amplitude is the dominant one.</p>
<p>- 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.<br />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...).</p>
<p>Best regards,</p>
<p>Marie</p>
<p>Le 16/03/2018 18:09, Richard Jones a écrit :</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div dir="ltr">Sean,
<div> </div>
<div>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.</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>-Richard Jones</div>
</div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Fri, Mar 16, 2018 at 1:05 PM, Sean Dobbs <span><<a href="mailto:sdobbs@fsu.edu">sdobbs@fsu.edu</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div dir="ltr">Richard,
<div> </div>
<div>Thanks a lot for doing this. Can you remind us, is Dirac++ a new library which is needed for building this new program?</div>
<div> </div>
<div>---Sean</div>
</div>
<br />
<div class="gmail_quote">
<div>
<div class="h5">
<div dir="ltr">On Fri, Mar 16, 2018 at 11:09 AM Richard Jones <<a href="mailto:richard.t.jones@uconn.edu">richard.t.jones@uconn.edu</a>> wrote:</div>
</div>
</div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div>
<div class="h5">
<div dir="ltr">Hello Lubomir and all,
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Invoking it without arguments generates the following usage message.</div>
<div> </div>
<div>
<div>Usage: genBH -n <#> [options] <output_file.hddm></div>
<div> where options may include any of the following</div>
<div> -t <#> : number of threads to run, default 1</div>
<div> -E <val> : energy of incident photon (GeV), default 9.0</div>
<div> -e <val> : use bremsstrahlung spectrum with endpoint e (GeV)</div>
<div> </div>
</div>
<div>The output is in hddm format, suitable for reading into a simulation, either hdgeant or hdgeant4.</div>
<div> </div>
<div>-Richard Jones</div>
<div> </div>
</div>
</div>
</div>
______________________________<wbr />_________________<br /> Halld-physics mailing list<br /> <a href="mailto:Halld-physics@jlab.org">Halld-physics@jlab.org</a><br /> <a href="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=" target="_blank" rel="noopener noreferrer">https://urldefense.proofpoint.<wbr />com/v2/url?u=https-3A__<wbr />mailman.jlab.org_mailman_<wbr />listinfo_halld-2Dphysics&d=<wbr />DwICAg&c=<wbr />HPMtquzZjKY31rtkyGRFnQ&r=<wbr />bxTPW7N21WY8eJ2MkW85CQ&m=<wbr />ihMBUZ9X9irTOEKa2JDvi07SCKi9Kv<wbr />YzAt8tXH9HfZI&s=<wbr />ixnmUrMUaSoneYTgbihLQ9snR8XQ6d<wbr />ouHXDr2Bx1bMU&e=</a></blockquote>
</div>
</blockquote>
</div>
</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br /> Halld-physics mailing list<br /> <a href="mailto:Halld-physics@jlab.org">Halld-physics@jlab.org</a><br /> <a href="https://mailman.jlab.org/mailman/listinfo/halld-physics" target="_blank" rel="noopener noreferrer">https://mailman.jlab.org/mailman/listinfo/halld-physics</a></div>
</blockquote>
</body></html>