<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi Andy,</p>
    <p>There is study showing that in the low pt range, it's not always
      the ME photon having the largest pT. So it might not work.<br>
      But turnning off QED in Pythia is definitely a good idea!<br>
      Thanks a lot! I'll try that.<br>
      <br>
      Best,<br>
      Yichen<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 07.03.2018 14:54, Andy Buckley
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:local-5344fa7c-f8b5-v1.1.4-22d9f20d@unity">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div>Here you are hitting the problem that the processes you are
        comparing are not actually the same, and you need to find a
        mapping between them.</div>
      <br>
      <div>I don't know what is most sensible in this case, but choosing
        the highest-pT photon (or the one with largest kT-distance from
        the lepton?) might be a reasonable approach. In general you
        cannot know which one was "first", since both the shower photons
        and the ME one are perturbative.</div>
      <br>
      <div>Alternatively, or to validate a heuristic for leading-photon
        identification, you could turn off the QED shower in Pythia!</div>
      <br>
      <div>Andy</div>
      <br>
      <div><signature id="initial">
          <div>
            <table cellspacing="0" cellpadding="0">
              <tbody>
                <tr>
                  <td colspan="2">
                    <div style="padding-bottom:15px;">
                      <div><strong>Dr Andy Buckley, Lecturer / Royal
                          Society University Research Fellow</strong></div>
                      <div>Particle Physics Experiment Group, University
                        of Glasgow</div>
                    </div>
                  </td>
                </tr>
                <tr>
                  <td style="vertical-align:top;"><br>
                  </td>
                  <td><br>
                  </td>
                </tr>
              </tbody>
            </table>
          </div>
        </signature></div>
      <div class="gmail_quote_attribution">On Mar 7 2018, at 1:03 pm,
        Yichen <a class="moz-txt-link-rfc2396E" href="mailto:yichen.li@cern.ch"><yichen.li@cern.ch></a> wrote:</div>
      <blockquote><br>
        <div><br>
          <div>Hi Andy,</div>
          <br>
          <div>
            <div>Thanks for the suggestion.</div>
            <div>Yes, I've considered using PromptFinalState.</div>
            <div>But the problem is there will be additional QED added
              by Pythia8, in addition to the one in the ME, which will
              be considered as PromptFinalState.</div>
            <div>And I don't want these additional QED photons, since
              the high order calculation, which will be used for
              deriving the kfactor, consider only 1 photon radiation.</div>
            <br>
            <div>But I didn't study this effect quantitatively. Maybe it
              can be neglected or suppressed with cuts. I'll take a
              look.</div>
            <br>
            <div>Best,</div>
            <div>Yichen</div>
          </div>
          <div>On 07.03.2018 10:56, Andy Buckley wrote:</div>
          <blockquote><br>
            <div>Hi Yichen,</div>
            <br>
            <div>The accepted way to identify hard-process leptons and
              photons is by working backward from them in the final
              state, and verifying that they do not have any hadronic
              ancestors. This is specified in the ATLAS truth-object
              definition PUB note, for example, and is most conveniently
              achieved in Rivet by using the PromptFinalState.
              Regardless of intentions, starting from looking for "ME"
              particles with particular status codes will be on the
              verge of unphysicality unless you are <em>very</em>
              careful.</div>
            <br>
            <div>Hope that helps,</div>
            <div>Andy</div>
            <br>
            <div>
              <div>
                <div>
                  <table cellspacing="0" cellpadding="0">
                    <tbody>
                      <tr>
                        <td colspan="2">
                          <div style="padding-bottom:15px;">
                            <div><strong>Dr Andy Buckley, Lecturer /
                                Royal Society University Research Fellow</strong></div>
                            <div>Particle Physics Experiment Group,
                              University of Glasgow</div>
                          </div>
                        </td>
                      </tr>
                      <tr>
                        <td style="vertical-align:top;"><br>
                        </td>
                        <td><br>
                        </td>
                      </tr>
                    </tbody>
                  </table>
                </div>
              </div>
            </div>
            <div>On Mar 7 2018, at 9:26 am, Yichen <a
                href="mailto:yichen.li@cern.ch"
                title="mailto:yichen.li@cern.ch" moz-do-not-send="true"><yichen.li@cern.ch></a>
              wrote:</div>
            <blockquote><br>
              <div><br>
                <div>Dear Andy and Torbjör,</div>
                <br>
                <div>
                  <div>Thanks a lot for your replies!</div>
                  <br>
                  <div>By looking for these ME particles, we are not
                    trying to do unphysical measurement. Our motivation
                    is the following:</div>
                  <div>1) We unfolded our measurement to a particular
                    decay channel of the ttbar (e.g. to e/mu+jets
                    channel). So we need the decay information of the
                    ttbar to remove other channels so that we can
                    compare the MC sample, which includes all
                    non-hadronic decay channels, with the unfolded
                    result.</div>
                  <div>2) We are trying to calculate kfactor for our MC
                    sample in a phase space where there is jet
                    multiplicity cut (as well as lepton/photon pt/eta
                    cuts). The higher order calculation is only at ME
                    level. So to get the kfactor, we want to identify
                    the ME leptons/photons in the MC sample and trace
                    their history until they reach their final states
                    and then use these final states to define the phase
                    space.</div>
                </div>
                <div>Here is the piece of code in Rivet (for analyzing
                  e+jets channel):</div>
                <div>""</div>
                <div>bool foundMEel = false;</div>
                <div>bool foundMEnuel = false;</div>
                <div>bool foundMEph = false;</div>
                <div>Particles all = event.allParticles();</div>
                <div>foreach (Particle p, all) {</div>
                <div>   if (p.genParticle()->status() == 23) {</div>
                <div>      if (fabs(p.pid()) == 11) foundMEel = true;</div>
                <div>      if (fabs(p.pid()) == 12) foundMEnuel = true;</div>
                <div>      if (fabs(p.pid()) == 22) foundMEph = true;</div>
                <div>   }</div>
                <div>}</div>
                <div>if (!(foundMEel && foundMEnuel &&
                  foundMEph)) return;</div>
                <div>""</div>
                <div>I put an example in cern lxplus068
                  /tmp/yili/example/</div>
                <div>If you can't use lxplus, I also put a copy in
                  dropbox: <a
