new jet hypo config

This merge request contains code that allows a more direct and understandable configuration of the jet hypo code. The emphasis is in making extensions to the current code easier as new functionality is needed in the future.

The jet hypo has the concept of a "scenario". A scenario labels a set of actions to be performed by the hypo. Simple examples are the dijet scenario, which requires the presence of a diet passing specifiable cuts, and the agg scenario which acts on the jet collection ass a whole. The simple scenario implements the Run 1 style jet hypo where conditions are applied to single jets. A non-simple scenario can be combined with a simple scenario.

The code in this merge request is made up of a number of modules. Those with names like scenario_XX.py (e.g. scenario_dijet.py) are concerned with extracting information from the incoming chainDict and presenting it in a standard form. This information is then used by the code in hypoConfigBuilder.py to initialise a system of AlgTools that are responsible for providing jet hypo objects required by TrigJetHypoToolMT

Future developments may require changes at various levels. It is expected that the most basic new functionality will be the most common: namely a new scenario is introduced which reuses the existing jet hypo comments. In this case a new scenario_XX.py needs to be provided. The modifications to hypoConfigBuilder are limited to adding an import of this module, and adding the new scenario to an internal routing table.

Whether or not the modifications to hypoConfigBuilder should be automated should be discussed within th eJet Trigger group.

Note that, despite the branch name, no markup files are used.

@jbossios @valentem @khoo @peter

Menu experts (@khoo @hrussell @markowen @dzanzi) please note the following:

• The scale factor (SF) used for djdphi and djdeta was changed from 0.1 to 0.01 to match the rest of the SFs (that means that 20 was changed 200, 26 to 260, etc)

• In Run 2, dphi20 requested dphi<2.0, while deta40 requested 4.0<deta. That means that the equivalent of dphi20deta40 in Run 3 would be djdphi200SEP400djdeta. Note please that all chains including XXdjdphi were now changed to djdphiXX0 to match what was actually applied in Run 2. This fixes the ambiguity present in Run 2 where min/max values were in different order b/w dphi and deta which caused Run 3 chains to be implemented incorrectly. This is a bugfix and count differences are expected (higher counts are expected for dphi>2.0 than for dphi<2.0 which is what is observed in the reference files).

Adding the urgent label since this is blocking other developments, this redesign is needed to be merged before continuing with any other development.

added JetHLTHypo master labels

added 1 commit

• c108f3b9 - jet hypo - iimprove display functionality for debugging of jet hypo tools

Compare with previous version

added 1 commit

• b1c67f5d - jety hypo new hypo test + code sanitisation in hypoConfigBuilder.py

Compare with previous version

added 1 commit

• 42fd01ff - jet hypo - add command line argument parsing to test_hypoConfigBuilder.py

Compare with previous version

added 1 commit

• 8493babe - jet hypo: increase coverage of hypoToolTests.py

Compare with previous version

Very interesting.

Do you think the handing of the scale factors of deta and dphi should be done as in run 2?

On the one hand, I am not to sure why we give three (string) digits to eta, in that it seems improbable that we need two digits after the decimal point. Thus the two digit convention for deta and dphi makes more sense.

Having two conventions in the same chain name would seem to be possibly confusing (as my scale factors demonstrate...). So would not one of the two following be an improvement:

• 2 digits everywhere
• 3 digits everywhere

Unless there is an overriding necessity to stick to the Run 2 less-than-ideal conventions.

Thanks for your feedback.

If we use SF = 0.1 then we need to have djdphi20 and 40djdeta If we use SF = 0.01 then we need djdphi200 and 400djdeta

On one hand, I would be inclined to use 0.1, since that would match what was used in Run 2, and that always means fewer changes someone adds the incorrect things to the menu. But I do see the point of using 0.01 to match what is used elsewhere (eta, jvt, etc). Considering that we are already changing/improving the behaviour of djdphi and we are working towards making things more clear and consistent, I would go with SF = 0.01. That means, we need to make the following changes instead:

• scale factor for djdeta should be 0.01 and not 1000
• We need to change 20djdphi by djdphi200 in SignatureDicts.py
• We need to change 40djdeta by 400djdeta in SignatureDicts.py
• We need to change 20djdphi by djdphi200 and 40djdeta by 400djdeta in the following chains in LS2_v1 menu:

HLT_j0_dijetSEP80j12etSEP700djmassSEP26djdphi_L1J20

HLT_j0_dijetSEP70j12etSEP1000djmassSEP20djdphiSEP40djdeta_L1J20

HLT_j70_0eta320_j50_0eta490_j0_dijetSEP70j12etSEP1000djmassSEP20djdphiSEP40djdeta__L1MJJ

ok, this is a question of what is clearest to non-specialists, and you certainly have more experience than I on this. I will follow the last recommendations for the next commit.

This is a question of how much you want to be able to express with.a given string.

The way things are set up now allows someone in the future freedom to set up chains they could not set up if we put the blockers in.

On the other hand, if you believe that some of the options available are necessarily illegal, and make no sense in principle, rather than being merely rare or unexpected, then the blocks should certainly be put in.

Finally, if you believe that the cases which would be blocked are vanishingly unlikely,with likelihood much smaller than the likelihood of a mis-configuration, then there is a case for removing the freedom.

....

I suppose we could assume the last case, and put in the checks. Future generations could modify the code if they needed to do so..

Are you talking about L38 or L39? I guess your comment is about L39. Regarding L38, I think there is no doubt all keys should be available for all chain parts, it is highly unlikely that a problem occurs but it doesn't hurt to ensure that the chain dict looks fine (which we would do by just removing L38 and using all_elemental_keys instead of elemental_keys).

Regarding L39, currently, our approach is to have a given threshold and a given etaRange even when we virtually do not want to have one. Like 0eta490 option for etaRange and the j0 chain for threshold. Again, I know I'm being picky here, I just wanted to bring this up but I could go either way.

BTW, please reply to the threads that I open such that we can follow up easily different discussions on different threads (in case I end up opening many simultaneously).

added 1 commit

• 1d3b1a2d - jet hypo - changes after discussions with J Bossio and M Valente.

Compare with previous version