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.
Dear Vishakha,
It looks like that one of the jobs in the /phenod/ data/vishakha/ MG5_aMC_ v3_3_2/ four_top_ nlo/SubProcesse s/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.