wiki:MW_development

Version 2 (modified by trac, 13 years ago) ( diff )

--

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

Note: See TracWiki for help on using the wiki.