-
Notifications
You must be signed in to change notification settings - Fork 10
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
changes in weightNames for PS for UL samples #546
Comments
For refactored weights I have a fix already: https://github.com/kdlong/cmssw/blob/ImprovedParsingNano/SimDataFormats/GeneratorProducts/src/PartonShowerWeightGroupInfo.cc#L19-L72 For the current Nano production one needs to parse the weights and detect which indices to use from that. Should be good enough to see if they have a colon and an equals sign in them. |
@kdlong |
@mariadalfonso, it goes directly in the weightproducts. They aren't really tied to a particular data tier. In the current setup, they are either produced at the GEN step and stored in the file, or recreated before running the NanoAOD if they are missing in the file read in. They could even be added in the re-MiniAOD. |
Hi all,
I'm going to take another look at improving the NanoGen dqm in the coming
days. In particular, it should be possible to add plots for the LHE weights
to see that the number of weights and their distribution is consistent
across productions.
Is there any way to run a NanoGen workflow when testing a GEN-->NanoAOD
sample in mcm during central production? If we always ran NanoGEN dqm
before submitting a sample, we could catch these problems before samples
are produced.
Best,
Kenneth
…On Tue, Oct 6, 2020 at 5:05 PM mariadalfonso ***@***.***> wrote:
@kdlong <https://github.com/kdlong>
Thanks
one question: this fix act at which stage of the production ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#546 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTCN4DJMKNPX27ZSADL6OLSJMW2NANCNFSM4SF6ZT6Q>
.
|
Hi Kenneth, |
Should just need to change this line: The other things to search for are: fsr:murfac=2.0 this would find all the appropriate weights, but maybe not in the same order as they are now. You could set a flag and adjust the doc string accordingly. |
@dteague |
I talked with Kenneth earlier today to clear up some issue. I have a working code base, but I'm testing/fixing problems that crop up. I should have a PR open before the end of the day |
At this point, comments would be appreciated. I tried to make the code as general as possible, but I ran into a problem of one of my test files was missing the names in the LumiHeader meaning new code had to be put in as a backup in case this happens. It might be more sensible to go with a more hardcoded approach, but a code review can resolve that question. As for testing, I tested on about 7 files from this sheet, all of different generators. |
Hi @dteague . Why does the format depend on the input files? This happens inside P 8.240 and is added on top of LHE. |
The default PS weight order is
While for certain files, eg
I don't know the exactly what's causing the difference, but the format differences are such that the main variations are not in the spot in the weight vector if the user wants to add just those (ie Possibly @kdlong knows the cause of this difference, else I can look into this. Hopefully that answers your question? |
This is confusing. Do you mind pointing me to a "normal" dataset. |
For normal, I meant its the format I found in most of the files I tested. Definitely the second format with Here has info on these sets as well as a link to the DAS page for convience! |
Are you sure the PS weights in Note that the first two above: |
Hi Alexander, My expectation was that there should basically be 2 formats: old-style Pythia, and new-style Pythia. Of course there is a little flexibility for samples that don't have weights at all or a smaller set. What I understood from discussions with Dylan is that there are a small number of very weird files. @dteague can you post the file/dataset where you saw the issues with the weight names? I thought it was /ZGTo2NuG_TuneCP5_13TeV-amcatnloFXFX-pythia8/RunIIAutumn18MiniAOD-102X_upgrade2018_realistic_v15-v1/MINIAODSIM but looking at a few files here I don't see a problem |
@agrohsje I rechecked my samples and I noticed the TTToHadronic was actually a As for @kdlong 's comment, I think I mentioned the wrong data set there, it was actual the |
Right. There could be a total of 4 cases. Samples with P 8.230 and below, as well as samples with P 8.240 and above. |
It makes more sense that this sample is the issue, since it at least has the weights entered by hand. I don't immediately see the issue with the header: https://cms-pdmv.cern.ch/mcm/public/restapi/requests/get_fragment/TOP-RunIIFall17wmLHEGS-00075/0 Hopefully it's a one off? Or are all the hand-pasted PS weight samples the same? |
Ok, looks like the pattern is that all names with a space before them (either \ then space at the next line, or ", name" end up empty. Is this fragment special, or was this the same thing we copy pasted in a lot of places? |
Ok. I did some more tests. Good news: The new P8.240 logic is robust against wrong spaces. The bad news (as Kenneth wrote): the old is not. As discussed in the HN thread, the old logic searches for the first space and uses everything up to this as the name, i.e. in case there are misleading spaces, the name will just be empty. |
Please run cmsdriver for UL including this fragment : |
Thanks @agrohsje. This is good to know. It means that some of our code in the weight refactor needs to be revisited. @dteague do you mind taking a look at that? @agrohsje do this UL samples already have MiniAOD? It's easier for us to print out the header from those and to test the nano with nanogen if so. |
For request with the PS inluded there are plenty of examples: |
the ul change should happen before v8 production. maybe @dteague can quickly comment on his status. |
Hi all, before today, I thought I should have my changes applied to the Andreas fix branch (PR 35 reference above). In that PR, the code works for all of the cases @agrohsje mentioned above. @kdlong told me this should be addressed to the master branch here, so I've cherry picked the changes and am debugging/retesting the code. I should have these changes pushed and a PR open by tonight |
@agrohsje @mariadalfonso @kdlong I ran into a few errors after rerunning the tests, but now its working on all the samples, and now a PR is open |
issue solve in cms-sw#31982 |
As reported here
https://hypernews.cern.ch/HyperNews/CMS/get/generators/4819/1/1/1.html
due to the changes in weightNames for parton shower weights in newer CMSSW
need to adjust NANO-AOD weights for all UL samples.
@agrohsje
The text was updated successfully, but these errors were encountered: