<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi Andy,</p>
    <p>Thanks for the suggestion.<br>
      Yes, I've considered using PromptFinalState.<br>
      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. <br>
      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.<br>
      <br>
      But I didn't study this effect quantitatively. Maybe it can be
      neglected or suppressed with cuts. I'll take a look.<br>
      <br>
      Best,<br>
      Yichen<br>
    </p>
    On 07.03.2018 10:56, Andy Buckley wrote:<br>
    <blockquote type="cite"
      cite="mid:local-b2e770a2-52f6-v1.1.4-22d9f20d@unity">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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><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 9:26 am,
        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>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>
                  <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 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>
    <br>
  </body>
</html>