MadGraph5_aMC@NLO

Support for split jobs when req_acc_fo < 0

Asked by Claudio Severi

Hello everyone,
I'm doing a tricky FO integration, and I would like to set by hand these parameters in the run card,

# These numbers are ignored except if req_acc_FO is equal to -1
 5000 = npoints_FO_grid ! number of points to setup grids
 4 = niters_FO_grid ! number of iter. to setup grids
 10000 = npoints_FO ! number of points to compute Xsec
 6 = niters_FO ! number of iter. to compute Xsec

It seems to me that doing so prevents mg5 from splitting the job, as line 2309 of amcatnlo_run_interface reads:

            if fixed_order and self.run_card['req_acc_FO'] > 0:
                ( go on to split jobs )

Is there any particular reason for this?

It would be nice to have the capability of using all cores available regardless of how the calculation is being done.

Thanks a lot,
Claudio

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
marco zaro Edit question
Last query:
Last reply:
Revision history for this message
marco zaro (marco-zaro) said : 		#1

Dear Claudio,
thanks for posting the question.
You are right, with req_acc_FO < 1 the runs will correspond to one job per integration channel.
i agree that it is not optimal; however, if you want to use all core, a criterion on which job to be run twice should also be put in place....
So I am not sure about how this can be improved.
I have also added Rikkert to the thread

Cheers,

MArco

Revision history for this message
marco zaro (marco-zaro) said : 		#2

Dear Claudio,
thanks for posting the question.
You are right, with req_acc_FO < 1 the runs will correspond to one job per integration channel.
i agree that it is not optimal; however, if you want to use all core, a criterion on which job to be run twice should also be put in place....
So I am not sure about how this can be improved.
I have also added Rikkert to the thread

Cheers,

MArco

Revision history for this message
Claudio Severi (claudio-severi) said : 		#3

 > if you want to use all core, a criterion on which job to be run twice should also be put in place.... So I am not sure about how this can be improved.

If I understand correctly, if I specify the number of PS points and iterations the job is only run once, so I don't think there is a need for a criterion for resubmission.

Perhaps we can make it so that the job is always split in nb_core pieces?

I tried and it seems to be working, but I'm not sure I'm doing things right.

Claudio

Revision history for this message
Rikkert Frederix (frederix) said : 		#4

Hello Claudio,

Setting req_acc_fo < 0 and putting the number of points and iterations by hand is, as far as I've seen, never more efficient than using a positive value for this parameter. What is the reason that for your interests you prefer to set the points and iterations by hand?

Best regards,
Rikkert

Revision history for this message
Claudio Severi (claudio-severi) said : 		#5

Thanks for your reply Rikkert,
the process is V+2j with some very stringent jet cuts, for which it seems that increasing the number of iterations is more desirable than increasing the number of points, perhaps because the integrator can adapt better to the small PS region I select.

Perhaps there is a better way to attack this kind of problem, what do you think?

Claudio

Revision history for this message
Rikkert Frederix (frederix) said : 		#6

Hello Claudio,

Depending on the exact phase-space region, it might be more beneficial to include a non-trivial bias_weight_function() in the cuts.f file to steer the phase-space generator towards the region of interest. This can then be combined with having somewhat less stringent cuts at the generation level, and the more extreme ones only in the analysis itself.

Best,
Rikkert

Can you help with this problem?

Provide an answer of your own, or ask Claudio Severi for more information if necessary.

To post a message you must log in.