MadGraph5_aMC@NLO

aMCatNLOError : An error occurred during reweight.

Asked by Benedikt Maier

Dear experts,

I'm generating

import model loop_sm-ckm
generate p p > t b~ j $$ w+ w- [QCD]

with a modified setscales.f to account for the recommended scale in the 4FS tchannel.

###
###

The crucial part to pick the kinematics of the b-quark in the setcales.f looks like:

         do i=nincoming+1,nexternal
            xm2=sqrt(dot(pp(0,i),pp(0,i)))
         enddo
         if (nexternal.eq.5) then
            tmp = dot(pp(0,nexternal-1),pp(0,nexternal-1))
            ptb = (pt(pp(0,nexternal-1)))**2
            tmpmass = sqrt(tmp)
         elseif (nexternal.eq.6) then
            tmp = dot(pp(0,nexternal-2),pp(0,nexternal-2))
            ptb = (pt(pp(0,nexternal-2)))**2
            tmpmass = sqrt(tmp)
         tmp=4d0*sqrt(tmp+ptb)
         temp_scale_id='4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3'

###
###

Now, I get the following error after trying to generate 250000 events:

INFO: Idle: 0, Running: 4, Completed: 64 [ 4h 19m ]
INFO: Idle: 0, Running: 3, Completed: 65 [ 4h 19m ]
INFO: Idle: 0, Running: 2, Completed: 66 [ 4h 19m ]
INFO: Idle: 0, Running: 1, Completed: 67 [ 4h 19m ]
INFO: Idle: 0, Running: 0, Completed: 68 [ 4h 21m ]
INFO: Doing reweight
INFO: Idle: 48, Running: 20, Completed: 0 [ current time: 17h26 ]
INFO: Idle: 47, Running: 20, Completed: 1 [ 8.3s ]
INFO: Idle: 46, Running: 20, Completed: 2 [ 8.4s ]
...
INFO: Idle: 0, Running: 10, Completed: 58 [ 12m 19s ]
INFO: Idle: 0, Running: 8, Completed: 60 [ 12m 49s ]
INFO: Idle: 0, Running: 4, Completed: 64 [ 13m 24s ]
INFO: Idle: 0, Running: 0, Completed: 68 [ 14m 4s ]
Error detected in "launch "
write debug file /afs/cern.ch/work/b/bmaier/public/Requests/PHYS14/top_newhope_2/run_01_tag_1_debug.log
If you need help with this issue please contact us on https://answers.launchpad.net/madgraph5
aMCatNLOError : An error occurred during reweight. Check the'reweight_xsec_events.output' files inside the 'SubProcesses/P*/G*/ directories for details
quit

####
#### The reweight_xsec_events.output says the following:
####

