Gauss merge requestshttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests2024-03-28T00:19:19+01:00https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1051Draft: Add Belle 2018 model to EvtGen - JIRA LHCBGAUSS-28942024-03-28T00:19:19+01:00Camille NormandDraft: Add Belle 2018 model to EvtGen - JIRA LHCBGAUSS-2894Adding a model in EvtGen of $`D \to K_S \pi\pi`$ based on [this BELLE/BaBar paper](https://arxiv.org/abs/1804.06153) from 2018.
The model can be used
* in "standalone" mode, to generate D-\>Kspipi.
* in addition with the `BTODDALITZCPK...Adding a model in EvtGen of $`D \to K_S \pi\pi`$ based on [this BELLE/BaBar paper](https://arxiv.org/abs/1804.06153) from 2018.
The model can be used
* in "standalone" mode, to generate D-\>Kspipi.
* in addition with the `BTODDALITZCPK` model on a parent B meson that takes as input gamma, deltaB and rB, to be used in gamma analysis.
JIRA task: https://its.cern.ch/jira/browse/LHCBGAUSS-2894
generated with:
/cvmfs/lhcb.cern.ch/lib/var/lib/LbEnv/3067/stable/linux-64/bin/lb-dev Gauss/v49r25John James BackJohn James Backhttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1045No Acceptance Cuts for daughters of Long Lived particles2024-03-26T14:34:38+01:00Andrea MerliNo Acceptance Cuts for daughters of Long Lived particlesOnly daughters of $\Omega^-$, $\Xi^-$, $\Xi^0$, $\Lambda^0$ and $K_S$ are removed from the acceptance cut of standard tools [DaughtersInLHCb.cpp#L95](https://gitlab.cern.ch/lhcb/Gauss/-/blob/Sim10/Gen/GenCuts/src/DaughtersInLHCb.cpp?ref_...Only daughters of $\Omega^-$, $\Xi^-$, $\Xi^0$, $\Lambda^0$ and $K_S$ are removed from the acceptance cut of standard tools [DaughtersInLHCb.cpp#L95](https://gitlab.cern.ch/lhcb/Gauss/-/blob/Sim10/Gen/GenCuts/src/DaughtersInLHCb.cpp?ref_type=heads#L95). Acceptance cuts are wrongly applied to daughters of $\Sigma^+$, $\Sigma^-$, long lived user defined particles (e.g. [Bd_MuPiMajoranaNeutrino2MuPi,m=3000MeV,t=100ps,DecProdCut.dec](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v30r102/dkfiles/Bd_MuPiMajoranaNeutrino2MuPi,m=3000MeV,t=100ps,DecProdCut.dec), [Bd_MuXMajoranaNeutrino2EENu,m=4000MeV,t=100ps,SS,DecProdCut.dec](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v30r102/dkfiles/Bd_MuXMajoranaNeutrino2EENu,m=4000MeV,t=100ps,SS,DecProdCut.dec)) or resonances produced in long lived user defined particles (e.g. [Bd_MuXMajoranaNeutrino2MuX,m=1600MeV,t=1000ps,SS,DecProdCut.dec](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/blob/v30r102/dkfiles/Bd_MuXMajoranaNeutrino2MuX,m=1600MeV,t=1000ps,SS,DecProdCut.dec)). Here I propose a much robust way to identify the daughters of long lived particles that does not rely on PDG ID. For the time being, the changes have been implemented only in DaughtersInLHCb. If they are accepted, I will implement them also in all the other tools that use the old buggy logic to exclude long lived particle daughters. This merge request has to be ported also to Sim09.Andrea MerliAndrea Merlihttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1037Fixes for lcg 1042024-01-29T10:34:57+01:00Marco Clemencicmarco.clemencic@cern.chFixes for lcg 104- fixed stand-alone compilation of public headers (see lhcb/LHCb!4211)
- some headers were fixed and some unused ones removed, in particular those containing syntax errors
- set the maximum C++ standard to 17 for GenEvent, because the ...- fixed stand-alone compilation of public headers (see lhcb/LHCb!4211)
- some headers were fixed and some unused ones removed, in particular those containing syntax errors
- set the maximum C++ standard to 17 for GenEvent, because the version of Pythia8 we use does not work with C++20 (see also Gaussino/Gaussino!158)https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1029Draft: Switch to master branch of EvtGen @ HepForge for Sim112024-03-28T00:28:53+01:00Gloria CortiDraft: Switch to master branch of EvtGen @ HepForge for Sim11This corresponds to !696 for Sim11 that is instead now targeting the `Sim10` branch
cc: @kreps, @jback, @tlathamThis corresponds to !696 for Sim11 that is instead now targeting the `Sim10` branch
cc: @kreps, @jback, @tlathamhttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1028Draft: Fix EvtIdSet initialisations2024-03-28T00:26:22+01:00Thomas LathamDraft: Fix EvtIdSet initialisationsAdapt code in Sim10 version of LbEvtGen to upstream changes to EvtIdSet constructors.
Created following discussion in https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1021#note_7312822
Closes #120Adapt code in Sim10 version of LbEvtGen to upstream changes to EvtIdSet constructors.
Created following discussion in https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1021#note_7312822
Closes #120https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1021Draft: Fix EvtIdSet initialisations2024-03-28T00:28:52+01:00Thomas LathamDraft: Fix EvtIdSet initialisationsAdapt code in LbEvtGen to upstream changes to EvtIdSet constructors.
Closes #120Adapt code in LbEvtGen to upstream changes to EvtIdSet constructors.
Closes #120https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/1020Draft: Add functionality to propogate weights through Pythia to HEPMC2023-11-06T17:08:41+01:00Nathan Allen Griesernathan.allen.grieser@cern.chDraft: Add functionality to propogate weights through Pythia to HEPMCAdd necessary feature to propogate MadGraph systematic variations through Pythia to HEPMC. Supports any other weights that need are passed to Pythia.Add necessary feature to propogate MadGraph systematic variations through Pythia to HEPMC. Supports any other weights that need are passed to Pythia.Philip James IltenNathan Allen Griesernathan.allen.grieser@cern.chPhilip James Iltenhttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/995Turn off the default behavior of Madgraph cuttool.2023-10-18T11:23:12+02:00Nathan Allen Griesernathan.allen.grieser@cern.chTurn off the default behavior of Madgraph cuttool.Decay files should have the option to pass cut tools to the Madgraph configuration, and not have it being forced to none.
We should probably also think about if we want to remove some of these other default settings to avoid this sort o...Decay files should have the option to pass cut tools to the Madgraph configuration, and not have it being forced to none.
We should probably also think about if we want to remove some of these other default settings to avoid this sort of issue in the future where people don't realise their `dkfile` options are being overwritten by the defaults.Gauss/v56r6Nathan Allen Griesernathan.allen.grieser@cern.chNathan Allen Griesernathan.allen.grieser@cern.chhttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/994Draft: Dependencies and Configurable options for Madgraph in Futurev52023-10-24T20:21:18+02:00Ruben PozziDraft: Dependencies and Configurable options for Madgraph in Futurev5Integrating Madgraph into Futurev5. Dependent on https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/151.
A more detailed explanation with diagrams, and on **how to test it** can be found here https://codimd.web.cern.ch/JtD7xAGqS6...Integrating Madgraph into Futurev5. Dependent on https://gitlab.cern.ch/Gaussino/Gaussino/-/merge_requests/151.
A more detailed explanation with diagrams, and on **how to test it** can be found here https://codimd.web.cern.ch/JtD7xAGqS6S9eSIyfmKqRA#.
It depends on implementation in Gaussino as described in Gaussino/Gaussino#39Ruben PozziRuben Pozzihttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/971Decay model for Phi needs to be updated2023-06-27T17:51:06+02:00Arnau Brossa GonzaloDecay model for Phi needs to be updatedActual model for Phi decays (EvtPhiDalitz) does not include angular distributions, and thus the helicity distribution is generated flat.
The old model was also buggy and needed to be fixed.
EvtVector3R bug also fixed
Presentation at s...Actual model for Phi decays (EvtPhiDalitz) does not include angular distributions, and thus the helicity distribution is generated flat.
The old model was also buggy and needed to be fixed.
EvtVector3R bug also fixed
Presentation at simulation meeting: https://indico.cern.ch/event/1283936/Gauss/v49r25Antonio Romero VidalArnau Brossa GonzaloAntonio Romero Vidalhttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/970Updating LbMadgraph and qmt2024-03-28T00:26:21+01:00Ruben PozziUpdating LbMadgraph and qmtModernizing and simplifying LbMadgraph to use it as template for implementation in Gaussino.
- Removing header file for LbMadgraph and adding it to the source file
- Modernization in the source file
- Fixing error with madgraph qmt test...Modernizing and simplifying LbMadgraph to use it as template for implementation in Gaussino.
- Removing header file for LbMadgraph and adding it to the source file
- Modernization in the source file
- Fixing error with madgraph qmt test and rewritingSim10/2024.02 (Gauss v56r8)Ruben PozziRuben Pozzihttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/969Correct wrong handling of RunNumbers for MadGraph2023-07-21T18:39:16+02:00Philip James IltenCorrect wrong handling of RunNumbers for MadGraphThis merge request provides an alternative solution to !966.This merge request provides an alternative solution to !966.Gauss/v56r5Philip James IltenAdrian Casais VidalPhilip James Iltenhttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/964Add GenXicc support for sqrt(s)=13.6TeV2023-04-25T16:47:03+02:00Michal KrepsAdd GenXicc support for sqrt(s)=13.6TeVGauss v56r4https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/962Add BcVegPy support for sqrt(s)=13.6TeV2023-04-25T16:55:35+02:00Michal KrepsAdd BcVegPy support for sqrt(s)=13.6TeVIn BcVegPy code we have hardcoded selection of gridpack directory, which does not support running at sqrt(s)=13.6TeV. This makes necessary change to code. For proper function, it will need also update of BcVegPyData to add corresponding ...In BcVegPy code we have hardcoded selection of gridpack directory, which does not support running at sqrt(s)=13.6TeV. This makes necessary change to code. For proper function, it will need also update of BcVegPyData to add corresponding gridpacks, which I will do as soon as gridpacks are generated.Gauss v56r4https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/960Adding PileUpTool to Madgraph adaptor2023-04-25T20:54:58+02:00Adrian Casais VidalAdding PileUpTool to Madgraph adaptorFollowing the [discussion ](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/merge_requests/1129#note_6603724) suggestions the PileUpTool is added by default to the Madgraph adaptor.
The other lines:
```
# Generation().DecayTool ...Following the [discussion ](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/merge_requests/1129#note_6603724) suggestions the PileUpTool is added by default to the Madgraph adaptor.
The other lines:
```
# Generation().DecayTool = ""
# Generation().SampleGenerationTool = "Special"
# # Special options.
# Generation().addTool(Special)
# Generation().Special.CutTool = ""
# Generation().Special.DecayTool = ""
# Generation().Special.ProductionTool = "MadgraphProduction"
```
are not included in the MR since the `Special` generation tool is already implemented in the adaptor and I believe that the `CutTool` and `DecayTool` are process specific. If that's not the case and these fields should be defaulted to `""` these can be adapted.Gauss v56r4https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/946Draft: Add the new Jpsi -> 4 leptons model2023-06-22T20:06:20+02:00Vitalii LisovskyiDraft: Add the new Jpsi -> 4 leptons modelThis MR adds a new EvtGen decay model that can be used to model Jpsi decays to 4 muons or 4 electrons (leptons of the same flavour).
The model is borrowed from the BES III collaboration in agreement between the physics coordinators of t...This MR adds a new EvtGen decay model that can be used to model Jpsi decays to 4 muons or 4 electrons (leptons of the same flavour).
The model is borrowed from the BES III collaboration in agreement between the physics coordinators of the two collaborations.
In BES III, this model was used as a combination of the "EvtDIY" model (Do It Yourself, that allows to plug any computed amplitude) and the (very long) amplitude expression that was coming in a separate .C file. The latter was adapted by Jianping Dai (BES III) to the LHCb case of unpolarised Jpsi production.
I have refurbished the code and performed numerous checks with it. It was checked that the Jpsi->4e and Jpsi->4mu simulations produce reasonable distributions. I also added checks for the spins of the particles etc.
Usage:
```
Decay J/psisig
1.000 e+ e- e+ e- PsiLLLL 3.097 0.000511;
Enddecay
```
or
```
Decay J/psisig
1.000 mu+ mu- mu+ mu- PsiLLLL 3.097 0.105658;
Enddecay
```
In principle, the model should also allow to simulate psi(2S) decays – thus the generic name and the need to provide the vector-meson mass as an argument; this was tested on 5 events but no check of the distributions was performed so far.
cc @lshchuts
Marked as a draft before some final checks are completed.Michal KrepsJohn James BackMichal Krepshttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/945update to AmpGen v2.42023-08-01T22:11:10+02:00Timothy David Evansupdate to AmpGen v2.4Updates AmpGen version to v2.4.
- Fixes the issues raised in https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/920 upstream
- Picks up improvements to source generation that should improve compile times (+source sizes) quite a bit.Updates AmpGen version to v2.4.
- Fixes the issues raised in https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/920 upstream
- Picks up improvements to source generation that should improve compile times (+source sizes) quite a bit.Gloria CortiAdam DavisTom HadavizadehPhilip James IltenGloria Cortihttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/944Fix Inclusive Userhook bug and configuration2024-03-28T00:21:32+01:00Tom HadavizadehFix Inclusive Userhook bug and configurationThis MR addresses two issues with the inclusive b-quark Userhook implementations for Pythia.
- The pT scale of the veto applied during the event evolution was being used before it was initialised. I've added more checks to prevent this ...This MR addresses two issues with the inclusive b-quark Userhook implementations for Pythia.
- The pT scale of the veto applied during the event evolution was being used before it was initialised. I've added more checks to prevent this happening.
- When used with most generation tools (e.g. SignalPlain or SignalRepeatedHadronisation) using the Userhooks will mean the pileup events are also produced with b-quarks in them. I've rewritten the python steering script to overwrite the chosen generation tool and force the use of 'Special', allowing separate Pythia instances for the signal and pile up. The normal 'DaughtersinLHCb' generator level cuts don't work with the Special tool so I've had to use the 'BcDaughtersinLHCb' tool and change the particle ID to different hadrons according to the requested EventType.
- The QMtest has been updated to use the new options fileSim10/2024.02 (Gauss v56r8)https://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/930Included variable width masses for GenXicc2023-02-03T11:09:08+01:00Philip James IltenIncluded variable width masses for GenXiccAs reported by @mpappaga, when generating resonances with GenXicc, the natural width of the double heavy baryon is not correctly sampled.As reported by @mpappaga, when generating resonances with GenXicc, the natural width of the double heavy baryon is not correctly sampled.Gauss v56r3Gloria CortiPhilip James IltenGloria Cortihttps://gitlab.cern.ch/lhcb/Gauss/-/merge_requests/929Draft: Decaying Luminosity2024-03-28T00:26:19+01:00Timothy David EvansDraft: Decaying LuminosityAdds the option to decay the luminosity, as expected in Run 5+.
- Adds a pileup tool that generates the time in the fill, and then a corresponding poisson distributed random number for the number of vertices.
- Adds a flag in Generatio...Adds the option to decay the luminosity, as expected in Run 5+.
- Adds a pileup tool that generates the time in the fill, and then a corresponding poisson distributed random number for the number of vertices.
- Adds a flag in Generation to give 'exclusive' productions (that is, event types where we force the parent particle to decay to a given final state). The reason for this is the distribution in time of signal, vs min bias is quite different, as the probability that there is a signal decay is ~ proportional to the number of vertices. Perhaps this flag could be deduced from the event type?
- The time in the fill is going to be a very useful number to store. There is a field in MCHeader for this but is used by ReDecay at the moment?Gloria CortiTimothy David EvansGloria Corti