DecFiles issueshttps://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues2023-07-20T04:37:55+02:00https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/25Problem with SignalPIDList for Sigma_c+ -> Lambda_c+ gamma decfile2023-07-20T04:37:55+02:00Liupan AnProblem with SignalPIDList for Sigma_c+ -> Lambda_c+ gamma decfileI would like to add a decfile for [Sigma_c+ -> (Lambda_c+ -> p+ K- pi+) gamma]cc as attached.[Sigmac_Lcgamma_pKpi_LoKiGenCut.dec](/uploads/053bb55f4658f03e014828027a141ed7/Sigmac_Lcgamma_pKpi_LoKiGenCut.dec)
In the test, I got stuck wit...I would like to add a decfile for [Sigma_c+ -> (Lambda_c+ -> p+ K- pi+) gamma]cc as attached.[Sigmac_Lcgamma_pKpi_LoKiGenCut.dec](/uploads/053bb55f4658f03e014828027a141ed7/Sigmac_Lcgamma_pKpi_LoKiGenCut.dec)
In the test, I got stuck with errors:
Generation.SignalPlai... ERROR LoKi::GenCutTool:: No particles are selected from: Sigma_c*~- StatusCode=FAILURE
Generation.SignalPlai... ERROR LoKi::GenCutTool:: No particles are selected from: Sigma_c*~- StatusCode=FAILURE
Generation.SignalPlai... ERROR LoKi::GenCutTool:: No particles are selected from: Sigma_c*+ StatusCode=FAILURE
But there is no Sigma_c*+ in my decay descriptor.
It turns out that the option file produced have Generation().SignalPlain.SignalPIDList = [ 4214,-4214 ] for Sigma_c*+ rather than 4212 for Sigma_c+, as attached.
[26163271.py](/uploads/5e2133ee1bd60672f99f9b75680c132f/26163271.py)
Can anyone help point out where the problem is?
Many thanks!Michal KrepsMichal Krepshttps://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/24How to fix parsing issues in decfiles?2023-10-18T15:50:35+02:00Eduardo RodriguesHow to fix parsing issues in decfiles?Morning @kreps, @adavis, while exchanging and working on some DecayLanguage package enhancements for the "simulation wizard" under development by @admorris and others, we discussed certain issues in parsing dec files. @admorris mentioned...Morning @kreps, @adavis, while exchanging and working on some DecayLanguage package enhancements for the "simulation wizard" under development by @admorris and others, we discussed certain issues in parsing dec files. @admorris mentioned that he could parse just about everything with his enhancements and that triggered me to check matters to improve even more DecayLanguage.
Turns out, I can at present parse everything but 7 out of the 7831 decfiles in version v32r9. Not bad! Along the way I had to correct tiny things that seem to be ignored by EvtGen. At large I noticed the following:
- Encoding errors for certain characters such as `ó`. That can be because I'm on Windows but no harm in fixing special characters that should not be in the files.
- Spurious lines of the kind ` ~`. Strange that this goes unnoticed but my parser is strict and such lines anyway look like a bug.
- Spurious end of decay lines with `;2` instead of `;`. This is harmless but, again, my parser is strict, which is not a bad thing IMO.
![parser](/uploads/d983a453349f99377c443d6387b1c4a6/parser.png)
[Yes the whole test took about 14 minutes. That's reasonable given that it parsed and constructed the chains of millions in the job. For reference parsing the whole DECAY.DEC with 10k-ish lines takes approximately 2 seconds, storing all info in there.]
The updates I'm suggesting to commit make no change to physics or anything, hence safe. Assuming you welcome such an update, to where would you like me to commit the fixes?
Many thanks and let me know soon so that I tick this off.Eduardo RodriguesEduardo Rodrigueshttps://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/23Do we have a CPU time monitoring in local decfile test functions ?2023-05-10T11:10:53+02:00Mengzhen WangDo we have a CPU time monitoring in local decfile test functions ?It might be useful to ask proponents to check CPU-time distribution figures like the ones in https://its.cern.ch/jira/browse/LHCBGAUSS-2812 , to minalize the possibility of errors like
```
EventWatchdog FATAL too much time on a si...It might be useful to ask proponents to check CPU-time distribution figures like the ones in https://its.cern.ch/jira/browse/LHCBGAUSS-2812 , to minalize the possibility of errors like
```
EventWatchdog FATAL too much time on a single event: aborting process
```
We may need not only the mean value, but also the distribution itself, to check the possibility of getting a "slow event".
Or do we already have some existing tools ?https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/22How to create a MCDecayTreeTuple from the .xgen file for Z(->mu mu) + gamma2023-04-04T14:43:51+02:00Jiuzhao LiHow to create a MCDecayTreeTuple from the .xgen file for Z(->mu mu) + gammaNow I can produce a Gauss-42112100-10000ev-20230404.xgen for `# Descriptor: pp -> (Z0gamma -> mu+ mu- gamma) ...`.
But I couldn't get a root file using the following command.
```
lb-run -c best DaVinci/v45r4 gaudirun.py MCZgammatuple.py
...Now I can produce a Gauss-42112100-10000ev-20230404.xgen for `# Descriptor: pp -> (Z0gamma -> mu+ mu- gamma) ...`.
But I couldn't get a root file using the following command.
```
lb-run -c best DaVinci/v45r4 gaudirun.py MCZgammatuple.py
```
My option file is put here.
[MCZgammatuple.py](/uploads/95516db8e32308fcea73d66a0e3c8de4/MCZgammatuple.py)
The Feynman diagram is put here.
![图片](/uploads/93044a7471ca3c83dd65bffa26caf61c/图片.png)https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/21Pipeline run-gauss Failed #270130522023-01-27T09:59:46+01:00Lakshan MadhanPipeline run-gauss Failed #27013052Job [#27013052](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/jobs/27013052) failed for e59dd518947bc23c3ed92ead1cb3ef93e0f5e496:
I have created a decfile to simulate gamma gamma -> tau tau in PbPb UPC using starlight and the merge...Job [#27013052](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/jobs/27013052) failed for e59dd518947bc23c3ed92ead1cb3ef93e0f5e496:
I have created a decfile to simulate gamma gamma -> tau tau in PbPb UPC using starlight and the merge requests here. https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/merge_requests/1273
The pipelines for this merge are failing but I believe it to be a time-out error in the initialisation phase of Starlight.
They are running fine locally albeit taking about 35 mins to complete.
Would we be able to increase the time limit to test it again? Many Thanks.Michal KrepsMichal Krepshttps://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/6Job Failed #30472792019-04-30T18:05:51+02:00Marcos Romero LamasJob Failed #3047279Job [#3047279](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/jobs/3047279) failed for 6e1c7a3b0c23b0db85c0d830a0c6c6846610351f:
I'm continuously getting errors with this test, and I don't know how to solve it.
I would appreciate an...Job [#3047279](https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/jobs/3047279) failed for 6e1c7a3b0c23b0db85c0d830a0c6c6846610351f:
I'm continuously getting errors with this test, and I don't know how to solve it.
I would appreciate any help on this.
Marcoshttps://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/3Help with 'Run Gauss to create a .xgen file'2018-10-12T16:34:35+02:00Martha Hiltonmartha.hilton@cern.chHelp with 'Run Gauss to create a .xgen file'Hi,
Please can you help with the instructions under 'Run Gauss to create a .xgen file'.
I am trying `./run bash` and am getting the error `-bash: ./run: No such file or directory`.
Many thanks.Hi,
Please can you help with the instructions under 'Run Gauss to create a .xgen file'.
I am trying `./run bash` and am getting the error `-bash: ./run: No such file or directory`.
Many thanks.https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/2Better to switch off spillover in the generator phase testing instructions?2018-09-19T16:17:49+02:00Mika Anton VesterinenBetter to switch off spillover in the generator phase testing instructions?I was just following the instructions to run Gauss in generator-only mode to produce `.xgen` files. All clear and :thumbsup:. Just one very minor observation/suggestion:
I noticed from the logs that Gauss defaults to running 2 spill over...I was just following the instructions to run Gauss in generator-only mode to produce `.xgen` files. All clear and :thumbsup:. Just one very minor observation/suggestion:
I noticed from the logs that Gauss defaults to running 2 spill over events on either side of the signal. It was easy to figure out how to switch this off, with `Gauss().SpilloverPaths = [ ]`, which seemed to substantially boost the event rate in my case. I was just wondering if this should be set by default in the standalone generation instructions/options?
For users that want to test decfiles on a few events, this probably isn't a big deal. However, I'm probably not the only person who uses the same instructions as a starting point for making studies with higher statistics, privately generated, `.xgen` files. E.g. many people use this to study the effects of gen-level cuts.
@kreps @philten @gcorti https://gitlab.cern.ch/lhcb-datapkg/Gen/DecFiles/-/issues/1Job Failed #16951812018-07-04T10:26:01+02:00Joao CoelhoJob Failed #1695181Job [#1695181](/lhcb-datapkg/Gen/DecFiles/-/jobs/1695181) failed for d23ab505d3b69b8225eeb673b805bc05e75e8855:
I'm not sure why this is failing. I made no changes to the decfiles since the last commit which ran this successfully.Job [#1695181](/lhcb-datapkg/Gen/DecFiles/-/jobs/1695181) failed for d23ab505d3b69b8225eeb673b805bc05e75e8855:
I'm not sure why this is failing. I made no changes to the decfiles since the last commit which ran this successfully.