Stripping issueshttps://gitlab.cern.ch/lhcb/Stripping/-/issues2023-07-25T16:15:36+02:00https://gitlab.cern.ch/lhcb/Stripping/-/issues/50Handle Duplicate input Warning more gracefully2023-07-25T16:15:36+02:00Nathan Allen Griesernathan.allen.grieser@cern.chHandle Duplicate input Warning more gracefullyWarning comes from duplicating the same input location in a line like in !1887 and !1884 . Need to add a test to catch these, or change how we raise the warning.Warning comes from duplicating the same input location in a line like in !1887 and !1884 . Need to add a test to catch these, or change how we raise the warning.Nathan Allen Griesernathan.allen.grieser@cern.chNathan Allen Griesernathan.allen.grieser@cern.chhttps://gitlab.cern.ch/lhcb/Stripping/-/issues/53Timeout in 2016 Stripping productions2024-03-19T15:26:57+01:00Aravindhan VenkateswaranTimeout in 2016 Stripping productionsA small percentage of 2016 Stripping production jobs failed due to some rare events taking order of 1 hour to process. In local tests for two of the input files where this happened, `StrippingB2CCHBd2LcLcKPiLine` showed up as the line ca...A small percentage of 2016 Stripping production jobs failed due to some rare events taking order of 1 hour to process. In local tests for two of the input files where this happened, `StrippingB2CCHBd2LcLcKPiLine` showed up as the line causing this.
The line doesn't seem to have a cap on the `MaxCandidates` it creates, and perhaps the combinatorics spiral out of control in some busy events, causing it to stall for so long. The line authors are requested to troubleshoot this and fix the line for future usage. In the current campaign, the code won't be changed.Aravindhan VenkateswaranNathan Allen Griesernathan.allen.grieser@cern.chShuqi ShengAravindhan Venkateswaranhttps://gitlab.cern.ch/lhcb/Stripping/-/issues/52Stripping21-patches needs CI tests2023-12-01T06:05:39+01:00Nathan Allen Griesernathan.allen.grieser@cern.chStripping21-patches needs CI testsTo accomodate the rolling nature of future developments, we need to get an update to the CI tests such that on `stripping21-patches` these are running out of the box. I'm uncertain whether the selections tests are working out of the box...To accomodate the rolling nature of future developments, we need to get an update to the CI tests such that on `stripping21-patches` these are running out of the box. I'm uncertain whether the selections tests are working out of the box for the Run 1 years, so we may need to do some checks and updates there (and add the bash piping to make them configurable like the Run 2 ones).
For triggering the CI, we can check the branch naming to see whether it's a Run 1 or Run 2 branch. This can be done similar to the current lines in the CI that check the WG names. We will also need to add a requirement that the current CI tests only run on `2018-patches`.
@avenkate Would you like to take a pass at this?
It would be ideal to have this ready in the next month or so so that we may make a larger call to the WGs through the liaisons that this new rolling development procedure will happen. I wouldn't expect much development by the end of the year, but maybe some would start following the winter closure so it would be good to have it ready.Aravindhan VenkateswaranAravindhan Venkateswaranhttps://gitlab.cern.ch/lhcb/Stripping/-/issues/51Stripping pages have some incorrect html code confusing parsers2024-01-22T13:09:48+01:00Mindaugas SarpisStripping pages have some incorrect html code confusing parsersin index.html, the tables listing all streams and the list entries for commonparticles are not properly closed.
They are all `<li>` opened, but never closed. Parsers close the entire block with `</li></li></li></li>...` at the very end...in index.html, the tables listing all streams and the list entries for commonparticles are not properly closed.
They are all `<li>` opened, but never closed. Parsers close the entire block with `</li></li></li></li>...` at the very end, but this is perceived as a nested list, repeating all entries iteratively. This makes it very difficult to modify the list elements.
Workaround: unwrap and rewrap all of the list elements.https://gitlab.cern.ch/lhcb/Stripping/-/issues/42S21 stripping cache is broken2023-06-08T16:57:00+02:00Nicole SkidmoreS21 stripping cache is brokenWhen trying to build the stripping cache for S21rX or S21rXp2 (using the instructions at
https://gitlab.cern.ch/lhcb-dpa/project/-/blob/master/source/wp5/CoordinatorGuidelines.rst
under "Prepare the StrippingCache") we get errors
```
/cv...When trying to build the stripping cache for S21rX or S21rXp2 (using the instructions at
https://gitlab.cern.ch/lhcb-dpa/project/-/blob/master/source/wp5/CoordinatorGuidelines.rst
under "Prepare the StrippingCache") we get errors
```
/cvmfs/lhcbdev.cern.ch/nightlies/lhcb-stripping21-patches/1012/Phys/InstallArea/x86_64-slc6-gcc49-opt/include/LoKi/ProtoParticles.h:491:7: note: candidate expects 0 arguments, 1 provided
/cvmfs/lhcbdev.cern.ch/nightlies/lhcb-stripping21-patches/1012/Phys/InstallArea/x86_64-slc6-gcc49-opt/include/LoKi/ProtoParticles.h:478:7: note: LoKi::ProtoParticles::HasDetector::HasDetector(const string&)
HasDetector ( const std::string& det ) ;
```
The full error can be found here
https://termbin.com/qilp
This is a new problem in the last 9 months given the MR https://gitlab.cern.ch/lhcb/DaVinci/-/merge_requests/350
NOTE: the strippingcaches for S21rXp2 were not used in production because I forgot to do this. THIS SHOULD BE ADDED TO LEGACY NOTESFederico Leo RediNathan Allen Griesernathan.allen.grieser@cern.chFederico Leo Redihttps://gitlab.cern.ch/lhcb/Stripping/-/issues/41Cannot get consistent results for S28r2 and S34r0p1 locally2024-01-22T12:08:33+01:00Nicole SkidmoreCannot get consistent results for S28r2 and S34r0p1 locallyRelates to DV too
## In stripping24r2-28r2-patches
- S24r2 is fine
- S28r2 cannot give consistent counters locally (ie. running the test twice produces different counters). The differences are small and do not affect the rates etc.
`...Relates to DV too
## In stripping24r2-28r2-patches
- S24r2 is fine
- S28r2 cannot give consistent counters locally (ie. running the test twice produces different counters). The differences are small and do not affect the rates etc.
```
PhotonHighSelZ0RareDecay ref) "# Phys/StdLooseAllPhotons" | 797 | 29295 | 36.757 | 17.512 | 1.0000 | 108.00
(PhotonHighSelZ0RareDecay new) "# Phys/StdLooseAllPhotons" | 797 | 29301 | 36.764 | 17.515 | 1.0000 | 108.00
```
Look at the differences in the lines btw S24r2 and S28r2?
## In 2018-patches
- S34 is fine
- S34r0p1 cannot give consistent counters locally
So its not a stack thing and not a rerunning the CALO thing.
Marco suggests it could be uninitialised pointer? Floating point number assigned wrong?
Test `2018-patches` reproducibility by running high statistics tests tests twice:
* S28r2: 60k test no rate difference
* S34r0p1: 100k test no rate difference
* S34: 100k test only 0.001% rate difference in StrippingZVTOP_High_LineEduardo RodriguesFederico Leo RediAravindhan VenkateswaranNathan Allen Griesernathan.allen.grieser@cern.chEduardo Rodrigues2023-08-01