| Version 1 (modified by , 13 years ago) ( diff ) |
|---|
Low mass SM Higgs search
LowMassSMHiggs
Ressource Material
- CVS Version of the code: version of the code
- 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
- Grid initialization.
- relative weight between solution in Blob/ECS
Different Idea
- Grid initialization: <br /> 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.
- Tau decay;<br /> 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.
- Transfer function:<br /> 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
- Permutation:<br /> we could/should develop a python code treating the permutation (supressing the identical permutation). This could be achieved with a MG stand alone test.
- grid for solution choices: <br />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
- Adaptative precision:<br />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
