Version 4 (modified by omatt, 8 years ago) (diff)

--

LowMassSMHiggs

## Ressource Material

1. 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 gg8;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- 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