Bug in the LHE writer of MadAnalysis 5

Bug #1472134 reported by Benjamin Fuks
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadAnalysis 5
Fix Released
Medium
Benjamin Fuks

Bug Description

Dear MA5 experts,

I am working with Madanalysis5 on reconstructed level NLO event files. So I have the hepmc output from aMC@NLO and I pass it through fastjet within the Madanalysis5 framework. I understand that I have two choices for that. I can ask for an output.lhco.gz or an output.lhe.gz file.

However in the lhco format all the events are assumed to be unweighted with weight 1. So the information of the negative weights at NLO seems to be lost, since they are all forced to have weight=+1. I also tried to read my hepmc with Delphes where I get an output.root file. Again, despite the fact that I see the negative weight information in the root file, once I use a given delphes script to change it to output.lhco, all the events are forced to have weight=+1. So this does not seem to be an issue of MadAnalysis5, but actually an issue of lhco files in general, because the weight information does not appear at all (there is just the header and the list of the events). If one wants to read the output.lhco, the total cross section has to be set from the user (usually taken from the original hepmc file), so this is not affected. However if one asks for distributions he will get distorted plots since now the negatively weighted events are not subtracted as they should, but added. So I conclude that lhco files for NLO studies (using aMC@NLO i.e. with negative weights) are not to be 100% trusted. Is this true? Do I understand correctly or I am doing something wrong?

Concerning the output.lhe.gz reconstructed level file, the weight information is passed (it appears like in the parton level lhe files), so If I ask for weighted histograms I get the subtraction of the negatively weighted events for the plots. However there are two issues in this case:

-The first is that the correct way to read with Madanalysis5 a reconstructed level file is to use the ./bin/ma5 -R. But once I put the 'R' flag I cannot load an output.lhe.gz file even if it is after fastjet. It asks again to apply fastsim before loading an lhe file. I can re-apply fastsim with the same settings but since this lhe file is not parton level, it does not 'see' correctly the pdgid's (because now they are different) and as a result when I plot NPID there are missing particles. I can read this with the normal ./bin/ma5, like it is parton level and in this case when I plot NPID, I indeed see the particles that I recognize in the output.lhe.gz file. Do I miss anything by doing this? Does the omission of the 'R' flag cause any hidden problems when reading the output.lhe.gz reconstructed level file? Is it ok to treat it like I would treat a parton level file even at the expert mode (e.g. use event.mc() instead of event.rec() etc.)?

-The second issue on the reconstructed lhe files is that the weight has the form of 0.0000823E+00 for instance. But this E+00 is not 'flexible'. So if the weight is smaller and it needs more decimals it does not go to E-**, instead it becomes zero. As a result whenever The weight is very small it appears as 0.0000000E+00, so it is impossible to get any plots. This is often the case If the event file is after Madspin, because the weight is suppressed by the BR's, or if I ask for many events because the sum of the weights is the cross section, so the value of each weight becomes smaller. I tested this by increasing the number of events in the same process, so the weight in each event of the reconstructed lhe file was decreasing and after a point it became zero instead of getting values like 0.0000823E-05. Can this be fixed? Is there a way around this?

Best,
Ioannis

Revision history for this message
Benjamin Fuks (fuks) wrote :

Hi Ioannis,

Thanks for the information. You found a bug in the LHE writer of madanalysis. Please retry with v1.2.beta where the bug has been fixed.

Cheers,

Benjamin

Changed in madanalysis5:
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Benjamin Fuks (fuks)
milestone: none → v1.2
Benjamin Fuks (fuks)
Changed in madanalysis5:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.