Readonly gridpack mode costs more time in "madevent"

Asked by Congqiao Li on 2021-05-01

Dear experts,

I am working on the validation of the readonly gridpack mode from a CMS study. I recently noticed that in the readonly gridpack mode, more calculation is done in the "madevent" step than the normal gridpack mode, hence costing more time. I can reproduce this issue in a w+0123jet LO gridpack produced by V2.6.1 and V2.7.2 [1], but no longer in the latest version V3.1.0 [2].

As in the experiment some old version gridpack may be recycled for use, I am interested to learn what causes the issue and how it was fixed.
As far as I have reached, the "madevent" job is launched by a script "ajob1" in each subprocess. For a readonly mode routine, the program release "ajob1" and launch it from *an empty* directory, i.e. there is no "G*" subfolders. However, I noticed that some file e.g. "ftn25" in the "G*" folder may be used during the "madevent" step -- if I manually launch "ajob1" with "ftn25" file in the "G*" folder exists, the job can be finished much faster [3] (which I think is the condition for normal gridpack mode). I am not sure how the input file "ftn25" functions, but because they are produced at the gridpack generation stage, I wonder they may be somehow useful when generating events.

Thus I have the following question:
1) What causes the extra calculation in the readonly gridpack mode; and what is being fixed in the latest version so the issue is solved?
2) What is exactly "ftn25" and how it plays into a "madevent" process.
3) For gridpacks already produced in the previous version, is it possible to solve it with a patch as well? Will there be other physical problem in the old version gridpack for readonly mode w.r.t. the normal mode (e.g. a different kinematics distribution) ?

Thank you very much for your time and answers.

Best regards,
Congqiao

----
Some materials I use:
[1] V2.7.2 gridpack: https://coli.web.cern.ch/coli/tmp/.210430-195717_mgtest/w3jet_mg272_fix.tar.gz
[2] V3.1.0 gridpack: https://coli.web.cern.ch/coli/tmp/.210430-195717_mgtest/w3jet_mg310.tar.gz
[3] a standalone "ajob1" test (grab from a CMS gridpack, in V2.6.1): https://coli.web.cern.ch/coli/tmp/.210430-195717_mgtest/standalone_ajob1_test.tar.gz
Untar it in a folder, launch "./ajob1" for the first time and it costs ~2 min to finish. Then launch it for a second time (now G117/ftn25 exists) and it costs only ~20 s.

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:

Hi,

This has been fixed a while ago (2 years ago?) after that issue being identified by CMS and reported to us.
The issue is indeed that the integration grid (the ftn25 file) was not correctly re-used in read-only mode.
A patch was already provided to CMS 2 years ago (I guess one can find the question or bu report on launchpad)

Cheers,

Olivier

> On 1 May 2021, at 11:45, Congqiao Li <email address hidden> wrote:
>
> New question #696856 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/696856
>
> Dear experts,
>
> I am working on the validation of the readonly gridpack mode from a CMS study. I recently noticed that in the readonly gridpack mode, more calculation is done in the "madevent" step than the normal gridpack mode, hence costing more time. I can reproduce this issue in a w+0123jet LO gridpack produced by V2.6.1 and V2.7.2 [1], but no longer in the latest version V3.1.0 [2].
>
> As in the experiment some old version gridpack may be recycled for use, I am interested to learn what causes the issue and how it was fixed.
> As far as I have reached, the "madevent" job is launched by a script "ajob1" in each subprocess. For a readonly mode routine, the program release "ajob1" and launch it from *an empty* directory, i.e. there is no "G*" subfolders. However, I noticed that some file e.g. "ftn25" in the "G*" folder may be used during the "madevent" step -- if I manually launch "ajob1" with "ftn25" file in the "G*" folder exists, the job can be finished much faster [3] (which I think is the condition for normal gridpack mode). I am not sure how the input file "ftn25" functions, but because they are produced at the gridpack generation stage, I wonder they may be somehow useful when generating events.
>
> Thus I have the following question:
> 1) What causes the extra calculation in the readonly gridpack mode; and what is being fixed in the latest version so the issue is solved?
> 2) What is exactly "ftn25" and how it plays into a "madevent" process.
> 3) For gridpacks already produced in the previous version, is it possible to solve it with a patch as well? Will there be other physical problem in the old version gridpack for readonly mode w.r.t. the normal mode (e.g. a different kinematics distribution) ?
>
> Thank you very much for your time and answers.
>
> Best regards,
> Congqiao
>
> ----
> Some materials I use:
> [1] V2.7.2 gridpack: https://coli.web.cern.ch/coli/tmp/.210430-195717_mgtest/w3jet_mg272_fix.tar.gz
> [2] V3.1.0 gridpack: https://coli.web.cern.ch/coli/tmp/.210430-195717_mgtest/w3jet_mg310.tar.gz
> [3] a standalone "ajob1" test (grab from a CMS gridpack, in V2.6.1): https://coli.web.cern.ch/coli/tmp/.210430-195717_mgtest/standalone_ajob1_test.tar.gz
> Untar it in a folder, launch "./ajob1" for the first time and it costs ~2 min to finish. Then launch it for a second time (now G117/ftn25 exists) and it costs only ~20 s.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Can you help with this problem?

Provide an answer of your own, or ask Congqiao Li for more information if necessary.

To post a message you must log in.