Hi, This is actually a bug of the lhapdf nn23nlo set. *** skip this if you do not care to know what the bug is *** More in details, the version from MG5 is not the same as the one from lhapdf. Turns out that the one from MG5 is the correct one and that they have to update their set on lhapdf. Indeed in lhapdf, the central set was generated with a fit for the options ‘always positive’ but the error set was fitted for the options ’can be negative’. so the set is inconsistent. In MG5aMC, the central set is ‘can be negative’ which is the central value of the associated error set. The LHAPDF author/NNPDF author are aware of this, but I do not know when and how this error will be solved. (The bug was actually spotted due to this project). Since this will pass by an update of the pdf, it is likely that people will not perform the update of the set for a long time… *** end of the bug description *** I just think of a new work-around which is not perfect but good enough 1) if the central pdf is zero, then use the wgt from the event to get the pdf value. 2) if the pdf is non zero, use it. in debug mode, this the second will need to a crash since the code will realize that a mismatch happens. I have updated the code such that in production mode, the test/crash does not happen. Cheers, Olivier PS: I have made a test from re-computing the central pdf from the errorset, and this slow down the code by huge factor (20 times slower) and provide the same result as the above. PPS: if you want to test, please run in production mode with python -O before the executable. > On Aug 23, 2016, at 16:24, Eleni Vryonidou