Cleaning DV configuration for Upgrade
Cleaning up DaVinci configuration in order to be ready for moving to GaudiConf2.
Merge request reports
Activity
added cleanup label
DaVinci Configuration
Slots:
- replace Stripping and Turbo stream slots with a unique common slot (since they are mutually exclusive)?
- remove DB tags and create a specific function to correctly picking them up (as done in Bender)?
- remove MoniSequence?
Arrays:
- remove legacy DataTypes
- remove default Detectors
- remove Streams and find an alternative solution?
Sequences:
- remove monitor sequence
Functions:
- create a function for auto-determine rootInTES
-
"checkoptions" to be modified accordingly
- remvove MC09
- merge Turbo and Stripping options?
- check rootInTES function
-
remove Turbo and DataTypes options in "configuresubpackages"
- Do we want to specify a DataType in the future?
- remove comment on RDST in "_init" function
- replace "_defineMonitors" with a global GaudiConf2 function common to all packages?
- include "_upgradeAction" in the main sequence since Upgrade is now the default
Questions:
- What types of input/output files we will be dealing with?
Edited by Davide Fazzini- Resolved by Eduardo Rodrigues
Great to see work starting on this. One immediate question: I thought you were going to keep the present configurable largely unchanged and develop the new one in parallel. That's possible and probably the easiest; and of course the best thing to do.
We should also discuss how to run DaVinci, I mean with what command. Should the default be
gaudirun.py DaVinci.Configuration:run
or something else, for example?added 1 commit
- 532f4e6b - restore original config and create a new one for Upgrade
I have restored the original configuration file and added a new one, called ConfigurationUpgrade.py, where we will implement all the changes. Regarding the choice about how to run DaVinci, I have not a strong opinion for the moment. I don't know if you have any preferences but I am wondering if we should keep a unique command, in common with all the other packages.
This week we are focusing work on this topic, so let me come back to this PR. I think it would make sense to try and converge on it asap and merge. This way we can focus on !432 (merged) which is fully targeting the future configurable. What do you think @dfazzini, @mamartin and @pkoppenb?
added lhcb-run3-cleanup label
Agreed. I added the label lhcb-run3-cleanup as it does things I would else be doing as part of https://gitlab.cern.ch/lhcb-dpa/project/-/issues/37