-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for EDAlias as a case in SwitchProducer #25907
Conversation
Also add a test for the other kind of duplicate check
…cts are registered in a callback triggered by an EDAlias. All BranchDescriptions have been created after processEDAliases(), so let's move the call to BranchDescription::setOnDemand() there.
The clone() is needed to make SwitchProducer (that is clonable) to support EDAliases as cases. Making EDAlias to inherit from _Parameterizable reduces copy-paste. Also add unit tests for using Modifier for EDAlias.
- In configuration need some special cases for EDAlias - Need to process Switch aliases after all EDAliases in Principal, otherwise the aliased-for ProductResolvers would not necessarily exist - Add DataManagingOrAliasProductResolver to be able to connect SwitchBaseProductResolver to AliasProductResolver - Extend the duplicate product check in ProductSelector to disallow keeping both a real product, and EDAlias-within-SwitchProducer alias of the product - Add a test to verify that having a producer and SwitchProducer-with-EDAlias pointing to that producer in the wrong oder in a Path leads to an exception
…s ignored in output
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25907/8386
|
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages: DataFormats/Provenance @cmsbuild, @smuzaffar, @Dr15Jones can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild, please test |
The tests are being triggered in jenkins. |
-1 Tested at: 194c177 You can see the results of the tests here: I found follow errors while testing this PR Failed tests: Build HeaderConsistency
I found compilation error when building: Entering library rule at Mixing/Base >> Compiling /build/cmsbld/jenkins/workspace/ib-any-integration/CMSSW_10_5_X_2019-02-11-1100/src/Mixing/Base/src/PileUp.cc >> Compiling /build/cmsbld/jenkins/workspace/ib-any-integration/CMSSW_10_5_X_2019-02-11-1100/src/Mixing/Base/src/BMixingModule.cc >> Compiling /build/cmsbld/jenkins/workspace/ib-any-integration/CMSSW_10_5_X_2019-02-11-1100/src/Mixing/Base/src/SecondaryEventProvider.cc /build/cmsbld/jenkins/workspace/ib-any-integration/CMSSW_10_5_X_2019-02-11-1100/src/Mixing/Base/src/SecondaryEventProvider.cc: In constructor 'edm::SecondaryEventProvider::SecondaryEventProvider(std::vector&, edm::ProductRegistry&, std::shared_ptr)': /build/cmsbld/jenkins/workspace/ib-any-integration/CMSSW_10_5_X_2019-02-11-1100/src/Mixing/Base/src/SecondaryEventProvider.cc:27:22: error: 'class edm::WorkerManager' has no member named 'setOnDemandProducts' workerManager_.setOnDemandProducts(preg, unscheduledLabels); ^~~~~~~~~~~~~~~~~~~ gmake: *** [tmp/slc7_amd64_gcc700/src/Mixing/Base/src/MixingBase/SecondaryEventProvider.cc.o] Error 1 >> Building shared library tmp/slc7_amd64_gcc700/src/Mixing/Base/src/MixingBase/libMixingBase.so c++: error: tmp/slc7_amd64_gcc700/src/Mixing/Base/src/MixingBase/SecondaryEventProvider.cc.o: No such file or directory |
Comparison not run due to Build errors (RelVals and Igprof tests were also skipped) |
The tests are being triggered in jenkins. |
@makortel , for me it is a bit strange that this PR trigger problems of these tests. May it be that the modification makes the tests to be sensitive and they cannot work in parallel at the same node? |
@civanch I fully agree that the unit test failures are strange. But the failures are somewhat random (e.g. in #25907 (comment) only Also @smuzaffar commented in #25917 (comment)
|
I confirm that in my local test build I manage to execute successfully the failing tests. Let's try again... |
-1 Tested at: 95d0376 You can see the results of the tests here: I found follow errors while testing this PR Failed tests: UnitTests
I found errors in the following unit tests: ---> test testTauEmbeddingProducers had ERRORS |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Dear all, please note that the PR #25736 is also experiencing strange and random unit test failures .... |
code-checks |
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25907/8490
|
@civanch @mdhildreth as far as I can see, the change under the simulation umbrella in Mixing/Base is just a direct consequence of the other updates (the method used has been replace by another one). The short matrix tests involving PU do not show any difference, and the random failures in the unit tests are not explicitly related to the SIM part, and looks most likely an issue with the test ssyetm itself (under investigation). In agreement with @smuzaffar I will move forward with the merge of this PR, so as we may verify in an IB whether we observe similar problems (none so far). |
+1 |
merge to verify in an IB environment whether the observed random crashes appear as well, or whether the problem is related to the PR test environment |
Seems that all unit tests indeed succeeded in the IB. |
@makortel indeed this points towards an issue in the test system... |
In a heterogeneous workflow it may happen that the (legacy) CPU and non-CPU modules are naturally defined so differently that the final legacy CPU products are produced in a very asymmetric way (e.g.
A
producesa1
,a2
, producerB
produces `b1D
producesa1
, producerC
producesa2
andb1
). In order to be able to handle such cases flexibly and efficiently, this PR extends the SwitchProducer mechanism to allow EDAliases as cases (in addition to EDProducers). This required first some fixes to EDAliases:
produces()
, and that callback gets triggered by EDAlias (output) BranchDescriptions, the EDProducer BranchDescriptions have an incorrect on-demand status leading to a wrong ProductResolver and eventually a job to hang because of starvation in the TBB scheduler. This situation happens because the on-demand status for EDProducer BranchDescriptions is set before the EDAliases are processed in the Schedule. The fix is to move the setting of the on-demand status of BranchDescriptions to be done after the EDAlias output BranchDescriptions have been created.EDAlias
cloneable and to inherit from_Parameterizable
Modifier.toReplaceWith()
Adding the support for EDAlias cases in SwitchProducer required the following changes
DataManagingOrAliasProductResolver
, from which theDataManaging
,Alias
, andSwitchBase
ProductResolvers inherit from, in order to be able use bothDataManaging
andAlias
ProductResolvers as therealProduct
inSwitchBaseProductResolver
ProductSelector
to detect the case when one attempts to keep in OutputModule both the real product, and the EDAlias-within-SwitchProducer. Similar check is already done for regular EDAliases (as mentioned above)BranchID
of the SwitchProducer and the case product/alias are different, while in case of EDAlias theBranchID
of the alias and the alias-for product as the same.Process
, separateSwitchProducers
from the normalEDProducers
. This change is needed in order to append elements to both@all_modules
and@all_aliases
vstring
s when filling the ProcessDescription. This way the case-EDAlias can away from theProcess.aliases_()
(as the case-EDProducers are not inProcess.producers_()
).keep *_foo*_*_*
.ProductSelector
, but that lead to SwitchProducer branches being dropped on inputs as they would be interpreted as branches depending on a dropped branch.This PR also adds a generic mechanism to allow customized configuration entities to pass import statements to configuration dump. Related, currently the case-producer fragments end up in the configuration dump while they should not, this PR fixes that (as a byproduct).
Tested in CMSSW_10_5_X_2019-02-08-1100, no changes expected in current workflows.