Low mass SM Higgs search

LowMassSMHiggs

Ressource Material

1. CVS Version of the code: ​version of the code
2. Ongoing Paper: ​paper

Code V2.5

After a new discussion (September 09) between Olivier and Pierre and inspired by a discussion to Fabio. We want to include the multi-channel techniques in MW. In the previous code (2.0), an overconstrained systems lead to unaligned peak, but also to different change of variable, different because they are not aligning the same peak. In consequence, the multi-channel techniques is possible to performed.

In principle, the multi-channel is pointless because the correct area of the PS should be selected by any of those change of variables (the constraints should be consistent) but MW computes also weights for different permutation/background where those constraints are in conflicts, causing slow integration. For those events/permutations, the multi-channel can contibutes to fastenize the integral (a lot?)

Development of Code

In a first step, (in progress), we will keep the different changes of variables provides by the python supra-code and run in multi-channel in those cases. Some script are added in the Python supra-script in order to compute the weights associated to each channel. The 'MadEvent trick' is used in order to choose wisely the weights of each channel.

A second step, will be to check to modify the supra-script in order to create additional change of variables in order to have all peaks aligned in at least one change of variables

We could(should?) think to fuse the supra code with Madgraph5 in order to have a full multi-channel program (multi-channel on the square matrix element and on the peak position). But this will be MG5 dependant and has some drawback (impossibility to modify Transfer Function after the diagram generation)

Test of V2.5

Test of V2.5 against 2.0:

Process	param	2.0	2.5	Comment
W production (->e-)	W at 80.4	14.36273+-7.3e-05	14.36218 +-1.5e-05	OK
	W at 100	15.80653 +-8.8e-05	15.80328 +-2.0-05	OK
	W at 150	17.8815 +- 1.0e-04	17.87489 +-3.0e-05	OK
(W>lnu)(W>jj)	80.4	48.27716+- 7e-05	48.255909+-6.6e-05	OK
	100	46.64555+- 8e-05	46.632452+- 6.1e-05	OK
	150	56.563823+- 6.5e-05	56.575452+-6.9e-05	OK
semi-lept tt	Mt=150	813.6807+-0.0015	813.6377+-0.0013	OK
	152.5	813.3573+-0.0343	812.5640 +-0.0032	OK
	155	812.6200+-0.0015	812.1788+-0.0024	OK
	157.5	812.8469+-0.0013	812.8812+-0.0015	OK
	160	814.1727+-0.0015	814.2527+-0.0047	OK
	162.5	815.5738+-0.0013	816.0374+-0.0037	OK
	165	819.1933+-0.0019	818.2402+-0.0014	more confident in 2.5
	167.5	822.4768+-0.0026	821.9353+-0.0038	OK
	170	827.7806+-0.0013	825.9346+-0.0019	more confident in 2.5

Check of version 2.5

Phase-Space Check

process	block	V2.5	true value	remarque
pp>e+e-u	A	(6.2952+-0.0017)E-5	6.299E-5
bg>(t>b(W>jj))jj	A+E	149301+-282	149748
jj(W>jj)jj	A+D	3.2503+- 0.0046	3.254
jj(W>eve)	A+C	3.244+- 0.008	3.254
jj(t>b(W>eve))	A+B	150800+-1900	149748
jj(W>bt) with (t>b(W>eve))	A+A	(5.233+-0.004)E+19	5.22E9
bg>(t>b(W>jj))jj	multi-channel	148500+- 1300	149748	(A+DD/A+E/A+11) (5e-17/1e-16/148500)
bg>(t>b(W>jj))jj	multi-channel		149748	(A+DD/A+E)
(W>lve)	B	(1.32 +-0.08)E-8	1.28E-8	instability in the jacobian (if pz(l)=E(l))
(W>lve)j	B	(6.2927 +- 0.0039)E-5	6.299E-5	non sensitive to the jac=0 area
uu~>(W+>b~(t>b(W+>e+ve)))(W->e-ve~)	B+A	5.201 +-0.046 E9	5.22E9
	B+B	149000+-500	149748
(W>lv)(W>lv)	B+C	3.238+- 0.007	3.254
(W>lv)(Z>mu+mu-)	B+D	3.24 +- 0.05	3.254
bg>(t>b(W+>jj))(W->e-ve~)	B+E	148100+- 1100	149748
(W>lv)(Z>mu+mu-)	B+fuse	3.24 +- 0.04	3.254
(W>lv)(Z>mu+mu-)	multi-channel	3.254+-0.003	3.254
(W>svt~(sta->ta-n1))	B+C (both massif)	(5.959+-0.006)E-5	5.967E-5
pp>(t>b(W+>e+ve))	C	1.28E-1	6.2982E-005	WRONG
tt~	D	5.247 +- 0.021 E+9	5.227E+09
H>WW>e+e-veve~	E	531.567756+-121.365377	3.254	instability in jac ????
H>WWj>e+e-veve~j	E		149753
WW>e+e-veve~	F	565.237354+-123.048905	3.254	instability in jac ?????
WWj>e+e-veve~j	E		149753
bu > td; t>benu	C	0.0468	3.257	in progress
bu > td; t>benu	B	3.25	3.257	in progress

