Avoiding 'ERROR: INTEGRAL APPEARS TO BE ZERO.' from mint-integrator2.f

Asked by Gauthier

Dear MadDevelopers,

I'm running e+ e- > b w+ b~ w- [QCD] in a custom model with v2.4.3, various model parameters, various center-of-mass energies, etc. and in many cases (about two failed runs for each successful one), I get an "error occurred during the collection of results" :just after the grid setup.

Going to the jobs' logs, it seems it is caused by an 'ERROR: INTEGRAL APPEARS TO BE ZERO.' generated by mint-integrator2.f. Order 1e5 phase-space points are 'TRIED' and order 10 give a 'NON-ZERO INTEGRAND'.

Somewhat above in the failed jobs' logs, it also seems some cryptic (but not fatal) error also appears just after the FasJet banner: "STOP 1
Backtrace for this error:
#0 0x00000033732ac5c4 in wait () from /lib64/libc.so.6
... "

One or two jobs out of about 50-80 are usually affected.

Do you have a clue about what this could be due to?
Is it actually a serious issue for the final result that a couple of jobs find an extremely tiny or vanishing integral?
In other words, if this issue cannot be solved in some simple way, could the results of those faulty jobs be somehow discarded?

Thanks a lot for your help!
Gauthier

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
marco zaro Edit question
Solved by:
Gauthier
Solved:
Last query:
Last reply:

This question was reopened

Revision history for this message
Valentin Hirschi (valentin-hirschi) said :
#1

Can you confirm that you took the b-quark massive and *not* part of the definition of the 'j' and 'p' multi-particle label definitions?
They must be massive so as to avoid additional top-quark resonances in the real-emission diagrams that are not present in the Born configurations.

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

Dear Gauthier,

The message 'ERROR: INTEGRAL APPEARS TO BE ZERO.' is due that only a couple of phase-space points gave a non-zero result. This means that all the other phase-space either did not pass the cuts or had a NAN or INF value and are skipped. Therefore, this has not really anything to do with integration channels giving a small contribution to the cross section; rather, the cross section of these integration channels cannot be estimated at all and therefore this error is raised.

Do you apply any stringent cuts?

As Valentin is writing already, the b-quarks need to massive (i.e., a four-flavour scheme) if you want to have the explicitly in the final state like that.

Do you use the complex mass scheme for the intermediate top quarks?

Best,
Rikkert

Revision history for this message
Gauthier (gauthier.d) said :
#3

Hi Valentin,
Hi Rikkert,

Thanks a lot for your thoughts about this issue!

Cen and I don't think the real emission would have resonances that are not already present at the Born level, if b's are massless. The reason is that this is e+e- initiated process, so that extra radiations are gluons only.

However, massless b's, indeed seemed to be at the source of this problem: the diagrams with photon splitting to bb̅ (which I forgot about) require a (direct or indirect) cut on the bb̅ invariant mass.

Thanks again!
Gauthier

Revision history for this message
Gauthier (gauthier.d) said :
#4

Hi Valentin,
Hi Rikkert,

I'm still running SM e+e- > bwbw, at fixed-order NLO, in the complex mass scheme, and looking at the dependence on a cut on the b-jets (anti-kt, R=0.4) invariant mass, comparing the massive and massless b cases (with an additional Eb>2.5GeV cut in the massless case).

Quite curiously, in the massless b case, the cross section grows as a function of the m(bb) cut until about 50 GeV where the massless and massive b cross sections converge to the same value. This is I guess due to a fair number of events with negative weights at low m(bb). It doesn't occur at fixed-order LO where the massless and massive b cross sections also converge at much smaller m(bb) cut values.

You can find the actual plot at http://www.desy.de/~durieux/mbb.png (bands stand for scale variation around mt, errorbars for MC uncertainties). It was obtained with v2.5.1-r331, and the default loop_sm UFO.

Do you have a clue about what is causing this peculiar behaviour of the massless b cross section and how it could be cured? Do you expect γ→bb̅ splitting to be problematic? We'd rather stick to massless b's as the counterterms we have implemented in our EFT model are computed within this approximation.

Thanks a lot for your insight!
Gauthier

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

Hi Gauthier,

I don't think that the Eb>2.5 GeV is an IR-safe cut for the massless case. Hence, the NLO cross section is not properly defined...
You first have to cluster the b's and gluon into jets, and apply the Eb (and invariant mass) cuts on the two b-flavoured jets instead of partons.

Best,
Rikkert

Revision history for this message
Gauthier (gauthier.d) said :
#6

Hi Rikkert,

That's actually what I do (with anti-kt, R=0.4).

(See line 303 and above in my http://www.desy.de/~durieux/cuts.f, where
lines I added or modified myself are enclosed between '!<' and '!>' marks.)

Thanks for your thoughts on this!

Gauthier

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

Hi Gauthier,

Ok. It's just that when looking at the plot, my feeling is that the cuts aren't applied correctly.

Looking in the cuts.f file, it seems like the following does not behave correctly if both b partons are in the same jet (and the real-emission gluon makes up the 2nd jet).

!<
! Identify the jet index 'i' of each b parton
! Add up the b-jet four momenta
         do k=0,3
            pb(k) = 0.d0
         enddo
         do j=1,nb
            do i=1,njet
               if (jet(bparti(j)).eq.i) then
                  if ( pjet(0,i).lt.eb ) then
                     passcuts_user=.false.
                     return
                  endif
                  do k=0,3
                     pb(k) = pb(k) + pjet(k,i)
                  enddo
               endif
            enddo
         enddo
         if (dot(pb,pb).lt.mbb**2) then
            passcuts_user=.false.
            return
         endif
!>

I think you need to add an additional:

if (jet(bparti(1)).eq.jet(bparti(2))) then
   passcuts_user=.false.
   return
endif

Best,
Rikkert

Revision history for this message
Gauthier (gauthier.d) said :
#8

Hi Rikkert,

This indeed solved my problem.

The corrected plot http://www.desy.de/~durieux/mbb_corrected.png makes a lot more sense.

Thanks a great lot for your time spent on this!

Cheers,

Gauthier