# Run Delphes on .hep outputs generated with aMC@NLO

Dear all,

I am trying to run Delphes (the version I got by typing install delphes from mg5 shell) on some NLO events.

This is what I did (MadGroah 5 v2 beta):

./bin/mg5

MG5>generate p p > t t~ [QCD]

aMC@NLO>output TestNLO

aMC@NLO>launch

and these steps create .hep output file from Herwig:

/TestNLO/

and then I do

cd Delphes

gunzip ../TestNLO/

./DelphesSTDHEP examples/

At this point I get the .root file with no errors while executing Delphes, but then when I look into the file, I see basically everything is 0, including the truth information on partons...

Any ideas?

Thanks in advance,

Michele

## Question information

- Language:
- English Edit question

- Status:
- Answered

- Assignee:
- Paolo Torrielli Edit question

- Last query:
- 2013-05-17

- Last reply:
- 2013-05-23

Hi Michele,

This looks like a problem with the support of negative weights in Delphes (but this is a pure guess).

Please contact the Delphes team (create a ticket at the following link: https:/

Cheers,

Olivier

On May 17, 2013, at 5:16 AM, Michele Pinamonti <email address hidden> wrote:

> New question #229096 on MadGraph5:

> https:/

>

> Dear all,

> I am trying to run Delphes (the version I got by typing install delphes from mg5 shell) on some NLO events.

> This is what I did (MadGroah 5 v2 beta):

> ./bin/mg5

> MG5>generate p p > t t~ [QCD]

> aMC@NLO>output TestNLO

> aMC@NLO>launch

> and these steps create .hep output file from Herwig:

> /TestNLO/

> and then I do

> cd Delphes

> gunzip ../TestNLO/

> ./DelphesSTDHEP examples/

>

> At this point I get the .root file with no errors while executing Delphes, but then when I look into the file, I see basically everything is 0, including the truth information on partons...

> Any ideas?

>

> Thanks in advance,

> Michele

>

> --

> You received this question notification because you are a member of

> MadTeam, which is an answer contact for MadGraph5.

Hi,

I have the same problem, I'm writing here because in my case not everything is 0. Particles do have their meaningful kinematics, and event weights are correctly stored (modulo some integer factor), but PID and charge, as well as Mass, are always 0, and this could be the real problem. The weight storing problem in Delphes was already solved here https:/

Please tell me if also with this new informations the bug should be forwarded to the Delphes team.

Giancarlo

Hi,

> Please tell me if also with this new informations the bug should be

> forwarded to the Delphes team.

Yes it should.

Cheers,

Olivier

On May 20, 2013, at 8:56 PM, Giancarlo Panizzo <email address hidden> wrote:

> Question #229096 on MadGraph5 changed:

> https:/

>

> Giancarlo Panizzo requested more information:

> Hi,

>

> I have the same problem, I'm writing here because in my case not

> everything is 0. Particles do have their meaningful kinematics, and

> event weights are correctly stored (modulo some integer factor), but PID

> and charge, as well as Mass, are always 0, and this could be the real

> problem. The weight storing problem in Delphes was already solved here

> https:/

>

> Please tell me if also with this new informations the bug should be

> forwarded to the Delphes team.

>

> Giancarlo

>

> --

> You received this question notification because you are a member of

> MadTeam, which is an answer contact for MadGraph5.

The discussion with Delphes team has been opened with ticket number 181

thanks

Giancarlo

Pavel Demin (pavel-demin) said : | #5 |

There is a bug in Delphes function that decodes STDHEP4 blocks (STDHEP + event weight).

The fixed STDHEP4 block reader will be available in Delphes 3.0.9.

Here is a preliminary version:

http://

I've also noticed the following problem with the STDHEP file that Giancarlo provided:

Some particles with status=1 have unphysical (nan or inf) vertex positions. I get the same values with both Delphes and MCFIO/STDHEP. So, it's not a reader problem. For example, here is a list of such particles from the first event:

number PID X Y Z Px Py Pz

61 14 nan nan nan 91.1621 -95.9792 -264.129

62 -13 nan nan nan 23.2651 -17.7621 -8.16779

73 -12 nan nan nan -67.5527 14.8692 60.7669

74 11 nan nan nan 6.20367 13.9842 -16.8727

Is it aMC@NLO or Herwig problem?

Hi Pavel,

Thanks for the comment.

Actually, I don't know for sure, if this is a Herwig or aMC@NLO problem.

I would guess Herwig.

Paolo could you investigate this?

Cheers,

Olivier

Just an info, Pavel version works greatly for me. I confirm the nan problem, in the 3% of total particles.

Giancarlo

Hi all,

I'm investigating. As soon as I find something I'll update you.

Cheers.

Paolo

And do remain the factor 264.212 in the weights (the sign is correct, I've checked the aMC@NLO negative weight fraction). This is already present in the lhe file, so this is for sure due to MC@NLO, I don't know if there's a reason to keep it, let me know.

Giancarlo

Dear Giancarlo, all,

the weight factor you quoted seems to be equal to the integral of the

absolute value of the differential cross section, i.e. what is written in

the last line of Events/

I would be grateful if you could try a run setting

sum = event_norm ! Normalize events to sum or average to the X sect.

instead of the default

average = event_norm ! Normalize events to sum or average to the X sect.

in the run_card, and tell me if the absolute value of the weights comes out

correct.

As for the NaNs or zeros, I'm still investigating, and it is probable they are

due to the STDHEP interface in aMC@NLO, which caused some headaches

in the past.

Could you also run with PYTHIA6Q instead of HERWIG6, and tell me whether

the final output has the same problems?

Cheers.

Paolo

On May 22, 2013, at 10:46 AM, Giancarlo Panizzo <email address hidden> wrote:

> Question #229096 on MadGraph5 changed:

> https:/

>

> Giancarlo Panizzo posted a new comment:

> And do remain the factor 264.212 in the weights (the sign is correct,

> I've checked the aMC@NLO negative weight fraction). This is already

> present in the lhe file, so this is for sure due to MC@NLO, I don't know

> if there's a reason to keep it, let me know.

>

> Giancarlo

>

> --

> You received this question notification because you are the assignee for

> this question.

Dear Giancarlo,

on the weights again.

> And do remain the factor 264.212 in the weights (the sign is correct,

> I've checked the aMC@NLO negative weight fraction). This is already

> present in the lhe file, so this is for sure due to MC@NLO, I don't know

> if there's a reason to keep it, let me know.

Probably I misinterpreted your previous email, sorry.

It seems that you reckon there is something wrong with the weight being

+-264.212 in the aMC@NLO LHE file.

That factor is such that if you sum all the weights, with their signs, and divide

the sum by the total number of events, you get the physical cross section.

In case you chose 'sum' instead of 'average' in the run_card.dat, then each

weight would just be +-(264.

average, would be the cross section.

Am I missing the point of your question?

Cheers.

Paolo

Thanks for the clarification, you have overestimated my question :)

Usually when working on (LO) unweighted events one has to introduce the total cross section info by hands, so, I don't know why, I expected the weights to be +-1, and that as usual one should have taken into account the total cross section info by hand, but I was wrong!

Thanks, I'm tryng the PYTHIA showering, I'll tell you.

Giancarlo

Ok, I've got the response. Showering with PYTHIA6Q gives NO nan or inf vertex values, while I have to update the numbers for Herwig: 40% ( not 3% as said before) of the particles have nan or +-inf vertex values.

Giancarlo

Hi Giancarlo,

thank you for the run.

This says that the problem is not generated before the shower phase,

so the core of aMC@NLO is safe.

Still, I don't think it is not internal to HERWIG6, rather to the STDHEP

interface to HERWIG6, which has some differences with respect to the

one to PYTHIA6. For example it could simply be that the vertex common

block is filled by STDHEP for PYTHIA and not for HERWIG.

Unfortunately I have not complete control on that interface, but I'll

investigate to see if I find anything.

Cheers.

Paolo

On May 22, 2013, at 3:46 PM, Giancarlo Panizzo <email address hidden> wrote:

> Question #229096 on MadGraph5 changed:

> https:/

>

> Giancarlo Panizzo posted a new comment:

> Ok, I've got the response. Showering with PYTHIA6Q gives NO nan or inf

> vertex values, while I have to update the numbers for Herwig: 40% ( not

> 3% as said before) of the particles have nan or +-inf vertex values.

>

> Giancarlo

>

> --

> You received this question notification because you are the assignee for

> this question.

Hi all,

at variance with what I was thinking, it seems that the NaN/Infinity problem is

intrinsic to HERWIG6, and not caused by the STDHEP interface.

Indeed, if one avoids using STDHEP, employing instead the mcatnlo_hwantop.f

analysis provided within the MCatNLO-utilities package (namely if one sets

EXTRALIBS =

EXTRAPATHS =

INCLUDEPATHS=

ANALYSE = mcatnlo_hwantop.o mcatnlo_

at the end of the shower_card.dat), and gets VHEP(j,i) printed out (for example

adding a write statement at line 159 of mcatnlo_hwantop.f), then Infinities and

NaNs are still there.

Unfortunately, I don't know the reasons for this behaviour, I can only say it is not

internal to aMC@NLO. The authors of HERWIG6 will surely know how to fix or

explain it.

Thank you all for your feedback.

Best regards.

Paolo

## Can you help with this problem?

Provide an answer of your own, or ask Michele Pinamonti for more information if necessary.