Cross-section Check

process	block	ratio ME/MW
(W>lv)	B	0.9991 +- 0.0014
(W>svt~(sta->ta-n1))	B+C	1.003 +- 0.006
SMU SMU	F	1.020 +- 0.005
tt> fully leptonique	D	1.00056 +- 0.025

Code V2.0

After a discussion (18 jan 08) between Olivier and Pierre, we have planned to write a new version of the code, with particular emphase on the generic and modular characters of the algorithm. In this new code, a supra-code (python script) will produce a phase-space generator (in fortran) that is specific to a certain topology. This version is currently on CVS (see link above).

Advantages of V2.0

The main advantage of this new organization of the code resides in the factorization of two difficulties:

• Given a topology, find a phase space generator that is appropriate to ME method
• write a code that select automatically the adequate phase-space parametrization for any topology

In the new code, the main code (which is almost the only topology-dependent file) has a very simple structure, that can be handled easily, even written explicitly for a given topology. Only the way to generate it automatically is intricate. If we choose the supra code to generate this file, it is still very easy to check its contents.

Also in this new version, it will be really easy to implement new blocks or new classes of ECS in the future.

The supra-code (python script)

This is for sure the most difficult part. The supra code will

• read the topology and record it in an appropriate structure: MadWeightAnalyzer MadWeightDiagramClass
• determine the class of ECS as well as the block structure of each blob, and organize the blocks in the adequate order
• write the main code in fortran (see below) that is the topology-dependent part of the phase-space generator

The phase-space generator

The associated fortran code will partially result from the supra-code. It will contain several things: PhaseSpaceGenerator

I. Generic subroutines

One subroutine for each block and each class of ECS. As discussed in the paper, a block (or a class of ECS) is nothing else than a specific local change of phase-space parametrization. Given the inputs (parameters+dynamical variables), the subroutine associated to a block will solve the change of variables and compute the jacobian. These subroutines are generic so that there is no need to generate them with a supra code.

II. The main code

This code will be specific to the topology at work, and generated by the supra-code. The aim of the main code is to generate a phase-space point and compute the associated phase-space weight and jacobian. This will be done according to the following steps:

• generation of invariant masses linked to factorized propagators. This generation will occur in an ascendant way so that we avoid unphysical regions as much as possible. This is particularly useful for topologies like H>WW*, where at least one of the W is off-shell.

• generation of momenta that are factorized (according to the decision made by the supra-code) according to the transfer function. We should generate points according to Gaussian distributions

• generation/resolution of the kinematics associated to the blobs (+ computation of the associated jacobian). These are made of blocks, in the sense discussed in the paper. The kinematics of any blob will be generated/resolved by calling (a certain number of) block subroutines defined in I.

• resolution of the change of variables corresponding to the ECS at work. This will be done by the call of a generic subroutine (see I.)

So the main code will be made of external calls to several blocks and one class of ECS. The number of calls, their ordering, the inputs that are passed through the subroutines depend on the topology. These issues will be handled in the supra-code.

III. Status and checks

Each block or ECS has been checked at least once by computing the phase space volume with a phase-space parametrization involving this block.

Block_name	Toplology	PS volume	check
Block A	ECS B + bl A (massless)	3.78 +/- 0.008	3.89
Block B	ECS B + bl B (massless)	0.0166 +/- 0.0001	0.0166
Block B	ECS B + bl B (massive)	0.001407 +/- 9e-6	0.001401
Block C	ECS B + bl C (massless)	(6.28+/-0.014)e-5	6.30e-5
Block C	ECS B + bl C (massive)	(9.75+/-0.02)e-6	9.74e-6
Block D	ECS B + bl D (massless)	(6.27+/-0.02)e-5	6.30e-5
Block E	ECS B + bl E (massless)	0.0165 +/-0.0001	0.0166
ECS A	ECS A (3FP, massless)	(6.301+/-0.01)e-5	6.299e-5
ECS A	ECS A (3FP, massive)	(9.741+/-0.01)e-6	9.755e-6
ECS B	ECS B (3FP, massive)	(9.740+/-?)e-6	9.755e-6
ECS C	ECS C (3FP, massless)	(6.293+/-0.003)e-5	6.299e-5
ECS C	ECS C (3FP, massive)	(1.716+/-0.001)e-5	1.715e-5
ECS D	ECS D (massless)	43.73+/-12.41	44.60
ECS D	ECS D ( massive)	692.29+/-17.88	694.28
ECS E	ECS E (massless)	0.01662+/-?	0.01662
ECS E	ECS E ( massive)	0.001627	0.001631
ECS F2	ECS E (massless)	0.01664+/-2e-5	0.01662
ECS F2	ECS E (massive)	0.001631+/-3e-6	0.001631

