-
Notifications
You must be signed in to change notification settings - Fork 789
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
Compilation Issues with reweight MG265 and SMEFTsim LO (master) #3084
Comments
Hi @GiacomoBoldrini which version of SMEFTSim is this? SMEFTSim 3.0? |
Hi @Saptaparna, thanks for the prompt answer. Yes it is v3.0.2 from https://github.com/SMEFTsim/SMEFTsim I should also add that a generation with the same model but different logic (one rwgt directory) works such as:
And reweight card something like:
As this method works, i deduced the issue stands in the reweight card difference. The latter approach is not feasible for a semileptonic final state due to the high number of diagrams. So we came up with the "change model" approach. Best, |
Actually i have to correct myself: pilotrun events do have reweighting weights and they seem to be plausible. I was looking at the wrong lhe. I'll copy here the cat of the partial lhe after two reweight steps with the "change model" reweight card. Weights are there and they differ, according to different hypothesis.
|
hi @GiacomoBoldrini . so pilot run looks good when using different rwgt pathes, but the pathes are still nested as you wrote above? and ./runcmsgrid.sh fails because the additional reweight pathes are not compiled when making the gridpack? |
Hi @agrohsje, Yes pilotrun is ok but rwgt dirs are still nested. I agree with you they won't be compiled by gridpack_generation.sh as it only look for the "rwgt" directory Here. But still i do not understand the nested structure, do you think it's expected? |
Right. I wanted to ask you to extend the logic of prepare_reweight to account for these special cases. However, I fail to understand the nested structure. |
Indeed If i run the reweighting step from a gridpack outside the genproduction environment ( ./bin/madevent --debug reweight run_01 ) i find this structure:
Where you can see that the "rwgt_*" directories are side by side. I'll attach also the reweight card:
|
Hi, I tried to compile the nested directories. I also tried to move them all in the same directory and then compile them. It does not solve the situation, the same error appear. Tried on both cmsconnect and lxplus. runcmsgrid.sh is able to generate events but the reweight breaks as before. I'll attach it here for completness [1]. However i tried changing reweight folder only once. That works fine, the event generation runs smoothly. Does this suggest something? Best, [1]
|
Hello, I'll reopen the conversation as I'm finding new infos.
In this way the folders are correctly placed:
Note here that the compilation path for the reweight needs an extra
becomes
If one tests this gridpack by placing an However, the process directory is moved at this point so the reweight card is no longer valid. A possible solution would be to change the reweight card (in
This seems to work at the moment. I'll carry new tests and hopefully come up with a PR if you'd like |
Actually a generation starting with reweight card the following
does work and should not need of any modification to the reweight card neither genproduction |
Dear experts,
I've been trying to generate the following process
where vector bosons are decayed with madspin.
The reweight is made changing model (and reweight folder) at each hypothesis such as:
The extramodel and restriction cards needed to reproduce the issue can be found here http://gboldrin.web.cern.ch/gboldrin/generators/SMEFTsim_U35_MwScheme_UFO.tar.gz
While this reweight card works in mg 265 interactive mode (generating events and then run LO reweighting), it fails with central tools while producing a gridpack.
Issuing
submit_cmsconnect_gridpack_generation.sh
does not yield errors either in codegen or during the pilot-run. Furthermore the newly computed weights do make sense:However they are not present in the pilot-run lhe file at
WmTo2JZto2L_dim6_ewk/WmTo2JZto2L_dim6_ewk_gridpack/work/unweighted_events.lhe
When unpacking the tarball and running
runcmsgrid.sh
the compilation breaks at the reweighting step because it is missing some fortran file (same as #2100 (comment)):Also compile the madevent folder fails due to some other missing files:
that means that also the generation without the reweighting is broken.
This also holds by generating the same gridpack locally (
gridpack_generation.sh
) and without madspin.Furthermore it is unclear the structure of the reweight folders which seems to be nested (highlighted with **):
while in the interactive reweighting they are created in the same directory.
I feel like this behaviour is unexpected. Could you have a look at it? Maybe i'm missing something here.
Thank you.
Best,
Giacomo
Logs & Tarball
At this link you can find the logs and the gridpack tarball that also contains the input cards if you need to have a look at them: http://gboldrin.web.cern.ch/gboldrin/gp_errors/
The text was updated successfully, but these errors were encountered: