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.
Modify

Opened 5 years ago

Closed 5 years ago

#296 closed defect (fixed)

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

Reported by: elunghi@indiana.edu Owned by: support@sherpa-mc.de
Priority: major Milestone: rel-2.1.1
Component: Unknown Version: 2.1.0
Keywords: Cc:

Description (last modified by Enrico Lunghi <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

Attachments (5)

Run.dat.SM (501 bytes) - added by elunghi@indiana.edu 5 years ago.
logSM (22.5 KB) - added by elunghi@indiana.edu 5 years ago.
Run.dat.SMEHC (505 bytes) - added by elunghi@indiana.edu 5 years ago.
logSMEHC (21.6 KB) - added by elunghi@indiana.edu 5 years ago.
Run.dat.SMEHC.direct (490 bytes) - added by Enrico Lunghi <elunghi@indiana.edu> 5 years ago.

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by elunghi@indiana.edu

Attachment: Run.dat.SM added

Changed 5 years ago by elunghi@indiana.edu

Attachment: logSM added

Changed 5 years ago by elunghi@indiana.edu

Attachment: Run.dat.SMEHC added

Changed 5 years ago by elunghi@indiana.edu

Attachment: logSMEHC added

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)

Changed 5 years ago by Enrico Lunghi <elunghi@indiana.edu>

Attachment: Run.dat.SMEHC.direct added

comment:3 Changed 5 years ago by Frank Siegert

Summary: HARD_DECAYS not working for Higgs decays in the SM+EHC modelAmegic 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
Status: newclosed

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

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

Resolution: fixed
Status: closedreopened

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

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
Status: reopenedclosed

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
Action
as closed The owner will remain support@sherpa-mc.de.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.