Using Amegic to include spin information in H->tautau decays

[Generic User (don't modify these fields)]

Dear Sherpa Authors,

We have been using Sherpa to generate SM Higgs in association with a Weak vector boson events. To include the spin information in the tau decay products, we included the SPIN_CORRELATIONS= 1 tag in our (run) section of the Run.dat, as directed in your documentation.

However, when I look at the pion energy spectrum in the Higgs CoM frame, which we expect to be asymmetric if Spin information is propagated through the decays, we find no Asymmetry, indicating that no spin information is included.

I wanted to check that we were calling this option correctly, I gather that it is not possible with COMIX but we tried AMEGIC also.

I've attached the Run.dat file and the bash script used to generate the events.

Are we doing things correctly to include spin information?

Many thanks, Chris Boddy

[Frank Siegert]

Hi Chris,

Thanks for your report. Yes, you are doing things correctly, and it seems that this issue has been around since version 1.2.0 (and you are the first one who notices/reports it). I have attached a simple patch that fixes this. Can you try it out and let me know whether it works for you? Here is how you apply it:

cd SHERPA-MC-1.2.1
patch -p0 < spin-correlations.patch
make install

[Generic User (don't modify these fields)]

Hi Frank,

Thanks for your quick reply. I applied your patch and remade Sherpa 1.2.1. Firstly, I couldn't get your patch to work, but changed by hand SHERPA/Single_Events/Signal_Processes.C by hand to match your patch.

I still see no asymmetry in the single-pion energy distribution from the tau decays, in the Higgs CoM frame, as would be expected if Spin information is propagated through the decays.

To be sure the changes were taken into account, I also ran the Run.dat with the COMIX ME instead if AMEGIC and received that message you included as part of the patch if the dynamic cast of proc returns a null pointer:

"Spin correlations can only be enabled when using Amegic as matrix element generator"

Of course, I don't see that message when I use the AMEGIC ME, but I still see no asymmetry. Is it possible that something else is required or that I've done something else incorrectly? Just to be clear the only file changed was SHERPA/Single_Events/Signal_Processes.C.

I'll attach the log files from the first and second call to the Sherpa executable and the makelibs, using Sherpa-1.2.1.

Thanks, Chris Boddy

[Frank Siegert]

Hi Chris,

So you are expecting a difference in the pion energy which should come from the correlations between the tau decays? I might be completely wrong, but I would expect the boost from the higgs decay to be dominant, such that any effect on the pion energy from the tau decay would be really small. So naively I wouldn't be surprised if spin correlations don't have any effect there. Do you have a reference for that?

I have attached three plots which show the effect of spin correlations in a similar process (HZ -> tau tau mu mu) and I see the expected correlations in the azimuthal angle and mass of the pions. But I can confirm that I don't see any difference in the energy.

Thanks, Frank

[Generic User (don't modify these fields)]

Hi Frank,

Okay. Sure; we were following the prescription in this article

arXiv:hep-ph/0101311v2 which is better explained here

19. Jadach, Z.Was Acta. Phys. Pol. B15 (1984) 1151

Looking to what they call A_{FastSlow}. I meant that we expected the pion energy in the Higgs CoM frame to show an asymmetry if the spin correlations were present. I didn't think the boost would matter since in this test the pions themselves are boosted to the CoM frame of the Higgs particle (I did this by constructing the Higgs 4-vector from the addition of the first (status 2) tau+ tau- pair of 4-vectors in the event, and using that to boost the pions from the tau decays to that frame, in events where both taus decay to a single pion and tau neutrino. Maybe this is not correct for Sherpa? I tried this with a Z->tau tau sample but again found A_{FastSlow} = 0 in the tau tau -> pi pi nu nu events.

I also see an asymmetric azimuthal angle distribution between the tau decay products.

Best, Chris

[Frank Siegert]

Hi Chris,

I was referring to the boost that the tau gets from the Higgs decay (i.e. in the Higgs CoM).

Thanks for the reference. Now what I thought you were after is Figure 2 (left) in arXiv:hep-ph/0101311v2 and here one can clearly see that as expected there won't be any spin correlation structure in the pion energy in the Higgs rest frame. For tau's produced by vector bosons as on the right hand side there are correlations which show up in this spectrum and they are correctly generated by Sherpa as well.

I haven't looked at the A_FastSlow observable yet (because I wasn't aware of it), but will try that out as well. Unfortunately (well, no, fortunately!) I'll be on holiday from tomorrow for a week. I'll take a look at this when I come back.

Frank

[Frank Siegert]

Hi Chris,

So I have now implemented this A_fastslow observable in a Rivet analysis that I run on top of the Sherpa events, and it works exactly as expected:

$ Sherpa EVENTS=10000 SPIN_CORRELATIONS=1
[...]
_sigma1=6.98662e-06
_sigma2=6.60171e-06
_sigma3=1.12098e-05
_sigma4=1.15149e-05
A_fastslow=-0.2516

$ Sherpa EVENTS=10000 SPIN_CORRELATIONS=0
[...]
_sigma1=9.22351e-06
_sigma2=8.93663e-06
_sigma3=9.12183e-06
_sigma4=9.03105e-06
A_fastslow=0.0002

I have attached the simple Rivet plugin analysis that I have written for this.

How did you treat the \sqrt{s} part in the definition of the z+-? This should be the Higgs mass in this case, because you boost into the Higgs rest frame.

I looked at Z[mumu]H[tautau] to make sure that I have unique pions and neutrinos in the end. You have been generating also taus from the W decay, maybe there is a problem with which tau you use for your analysis?

Frank

[Generic User (don't modify these fields)]

Hi Frank, It's taken some time to get Rivet installed properly with the boost libraries but I finally managed to use your MYANALYSIS.cc in Rivet, so thanks for that!

One question though, for every event in my Z(->mumu)H(->tautau) sample I see many pi+ and pi- particles so not once did the Rivet anaylsis identify an event with only one pi+, one pi- and 2 neutrinos and so _sigma1,.. _sigma4 are all zero (I see that cout message "No piplus" a lot). Do you have the Run.dat file that you used with your ZH sample, that you used with your Rivet analysis so I can verify that my copy of Sherpa has your spin correlations patch applied correctly?

Thanks again, Chris Boddy

[Frank Siegert]

Hi Chris,

well, that might explain it. So you have been looking at the fully hadronic final state at LHC so far? I simply looked at e+e- -> HZ to avoid exactly the issue that I am picking up the wrong pions:

(run){
  OUTPUT = 2
  ANALYSIS = Rivet
  SPIN_CORRELATIONS = 1
}(run)
(me){
  ME_SIGNAL_GENERATOR   = Amegic
  SCALES          = VAR{sqr(120)}
}(me)
(shower){
  SHOWER_GENERATOR=None
  CSS_MAXEM = 0
}(shower)
(fragmentation){
  YFS_MODE = 0
}(fragmentation)
(model){
  STABLE[15] = 0
  MASSIVE[15] = 1
}(model)
(beam){
  BEAM_1          = 11
  BEAM_ENERGY_1   = 450.625
  BEAM_2          = -11
  BEAM_ENERGY_2   = 450.625
}(beam)
(processes){
  Process : 11 -11 -> 25[a] 23[b]
  DecayOS : 25[a] -> 15 -15
  DecayOS : 23[b] -> 13 -13
  End process
}(processes)

That's why my test analysis is so much simplified, I should have mentioned that. So what did your initial analysis look like? How did you make sure that you looked only at the "correct" pions, i.e. the ones from the two taus from the higgs? Otherwise I don't understand how you want to get the exact A_fastslow=-0.25.

[Generic User (don't modify these fields)]

Hi Frank,

Okay, thanks. Yes for our test we had to select the pions that originated from particles with fabs(pdg15) whose only other decay product was an fabs(pdg16) with status 1. Using W-> e nu H->tau tau we did get the desired result with other generators.

So, to be consistent with your results I ran with the Run.dat file for ee->Z(->mumu)H(->tautau) you just posted. I fed the events into your Rivet analysis and it produced at the end of the output, after running 10000 events

SPIN_CORRELATIONS = 0 Rivet.Analysis.Handler: INFO Finalising analyses _sigma1=-0.0172222 _sigma2=-0.144111 _sigma3=-0.0331111 _sigma4=-0.0338889 A_fastslow=0.413139

======================================

SPIN_CORRELATIONS = 1 Rivet.Analysis.Handler: INFO Finalising analyses _sigma1=-0.0142222 _sigma2=-0.137667 _sigma3=-0.035 _sigma4=-0.0363333 A_fastslow=0.360876

This done using a fresh installation of Sherpa 1.2.1 downloaded yesterday, after installing the patch above. And I did see the out message about only Amegic including spin correlations if I I switched the ME to Comix instead so the patch did properly modify SHERPA/Single_Events/Single_Processes.C.

Would it be helpful to post a tarred version of my installation of Sherpa or try compiling your installation and re-running the Rivet analysis? Maybe this difference would be explained by some other difference in our installations?

Cheers, Chris

[Frank Siegert]

Hi Chris,

sorry about the late reply, the last weeks were incredibly busy. But I just had an idea what might be going wrong in your setup as opposed to mine: You have left the tau massless in the ME calculation, which basically means that the shower will have to shift it on its real mass shell "a posteriori". So the tau-momenta that enter the decay matrix element aren't equal to the ones in the production matrix element, which is a mismatch that the spin correlation algorithm can't cope with. Simple solution if this is indeed the culprit: Set them massive in the ME calculation using MASSIVE[15]=1 (just like you do for b+t) and re-generate the Process/ libraries and integration Results/.

Let me know if that makes a difference!

Cheers, Frank

[Generic User (don't modify these fields)]

Hi Frank,

Thanks; that s very interesting about the showering! But when I run your Rivet analysis over events created with your ee->ZH Run.dat configuration file, where the MASSIVE[15]=1 option is set explicitly, I seem to get a different result to when you ran it, as I mentioned before. When I run it over half of the events have an A_fastslow in the second bin (your sigma2) regardless of whether the SPIN_CORRELATIONS option is set to one or zero.

I was going to suggest that if you wished I could search through your release to look for differences with the one that I have, if you wanted to upload or email me a tar ball of your release. I think I could do it quite quickly with a bash script.

Best wishes, Chris

[Frank Siegert]

Hi Chris,

two issues:

1. I tried this with the recently released 1.2.2 and had to realise that yet another problem appeared in that release which makes spin correlations crash :( This is easily fixable, see #92 for more details, but still annoying.

2. One thing that I hadn't mentioned above, because I took it for granted: I was only using tau -> pi nu decays in my testing (because that's the only ones to which the Afastslow=-0.25 should apply). Did you do that as well, i.e. did you have a Decaydata/tau-/Decays.dat in your working directory which restricts to only that one decay channel? I have just tried again with that and see -0.25 just fine.

So I have put together a tar ball and shell script which contains everything that I did (including the fix for #92). It only assumes that you have already installed Rivet (using the rivet-bootstrap script) and have source the rivetenv.sh created by that. From then on it's as simple as

tar xzf sctest.tar.gz
cd sctest
./test.sh

That will do two Sherpa runs, the first of which with SC gives me

Rivet.Analysis.Handler: INFO  Finalising analyses
_sigma1=6.98662e-06
_sigma2=6.60171e-06
_sigma3=1.12098e-05
_sigma4=1.15149e-05
A_fastslow=-0.2516
Rivet.Analysis.Handler: INFO  Processed 10000 events

and the second without SC gives me

Rivet.Analysis.Handler: INFO  Finalising analyses
_sigma1=9.22351e-06
_sigma2=8.93663e-06
_sigma3=9.12183e-06
_sigma4=9.03105e-06
A_fastslow=0.0002
Rivet.Analysis.Handler: INFO  Processed 10000 events

Can you try from that?

[Generic User (don't modify these fields)]

Hi Frank,

Aah yes; I had assumed that your Rivet analysis veto'd the events with other types of hadronic tau decay.

I now see the expected results for A_fastlow using your Rivet analysis with and without the SPIN_CORRELATIONS flag, for Z and SM H to tau tau decays.

Thanks so much for your help! Chris

[Frank Siegert]

Great, thanks.

[Generic User (don't modify these fields)]

Hi Frank,

So I have since found that the spin correlation information is being propogated, but only in your e+e- ->ZH ->ll tautau events.

My analysis of the pp->ZH->ll tautau still shows no evidence of asymmetry in the pion energy spectrum of A_fastslow = 0, instead of -0.25.

I have altered your Rivet analysis so that it can also do this test on files with many pions and taus, and it shows the same results as your analysis in the ee->ZH->lltautau decays (A_fastslow = -0.25) , but still A_fastslow = 0.02 for pp->ZH->ll tautau.

I've attached the Rivet analysis I used and the Run.dat that has all the options that you specified before. Can you confirm this please?

Best wishes, Chris

[Frank Siegert]

Hi Chris,

Looking at the events which are produced by your run card I have a suspicion where this problem comes from: The tau momenta are shifted about quite often before they decay, e.g. in the shower and QED radiation. This probably breaks the spin correlation algorithm, which assumes a factorisation into production and decay without any other changes "in between".

I can't look into it any closer currently because I am travelling until Aug 9th. And I don't have an immediate idea how to solve this in a simple way, so I'll have to think about it a bit.

Thanks in any case for bringing this to our attention and following up through the many stages of it.

Frank

[Frank Siegert]

This would be possible to fix for Amegic, but that wouldn't be very helpful for most of our SM samples which use Comix to produce the tau. Thus postponed until the new spin correlations (with the full inclusive decays package) are implemented in 2.0 and also available for Comix.

[adam.martin@cern.ch]

Hello-

Has the issue of spin correlations in h-> tau tau-> hadronic tau decays been fixed in the current Sherpa 2.0? I have been trying to reproduce the distributions in hep-ph 0305082 for gg->h->tau tau -> pi^{+ nu pi}- nu and have had no success. I am running with Amegic and setting SPIN_CORRELATIONS=1 and HARD_SPIN_CORRELATIONS = 1. The run card is attached. Thanks

Adam Martin

[adam.martin@cern.ch]

sherpa2.0_higgstotautauruncard

[Frank Siegert]

Dear Adam,

Sorry about the late reply! Yes, the spin correlations should work in that example. But for hadronic tau decays you also need

SOFT_SPIN_CORRELATIONS = 1

cf. http://sherpa.hepforge.org/doc/SHERPA-MC-2.0.beta2.html#Further-remarks

If you are still seeing any issues, please feel free to reopen with more details.

Cheers, Frank