Hi all,
just noticed a possible bug:

inside SubProcesses/cuts.f, line 142 reads

                     if (ipdg(i).eq.-ipdg(j)) then

however, it should be ipdg_reco in both cases and not ipdg, right? (that
is, the pdg's of the particles after the recombination with photons...)
If anybody could confirm, I will push the fix.

Best wishes,


Marco Zaro


On Thu, May 21, 2020 at 11:42 PM Valentin Hirschi <
<email address hidden>> wrote:

> So the problem seem to simply be that these few lines in `Binoth_LHA.f`:
>
>          CALL COLLIER_COMPUTE_UV_POLES(.FALSE.)
>          CALL COLLIER_COMPUTE_IR_POLES(.FALSE.)
>
> are called *after* the similar ones in `check_poles.f`:
>
> c Make sure that stability checks are always used by MadLoop, even for
> c initialization
>       CALL FORCE_STABILITY_CHECK(.TRUE.)
>       CALL COLLIER_COMPUTE_UV_POLES(.TRUE.)
>       CALL COLLIER_COMPUTE_IR_POLES(.TRUE.)
>
> which of course means you'd get zero poles when running with COLLIER only.
>
> The introduction of a common block "flag" of the sort of:
>
> logical IS_DOING_POLE_CHECK
> common pole_check/IS_DOING_POLE_CHECK
> data IS_DOING_POLE_CHECK/.FALSE./
>
> would allow to solve the problem by using it to make sure that
> `Binoth_LHA.f` does not disable pole computations with COLLIER when doing
> pole checks.
>
> On Thu, May 21, 2020 at 9:42 PM Valentin Hirschi <
> <email address hidden>>
> wrote:
>
> > Sorry for my slow reaction, I will have a serious look at this.
> > I'll check with Olivier what is the exact setup to reproduce the problem.
> > The fact that the problem cannot be reproduced in standalone (unless I
> > misunderstood the situation, in which case apologies) made me kind of put
> > it aside in so far as it did not seem like a genuine MadLoop problem but
> > more its use within MadFKS.
> > Hopefully I'll be able to easily spot the offending parameter by simply
> > comparing MadLoop's run for one particular point within MadFKS and in
> > standalone (which is what I was hoping would straight-forwardly reveal
> the
> > issue).
> > But it seems that the problem is more involved than I thought so I'll
> > investigate and let you knw.
> >
> > On Thu, May 21, 2020 at 3:57 PM Olivier Mattelaer <
> > <email address hidden>> wrote:
> >
> > > Review: Approve
> > >
> > > Hi,
> > >
> > > Sorry indeed I miss the fact that Rik change the line in that version
> but
> > > only in a cosmetic way.
> > > Consequently to this I have force the printout of the poles in 2.7.3
> and
> > > found the same printout:
> > >
> > >  ---- POLES CANCELLED ----
> > >  POLES ANCELLATION, DIFFERENCE <    1.0000000000000003E-005
> > >   COEFFICIENT DOUBLE POLE:
> > >         MadFKS:  -0.48049656339581920                OLP:
> > > 0.0000000000000000
> > >   COEFFICIENT SINGLE POLE:
> > >         MadFKS:    1.2727761694678807                OLP:
> > > 0.0000000000000000
> > >   FINITE:
> > >            OLP:  -0.69598571535491494
> > >
> > >   MOMENTA (Exyzm):
> > >            1   39.800372893656203        0.0000000000000000
> > > 0.0000000000000000        39.800372893656203      \
> > >   0.0000000000000000
> > >            2   39.800372893656203       -0.0000000000000000
> > >  -0.0000000000000000       -39.800372893656203      \
> > >   0.0000000000000000
> > >            3   39.800372893656203       -18.912294290529488
> > >  -32.109690658036719       -13.977216210235818      \
> > >   0.0000000000000000
> > >            4   39.800372893656203        18.912294290529488
> > > 32.109690658036719        13.977216210235818      \
> > >   0.0000000000000000
> > >
> > > Now running in standalone mode on the same PS point we have (with
> > collier):
> > > || Total(*) Born contribution (GeV^0):
> > > |    Born        =  6.2823500530737046e+00
> > > || Total(*) virtual contribution normalized with born*alpha_S/(2*pi):
> > > |    Finite      =  1.3071069893544380e+00
> > > |    Single pole = -4.7247991865699230e+00
> > > |    Double pole = -2.6666666666666692e+00
> > > |  (*) The results above sum all starred contributions below
> > >
> > >
> > > Since Valentin does not want to take a look at this and that I'm
> > > completely  loss on this I have:
> > > 1) revert the bypass on the check of the poles for COLLIER
> > > 2) set the default for madloop to ninja then cuttools (collier is only
> on
> > > request)
> > > I have done that both in 2.7.3 and 3.0.2
> > > As soon as Valentin found the time to fix this, we can revert this
> > > obviously but I have spent too much time on this and want ( and need to
> > > focus on something else)
> > >
> > > So with this, we are ready to release 3.0.2
> > >
> > > Cheers,
> > >
> > > Olivier
> > >
> > >
> > > --
> > >
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/3.0.2/+merge/381317
> > > Your team MadDevelopers is subscribed to branch
> > > lp:~maddevelopers/mg5amcnlo/3.0.2.
> > >
> >
> >
> > --
> > Valentin
> >
> > https://code.launchpad.net/~maddevelopers/mg5amcnlo/3.0.2/+merge/381317
> > Your team MadDevelopers is subscribed to branch
> > lp:~maddevelopers/mg5amcnlo/3.0.2.
> >
>
>
> --
> Valentin
>
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/3.0.2/+merge/381317
> Your team MadDevelopers is subscribed to branch
> lp:~maddevelopers/mg5amcnlo/3.0.2.
>