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.
>
So the problem seem to simply be that these few lines in `Binoth_LHA.f`:
CALL COLLIER_ COMPUTE_ UV_POLES( .FALSE. ) COMPUTE_ IR_POLES( .FALSE. )
CALL COLLIER_
are called *after* the similar ones in `check_poles.f`:
c Make sure that stability checks are always used by MadLoop, even for _CHECK( .TRUE.) COMPUTE_ UV_POLES( .TRUE.) COMPUTE_ IR_POLES( .TRUE.)
c initialization
CALL FORCE_STABILITY
CALL COLLIER_
CALL COLLIER_
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 IS_DOING_ POLE_CHECK POLE_CHECK/ .FALSE. /
common pole_check/
data IS_DOING_
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. 003E-005 81920 OLP: 91494 046e+00 S/(2*pi) : 380e+00 9230e+00 6692e+00 /code.launchpad .net/~maddevelo pers/mg5amcnlo/ 3.0.2/+ merge/381317 /code.launchpad .net/~maddevelo pers/mg5amcnlo/ 3.0.2/+ merge/381317
> 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.0000000000000
> > COEFFICIENT DOUBLE POLE:
> > MadFKS: -0.480496563395
> > 0.0000000000000000
> > COEFFICIENT SINGLE POLE:
> > MadFKS: 1.2727761694678807 OLP:
> > 0.0000000000000000
> > FINITE:
> > OLP: -0.695985715354
> >
> > 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.2823500530737
> > || Total(*) virtual contribution normalized with born*alpha_
> > | Finite = 1.3071069893544
> > | Single pole = -4.724799186569
> > | Double pole = -2.666666666666
> > | (*) 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:/
> > Your team MadDevelopers is subscribed to branch
> > lp:~maddevelopers/mg5amcnlo/3.0.2.
> >
>
>
> --
> Valentin
>
> https:/
> Your team MadDevelopers is subscribed to branch
> lp:~maddevelopers/mg5amcnlo/3.0.2.
>
--
Valentin