Resolve "Separate option for mcPaths TreeName"

Release notes

Improved consistency for specifying treeNames to be used for input files: they can now be specified in the initialize master/campaign configs as (parentheses giving alternative name segments) mc(data)Paths(FileLists)TreeName , mc(data)TreeName or simply treeName. The more specific/longer named tags take precedence over the more general/shorter tags. All of the overwrite a potential suffix of the form path/to/samples:treeNameSuffix if applicable to the respective case

Details

Closes #249 (closed)

added [CAH] suggestion + labels

added 1 commit

• 350b51a6 - Add config for mcPathsTreeName

Compare with previous version

unmarked as a Work In Progress

Hi @tzorbas,

thanks for the MR, I think this makes perfect sense. Just one little suggestion: since we already have specific options for use with fileLists I think we should call the option treeName everywhere (data,mc x fileLists, directory scan) and use mcPathsTreeName and the like as additional options to overwrite treeName for the individual cases (the the more specific option is set).

I don't mind who implements it but wanted to first ask you on your opinion.

Hi @rgugel, I agree, this is true, it shouldn't matter what the input type is, all MC accessed by any of these methods would all just be calling the same tree name, so it makes sense to just use a common option.
Data might be a little different in the case of systematic variations as only MC changes (for us), so perhaps be careful here.

So, let's go with the following: mcFileListTreeName > mcTreeName > treeName meaning, the more specific one takes precedence if set, otherwise fall back to the next more general one. Should be easy to implement, so I might just give it a try later

added 1 commit

• edd60306 - consistently introducing tags to specify the treeName to be read with names...

Compare with previous version

Ok, should be all in place now. Can I ask you to take another look just in case I missed something? If there's no further issue and once the CI agrees I'd be happy to merge this

changed the description

Looks good! Many thanks @rgugel

mentioned in commit 17a9020b

merged