sherpa is hosted by Hepforge, IPPP Durham
close Warning: Can't synchronize with repository "(default)" (/hepforge/svn/sherpa does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 5 years ago

Closed 5 years ago

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

Reported by: Owned by: elunghi@indiana.edu support@sherpa-mc.de major rel-2.1.1 Unknown 2.1.0

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

### comment:1 Changed 5 years ago by Enrico Lunghi <elunghi@indiana.edu>

Description: modified (diff)

### comment:2 Changed 5 years ago by Enrico Lunghi <elunghi@indiana.edu>

Description: modified (diff)

### comment:3 Changed 5 years ago by Frank Siegert

Summary: HARD_DECAYS not working for Higgs decays in the SM+EHC model → Amegic cluster algorithm: wrong colour flow for H->gg decays in the SM+EHC model

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? ;-)

### comment:4 Changed 5 years ago by Stefan Hoeche

Resolution: → fixed new → closed

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

### comment:5 Changed 5 years ago by steffen@phys.uni-goettingen.de

Resolution: fixed closed → reopened

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:

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

### comment:6 Changed 5 years ago by Frank Siegert

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

### comment:7 Changed 5 years ago by marek

Resolution: → fixed reopened → closed

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.

### Modify Ticket

Change Properties
Summary: Description: You may use WikiFormatting here. 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 defectenhancementtaskquestionsetup blockercriticalmajorminortrivial rel-2.1.1 rel-2.2.1rel-2.3.0 perfect Hadron DecaysHadronizationME GeneratorParton ShowerQED RadiationUnderlying EventUnknown 2.2.42.2.32.2.22.2.12.2.02.1.12.1.02.0.01.4.52.0.beta21.4.32.0.beta1.4.21.4.11.4.01.3.11.3.01.2.31.2.21.2.11.2.01.1.31.1.21.1.11.1.01.0.121.0.111.0.101.0.91.0.80.trunk0.devbranch
Action
as closed The owner will remain support@sherpa-mc.de.