Draft: first draft of a text based configuration for common CP algorithms

So far this is mostly a simple demonstrator of what such a file could look like to get the whole discussion moving again. I tested that it generates a sequence and sort of does what I expect, but I didn't try to run or validate the sequence. A number of sequence types are still missing, e.g. electrons, taus, b-tagging, as well as a lot of configuration options besides setting container names and working points.

I guess the immediate question is whether people are happy with the general format for the text configuration (see TextConfig.txt). I laid out the general format I was thinking of quite a while back in a presentation, so here is now some actual code example. Essentially my interpretation of a flat text file of (ordered) name value pairs.

The general configuration follows some format like this, in which the name is used for the name in the event store:

# create a new output container called MyJets_%SYS%
MyJets = new Jets
# set a configuration option for that container, in this case the input container
MyJets.JetContainer = AntiKt4EMPFlowJets

I decided not to have the users specify the _%SYS% everywhere. That seems very tedious, instead we can decide on a syntax for the few times people don't want it.

For objects with multiple working points they are all declared like new sub-objects, where the sub-object name is used for the postfix used in all decorations

MyMuons = new Muons
MyMuons.medium = new Muons.Medium.Iso
MyMuons.tight  = new Muons.Tight.Iso

This will just use the calibration algorithms from the first working point sequence and discard the rest. They ought to be identical.

For Met, all input containers need to be manually specified:

MyMet = new Met
MyMet.Jets = MyJets
MyMet.Muons = MyMuons

I don't know if it is necessary to also specify a selection decoration for each container as well. I mean probably, but I guess I'll either have to add that as an option to MetMakerAlg or schedule a whole bunch of view-container algorithms. Either way, I hope syntactically that could then be handled by replacing e.g. MyMuons with MyMuons.tight.

I'm sure technically there is a lot to be criticized about the implementation, not sure if it is worth the effort at this point. I essentially added one feature at a time and modified code to make that work, and if we keep going forward with this there will be more of that happening. The only sort of note-worthy points here are probably that we have what I would guess are called flags in Athena configuration (in my code an object called metaVar), and that I need to store some information about containers I create for configuring subsequent containers. The later has been a recurring theme with CP algorithm configuration, and so far for this prototype it is just which original jet container the jets come from so that the Met can use the right terms. For simplicity I just added that to metaVar as well.

If we end up using @jburr's block configuration there is probably some redundancy here, or at least the configuration interface for the actual sequences would look completely different. However, I would hope that the actual configuration format would be unaffected by such things, but it's probably another reason not to worry too much about the actual implementation at this point.

Not sure if we can borrow any infrastructure from the "new" Athena offline configuration. I neither know whether it is worth the effort, or even technically possible as it may be too married to Athena internals. But unless there are huge code savings to be had it is probably not worth the effort.

Not sure what time scale is realistic to get something to users. The next software tutorial is early November, which may be too tight, even if we decide to put in a temporary implementation that then gets replaced at some point.

Tagging the usual suspects, please add more people as you see fit: @jburr @tadej @lheinric @vimartin