events.lhe file for a aMC@NLO simulation

Hi,

Indeed the the file generated is no physical on its own.
It has to be showered (with the parton-shower that you specified when the events were generated).
So analysing the .hep should lead to the correct prediction.

Cheers,

Olivier

> On 14 Apr 2017, at 00:27, Ezequiel Alvarez <email address hidden> wrote:
>
> New question #618795 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/618795
>
> Dear All,
>
> I'm simulating p p > t t~ [QCD] since I want to compute the SM ttbar charge asymmetry
>
> A= ( N(∆|y| > 0) − N(∆|y| < 0) ) / ( N(∆|y| > 0) + N(∆|y| < 0) ).
>
> I wonder if the events.lhe file that comes out from the simulation is physical to compute such an asymmetry? (I guess it doesn't, since I get a negative charge asymmetry, and the SM is postive (1205.6580) )
>
> Do I need to analyse the .hep files yes or yes to study the NLO ttbar production at the LHC to see the non-zero charge asymmetry?
>
> Thanks, Ezequiel.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

I have simulated p p > t t~ [QCD], showered using Herwig, then converted the hep file to root using the converter provided by Delphes (named DelphesSTDHEP), and then computed the ttbar charge asymmetry using the 2 tops that come from the parton collision. I have also tried computing the charge asymmetry using the 2 tops right before they decay. In both cases I get a charge asymmetry incompatible with the SM prediction (comparing to 1205.6580).

For instance, for the first case I get Ac(∆|eta|)=0.20(5) %, where the SM prediction for only QCD@NLO is 0.83(5)%. (My uncertainty is MC). The second case is worse.

I think that there is a disagreement beyond fluctuations. Do you see that I'm doing something incorrect, or that should be improved? Or should I be happy with this result? In my understanding I'm now using the unweighted event since it is after showering.

Thank you! Best, Ezequiel.

Hi Ezequiel,

as Olivier pointed out, you have to shower when it comes to NLO event files. I have worked on similar topics for the charge asymmetry. One thing that you have to make sure is that the conversion from hep to root is done properly. Even after the shower you will still have negatively weighted events. I believe that most probably the problem lies there. First of all look at the root output and check that this information is passed. If not, then you should not use it.

If yes, treat the output as if it is weighted, so that the negative weights will be subtracted instead of being added. One quick way to see this is to sum all the weights. This should give you the total cross section (if in the run_card.dat you had "sum = event_norm" ) or the average (average = event_norm). If you do not reproduce this it means that the events are treated all as if they have positive weights and this is the reason that the asymmetry calculation gives a wrong result.

If this works, you will get a number closer to the paper but still probably not the same. If I understand correctly you estimate the denominator from the same event file, so at NLOQCD. This is not what is done in 1205.6580, and I quote:
"Therefore we evaluate the denominators of all the asymmetries considered in this paper with LO QCD matrix elements".

There are two ways to calculate the asymmetry, one expanding on the perturbative order consistently for numerator and denominator (so NLOQCD/NLOQCD) and the other expanding on the asymmetry itself, which is zero at LO, so in this case the leading term becomes the NLOQCD/LOQCD, what they are doing on the paper. Finally if you want to compare in high precision you need to put the same scales, PDf sets, top mass value as they do. Keep this also in mind.

Best,
Ioannis

Hi Ioannis,

thanks for getting involved and clarifying!

Do you know of any .hep --> .root converter that actually does the conversion properly? That is, yields unweighted events. (Since I don't know what command to use in root to check if the root file has the events correctly weighted.)

Thank you very much! Ezequiel.

Hi Ezechiel,

This is not possible to have an unweighted sample of events starting from a sample of events with both positive and negative weights.

Cheers,

Olivier

> On 26 Apr 2017, at 15:27, Ezequiel Alvarez <email address hidden> wrote:
>
> Question #618795 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/618795
>
> Status: Answered => Open
>
> Ezequiel Alvarez is still having a problem:
> Hi Ioannis,
>
> thanks for getting involved and clarifying!
>
> Do you know of any .hep --> .root converter that actually does the
> conversion properly? That is, yields unweighted events. (Since I don't
> know what command to use in root to check if the root file has the
> events correctly weighted.)
>
> Thank you very much! Ezequiel.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Ezequiel,

to my knowledge there is no tool available, at the current time in general, to do the conversion "positive and negative weights"->"only positive weights" consistently. They can be forced to be all positive, but of course this will lead to nonphysical results.

So the consistent thing for now is to keep the negative weights all the way. To my knowledge, in Delphes this is done for the final root output. I believe that if you treat everything as if you have a weighted sample, this will solve your problem.

Best,
Ioannis

Hi Ioannis,

> I believe that if you treat everything as if you have a weighted sample,
> this will solve your problem.

I do not understand: I have the root file coming out from the Delphes .hep --> .root converter. Then how should I proceed to get the tt charge asymmetry? Because, from each event I can study t and tbar momenta and in principle count it as N+ or N-. Now if the events is negative-weighted, should I discard it? If you could describe me roughly what to do with the root output, I'd be grateful.

Than you very much, Ezequiel.

Hi Ezequiel,

all the events are to be taken under consideration.

You want to do A_C = (N[+]-N[-])/(N[+]+N[-]) (1).

So when you find an event to be N[+] you add it with weight 1 to pile up the total N[+]. Every time such an event occurs, you increase the N[+] by 1. This is where the problem appears. If this event has negative weight, it should be added with -1 to the N[+] collection (so it should actually be subtracted and reduce the N[+] ). The same goes for the N[-] part.

This is not important only for the asymmetry, but also for distributions. I do not have much root experience, but I can give you similar examples from Madanalysis5 code, which is c++/root based.

If I have a LO sample (only positive weights) I can plot the Rapidity of the top like

Y_t -> Fill( t_momentum(). Rapidity() ); // Normalized to the total number of events
or
Y_t -> Fill( t_momentum(). Rapidity() , event.mc()->weight() ); // Normalized to the sum of the weights

At LO, where all the weights are positive these definitions are identical apart from the overall normalization. In the second case instead of adding 1 every time at the corresponding bin, you add the weight of the event. But since the event file is unweighted (= all the weights have the same value), this does not change the shape.

At NLO these two definitions would not give you the same result. In the first case you disregard the weight, so you always add an entry with y-length=1 to the corresponding bin. In the second case, for each event, you add an entry with y-length=weight, so if the weight is negative, it is actually subtracted. So the first definition would give you a wrong shape, whereas the second will give you the correct one.

The same is true for the asymmetry calculation. For example let us say that I define in my analysis the variables

float D_y, N_plus, N_minus ;
// D_y= |y(t)| - |y(tbar)|
D_y = abs(t_momentum().Rapidity()) - abs(tbar_momentum().Rapidity());
N_plus=0;
N_minus=0;

Now I build the N[+] and N[-] in an event by event basis. I loop over all the events and I do

if (D_y > 0) {N_plus = N_plus + 1};
if (D_y < 0) {N_minus = N_minus + 1};

Now I have everything and I can apply equation (1). Only I will face the same problem as with the histogram definition 1. Because now I add every time regardless the weight and this will give a wrong result. I can pass this problem by modifying the above statements as following.

if (D_y > 0) {N_plus = N_plus + 1*event.mc()->weight()};
if (D_y < 0) {N_plus = N_minus + 1*event.mc()->weight()};

Now I multiply every time the "1" with the weight, so if it is negative it changes the sign and I actually subtract the event. I also change the overall normalization, but I do not care since I take a ratio, so it always cancels out.

What is actually done with this change is that instead of calculating numbers of events we are actually calculating
cross sections i.e.

A_C = (sigma[+]-sigma[-])/sigma_total (2)

Again similar to the histogram case, at LO the equations (1) and (2) will give exactly the same result, but at NLO only equation (2) will give the correct result.

Finally for accessing the weight information, as I told you I have not much root experience. But I assume that there must be a branch in the tree, where global event variables are defined. Look for a variable named weight(), if it is in a histogram there should be two spikes one in "1" (or "+weight") and one in "-1" (or "-weight"). This would mean the the information is passed properly and it can be accessed.

Best,
Ioannis

Dear Ioannis,

you are the man!

This not only solved my question, but also gave me a great learning. Thank you for the detail!

Best, Ezequiel.

ps: I still need to solve the root access to the weight. As soon as I have it I'll post it here for general help.