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
Run GeneratorFilter modules in an external process controlled by cmsRun #29445
Conversation
The ReadBuffers can now safely determine if the underlying buffer address was changed by a different ReadBuffer using the same shared memory.
These classes are used by the ExternalGeneratorFilter module for communicating with an external process.
Identical objects were returned failed comparisons
The added tests make sure what are supposed to be identical products are actually identical.
Also applied formatting.
The code used to merge GenLumiInfoProducts does not handle merging of the XSec information.
Can use a configuration parameter of ExternalGeneratorFilter to turn on verbose reporting from the external process.
The code-checks are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29445/14624
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29445/14625
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages: FWCore/Integration @SiewYan, @smuzaffar, @efeyazgan, @Dr15Jones, @mkirsano, @makortel, @cmsbuild, @agrohsje, @alberto-sanchez, @qliphy can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild, please test |
+core |
How can we eventually deploy the external GeneratorFilter? I'm wondering like what steps are needed from the GEN side, and where exactly we can or have to specify that a generator would be run externally (like does it have to into the generator configuration fragments, or can we have some more general switch e.g. in cmsDriver). (I know this PR is probably not the best place to discuss if the questions are nontrivial, should we open an issue, or how should we proceed?) |
What is the plan for evaluating this? This was placed as a high priority by the L1s. |
@alberto-sanchez @agrohsje @efeyazgan @mkirsano @qliphy @SiewYan |
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2) |
|
||
// forward declarations | ||
|
||
namespace edm::shared_memory { | ||
class ReadBuffer { | ||
public: | ||
/** iUniqueName : must be unique for all processes running on a system. | ||
iBufferIndex : is a pointer to a shared_memory address where the same address needs to be shared by ReadBuffer and WriteBuffer. | ||
iBufferInfo : is a pointer to a shared_memory address where the same address needs to be shared by ReadBuffer and WriteBuffer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you kept the same description on purpose?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of the variable is unchanged, I just changed the name to better reflect what it was doing.
|
||
// forward declarations | ||
|
||
namespace edm::shared_memory { | ||
class WriteBuffer { | ||
public: | ||
/** iUniqueName : must be unique for all processes running on a system. | ||
iBufferIndex : is a pointer to a shared_memory address where the same address needs to be shared by ReadBuffer and WriteBuffer. | ||
iBufferInfo : is a pointer to a shared_memory address where the same address needs to be shared by ReadBuffer and WriteBuffer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was intentional.
+1 |
Hi @Dr15Jones @smrenna @qliphy ,
|
Hi @agrohsje, I believe @Dr15Jones already did that (see below)? Or is the logic in
|
Should we plan to do validation on high statistics relvals for the next pre-release? Could GEN come with few workflows to use this feature before? |
@makortel no. that is exactly what i had in mind. missed the commit from chris, sorry. |
I did some preliminary test for the BPH dumby test as Chris used and further pointed me and it looks really nice. Previously, this dumby one had, with whatever number of cores (evtGen does not support MP), something around 35 events/lumi. With these implementations we could reach, with 4 cores, around 196 events/lumi. In terms of time/evt, prevously we had something around 0.3s to 0.6s. Now, my test indicates something around 0.0734s (a huge gain in core efficiency). |
We have done some local tests as you can see from above what Jordan reported on a BPH request, and also a MadGraph request: GEN plan to have a dedicated discussions on May 4th: |
…un (106X) Backport from cms-sw#29445. Additional changes: - GeneratorInterface/Core/bin/externalGenerator.cc: L131: disable macro CMS_SA_ALLOW. - GeneratorInterface/Pythia8Interface/test/compare_identical_generators_cfg.py: L6-8: default way to specify process.maxEvents, process.options. - GeneratorInterface/Pythia8Interface/test/compare_external_generators_cfg.py: L6-8: same. - GeneratorInterface/Pythia8Interface/test/compare_external_generators_streams_cfg.py: L6-12: same.
…un (106X) Backport from cms-sw#29445. Additional changes: - GeneratorInterface/Core/bin/externalGenerator.cc: L131: disable macro CMS_SA_ALLOW. - GeneratorInterface/Core/plugins/ExternalGeneratorFilter.cc: L3: add header "FWCore/Framework/interface/Run.h". - GeneratorInterface/Pythia8Interface/test/compare_identical_generators_cfg.py: L6-8: default way to specify process.maxEvents, process.options. - GeneratorInterface/Pythia8Interface/test/compare_external_generators_cfg.py: L6-8: same. - GeneratorInterface/Pythia8Interface/test/compare_external_generators_streams_cfg.py: L6-12: same.
PR description:
ExternalGeneratorFilter is a cmsRun module which can be configured to run a module built from GeneratorFilter<> in a separate process. This separate process is controlled by ExternalGeneratorFilter and cooperatively shares the CPU with cmsRun.
PR validation:
Additional unit tests were added to compare the output of Pythia8GeneratorFilter run directly within cmsRun and run via the ExternalGeneratorFilter. With just 1 stream/thread the output is identical. With multiple streams, the GenLumiInfoHeader, edm::HepMCProduct, GenEventInfoProduct and the GenRunInfoProduct are identical. The GenLumiInfoProduct is nearly identical exception the XSec value and errors are different.