Amegic cluster algorithm: wrong colour flow for H->gg decays in the SM+EHC model

[elunghi@indiana.edu]

There seems to be a problem with the Higgs-gluon-gluon effective interaction in the model SM+EHC when using HARD_DECAYS.

If I generate "93 93 -> 23 25" in the SM with HARD_DECAYS = 1 correctly generate events decaying the W, Z and H (See Run.dat.SM and logSM).

If I simply replace SM->SM+EHC, the event generation fails with an "Invalid Color Flow" (See Run.dat.SMEHC and logSMEHC). If, after generating the decay tables, I edit by hand the file "Results/Decays/h0" and set the H->gg width to 0, event generation succeeds.

PS1: Note that the problem persists whether I decay or not the taus

PS2: the log files I posted where obtained with Sherpa 2.1.0 on Ubuntu installed on a virtual machine on a mac. I obtain similar results with Sherpa 2.0.0 installed directly on the mac (in this case I have to add MASSIVE[15]=1 or Sherpa won't generate the tau decay table).

PS3: apparently the problem appears even without HARD_DECAYS. In fact, the same error appears if I try to generate events in which the Higgs is explicitly decayed to gg in SM+EHC. See the Run.dat.SMEHC.direct

[Frank Siegert]

Indeed, even without any HARD_DECAYS involved, i.e. with Run.dat.SMEHC.direct, this does not get the correct colour flow from the cluster algorithm. The debugging output shows a cluster amplitude with the two gluons in (anti)triplet colour state:

          (0x22f3800): 2 -> 2 {
            \mu_r = 14000, \mu_f = 14000, \mu_q = 123.515, \mu = 123.515
            k_T = 123.515, z = 0, phi = 0, kin = 0, K = 0
            oew = 2, oqcd = 0, nlo = 0, new = (<no entry>), ncl = 0, flag = 0
            decs = { (2,3)[h0|2,0] }
                     (0)          db (-1087.79,-0,-0,-1087.79) 2.15792e-05 (0,500) [1|3]
                     (1)           d (-3.50619,-0,-0,3.50619) -2.82352e-06 (500,0) [1|3]
                   (2,3)          h0 (219.97,6.00696,-3.89734,217.772) 30.1812 (0,0) [7|3] <-> (1)
                     (4)           Z (871.326,-6.00696,3.89734,866.511) 91.188 (0,0) [1|3]
          }
          (0x2351f60): 2 -> 3 {
            \mu_r = 14000, \mu_f = 14000, \mu_q = 14000, \mu = 8.69946
            k_T = 8.69946, z = 0, phi = 0, kin = 0, K = 0
            oew = 3, oqcd = 2, nlo = 0, new = (3), ncl = 0, flag = 0
            decs = { (2,3)[h0|2,0] }
                     (0)          db (-1087.79,-0,-0,-1087.79) 2.15792e-05 (0,500) [0|3]
                     (1)           d (-3.50619,-0,-0,3.50619) 7.86239e-07 (500,0) [0|3]
                     (2)           G (20.8816,0.0775222,8.33026,19.1478) -4.76837e-07 (601,0) [0|3]
                     (3)           G (199.089,5.92944,-12.2276,198.625) 0 (0,601) [0|3]
                     (4)           Z (871.326,-6.00696,3.89734,866.511) 91.188 (0,0) [0|3]
          }

So this seems to be a problem in the Amegic cluster algorithm. Any ideas from the Amegic gurus? ;-)

[Stefan Hoeche]

Fixed on trunk r24023, rel-2-1-1 r24024.

[steffen@phys.uni-goettingen.de]

While everything works fine on current trunk now, up-to-date rel-2-1-1 still has issues. Depending if YFS is on or off I get the errors:

Sherpa: Hard_Decay_Handler::AddPhotonsClustering throws fatal error:

Adding QED to coloured particle.

Sherpa: Hard_Decay_Handler::AddDecayClustering throws fatal error:

Colour partner not found

Looking a it I am not easily able to debug the issue, i.e. identify the relevant difference between versions.

Any help is appreciated.

Steffen

[Frank Siegert]

Korinna reported a similar issue the other day for VVV... but I don't know whether Marek has already looked at it.

[marek]

This should have been fixed with r24064 (trunk), r24067(rel-2-1-1). The issue was that the fix for the colour assignment in the above case (singlet -> octet octet) was now also assigning octet colour indices for singlet -> singlet singlet cluster sequences. This interfered with fail-safes preventing YFS-photons to be clustered with colour-charged particles.

Please reopen if the problem persists.