Home » Blogs » devika's blog

Run 13 W Analysis : Final Results : BG Estimation using New (SL16g) embedding

Updated on Thu, 2017-10-12 12:52. Originally created by devika on 2017-08-22 15:11. 
 BG Estimation using New (SL16g) embedding in comparison to preliminary (SL16f) embedding
 
Run 13 Period 1:

bla
 

 
Run 13 Period 2:

Tau Embedding Issue


Summary

  • The first problem was W->Tau->e+nu is not properly handled in GEANT.
  • Reported to Jason. He found several bugs and fixed them. Also we had to add neutrinos to GEANT by hand (unfortunately GEANT was tried to decay them)
  • After above fixes, the first problem seems to solved but another came, Polarization of decaying tau was not set.
  • Jason suggested to decay them using PYTHIA 8 decayer. (PYTHIA 8 gives nice way of handling tau polarization) [However this method might need some matrixes that would implement in PYTHIA 8 generator. But we used PYTHIA 6 generator) So did not work! (at least for me!) / or may be there's another explanation ?
  •  



Explanation from Jason :


08 /29/17 : 

The initial W decay goes to tau + X as planned.  The tau is pushed onto the geant stack for further processing.  Unfortunately, so are all of the other particles in the decay chain.  So we end up with tau --> e+ nu in the event record twice. Essentially, the particles in the initial W-->tau decay are not being deselected. I vaguely recall that we tracked this issue once before.... but don't see anything in the CVS commit history. 

From the log file, first event has the following system...

    no        id   name            status     mothers   daughters     colours      p_x        p_y        p_z         e          m
     0        90   (system)           -11     0     0     0     0     0     0     -0.046     -5.798    -28.131     85.207     80.220
     1        24   (W+)               -22     0     0     2     3     0     0     -0.046     -5.798    -28.131     85.207     80.220
     2       -15   (tau+)             -23     1     0     4     6     0     0     -7.577    -29.549     16.027     34.505      1.777
     3        16   nu_tau              23     1     0     0     0     0     0      7.531     23.751    -44.158     50.702      0.000
     4       -16   nu_taubar           91     2     0     0     0     0     0     -2.010     -8.374      4.573      9.751      0.000
     5       -11   e+                  91     2     0     0     0     0     0     -3.700    -12.298      6.063     14.202      0.001
     6        12   nu_e                91     2     0     0     0     0     0     -1.866     -8.877      5.390     10.552      0.000
                                   Charge sum:  1.000           Momentum sum:     -0.046     -5.798    -28.131     85.207     80.220

The W creates a tau, which subsequently decays via tau --> e nu ...

The code is *supposed* to place the tau onto the geant stack for further processing, and then pass to pythia for its decay.  We see this in the next printout from pythia

 --------  PYTHIA Event Listing  (complete event)  ---------------------------------------------------------------------------------

    no        id   name            status     mothers   daughters     colours      p_x        p_y        p_z         e          m
     0        90   (system)           -11     0     0     0     0     0     0     -7.577    -29.549     16.027     34.505      1.777
     1       -15   (tau+)             -23     0     0     2     4     0     0     -7.577    -29.549     16.027     34.505      1.777
     2       -16   nu_taubar           91     1     0     0     0     0     0     -0.103     -0.423      0.025      0.436      0.000
     3       -11   e+                  91     1     0     0     0     0     0     -6.374    -25.276     13.647     29.423      0.001
     4        12   nu_e                91     1     0     0     0     0     0     -1.100     -3.850      2.355      4.645      0.000
                                   Charge sum:  1.000           Momentum sum:     -7.577    -29.549     16.027     34.505      1.777


So... I expect to see a positron with pz = 13.647 in the FZD file.  And I do.  Unfortunately, I *also* see the positron from the initial W --> tau decay chain.

starsim> gfile p /star/u/jlzhang/data01/wEmbedding2013_pub/Wpt_2013/fzd/st_14137049_0.starsim.fzd
starsim> trig 1
starsim> gprint kine

...
     77  POSITRON      2    -3.7003   -12.2984     6.0633    14.2023    30    31
...
     80  POSITRON      2    -6.3743   -25.2759    13.6466    29.4234    32    33



09/20/17:

I found two bugs, one in the interface between the decay manager and starsim, the other in the pythia8 decayer.

The bug in the interface was due to an uninitialized array of flags.  If the flag is zero, the particle might not get passed back to geant depending on the logic.  If it was not zero the particle always gets passed back to geant.  Since the array was not initialized to zero, every particle in the chain got passed back to geant.

The second bug has to do with how pythia 8 simulates some decays.  It may setup a "system" particle as its first entry.  when that was the case, I as ignroing the system particle and, consequently, messing up pointers to daughter particles.