==== POWHEG (OR POSSIBLY HERWIG) WILL USE LHAPDFv6 ====
LHAPDF 6.1.4 loading /cvmfs/cms.cern.ch/slc6_amd64_gcc472/external/lhapdf6/6.1.4/share/LHAPDF/NNPDF30_nlo_as_0118_nf_4/NNPDF30_nlo_as_0118_nf_4_0000.dat
NNPDF30_nlo_as_0118_nf_4 PDF set, member #0, version 1; LHAPDF ID = 260400
==== POWHEG (OR POSSIBLY HERWIG) WILL USE LHAPDFv6 ====
LHAPDF 6.1.4 loading /cvmfs/cms.cern.ch/slc6_amd64_gcc472/external/lhapdf6/6.1.4/share/LHAPDF/NNPDF30_nlo_as_0118_nf_4/NNPDF30_nlo_as_0118_nf_4_0000.dat
NNPDF30_nlo_as_0118_nf_4 PDF set, member #0, version 1; LHAPDF ID = 260400
LHAPDF 6.1.4 loading /cvmfs/cms.cern.ch/slc6_amd64_gcc472/external/lhapdf6/6.1.4/share/LHAPDF/NNPDF30_nlo_as_0118_nf_4/NNPDF30_nlo_as_0118_nf_4_0001.dat
NNPDF30_nlo_as_0118_nf_4 PDF set, member #1, version 1; LHAPDF ID = 260401
LHAPDF 6.1.4 loading /cvmfs/cms.cern.ch/slc6_amd64_gcc472/external/lhapdf6/6.1.4/share/LHAPDF/NNPDF30_nlo_as_0118_nf_4/NNPDF30_nlo_as_0118_nf_4_0002.dat
NNPDF30_nlo_as_0118_nf_4 PDF set, member #2, version 1; LHAPDF ID = 260402
LHAPDF 6.1.4 loading /cvmfs/cms.cern.ch/slc6_amd64_gcc472/external/lhapdf6/6.1.4/share/LHAPDF/NNPDF30_nlo_as_0118_nf_4/NNPDF30_nlo_as_0118_nf_4_0003.dat
...
NNPDF30_nlo_as_0118_nf_4 PDF set, member #98, version 1; LHAPDF ID = 260498
LHAPDF 6.1.4 loading /cvmfs/cms.cern.ch/slc6_amd64_gcc472/external/lhapdf6/6.1.4/share/LHAPDF/NNPDF30_nlo_as_0118_nf_4/NNPDF30_nlo_as_0118_nf_4_0099.dat
NNPDF30_nlo_as_0118_nf_4 PDF set, member #99, version 1; LHAPDF ID = 260499
LHAPDF 6.1.4 loading /cvmfs/cms.cern.ch/slc6_amd64_gcc472/external/lhapdf6/6.1.4/share/LHAPDF/NNPDF30_nlo_as_0118_nf_4/NNPDF30_nlo_as_0118_nf_4_0100.dat
NNPDF30_nlo_as_0118_nf_4 PDF set, member #100, version 1; LHAPDF ID = 260500
 A PDF is used, so alpha_s(MZ) is going to be modified
 Old value of alpha_s from param_card: 0.11799999999999999
 New value of alpha_s from PDF lhapdf : 0.11227348553523188
 using LHAPDF
 Enter event file name
 Enter 1 to save all cross sections on tape
       0 otherwise
 Using:
 QES_over_ref: 1.0000000000000000
 muR_over_ref: 1.0000000000000000
 muF1_over_ref: 1.0000000000000000
 muF2_over_ref: 1.0000000000000000
 Doing scale reweight:
  0.50000000000000000 < mu_F < 2.0000000000000000
  0.50000000000000000 < mu_R < 2.0000000000000000
 Doing PDF reweight:
 Central set id: 260400
 Min error set id: 260401
 Max error set id: 260500

 The events appear to be unweighted
  Will store the ratios of recomputed weights
  over reference weights
 ================================
 process combination map (specified per FKS dir):
  1 map 1 2
  1 inv. map 1 2
  2 map 1 2
  2 inv. map 1 2
  3 map 1 2
  3 inv. map 1 2
  4 map 1 2
  4 inv. map 1 2
  5 map 1 2
  5 inv. map 1 2
  6 map 1 2
  6 inv. map 1 2
  7 map 1 1 1 1 2 2 2 2
  7 inv. map 4 8
  8 map 1 2
  8 inv. map 1 2
  9 map 1 1 2 2
  9 inv. map 2 4
 10 map 1 2
 10 inv. map 1 2
 ================================
 Scale values (may change event by event):
 muR, muR_reference: 0.957774D+02 0.957774D+02 1.00
 muF1, muF1_reference: 0.957774D+02 0.957774D+02 1.00
 muF2, muF2_reference: 0.957774D+02 0.957774D+02 1.00
 QES, QES_reference: 0.957774D+02 0.957774D+02 1.00

 muR_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3
 muF1_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3
 muF2_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3
 QES_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3

 alpha_s= 0.11140954936075177

#####################
#####################

So I supsect something is going wrong with the scale reweighting.

However, a run with 10000 events worked fine, and the corresponding antitop generation also runs smoothly (with another setscales.f to pick the b quark there, too, which is just the nexternal-2 and nexternal-3 respectively to account for the different order of particles in the folder_structure).

I checked that I picked the b quark every time, and previous versions of madgraph like 2.1.2 etc worked perfectly fine with scale reweighting, but now I get this error, and I don't know what is the problem :)

Thanks,
Benedikt

Question information

Language:
English Edit question
Status:
Open
For:
MadGraph5_aMC@NLO Edit question
Assignee:
Rikkert Frederix Edit question
Last query:
Last reply:
Revision history for this message
Benedikt Maier (bmaier) said : 		#1

This morning I got the same error with the corresponding antitop generation (300k events). It was the run_02, the run_01 with another 300k events went fine ... :/

Revision history for this message
Rikkert Frederix (frederix) said : 		#2

Dear Benedikt,

There should be many SubProcesses/P*/G*/reweight_xsec_events.output files. Are none of them giving any hints about what might have gone wrong? Or are they all similar to the one you pasted above?

Besides the error you get, I see that you are using a model with a non-diagonal CKM matrix. Does this include the 3rd generation? Ie., a non-zero V_ts or V_td ? Because if this is the case, I'm not 100% sure that the code will give you the correct results.

Best,
Rikkert

Revision history for this message
Benedikt Maier (bmaier) said : 		#3

Hi Rikkert,

I'm trying to answer the second part first:
I checked this by inserting the following lines right before the "scale_global_reference=tmp" line in the setscales.f:

