Skip to content
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

Merged
merged 14 commits into from Apr 21, 2020

Conversation

Dr15Jones
Copy link
Contributor

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.

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.
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.
@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29445/14624

  • This PR adds an extra 92KB to repository

Code check has found code style and quality issues which could be resolved by applying following patch(s)

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29445/14625

  • This PR adds an extra 96KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @Dr15Jones (Chris Jones) for master.

It involves the following packages:

FWCore/Integration
FWCore/SharedMemory
GeneratorInterface/Core
GeneratorInterface/Pythia8Interface
SimDataFormats/GeneratorProducts

@SiewYan, @smuzaffar, @efeyazgan, @Dr15Jones, @mkirsano, @makortel, @cmsbuild, @agrohsje, @alberto-sanchez, @qliphy can you please review it and eventually sign? Thanks.
@mkirsano, @makortel, @rovere, @apsallid, @agrohsje, @wddgit, @lecriste, @alberto-sanchez, @fabiocos this is something you requested to watch as well.
@silviodonato, @dpiparo you are the release manager for this.

cms-bot commands are listed here

@makortel
Copy link
Contributor

@cmsbuild, please test

@makortel
Copy link
Contributor

+core

@makortel
Copy link
Contributor

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?)

@Dr15Jones
Copy link
Contributor Author

What is the plan for evaluating this? This was placed as a high priority by the L1s.

@silviodonato
Copy link
Contributor

What is the plan for evaluating this? This was placed as a high priority by the L1s.

@alberto-sanchez @agrohsje @efeyazgan @mkirsano @qliphy @SiewYan

@qliphy
Copy link
Contributor

qliphy commented Apr 21, 2020

+1

@cmsbuild
Copy link
Contributor

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.
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Contributor Author

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was intentional.

@silviodonato
Copy link
Contributor

+1
@Dr15Jones please have a look at my (trivial) comments above

@cmsbuild cmsbuild merged commit 8869156 into cms-sw:master Apr 21, 2020
@Dr15Jones Dr15Jones deleted the interProcGenerator branch April 21, 2020 14:21
@agrohsje
Copy link

Hi @Dr15Jones @smrenna @qliphy ,
I thought about this a little bit. Wouldn't it make sense to combine the cross sections taking their relative uncertainties into account. Referring to this comment from Chris:

For reviewers: the existing GenLumiInfoProduct::mergeProduct method does not attempt to combine the values for XSec. Instead, we just get the value from the first GenLumiInfoProduct. That seems less than optimal. Is there a reasonable way to combine the XSec values to get a more accurate number?

@makortel
Copy link
Contributor

I thought about this a little bit. Wouldn't it make sense to combine the cross sections taking their relative uncertainties into account.

Hi @agrohsje, I believe @Dr15Jones already did that (see below)? Or is the logic in GenXSecAnalyzer sub-optimal?

#29445 (comment)

You may refer to GenXSecAnalyzer which combines GenLumiInfoProduct to get accurate Xsec.

I used that calculation to handle XSec improvements in call to GenLumiInfoProduct::mergeProduct.

@srimanob
Copy link
Contributor

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?

@agrohsje
Copy link

@makortel no. that is exactly what i had in mind. missed the commit from chris, sorry.

@jordan-martins
Copy link
Contributor

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).

@qliphy
Copy link
Contributor

qliphy commented Apr 23, 2020

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?

We have done some local tests as you can see from above what Jordan reported on a BPH request, and also a MadGraph request:
#28899 (comment)

GEN plan to have a dedicated discussions on May 4th:
https://indico.cern.ch/event/894534/
where we will make further plans on validation, and foresee further improvement with MG support with readonly gridpack option.

colizz added a commit to colizz/cmssw that referenced this pull request Jul 12, 2020
…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.
colizz added a commit to colizz/cmssw that referenced this pull request Jul 12, 2020
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants