Run2021 Merge

[pbutti]

Time to bring back run2021 into master.

[cbravo135]

I have been using this branch for months, given multiple talks using it, including the recent work I did aligning the 2021 SVT.

[JeremyMcCormick]

Has the full MC chain been checked with this on a few of the new detectors and maybe a couple of the old ones?

Might want to do this as it would verify that the LCDD and compact don't have a geometry mismatch.

[cbravo135]

I don't think it is needed to check the MC chain for multiple detectors for this PR. The change that would potentially change stuff wrt the lcdd/compact already happened in #903. The one thing here that I didn't realize was in the branch are changes from TongTong for the DAQ configuration work he did. I do have some comments on how that was done, mostly that there is a big block of else if statements to choose the correct resource for the correct run number. This should have been done using the database, as this sort of issue is exactly what the database system was designed to solve.

[tongtongcao]

I don't think it is needed to check the MC chain for multiple detectors for this PR. The change that would potentially change stuff wrt the lcdd/compact already happened in #903. The one thing here that I didn't realize was in the branch are changes from TongTong for the DAQ configuration work he did. I do have some comments on how that was done, mostly that there is a big block of else if statements to choose the correct resource for the correct run number. This should have been done using the database, as this sort of issue is exactly what the database system was designed to solve.

For a DAQ configuration, it includes some parameters, but not much like gain or pedestals or else for Ecal/Hodo/SVT channels.
Currently, we already have parsers to parse DAQ configuration for each experiment run, and have a system to reach parameters based on the parsers.
For each experiment, there are only several versions for DAQ configuration. So we just need small space to save DAQ configurations in resource.
Certainly, we can use DB to store parameters. But it will be a big task.
Besides development of complicates tables for DAQ configurations (many details in DAQ configuration), I can image that all stuffs related to DAQ configuration in hps-java need to be modified, not just for 2021, but also for 2019 and 2016.
I personally don't think that it is worthy to take too much energy on developing DB for DAQ configuration, and just for saving so small space expense.
For configurations in hps-java, DB is an option, but resource is also a choice for small space expense.

[cbravo135]

Just to be clear for TongTong, my comment was not about the data from the config files being a resource. My comment was about this particular block of code being a mess. What this code achieves can be more cleanly achieved via the db, by making a table that holds the names of each of the config file resources that could be used and making entries in the conditions db to associate each one with the appropriate run numbers.

[tongtongcao]

It sounds not a big job. Let's put it into to-do list.
The current code works. I suggest to merge the branch firstly, and then open an issue to do update later.

[tongtongcao]

I worked on the branch for a while. No issues happened. So I approve the PR.