Allow to renounce inputs resulting from expressions in the ExpressionParser

The renounceInput of the IDataHandleHolder is overloaded in the ExpressionParserUser template to propagate the inputs which are to be renounced to the proxy loader. These inputs are memorised, and taken into consideration at the time the proxy loader is declaring the data needed for its expressions.

Still a draft, in case there are already some comments (@ssnyder, @leggett)

With this MR e.g. the DRAW_ZMUMU output can be created in athenaMT. Without it the scheduler will complain because the skimming tool of the derivation framework kernel will use in its expressions a variable created by one of the augmentation tools used in the same kernel.

Hey, Not 100% related with expression partsing.

Also are there some other conditions the issue can happen, or with current scheduler will happen if tools A,B are in the same alg and have a dependency like A writes foo and B reads foo?

The way Derivation is setup (still heavily tool based ) we might have cases that this happens inside the same Derivation kernel. Since there is not explicit algorithm other that the part you modify (also in this MR) that loops over the tools which is fully configurable.

Is there some idea one how we would want to handle these cases a bit more general? i.e when the dependency is not just by the expression parser but can happen based on configuration properties of order of tools what not. Already looking on DerivationTools and moving to handles there are configuration of tools that this could easily happen ... Admitedly would be easier if we move to algs from tools in place but this does not seem to be the plan yet.

I had the problem before in the ambiguity resolver. Initially I solved it by adding a property to instruct a tool not to declare certain data. But that was quite tedious to configure and very error prone. Now, similar to here the ambiguity resolver initiates a certain set of tools to renounce data created by the ambiguity resolver.

Since only the tool or algorithm which provokes the conflict (i.e. uses e.g. tools which both write and read a certain data) knows whether the data is created before it is used. Thus, only this top-level algorithm or tool knows whether the "conflict" can be ignored. Therefore it is difficult to come up with a general solution other than a property, I would say.

Hi, what I wonder , is if the derivation tools should have a hook method like renounceDepenciesFor() to return back to the generic DerivationKernel.cxx a list of dependencies for it to ignore, based on tool configuration, like renounceInputDependenciesFor = [] Or if the DerivationKernel itself should have a property which then we configure .

I can see the issue happening for other things than the expression parser for which you did practically such a hook.

I assume we will not switch the derivation tools looping over collections to algorithms. In which case we would not need that perhaps ...

I forgot to add this to the description, the DerivationKernel would renounce also all inputs from all tools which are among the outputs created by tools executed in the preceding steps (steps are augmentation, skimming, thining or the first two swapped). So, the case You describe is covered.

But there are certainly other cases not linked to the DerivationKernel.

Ah OK, this then answers my 0 level question .

added 2 commits

• 9ea979b2 - Allow to renounce inputs resulting from expressions in the ExpressionParser
• 3b255280 - Renounce inputs to skimming and thinning tools created by augmentation tools of the same Kernel.

Compare with previous version

Simplified the approach at the cost of efficiency. The inefficiency can be addressed in case it shows up.

marked this merge request as ready

changed title from Draft: Allow to renounce inputs from dynamic data consumers. to Allow to renounce inputs resulting from expressions in the ExpressionParser

changed the description

This merge request affects 2 packages:

• PhysicsAnalysis/CommonTools/ExpressionEvaluation
• PhysicsAnalysis/DerivationFramework/DerivationFrameworkCore

Affected files list will not be printed in this case

added Analysis Derivation master review-pending-level-1 labels

CI Result SUCCESS (hash 3b255280)

	Athena	AthSimulation	AthGeneration	AnalysisBase	AthAnalysis	DetCommon
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 1
AthSimulation: number of compilation errors 0, warnings 0
AthGeneration: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
AthAnalysis: number of compilation errors 0, warnings 1
DetCommon: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 30525]

added 1 commit

• 2df7e028 - Renounce inputs to skimming and thinning tools created by augmentation tools of the same Kernel.

Compare with previous version

fixed compiler warning.

This merge request affects 2 packages:

• PhysicsAnalysis/CommonTools/ExpressionEvaluation
• PhysicsAnalysis/DerivationFramework/DerivationFrameworkCore

Affected files list will not be printed in this case

CI Result SUCCESS (hash 2df7e028)

	Athena	AthSimulation	AthGeneration	AnalysisBase	AthAnalysis	DetCommon
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
AthGeneration: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
AthAnalysis: number of compilation errors 0, warnings 0
DetCommon: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 30527]

added review-approved label and removed review-pending-level-1 label

merged

mentioned in commit d1953b4b

added sweep:ignore label