IV. Differential weight

A histrogram package (dbook) has been set up in MadWeight, in order to draw differential distributions of the weight. One first application is the reconstruction of top quark pair invariant mass in tt>2l events.

-

--- MadWeight: the general code

Status and checks

Checked processes (after the fuse of MW in MG trunk):

Process	status
gg> (h>(w+>e+ ve )(w- > mu- vm~ ) )	OK!	Olivier
gg<script type="text/javascript" src="​http://cp3wks05.fynu.ucl.ac.be/twiki/pub/TWiki/TinyMCEPlugin/tinymce/jscripts/tiny_mce/themes/advanced/langs/en.js"></script><script type="text/javascript" src="​http://cp3wks05.fynu.ucl.ac.be/twiki/pub/TWiki/TinyMCEPlugin/tinymce/jscripts/tiny_mce/plugins/twikibuttons/langs/en.js"></script><script type="text/javascript" src="​http://cp3wks05.fynu.ucl.ac.be/twiki/pub/TWiki/TinyMCEPlugin/tinymce/jscripts/tiny_mce/plugins/twikiimage/langs/en.js"></script>8;gt;( h>(w+>e+ ve )(w- > e- ve~ ) )	-> event	Olivier
gg>( h>(w+>e+ ve (w- > e- ve~ ) )	-> event	Olivier
pp>(er+>e+ n1) (er->e- n1)	OK!	Pierre
pp>(mur+>mu+ n1) (mur->mu- <script type="text/javascript" src="​http://cp3wks05.fynu.ucl.ac.be/twiki/pub/TWiki/TinyMCEPlugin/tinymce/jscripts/tiny_mce/themes/advanced/langs/en.js"></script><script type="text/javascript" src="​http://cp3wks05.fynu.ucl.ac.be/twiki/pub/TWiki/TinyMCEPlugin/tinymce/jscripts/tiny_mce/plugins/twikibuttons/langs/en.js"></script><script type="text/javascript" src="​http://cp3wks05.fynu.ucl.ac.be/twiki/pub/TWiki/TinyMCEPlugin/tinymce/jscripts/tiny_mce/plugins/twikiimage/langs/en.js"></script>n1) )	not checked yet	Pierre
pp>(t>b(W+>e+ve))(t~>b~(W->mu-vm~))	Ok!	Pierre
pp>(t>b(W+>mu+vm)) (t~>b~(W->mu-vm~))	not checked yet
pp>(t>b(W+>mu+vm)) (t~>b~(W->mu-vm~))	not checked yet
pp>(t>b(W+>mu+vm)) (t~>b~(W->jj))	not checked yet
pp>(t>b(W+>jj)) (t~>b~(W->jj))	not checked yet

Things to do for the next Release

1. Grid initialization.
2. relative weight between solution in Blob/ECS

Different Idea

1. Grid initialization:
   The transfer functions coud(should?) have their own grid this could be achieved by integrating the one-dimensional transfer functions. If this is needed (probably only for some hard cases), this could be done on an event-by-event basis. In other case a typical events could do the job once.
2. Tau decay;
   it could be possible to have a special change of variable for the tau>lepton decay, using the coliniarity of the decay. A starting grid for the neutrinos angles could be used if we want to stay completely general.
3. Transfer function:
   we could use a supra code trick for the transfer functions. This will give gain of time (~1%) but the main goal is to simplify the way to add a transfer functions in special case. -> Done in Version 2.5
4. Permutation:
   we could/should develop a python code treating the permutation (supressing the identical permutation). This could be achieved with a MG stand alone test.
5. grid for solution choices:
   For the moment each solution (in change of variables) has the same probability to choose. Adding an adaptative grid on this could be interesting (->include those variable in VEGAS). An other idea will be to use the jacobian in order to improve our choices
6. Adaptative precision:
   For the moment the weight in each SubProcess the weights are computed with the same precision, in a normalized mode or in order to have refine procedure, a adaptative precision could be cut the processing time by a significative factor.

-- Main.OlivierMattelaer - 24 Nov 2008