<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt'>
<p>Dear Richard and "dilepton's people", <br /><br />I think we can have more detailed technical discussion during dilepton meetings.<br /><br />Just to briefly address your points,<br /><br />- my generator is not throwing away any event. A flag is attributed to each event telling if it should be rejected or not at the analysis level. You can find more details on the content in my wiki page, as well as the most recent public version of the generator:<br /><a href="https://hallaweb.jlab.org/wiki/index.php/DDVCS_and_TCS_event_generator">https://hallaweb.jlab.org/wiki/index.php/DDVCS_and_TCS_event_generator</a></p>
<p>It contains 2 leading BH diagrams + 2 TCS diagrams, including GPDs and beam/target polarization.<br /><br />- I have done all cross checks on total cross section by using various way for generating events, and by fitting simulated results with independent theory calculations (presentations at some Hall A & C collaboration meetings in 2015). Also, calculations are based on the following article (part of my PhD): <br />https://link.springer.com/article/10.1140%2Fepja%2Fi2015-15103-3<br />Everything on this work was checked multiple times between authors and other persons. All my comments are based on lot of studies I have done over the past few years for this reaction, most have been double checked.<br /><br />- Rafo's and my code have been used for developping the proposals PR-12-12-01, E12-12-06A, LOI-12-15-007. We have not found any issues with simulations, and for same conditions our results are in agreement. I am using my code for all my current work on this topic.<br /><br />- For amplitude developement of total x-sec I refer to: https://link.springer.com/article/10.1007%2Fs100520200917<br />Rafo's code is based on this article.<br /><br />best regards, <br /><br />Marie<br /><br /></p>
<p>Le 19/03/2018 14:00, 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">Maria, thank you for your message. My responses are below.
<div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Mon, Mar 19, 2018 at 10:44 AM, Marie Boer <span><<a href="mailto:mboer@jlab.org">mboer@jlab.org</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div style="font-size: 10pt;">
<p><span style="font-size: 10pt;">- 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 completely 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.</span></p>
</div>
</blockquote>
<div>There is no problem imposing a selection of which events you want to simulate. You should not feel you have to simulate them all. But the generator is very fast, compared to simulation. There is no advantage throwing away part of the phase space at the generator stage, and it has the great advantage of providing a numerical cross-check by reporting the total cross section. A first rule for generators is, generate the full phase space, and then make selection at the simulation step. A second rule is measure the generator MC efficiency and make sure it is close to 1 on the full phase space, not on some selected sub-region. Otherwise your users of the generator will see problems when they try to reduce their dependence on the built-in cuts, and find that their numerical errors blow up. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div style="font-size: 10pt;">
<p><span style="font-size: 10pt;">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.</span></p>
</div>
</blockquote>
<div> </div>
<div>I disagree with this. Using interpolations introduces another level of approximation to the process. Why do that when you can generate everything directly without approximation? There is no motivation for resorting to this approximation.</div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div style="font-size: 10pt;">
<p>- I am not sure to well understand your notations, but for leading twist dilepton photoproduction, the M-- amplitude is the dominant one.</p>
</div>
</blockquote>
<div>There a 4 diagrams, two of them look like the incident photon decaying into two leptons, followed by rescattering of one of the two leptons. Those I call "gamma decays" diagrams. These are dominant, so I presume you are calling these M--. The other two diagrams look like Compton scattering with the scattered photon being off-shell and scattering into a lepton pair. This I call "Compton-Dalitz". Whatever you call them, those are the complete set of tree level for this process. </div>
<blockquote class="gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div style="font-size: 10pt;">
<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>
</div>
</blockquote>
<div>Yes, that's right. The way I treat these two diagrams in my generator is only half-hearted at best. When you use my generator, I suggest that you set F1_timelike = F2_timelike = 0. That way these diagrams are suppressed, and only the leading two gamma-decay diagrams are included. The interference between the gamma-decay and TCS diagrams is the leading correction. My generator, as presently written, does not have an accurate account of the way that proton structure affects the TCS amplitude in it. Until it does, leaving the inputs F1_timelike and F2_timelike at zero is the best way to use it. For computing BH background in GlueX, these interference terms are not relevant.</div>
<div> </div>
<div>-Richard Jones </div>
</div>
</div>
</div>
</div>
</blockquote>
</body></html>