I checked code in recently to fix these issues, and it should be available in DEV.  I believe your macros should work now.

But the code crashed again even with the DEV library

09/21/17:

Looks like it is crashes when it reaches the part of the code where it tries to handle particles that G3 doesn't know about.  It tries to decay them.  But in
this case, the particle is a neutrino, so it has no daughters to decay.

I suspect the issue is that the tau neutrino isn't known to geant... this is problematic because the rule I setup for handling unknown particles is to have them decay immediately.  Neutrinos don't decay, so we end up accessing a null pointer.

 To test this, you can try adding the neutrinos to geant using the AddParticleToG3 method defined on StarParticleData.  I would add both neutrinos and antineutrinos.  Set them up as G3 particle IDs 60, 61, 65.


TParticlePDG * StarParticleData::AddParticleToG3  ( const char *  name, 
    const double  mass, 
    const double  lifetime, 
    const double  charge, 
    const int  tracktype, 
    const int  pdgcode, 
    const int  g3code, 
    const double *  bratio = 0, 
    const int *  mode = 0  
  )  

Life time of Neutrinos ? (PDG doesn't have a value) and mass, What to put exactly ?

PDG parameters: link


track types:

{ 1, "Photon" },     
{ 2, "Leptom" },
{ 3, "Hadron" }, 
{ 4, "Hadron" },
{ 5, "Lepton" },
{ 6, "Geantino" },
{ 7, "Cherenkov" },
{ 8, "Heavyion" },
{ 9, "Monopole" }




10/2/17

We are running into an issue here because we have not set the polarization vector for the tau being decayed.

If you scroll down to the "tau decays" section here...
http://home.thep.lu.se/~torbjorn/pythia81html/ParticleDecays.html

This may be a solution:

py8decayer -> Set( "ParticleDecays:sophisticatedTau = 2" );
py8decayer -> Set( "ParticleDecays:tauMother = <pdg of Z0>" );
py8decayer -> Set( "ParticleDecays:tauPolarization  = <spinup>" );

This tells pythia8 to decay the tau using a model, the mother particle for the decay, and the polarization information.

Here, spinup is defined by the Les Houches Accord, as the cosine of the angle between the spin vector and the momentum vector, as measured in the lab frame...  by which I think they mean the frame of the mother particle...

http://home.thep.lu.se/~leif/LHEF/classLHEF_1_1HEPEUP.html#af6db3ad48c1a9af8ada8f9e291cc07b4

The other option would involve passing the polarization information (if it is available) from pythia 6, through geant, through ROOT TParticle class, and into pythia 8.   Let me know if you need this, and we will figure out how to implement.

********************************************


I tried following Options for ParticleDecays:sophisticatedTau, ParticleDecays:tauMother, ParticleDecays:tauPolarization  :

decayPy8->Set( "ParticleDecays:sophisticatedTau = 2" );                                                                            
decayPy8->Set( "ParticleDecays:tauMother = 0" );                                                                                   
dacayPy8->Set( "ParticleDecays:tauPolarization  = 0" );



 
10/3/17

 I'm pretty sure that we have limited options once we require keeping the W (or Z) in the geant event record. When we split particle generation (pp-->Z) from the particle decay (Z-->tau tau), we lose the ability to do correlated decays for the Z.  We also lose the matrix elements from W production, so the decay stage will always treat the W as "unpolarized".  (Thus the warnings from pythia).

So I see a few ways forward:

1) Use pythia 8, let it decay the W/Z, lose the particles in the (geant) event record.

You will still be able to trace the W/Z decay and daughters through the event generator record, but that's another file to go through.
The matrix elements, and all correlations for the tau decays, will be handled "properly".

I put "properly" in quotes, because ultimately pythia assumes unpolarized pp collisions.  So the matrix elements for W/Z production integrate over the various spin states equally, whereas RHIC doesn't.

2) Do what we are currently doing.  Use pythia 6 generate, decay in pythia 8, save particles
in geant record.

We will need to force the tau decay by hand--

py8decayer -> Set( "ParticleDecays:sophisticatedTau = 2" );
py8decayer -> Set( "ParticleDecays:tauMother        = 24" ); // for W+/-, ...
py8decayer -> Set( "ParticleDecays:tauPolarization  = <spinup>" );



Some Docu: <spinup> click
http://svn.cern.ch/guest/AliRoot/trunk/PYTHIA8/pythia8175/src/TauDecays.cxx



-1 < Eta < +1

Seems there's a problem with "tau" BG in new embedding. Checking !!!

BG Counts:

Why Tau BG count is so small?



W---> Tau Selection in W code 






 
»