href="https://www.dropbox.com/sh/5tdl2slccr3dc9u/AACHY9hlB6pvdrpcSql_2M_na?dl=0"
title="https://www.dropbox.com/sh/5tdl2slccr3dc9u/AACHY9hlB6pvdrpcSql_2M_na?dl=0"
                    moz-do-not-send="true">https://www.dropbox.com/sh/5tdl2slccr3dc9u/AACHY9hlB6pvdrpcSql_2M_na?dl=0</a></div>
                <br>
                <div>In this example code, the evnt/ dir hosts the HEPMC
                  format of the MC sample. Its corresponding LHE can be
                  found with the name events.lhe</div>
                <div>From the events.lhe, you can find that this is a
                  pure e+jets channel sample. So with the above code,
                  every event should pass the cut. But only 24% passed.</div>
                <br>
                <div>Best,</div>
                <div>Yichen</div>
                <br>
                <div>
                  <div>On 06.03.2018 21:09, Andy Buckley wrote:</div>
                </div>
                <blockquote><br>
                  <div>Hi Yichen,</div>
                  <br>
                  <div>One of the major design features of Rivet is to
                    avoid unphysical search criteria like this.
                    Different generators write hard processes with
                    different status codes and different topologies, so
                    there is no portable way to look for their
                    particles. More importantly, there is nothing
                    physically distinct about "the matrix element" from
                    the rest of the perturbative simulation: you are in
                    danger of "measuring" an artefact of the
                    calculation, rather than something physical.</div>
                  <br>
                  <div>On your specific question, I don't know where the
                    problem is, since you've not supplied any example
                    code. But if you are using the Rivet FinalState, for
                    example, then the name gives a hint as to why there
                    are no matrix element particles in it! I guess that
                    you are doing something else, though, if you were
                    able to get what you wanted with Pythia6. Rivet
                    doesn't do any special treatment of generator
                    internal status codes.</div>
                  <br>
                  <div>Andy</div>
                  <br>
                  <div>
                    <div>
                      <div>
                        <div>
                          <table cellspacing="0" cellpadding="0">
                            <tbody>
                              <tr>
                                <td colspan="2">
                                  <div style="padding-bottom:15px;">
                                    <div><strong>Dr Andy Buckley,
                                        Lecturer / Royal Society
                                        University Research Fellow</strong></div>
                                    <div>Particle Physics Experiment
                                      Group, University of Glasgow</div>
                                  </div>
                                </td>
                              </tr>
                              <tr>
                                <td style="vertical-align:top;"><br>
                                </td>
                                <td><br>
                                </td>
                              </tr>
                            </tbody>
                          </table>
                        </div>
                      </div>
                    </div>
                  </div>
                  <div>On Mar 6 2018, at 6:13 pm, Yichen <a
                      href="mailto:yichen.li@cern.ch"
                      title="mailto:yichen.li@cern.ch"
                      moz-do-not-send="true"><yichen.li@cern.ch></a>
                    wrote:</div>
                  <blockquote><br>
                    <div>
                      <div>Dear Pythia8/Rivet experts,</div>
                      <br>
                      <div>I'm using Rivet to analyze a MG5+Pythia8
                        ttbar+photon sample.</div>
                      <div>And I'm trying to get the matrix element
                        particles using status==23 cut.</div>
                      <div>But it turns out that in many cases,
                        "status==23" can't capture all the</div>
                      <div>matrix element particles!</div>
                      <div>(I did similar study for Pythia6, where all
                        matrix element particles can</div>
                      <div>be identified with status==3)</div>
                      <br>
                      <div>Do you know what could be the source of the
                        problem?</div>
                      <div>I'm not sure if it's due to Pythia8 or Rivet.
                        So I send this email to</div>
                      <div>both mailing lists.</div>
                      <div>And please let me know if you need more
                        information!</div>
                      <br>
                      <div>Thanks a lot!</div>
                      <br>
                      <div>Yichen Li</div>
                      <br>
                      <div>_______________________________________________</div>
                      <div>Rivet mailing list</div>
                      <div><a href="mailto:Rivet@projects.hepforge.org"
                          title="mailto:Rivet@projects.hepforge.org"
                          moz-do-not-send="true">Rivet@projects.hepforge.org</a></div>
                      <div><a
                          href="https://www.hepforge.org/lists/listinfo/rivet"
title="https://www.hepforge.org/lists/listinfo/rivet"
                          moz-do-not-send="true">https://www.hepforge.org/lists/listinfo/rivet</a></div>
                    </div>
                  </blockquote>
                </blockquote>
              </div>
            </blockquote>
          </blockquote>
        </div>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>