Comment 3 for bug 1986923

Revision history for this message
Rikkert Frederix (frederix) wrote :

Dear Vishakha,

It looks like that one of the jobs in the /phenod/data/vishakha/MG5_aMC_v3_3_2/four_top_nlo/SubProcesses/P0_gg_tttxtx/all_G* directories crashed. Do the log.txt files in these directories show a crash or a reason why one of these jobs stopped prematurely?

Two side remarks:
- I notice that you are using a four-flavour scheme for this process. This is very much non-optimal and you should switch to a five flavour scheme for increased accuracy.
- I see that you prefer setting the number grid points and iterations explicitly instead of letting MG5_aMC figure it out by setting a small req_acc_FO. Explicitly setting the number of points as you do is typically way more CPU intensive, since it will use this number of points for each integration channel irrespective of the contribution of that integration channel to the overall results, meaning a lot of wasted CPU time if the contribution of these integration channels is small. Instead, using req_acc_FO typically results in a better distribution of the points among the integration channels. In fact, the best method is probably to first run with req_acc_FO = 0.003, and, if the results are not accurate enough, reduce this number accordingly by e.g., dividing it by three (which will result in roughly a factor 10 longer running time) and then do a second run with the 'bin/calculate_xsec --nocompile --only_generation' command (or similar if using the 'launch' command) which skips compilation and starts from the existing grids to increase the accuracy of those.