print *, "nexternal: " , nexternal , " pt b: ", sqrt(ptb)
print *, "mass_b" , tmpmass

Every log.txt file in every SubProcess/P*/GF*/ directory shows me something like the following

 nexternal: 6 pt b: 3.0046183941562594
 mass_b 4.6999999999999877
 nexternal: 6 pt b: 3.0046183941562594
 mass_b 4.6999999999999877
 nexternal: 6 pt b: 3.0046183941562594
 mass_b 4.6999999999999877
 nexternal: 6 pt b: 37.889099535266375
 mass_b 4.7000000000011761
 nexternal: 6 pt b: 37.889099535266375
 mass_b 4.7000000000011761

So it seems to pick the b quark every time. Is this what you were referring to? :)

Now for the error with the reweighting:

I noticed that the P0_ug_tbxd/GF2_6/events.lhe.rwgt is the only lhe file that does NOT end with

  </rwgt>
  </event>
</LesHouchesEvents>

but only with

  </rwgt>
  </event>

so the </LesHouchesEvents> is missing there. In this lhe file, there are also only 848 events, whereas in all the other GF2_* there are 4964 events. (I have 5000 = nevt_job in this case, but the problem is also there when it is set to -1). And in the last folder, GF2_23 of this Subprocess, there are 4984 events.

And finally, also the reweight_xsec_events.output reveals something interesting:

#####################
...

 Scale values (may change event by event):
 muR, muR_reference: 0.517975D+02 0.517975D+02 1.00
 muF1, muF1_reference: 0.517975D+02 0.517975D+02 1.00
 muF2, muF2_reference: 0.517975D+02 0.517975D+02 1.00
 QES, QES_reference: 0.517975D+02 0.517975D+02 1.00

 muR_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3
 muF1_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3
 muF2_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3
 QES_reference [functional form]:
    4*Sqrt[m(b)**2 + pT(b)**2], b=b quark mod 3

 alpha_s= 0.12331296327300700
 Error in compute_rwgt_wgt_Sev_nbody
  Mismatch in ES scale 352.43461503980552 356.41390999999999

################

In the run_card.dat, the ES scale is set to

 F = fixed_QES_scale

Is this of any help?

(A quick thought that comes to my mind: Actually, I inherited the setscales.f from a former version of Madgraph_aMCatNLO, where I made those changes, and simply copied and used it in MG5_aMCatNLO 2.2.1. I think I checked, and it should still - apart from the modifications that I made - be the default setscales.f that ships with MadGraph, but maybe I overlooked something and this "old" setscales.f does not work in the new version.)

Thanks a lot,
Benedikt

Revision history for this message
Rikkert Frederix (frederix) said : 		#4

Dear Benedikt,

This is not what I meant with the non-diagonal CKM matrix elements (in the third generation).
If you generate your process

import model loop_sm-ckm
generate p p > t b~ j $$ w+ w- [QCD]

you get many WARNINGS printed in a bold blue font on the screen, suggesting that code neglects something that one should explicitly check to be zero. (If it is non-zero, the results can be wrong; it's not a gauge independent set that is wrong). So, please check this explicitly.

Anyway, assuming that there is no problem in the process definition, the problem you are having is essentially this error that stops the code:

  Mismatch in ES scale 352.43461503980552 356.41390999999999

This is due to the fact that the events written in the event file do "only" have 8 digits (or so). In the way you compute the scales, there can be large cancelations between various terms, which means that those 8 digits might not be enough. I think that there won't be a bias in the code if you use this, so it should be safe to simply remove the stop statement after this check. Simply remove it in the SubProcesses/reweight_xsec.f code (3 places).

By using the "launch --reweightonly" it does only the reweighting, using the results from the last run. In that way you don't need to generate your events.

Best,
Rikkert

Revision history for this message
Benedikt Maier (bmaier) said : 		#5

Hi Rikkert,

sorry for the late answer, and thanks for your one!

Removing the stop statements in the three places helped.

Concerning the process definition

import model loop_sm-ckm
generate p p > t b~ j $$ w+ w- [QCD] ,

I see the warnings, but I do not understand what their implications are for this generation. Apparently, all loop diagrams which are no pure QCD-contribution are neglected. Could you give me an example of such a diagram in this process?

On the other hand, the cross section of this generation is in good agreement with what I get from MCFM, Powheg, etc, so I would suspect that ok, some diagrams are neglected, but every pure QCD-loop-contribution is still in there, so the results should be trustable?

How else would it be possible to generate the t channel single top process with full ckm matrix, allowing transitions between quark generations?

Thanks a lot,
Benedikt

Can you help with this problem?

Provide an answer of your own, or ask Benedikt Maier for more information if necessary.

To post a message you must log in.