Stripping issueshttps://gitlab.cern.ch/lhcb/Stripping/-/issues2024-03-19T15:26:57+01:00https://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/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/49Confusing Behavior in B2OC Definitions2023-07-12T10:19:26+02:00Nathan Allen Griesernathan.allen.grieser@cern.chConfusing Behavior in B2OC DefinitionsAn issue was raised by @alupato about how the different line definitions are working within B2OC modules. Looking specifically at the LB2XBuilder, the intention was to edit the ```AM_MIN``` values. The relevant selector in the config d...An issue was raised by @alupato about how the different line definitions are working within B2OC modules. Looking specifically at the LB2XBuilder, the intention was to edit the ```AM_MIN``` values. The relevant selector in the config dictionaries is the ```B2X``` one [1].
Here you can see for Stripping34 this value was set to 4750 and 7000 MeV, with a comment saying that the Lb2X builder overwrites the min value to 5200 [2].
However, within the make functions of the Lb2XBuilder, there are what seems to be users trying to redefine these values [3,4,5], but this does not seem to be being propagated correctly [6].
Multiple questions arise from this:
- How is a new analyser supposed to define selections for these lines hidden within these makers, when the lineconfig dictionary only carries some top level selection?
- Are the intended selections by analysers (3-5 below) being intentionally overwritten (and if so, why do these lines still exist) or were these ran with the incorrect intended values?
- What is the correct (intended?) way for an analyser to edit this ```AM_MIN``` value for the specific lines housed in this module?
[1] https://gitlab.cern.ch/lhcb/Stripping/-/blob/2018-patches/Phys/StrippingSettings/python/StrippingSettings/Stripping34/LineConfigDictionaries_B2OC.py#L185
[2] https://gitlab.cern.ch/lhcb/Stripping/-/blob/2018-patches/Phys/StrippingSelections/python/StrippingSelections/StrippingB2OC/Beauty2Charm_Lb2XBuilder.py#L804
[3] https://gitlab.cern.ch/lhcb/Stripping/-/blob/2018-patches/Phys/StrippingSelections/python/StrippingSelections/StrippingB2OC/Beauty2Charm_Lb2XBuilder.py#L1503
[4] https://gitlab.cern.ch/lhcb/Stripping/-/blob/2018-patches/Phys/StrippingSelections/python/StrippingSelections/StrippingB2OC/Beauty2Charm_Lb2XBuilder.py#L1517
[5] https://gitlab.cern.ch/lhcb/Stripping/-/blob/2018-patches/Phys/StrippingSelections/python/StrippingSelections/StrippingB2OC/Beauty2Charm_Lb2XBuilder.py#L1529
[6]https://lhcbdoc.web.cern.ch/lhcbdoc/stripping/config/stripping34/bhadron/strippinglb2lcdstkstbeauty2charmline.html2023 Re-Strip CampaignAlessandro BertolinAlessandro Bertolinhttps://gitlab.cern.ch/lhcb/Stripping/-/issues/48Clean up of some too-old archives2023-06-16T11:18:51+02:00Eduardo RodriguesClean up of some too-old archivesHey there, while linting the repository I noticed that several subdirectories contain a series of Stripping campaign versions. I would argue that we can get rid of most of them. I see the following:
```
$ ls CommonParticlesArchive/pytho...Hey there, while linting the repository I noticed that several subdirectories contain a series of Stripping campaign versions. I would argue that we can get rid of most of them. I see the following:
```
$ ls CommonParticlesArchive/python/CommonParticlesArchive/
__init__.py Stripping27 Stripping30r2 Stripping31r2 Stripping34r0p1 Stripping35r3
Stripping24r2 Stripping28r2 Stripping30r3 Stripping33r2 Stripping34r0p2
Stripping25 Stripping28r2p1 Stripping31r1 Stripping34 Stripping35r2
$ ls StrippingArchive/python/StrippingArchive/
__init__.py Stripping27 Stripping30r2 Stripping31r2 Stripping34r0p1 Stripping35r3
Stripping24r2 Stripping28r2 Stripping30r3 Stripping33r2 Stripping34r0p2 Utils.py
Stripping25 Stripping28r2p1 Stripping31r1 Stripping34 Stripping35r2
$ ls StrippingSettings/python/StrippingSettings/
__init__.py Stripping25 Stripping28r2p1 Stripping31r1 Stripping34 Stripping35r2
makeDB.py Stripping27 Stripping30r2 Stripping31r2 Stripping34r0p1 Stripping35r3
Stripping24r2 Stripping28r2 Stripping30r3 Stripping33r2 Stripping34r0p2 Utils.py
```
It would be ideal to clean this all up before linting what actually is to be kept. I hope you agree.
This goes for the various legacy branches though I've been only looking at 2018-patches.Federico Leo RediAravindhan VenkateswaranNathan Allen Griesernathan.allen.grieser@cern.chFederico Leo Redihttps://gitlab.cern.ch/lhcb/Stripping/-/issues/472017-patches and stripping21-patches user tests uses old data (grid/prod) swt...2023-04-26T10:44:22+02:00Nathan Allen Griesernathan.allen.grieser@cern.ch2017-patches and stripping21-patches user tests uses old data (grid/prod) swtest locationAs was changed in https://gitlab.cern.ch/lhcb/Stripping/-/merge_requests/1712 , the ```2017-patches``` user test xml file uses the test data in ```/eos/lhcb/grid/prod/lhcb/swtest/``` , and this should be updated to use the CERN-SWTEST gr...As was changed in https://gitlab.cern.ch/lhcb/Stripping/-/merge_requests/1712 , the ```2017-patches``` user test xml file uses the test data in ```/eos/lhcb/grid/prod/lhcb/swtest/``` , and this should be updated to use the CERN-SWTEST grid storage space.
The xml file used is : https://gitlab.cern.ch/lhcb/Stripping/-/blob/2017-patches/Phys/StrippingSelections/tests/data/Reco17_DataType2017_Run195969.xml
The error reported when running the test is:
```
Error in <TNetXNGFile::Open>: [ERROR] Server responded with an error: [3011] Unable to open file /eos/lhcb/grid/prod/lhcb/swtest/lhcb/data/2017/RAW/FULL/LHCb/COLLISION17/195969/195969_0000000791.raw; No such file or directory
IODataManager ERROR Error: connectDataIO> Cannot connect to database: PFN=mdf:root://eoslhcb.cern.ch//eos/lhcb/grid/prod/lhcb/swtest/lhcb/data/2017/RAW/FULL/LHCb/COLLISION17/195969/195969_0000000791.raw FID=ba265044-7707-11e7-b20e-001e67ddce9d
IODataManager ERROR Failed to open dsn:ba265044-7707-11e7-b20e-001e67ddce9d Federated file could not be resolved from 1 entries.
```
The case is also the same for ```stripping21-patches``` for Run 1 tests.
The xml file in that case is : https://gitlab.cern.ch/lhcb/Stripping/-/blob/stripping21-patches/Phys/StrippingSelections/tests/data/Reco15a_Run164668.xmlhttps://gitlab.cern.ch/lhcb/Stripping/-/issues/46Update README.md to correctly steer new campaign developments2023-05-30T11:39:25+02:00Nathan Allen Griesernathan.allen.grieser@cern.chUpdate README.md to correctly steer new campaign developmentsThe current README is quite vague. Whether a new campaign comes this summer or not, we should update and steer developments to the correct branch (as this should still be the same whether the campaign is this summer or next year or when...The current README is quite vague. Whether a new campaign comes this summer or not, we should update and steer developments to the correct branch (as this should still be the same whether the campaign is this summer or next year or whenever...)Nathan Allen Griesernathan.allen.grieser@cern.chNathan Allen Griesernathan.allen.grieser@cern.chhttps://gitlab.cern.ch/lhcb/Stripping/-/issues/45Clean up defunct branches2023-04-20T13:05:54+02:00Mark SmithClean up defunct branchesThere are ~1000 branches in Stripping. I guess most are from ancient abandoned attempts or lines that got merged but the branch didn't get deleted. It might be nice to get rid of some.There are ~1000 branches in Stripping. I guess most are from ancient abandoned attempts or lines that got merged but the branch didn't get deleted. It might be nice to get rid of some.https://gitlab.cern.ch/lhcb/Stripping/-/issues/44Various Stripping and DaVinci tests failing in 201X-patches2023-04-05T15:45:46+02:00Eduardo RodriguesVarious Stripping and DaVinci tests failing in 201X-patchesTake https://lhcb-nightlies.web.cern.ch/nightly/lhcb-2018-patches/1230/ as an example. We all know there are some long standing issues being worked on but I see totally independent failures, seems since a while, and these ought to be add...Take https://lhcb-nightlies.web.cern.ch/nightly/lhcb-2018-patches/1230/ as an example. We all know there are some long standing issues being worked on but I see totally independent failures, seems since a while, and these ought to be addressed as soon as feasible to avoid being "blind" with other issues.
Assigning to you 3 for the various matters - @fredi, @ngrieser, @masmith.Federico Leo RediMark SmithNathan Allen Griesernathan.allen.grieser@cern.chFederico Leo Redihttps://gitlab.cern.ch/lhcb/Stripping/-/issues/43chore: update default branch and README content2023-03-15T17:24:18+01:00Eduardo Rodrigueschore: update default branch and README contentHi @fredi, @masmith, I was looking around and was surprised to realise that the default branch for Stripping is `2018-branches`. I would have assumed it is `run2-patches` since a while, as the default legacy branch by construction. Can y...Hi @fredi, @masmith, I was looking around and was surprised to realise that the default branch for Stripping is `2018-branches`. I would have assumed it is `run2-patches` since a while, as the default legacy branch by construction. Can you update asap?
I also see that the README does not contain the relevant information and should be updated as well. Have a look at what we're doing in master for Moore or DaVinci, for example.Federico Leo RediMark SmithFederico Leo Redihttps://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-01https://gitlab.cern.ch/lhcb/Stripping/-/issues/40Warnings about PatDownstream in IFT campaigns2023-05-18T12:03:02+02:00Nicole SkidmoreWarnings about PatDownstream in IFT campaignsWhen building the strippingcaches in DV 2018-patches we get the warning
```
[WARNING] Submodule StrippingArchive.Stripping30r2.StrippingCalib.StrippingTrackEffDownMuon raises the exception "cannot import name PatDownstream" and will be s...When building the strippingcaches in DV 2018-patches we get the warning
```
[WARNING] Submodule StrippingArchive.Stripping30r2.StrippingCalib.StrippingTrackEffDownMuon raises the exception "cannot import name PatDownstream" and will be skipped !
```
for S30r3, S31r2 and S30r2.
We know the origin of this problem (see https://gitlab.cern.ch/lhcb/Stripping/-/merge_requests/1413 for how we fixed it there) but in these particular cases it is harmless, these are IFT campaigns and so dont use Calib lines. However the warnings are annoying.
The quickest remedy is to simply delete the useless archives in these campaigns https://gitlab.cern.ch/lhcb/Stripping/-/tree/2018-patches/Phys/StrippingArchive/python/StrippingArchive/Stripping31r2. This activity should be seen as part of the clean up of redundant archives.Federico Leo RediNathan Allen Griesernathan.allen.grieser@cern.chFederico Leo Redihttps://gitlab.cern.ch/lhcb/Stripping/-/issues/39segmentation violation during DST writing after selection with `DTF_FUN`2019-12-23T12:24:42+01:00Marian Stahlmarian.stahl@cern.chsegmentation violation during DST writing after selection with `DTF_FUN`# Context
This seg fault happens very rarely, and is holding back the current stripping campaigns. <br>
It was noticed in 2016 data with the `Xic2LambdaKPi` module, but it's likely that also other lines are affected.
# Description
The s...# Context
This seg fault happens very rarely, and is holding back the current stripping campaigns. <br>
It was noticed in 2016 data with the `Xic2LambdaKPi` module, but it's likely that also other lines are affected.
# Description
The seg fault occurs when trying to write the DST after a candidate for `StrippingXic2LambdaKPi_XicpLine` was found. The code runs fine when [both `DTF_FUN` cuts](https://gitlab.cern.ch/lhcb/Stripping/blob/stripping24r2-28r2-patches/Phys/StrippingSelections/python/StrippingSelections/StrippingCharm/StrippingXic2LambdaKPi.py#L83) of the mother combination are removed or replaced by their non-DTF equivalents.
## Possible source of error
It seems as if a vertex has been modified/removed? by the DTF, such that the link provided to the DST writers points nowhere.
## How to move forward?
The quick and easy solution is to remove cuts on `DTF_FUN` functors. This is not a big issue for the `Xic2LambdaKPi` module, but would certainly harm the [`XicToSigmaKPi`](https://gitlab.cern.ch/lhcb/Stripping/blob/2017-patches/Phys/StrippingSelections/python/StrippingSelections/StrippingCharm/StrippingXicToSigmaKPi.py) lines which rely heavily on the DTF (see also the discussion in https://groups.cern.ch/group/lhcb-reconstruction/Lists/Archive/Flat.aspx?RootFolder=%2Fgroup%2Flhcb%2Dreconstruction%2FLists%2FArchive%2FReconstruction%20of%20Sigma%2B%20%2D%20p%20pi0&FolderCTID=0x0120020030FF8979BD9D1640BD2549BA2063796A). I would like to keep the Sigma lines, since they give a hint whether or not it is feasible to write trigger lines for them in Run3.<br>
Having said that, it would be much appreciated if @ibelyaev and @wouter have a look, to possibly find and fix the source of the problem.
## More (random) information
- The event that causes the trouble is a $`\Xi_c^+ \to \Lambda K_S^0 \pi^+`$ candidate. In that event, the $`\Lambda`$ is DD and $`K_S^0`$ LL.
- Switching off the `dstWriter` sequence (as it's done in the users tests) doesn't cause a seg fault.
- Log files:
liaisons testing script on the problematic RDST running only `Xic2LambdaKPi`<br>
[liaisons_Xic2LambdaKPi_only_unmodified_default_verbosity.log](/uploads/bc39b4d3b04c9b7eeeb1bc9027ab68b6/liaisons_Xic2LambdaKPi_only_unmodified_default_verbosity.log)<br>
... same in DEBUG mode<br>
[liaisons_Xic2LambdaKPi_only_unmodified_debug.log](/uploads/f7fc6e3e41e837315e14082cbd59b296/liaisons_Xic2LambdaKPi_only_unmodified_debug.log)<br>
... and switching off `dstWriter` sequence. The selection that passes here is the one triggering the seg fault<br>
[users_Xic2LambdaKPi_KS_LL_L_DD.log](/uploads/6f7ae5180a9db9e6e92569f350c8affc/users_Xic2LambdaKPi_KS_LL_L_DD.log)Marian Stahlmarian.stahl@cern.chMarian Stahlmarian.stahl@cern.chhttps://gitlab.cern.ch/lhcb/Stripping/-/issues/38Clean up stripping logs for run1+2 campaigns2019-07-04T17:47:30+02:00Nicole SkidmoreClean up stripping logs for run1+2 campaignsThe logs are a mess of warnings and errors. A lot of these are well known and can be turned off. Maybe a debug setting?The logs are a mess of warnings and errors. A lot of these are well known and can be turned off. Maybe a debug setting?Nicole SkidmoreNicole Skidmorehttps://gitlab.cern.ch/lhcb/Stripping/-/issues/37Prepare Stripping 28r2 (pp 2016)2019-07-04T17:47:29+02:00Carlos Vazquez SierraPrepare Stripping 28r2 (pp 2016)* https://its.cern.ch/jira/browse/LBOPG-105* https://its.cern.ch/jira/browse/LBOPG-105Re-stripping of Run 1 & Run 2 LHCb dataCarlos Vazquez SierraNicole SkidmoreCarlos Vazquez Sierrahttps://gitlab.cern.ch/lhcb/Stripping/-/issues/36Problems with Run 1 re-stripping campaigns2019-03-20T15:24:03+01:00Carlos Vazquez SierraProblems with Run 1 re-stripping campaigns## Unsolved:
* Overtiming with B2SS lines (@jcidvida ).
## Waiting for action:
* Problems with gluino & jet lines (GenericVertexFinder fails) (@mmarinan ):
* Needs feedback from @wouter .
## Unsolved:
* Overtiming with B2SS lines (@jcidvida ).
## Waiting for action:
* Problems with gluino & jet lines (GenericVertexFinder fails) (@mmarinan ):
* Needs feedback from @wouter .
Re-stripping of Run 1 & Run 2 LHCb dataCarlos Vazquez SierraCarlos Vazquez Sierrahttps://gitlab.cern.ch/lhcb/Stripping/-/issues/35Fixes for Stripping21rXp1 campaigns (stripping21-patches)2019-02-13T18:04:51+01:00Carlos Vazquez SierraFixes for Stripping21rXp1 campaigns (stripping21-patches)Repositories for Stripping21rXp1 campaigns (2011 & 2012 re-stripping campaigns) need to be "modernised" in order to have the same structure as Run 2 campaigns.
The branch is ```stripping21-patches```. Please check out the corresponding ...Repositories for Stripping21rXp1 campaigns (2011 & 2012 re-stripping campaigns) need to be "modernised" in order to have the same structure as Run 2 campaigns.
The branch is ```stripping21-patches```. Please check out the corresponding package from this branch, create a new branch and work on it. The main tasks to carry out here are:
## Distribute the line builders per WG
All line builders in Phys/StrippingSelections are mixed together, and this has to be sorted out. To do this, an idea would be to ```grep``` per WG and move the files to the corresponding WG folder (that has to be created). An example in bash (needs to be tested) to classify QEE, B&Q and RD builders (should be done for all WGs) would be (to be ran at python/StrippingSelections):
```
for wg in BandQ QEE RD
do
mkdir Stripping${wg} && grep -l -Z -r "\['${wg}'\]" . | xargs -0 -I{} mv {} Stripping${wg}/
done
```
After the classification is done, auxiliar python files have to be added to the WG folders as it is done for 2018-patches (please use this branch as a guideline). To know which files should be imported and which not, one can check the ```__init__``` file in python/StrippingSelections and reproduce the same imports but per WG (each WG folder needs an ```__init__``` file). More additional files might be needed, i.e. ```Utils.py```, please use 2018-patches as a guideline on what put there (if you have doubts please let me know). Also, please be very careful and always compare to 2018-patches so you are sure you are not missing any file.
**Addendum:** it seems some of the builders do not use the current structure of ```default_config```, hence they are not parseable by the testing scripts. This should be fixed. Also, some of the builders do not include a WG tag. Liaisons should be requested to classify these builders.
## Fix the test scripts to test from Selections
There are two different test scripts, one for Run 1 and another one for Run 2. This is because the structure is different in Selections (see above). Once the Selections are fixed, these scripts need to be updated as well (for both users and liaisons). As before, use 2018-patches as a guideline. You might need to do changes as well to the ```StrippingStream``` logic (or any Configurables that affects the call of any line builder by the dictionary name), which is hosted in the Stripping project as well. Just by having a look to the test script, you will see which Configurables are used and therefore what needs to be updated in case there is a failure when running the script. **Please be sure the tests are running for all WGs.**
## Fix the test scripts to test from Settings
Same as above, but running from Settings instead of Selections. Changes here should be minimal, if Settings needs to be changed, please let me know. You can use Stripping21(r1) settings for this test. Just by having a look to the test script, you will see which Configurables are used and therefore what needs to be updated in case there is a failure when running the script. **Please be sure the tests are running for all WGs.**
## Final clean-up and assure consistency
Clean-up the old test and data files (add new db tags) and utils for liaisons, i.e. dictionaries collection. Also, do a global check to be sure everything is consistent.
## Propagate changes to StrippingArchive
This is the most complicated part, ensure we can run previous Run 1 campaigns Stripping21(rXp0) from the archive and there are zero problems. A similar work as with Selections should be done here but in StrippingArchive (be careful of differences with ```default_config```). Changes to some Configurables may be needed as well. This should be left for the end, as it only affects the AppConfig options and the coordinators tests.
Once a task is completed, please tick it below:
* [x] Distribute the line builders per WG @mmarinan
* [x] Fix the test scripts to test from Selections @ausachov
* [x] Fix the test scripts from test from Settings @ausachov
* [x] Final clean-up @cvazquez
* [x] Propagate changes to StrippingArchive @cvazquez @nskidmor Re-stripping of Run 1 & Run 2 LHCb dataCarlos Vazquez SierraVitalii LisovskyiMatthieu MarinangeliAndrii UsachovCarlos Vazquez Sierrahttps://gitlab.cern.ch/lhcb/Stripping/-/issues/34Prepare Stripping 29r2p1 (pp 2017)2019-07-04T17:47:29+02:00Carlos Vazquez SierraPrepare Stripping 29r2p1 (pp 2017)* https://its.cern.ch/jira/browse/LBOPG-106
* https://its.cern.ch/jira/browse/LBOPG-106
Re-stripping of Run 1 & Run 2 LHCb dataNicole SkidmoreNicole Skidmore