Merge lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny
Status: | Merged |
---|---|
Merge reported by: | Olivier Mattelaer |
Merged at revision: | not available |
Proposed branch: | lp:~maddevelopers/mg5amcnlo/3.0.1 |
Merge into: | lp:~maddevelopers/mg5amcnlo/FKS_EW_granny |
Diff against target: |
48081 lines (+15230/-26000) 241 files modified
MadSpin/decay.py (+12/-3) MadSpin/interface_madspin.py (+342/-174) MadSpin/madspin (+19/-21) MadSpin/src/driver.f (+5/-5) Template/LO/Cards/run_card.dat (+1/-1) Template/LO/SubProcesses/genps.f (+7/-18) Template/LO/SubProcesses/reweight.f (+102/-10) Template/LO/SubProcesses/unwgt.f (+11/-0) Template/NLO/FixedOrderAnalysis/analysis_HwU_general.f (+880/-0) Template/NLO/MCatNLO/Makefile_MadFKS (+1/-1) Template/NLO/SubProcesses/MC_integer.f (+3/-6) Template/NLO/SubProcesses/analysis_lhe.f (+31/-15) Template/NLO/SubProcesses/check_poles.f (+2/-2) Template/NLO/SubProcesses/combine_plots_FO.sh (+56/-110) Template/NLO/SubProcesses/driver_mintFO.f (+53/-23) Template/NLO/SubProcesses/driver_mintMC.f (+8/-14) Template/NLO/SubProcesses/fks_singular.f (+19/-9) Template/NLO/SubProcesses/genps_fks.f (+1/-1) Template/NLO/SubProcesses/makefile (+0/-6) Template/NLO/SubProcesses/mint-integrator2.f (+4/-4) Template/NLO/SubProcesses/montecarlocounter.f (+3259/-3231) Template/NLO/SubProcesses/read40.for (+1/-1) Template/NLO/SubProcesses/split40.f (+0/-51) Template/NLO/SubProcesses/symmetry_fks_v3.f (+52/-9) UpdateNotes.txt (+55/-3) VERSION (+2/-3) aloha/aloha_writers.py (+24/-7) aloha/create_aloha.py (+3/-4) madgraph/core/base_objects.py (+8/-2) madgraph/fks/fks_base.py (+7/-2) madgraph/fks/fks_helas_objects.py (+1/-1) madgraph/interface/amcatnlo_interface.py (+23/-10) madgraph/interface/amcatnlo_run_interface.py (+91/-106) madgraph/interface/common_run_interface.py (+106/-26) madgraph/interface/extended_cmd.py (+40/-11) madgraph/interface/launch_ext_program.py (+15/-10) madgraph/interface/loop_interface.py (+13/-5) madgraph/interface/madevent_interface.py (+32/-11) madgraph/interface/madgraph_interface.py (+57/-16) madgraph/interface/reweight_interface.py (+13/-5) madgraph/iolibs/export_fks.py (+16/-6) madgraph/iolibs/export_v4.py (+43/-34) madgraph/iolibs/file_writers.py (+3/-3) madgraph/iolibs/files.py (+3/-0) madgraph/iolibs/template_files/matrix_standalone_splitOrders_v4.inc (+2/-2) madgraph/iolibs/template_files/matrix_standalone_v4.inc (+1/-1) madgraph/iolibs/ufo_expression_parsers.py (+240/-12) madgraph/loop/loop_exporters.py (+15/-1) madgraph/loop/loop_helas_objects.py (+3/-3) madgraph/madevent/gen_crossxhtml.py (+18/-2) madgraph/madevent/sum_html.py (+7/-1) madgraph/various/banner.py (+44/-18) madgraph/various/hepmc_parser.py (+362/-0) madgraph/various/lhe_parser.py (+61/-7) madgraph/various/misc.py (+4/-3) madgraph/various/systematics.py (+1/-0) mg5decay/decay_objects.py (+1/-1) models/check_param_card.py (+9/-5) models/import_ufo.py (+380/-37) models/model_reader.py (+7/-1) models/write_param_card.py (+2/-2) tests/IOTests.py (+11/-5) tests/acceptance_tests/test_cmd_amcatnlo.py (+13/-6) tests/acceptance_tests/test_cmd_madevent.py (+36/-9) tests/acceptance_tests/test_cmd_madloop.py (+2/-2) tests/acceptance_tests/test_cmd_reweight.py (+2/-2) tests/acceptance_tests/test_madspin.py (+166/-0) tests/acceptance_tests/test_madweight.py (+6/-6) tests/acceptance_tests/test_model_equivalence.py (+8/-6) tests/input_files/DM_pion/CT_couplings.py (+1731/-0) tests/input_files/DM_pion/CT_vertices.py (+1291/-0) tests/input_files/DM_pion/__init__.py (+48/-0) tests/input_files/DM_pion/coupling_orders.py (+25/-0) tests/input_files/DM_pion/couplings.py (+563/-0) tests/input_files/DM_pion/decays.py (+113/-0) tests/input_files/DM_pion/function_library.py (+71/-0) tests/input_files/DM_pion/lorentz.py (+182/-0) tests/input_files/DM_pion/object_library.py (+377/-0) tests/input_files/DM_pion/param_pion.dat (+183/-0) tests/input_files/DM_pion/parameters.py (+858/-0) tests/input_files/DM_pion/particles.py (+489/-0) tests/input_files/DM_pion/propagators.py (+35/-0) tests/input_files/DM_pion/py.py (+67/-0) tests/input_files/DM_pion/vertices.py (+1007/-0) tests/input_files/DM_pion/write_param_card.py (+207/-0) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_gg_ttx%configs_and_props_info.dat (+0/-1358) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_gg_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_gg_ttx%leshouche_info.dat (+0/-143) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_uux_ttx%configs_and_props_info.dat (+0/-504) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_uux_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_uux_ttx%leshouche_info.dat (+0/-123) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_uxu_ttx%configs_and_props_info.dat (+0/-504) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_uxu_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksreal/%SubProcesses%P0_uxu_ttx%leshouche_info.dat (+0/-123) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ag_ttx%configs_and_props_info.dat (+0/-709) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ag_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ag_ttx%leshouche_info.dat (+0/-64) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ddx_ttx%born.f (+1/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ddx_ttx%configs_and_props_info.dat (+0/-1668) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ddx_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ddx_ttx%leshouche_info.dat (+0/-147) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ddx_ttx%matrix_3.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ddx_ttx%matrix_4.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ddx_ttx%matrix_6.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_dxd_ttx%born.f (+1/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_dxd_ttx%configs_and_props_info.dat (+0/-1668) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_dxd_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_dxd_ttx%leshouche_info.dat (+0/-147) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_dxd_ttx%matrix_3.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_dxd_ttx%matrix_4.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_dxd_ttx%matrix_6.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ga_ttx%configs_and_props_info.dat (+0/-709) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ga_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_ga_ttx%leshouche_info.dat (+0/-64) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_gg_ttx%configs_and_props_info.dat (+0/-2012) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_gg_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_gg_ttx%leshouche_info.dat (+0/-129) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_gg_ttx%matrix_1.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_gg_ttx%matrix_2.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_gg_ttx%matrix_5.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_gg_ttx%matrix_6.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_uux_ttx%configs_and_props_info.dat (+0/-1668) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_uux_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_uux_ttx%leshouche_info.dat (+0/-147) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_uxu_ttx%configs_and_props_info.dat (+0/-1668) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_uxu_ttx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_pptt_fksrealew/%SubProcesses%P0_uxu_ttx%leshouche_info.dat (+0/-147) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_dxu_wp%V0_dxu_wp%CT_interface.f (+7/-264) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_dxu_wp%V0_dxu_wp%GOLEM_interface.f (+0/-748) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_dxu_wp%V0_dxu_wp%TIR_interface.f (+4/-12) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_dxu_wp%V0_dxu_wp%born_matrix.f (+2/-2) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_dxu_wp%V0_dxu_wp%loop_matrix.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_udx_wp%V0_udx_wp%CT_interface.f (+7/-264) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_udx_wp%V0_udx_wp%GOLEM_interface.f (+0/-748) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_udx_wp%V0_udx_wp%TIR_interface.f (+4/-12) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_udx_wp%V0_udx_wp%born_matrix.f (+2/-2) tests/input_files/IOTestsComparison/IOExportFKSTest/test_ppw_fksall/%SubProcesses%P0_udx_wp%V0_udx_wp%loop_matrix.f (+3/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_tdecay_fksreal/%SubProcesses%P0_t_budx%configs_and_props_info.dat (+0/-261) tests/input_files/IOTestsComparison/IOExportFKSTest/test_tdecay_fksreal/%SubProcesses%P0_t_budx%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_tdecay_fksreal/%SubProcesses%P0_t_budx%leshouche_info.dat (+0/-33) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%MadLoop5_resources%ColorDenomFactors.dat (+0/-50) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%MadLoop5_resources%ColorNumFactors.dat (+0/-50) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%MadLoop5_resources%HelConfigs.dat (+0/-16) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%CT_interface.f (+19/-270) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%GOLEM_interface.f (+0/-748) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%TIR_interface.f (+4/-12) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%born_matrix.f (+5/-5) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%coef_construction_1.f (+16/-14) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%f2py_wrapper.f (+37/-2) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%helas_calls_ampb_1.f (+7/-8) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%improve_ps.f (+24/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%loop_matrix.f (+21/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%mp_coef_construction_1.f (+16/-16) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%V0_dxu_veep%mp_helas_calls_ampb_1.f (+6/-7) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%configs_and_props_info.dat (+0/-347) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%leshouche_info.dat (+0/-43) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%matrix_1.f (+1/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%matrix_2.f (+1/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_dxu_veep%matrix_3.f (+1/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%MadLoop5_resources%ColorDenomFactors.dat (+0/-50) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%MadLoop5_resources%ColorNumFactors.dat (+0/-50) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%MadLoop5_resources%HelConfigs.dat (+0/-16) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%CT_interface.f (+19/-270) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%GOLEM_interface.f (+0/-748) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%TIR_interface.f (+4/-12) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%born_matrix.f (+5/-5) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%coef_construction_1.f (+16/-14) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%f2py_wrapper.f (+37/-2) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%helas_calls_ampb_1.f (+7/-8) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%improve_ps.f (+24/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%loop_matrix.f (+21/-3) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%mp_coef_construction_1.f (+17/-17) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%V0_udx_veep%mp_helas_calls_ampb_1.f (+6/-7) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%configs_and_props_info.dat (+0/-347) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%iproc.dat (+0/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%leshouche_info.dat (+0/-43) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%matrix_1.f (+1/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%matrix_2.f (+1/-1) tests/input_files/IOTestsComparison/IOExportFKSTest/test_wprod_fksew/%SubProcesses%P0_udx_veep%matrix_3.f (+1/-1) tests/input_files/IOTestsComparison/IOExportV4IOTest/export_matrix_element_v4_standalone/matrix.f (+1/-1) tests/input_files/IOTestsComparison/MECmdShell/check_html_long_process_strings/info.html (+80/-80) tests/input_files/IOTestsComparison/MadLoop_output_from_the_interface/TIR_output/%ggttx_IOTest%SubProcesses%P0_gg_ttx%CT_interface.f (+23/-279) tests/input_files/IOTestsComparison/MadLoop_output_from_the_interface/TIR_output/%ggttx_IOTest%SubProcesses%P0_gg_ttx%GOLEM_interface.f (+0/-823) tests/input_files/IOTestsComparison/MadLoop_output_from_the_interface/TIR_output/%ggttx_IOTest%SubProcesses%P0_gg_ttx%TIR_interface.f (+4/-12) tests/input_files/IOTestsComparison/MadLoop_output_from_the_interface/TIR_output/%ggttx_IOTest%SubProcesses%P0_gg_ttx%born_matrix.f (+2/-2) tests/input_files/IOTestsComparison/MadLoop_output_from_the_interface/TIR_output/%ggttx_IOTest%SubProcesses%P0_gg_ttx%loop_matrix.f (+3/-3) tests/input_files/IOTestsComparison/SquaredOrder_IOTest/sqso_uux_uuxuuxx/matrix_NoSQSO.f (+1/-1) tests/input_files/IOTestsComparison/SquaredOrder_IOTest/sqso_uux_uuxuuxx/matrix_QCDsq_le_6.f (+2/-2) tests/input_files/IOTestsComparison/SquaredOrder_IOTest/sqso_uux_uuxuuxx/matrix_ampOrderQED2_eq_2_WGTsq_le_14_QCDsq_gt_4.f (+2/-2) tests/input_files/IOTestsComparison/TestCmdMatchBox/MatchBoxOutput/%TEST%SubProcesses%P0_wpwm_wpwm%matrix.f (+8/-8) tests/input_files/IOTestsComparison/TestCmdMatchBox/MatchBoxOutput/%TEST%SubProcesses%P1_uux_uux%CT_interface.f (+15/-273) tests/input_files/IOTestsComparison/TestCmdMatchBox/MatchBoxOutput/%TEST%SubProcesses%P1_uux_uux%GOLEM_interface.f (+0/-755) tests/input_files/IOTestsComparison/TestCmdMatchBox/MatchBoxOutput/%TEST%SubProcesses%P1_uux_uux%TIR_interface.f (+4/-12) tests/input_files/IOTestsComparison/TestCmdMatchBox/MatchBoxOutput/%TEST%SubProcesses%P1_uux_uux%loop_matrix.f (+3/-3) tests/input_files/IOTestsComparison/long_ML_SMQCD_default/dux_mumvmxg/%..%..%Source%MODEL%model_functions.f (+0/-21) tests/input_files/IOTestsComparison/long_ML_SMQCD_default/dux_mumvmxg/%..%..%Source%MODEL%model_functions.inc (+0/-2) tests/input_files/IOTestsComparison/long_ML_SMQCD_default/dux_mumvmxg/born_matrix.f (+1/-1) tests/input_files/IOTestsComparison/long_ML_SMQCD_default/gg_wmtbx/%..%..%Source%MODEL%model_functions.f (+0/-21) tests/input_files/IOTestsComparison/long_ML_SMQCD_default/gg_wmtbx/%..%..%Source%MODEL%model_functions.inc (+0/-2) tests/input_files/IOTestsComparison/long_ML_SMQCD_default/gg_wmtbx/born_matrix.f (+1/-1) tests/input_files/IOTestsComparison/long_ML_SMQCD_optimized/dux_mumvmxg/%..%..%Source%MODEL%model_functions.f (+0/-21) tests/input_files/IOTestsComparison/long_ML_SMQCD_optimized/dux_mumvmxg/%..%..%Source%MODEL%model_functions.inc (+0/-2) tests/input_files/IOTestsComparison/long_ML_SMQCD_optimized/dux_mumvmxg/born_matrix.f (+1/-1) tests/input_files/IOTestsComparison/long_ML_SMQCD_optimized/gg_wmtbx/%..%..%Source%MODEL%model_functions.f (+0/-21) tests/input_files/IOTestsComparison/long_ML_SMQCD_optimized/gg_wmtbx/%..%..%Source%MODEL%model_functions.inc (+0/-2) tests/input_files/IOTestsComparison/long_ML_SMQCD_optimized/gg_wmtbx/born_matrix.f (+1/-1) tests/input_files/IOTestsComparison/short_ML_SMQCD_LoopInduced/gg_hh/%..%..%Source%MODEL%model_functions.f (+0/-21) tests/input_files/IOTestsComparison/short_ML_SMQCD_LoopInduced/gg_hh/%..%..%Source%MODEL%model_functions.inc (+0/-2) tests/input_files/IOTestsComparison/short_ML_SMQCD_default/ddx_ttx/born_matrix.f (+1/-1) tests/input_files/IOTestsComparison/short_ML_SMQCD_default/gg_ttx/%..%..%Source%MODEL%model_functions.f (+0/-21) tests/input_files/IOTestsComparison/short_ML_SMQCD_default/gg_ttx/%..%..%Source%MODEL%model_functions.inc (+0/-2) tests/input_files/IOTestsComparison/short_ML_SMQCD_default/gg_ttx/born_matrix.f (+1/-1) tests/input_files/IOTestsComparison/short_ML_SMQCD_optimized/ddx_ttx/born_matrix.f (+1/-1) tests/input_files/IOTestsComparison/short_ML_SMQCD_optimized/gg_ttx/%..%..%Source%MODEL%model_functions.f (+0/-21) tests/input_files/IOTestsComparison/short_ML_SMQCD_optimized/gg_ttx/%..%..%Source%MODEL%model_functions.inc (+0/-2) tests/input_files/IOTestsComparison/short_ML_SMQCD_optimized/gg_ttx/born_matrix.f (+1/-1) tests/parallel_tests/madevent_comparator.py (+2/-2) tests/parallel_tests/me_comparator.py (+3/-5) tests/parallel_tests/test_ML5.py (+1/-1) tests/parallel_tests/test_ML5MSSMQCD.py (+1/-1) tests/parallel_tests/test_aloha.py (+168/-2) tests/parallel_tests/test_cmd_amcatnlo.py (+5/-3) tests/parallel_tests/test_madweight.py (+3/-3) tests/test_manager.py (+1/-1) tests/time_db (+80/-78) tests/unit_tests/fks/test_extra_ew.py (+26/-3) tests/unit_tests/fks/test_fks_base.py (+10/-10) tests/unit_tests/iolibs/test_export_v4.py (+1/-1) tests/unit_tests/iolibs/test_helas_call_writers.py (+30/-30) tests/unit_tests/iolibs/test_link_to_ufo.py (+7/-2) tests/unit_tests/iolibs/test_ufo_parsers.py (+56/-3) tests/unit_tests/madspin/test_madspin.py (+7/-0) tests/unit_tests/various/test_banner.py (+19/-0) tests/unit_tests/various/test_decay.py (+2/-2) tests/unit_tests/various/test_import_ufo.py (+138/-8) tests/unit_tests/various/test_misc.py (+48/-7) vendor/CutTools/src/makefile (+10/-4) vendor/CutTools/src/qcdloop/aaxex.f (+1/-1) vendor/IREGI/src/qcdloop/ff/aaxex.f (+1/-1) vendor/IREGI/src/qcdloop/ff/makefile (+1/-1) |
To merge this branch: | bzr merge lp:~maddevelopers/mg5amcnlo/3.0.1 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Olivier Mattelaer | 2018-10-04 | Approve on 2018-12-19 | |
marco zaro | 2018-10-04 | Needs Fixing on 2018-11-21 | |
Hua-Sheng Shao | 2018-10-04 | Pending | |
Valentin Hirschi | 2018-10-04 | Pending | |
davide.pagani.85 | 2018-10-04 | Pending | |
Review via email:
|
Commit message
Hi guys,
Before getting super excited and doing lots of test for the 4FS, we should release this code first...
Note: I proposed for merging with the FKS_EW_granny branch -- I don't know if this is exactly the branch relevant to the 3.0.0 release.
Cheers,
Rik
marco zaro (marco-zaro) wrote : | # |
Rikkert Frederix (frederix) wrote : | # |
It's not enabled. We should. Could you please do this?
- 942. By marco zaro on 2018-10-04
-
fixes in amcatnlo_
run_interface. py to enable NLOPS for QCD-only
not fully working yet
marco zaro (marco-zaro) wrote : | # |
I have pushed a fix, however, it is not complete yet (and the behaviour is quite strange)
for example, I cannot set fixed_order=OFF via the switches.
However, ./bin/generate_
launch aMC@NLO
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = ON ⇐ ̶O̶F̶F̶ ̶ | ON |
| 3. Shower the generated events | shower = OFF ⇐ ̶H̶E̶R̶W̶I̶G̶6̶ ̶ | OFF|PYTHIA6Q|
| 4. Decay onshell particles | madspin = OFF | ON|onshell |
| 5. Add weights to events for new hypp. | reweight = OFF | ON|NLO|NLO_TREE|LO |
| 6. Run MadAnalysis5 on the events generated | madanalysis = Not Avail. | Please install module |
\======
Either type the switch number (1 to 6) to change its setting,
which looks weird…
can anyone who knows better the business of these switches have a look?
thanks!
cheers,
Marco
> On 4 Oct 2018, at 15:07, Rikkert Frederix <email address hidden> wrote:
>
> It's not enabled. We should. Could you please do this?
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
- 943. By Rikkert Frederix on 2018-10-04
-
fixed the switches
Rikkert Frederix (frederix) wrote : | # |
Hi,
A small change means that the switches are okay now for the QCD stuff. However, for QED, the formatting looks off. I'm not sure we should be too worried about this, since it works correctly. If there is a simple fix, we might apply it.
Cheers,
Rikkert
- 944. By marco zaro on 2018-10-04
-
small fix
Hi Rikkert,
The display is actually perfect for QED (see below):
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = ON | No NLO+PS available for EW correction |
\======
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'madspin=onshell' at the prompt)
Type 'help' for the list of all valid option
Type '0', 'auto', 'done' or just press enter when you are done.[60s to answer]
Maybe are you referring to the display in debug mode, which include the hidden line (madspin/...)
which are important to see (but only in debug mode). [Also for the hidden option of MadSpin]
In that case, formatting is indeed weird.
I have (slightly) improve it
1) passing the color to green (more consistent with debug coloring in general)
2) fixing the change of length due to the presence of the coloring
This is still not perfect since the length of each column does not take into account those hidden line.
and therefore they can go to overflow.
Cheers,
Olivier
> On 4 Oct 2018, at 17:16, Rikkert Frederix <email address hidden> wrote:
>
> Hi,
>
> A small change means that the switches are okay now for the QCD stuff. However, for QED, the formatting looks off. I'm not sure we should be too worried about this, since it works correctly. If there is a simple fix, we might apply it.
>
> Cheers,
> Rikkert
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
- 945. By olivier-mattelaer on 2018-10-04
-
fix some question formatting for hidden line [debgug mode only]
Hi,
I run (some of) the test this morning (actually 630 of thoses)
and this one sounds quite bad:
ERROR: test_generate_
check that the generate command works as expected.
-------
Traceback (most recent call last):
File "/Users/
self.
File "/Users/
self.
File "/Users/
Valid property are %s""" % (name,self.
PhysicsObjectError: splitting_types is not a valid property for this object: FKSMultiProcess
Valid property are ['has_isr', 'use_numerical', 'amplitudes', 'born_processes', 'pdgs', 'ignore_
some other crashes like this one:
=======
FAIL: testIO_
target: SubProcesses/
-------
Traceback (most recent call last):
File "/Users/
testKeys=
File "/Users/
self.
File "/Users/
self.
AssertionError: ' CALL FFV1_2(
Which should be related to model optimization include in 2.6.3. I believe that this is fine (amy does not agree?)
Cheers,
Olivier
On 4 Oct 2018, at 23:24, Olivier Mattelaer <<email address hidden>
Hi Rikkert,
The display is actually perfect for QED (see below):
The following switches determine which programs are run:
/================== Description =======
| 1. Type of perturbative computation | order = NLO | LO |
| 2. No MC@[N]LO matching / event generation | fixed_order = ON | No NLO+PS available for EW correction |
\======
Either type the switch number (1 to 6) to change its setting,
Set any switch explicitly (e.g. type 'madspin=onshell' at the prompt)
T...
- 946. By marco zaro on 2018-10-05
-
fixed one test
marco zaro (marco-zaro) wrote : | # |
Hi Olivier,
the test you mentioned below was simply not updated after a change I did.
Now it is passing.
Cheers,
Marco
> On 5 Oct 2018, at 09:48, Olivier Mattelaer <email address hidden> wrote:
>
> Hi,
>
> I run (some of) the test this morning (actually 630 of thoses)
> and this one sounds quite bad:
>
> ERROR: test_generate_
> check that the generate command works as expected.
> -------
> Traceback (most recent call last):
> File "/Users/
> self.assertEqua
> File "/Users/
> self.is_
> File "/Users/
> Valid property are %s""" % (name,self.
> PhysicsObjectError: splitting_types is not a valid property for this object: FKSMultiProcess
>
> Valid property are ['has_isr', 'use_numerical', 'amplitudes', 'born_processes', 'pdgs', 'ignore_
>
> some other crashes like this one:
>
> =======
> FAIL: testIO_
> target: SubProcesses/
> -------
> Traceback (most recent call last):
> File "/Users/
> testKeys=
> File "/Users/
> self.assertFile
> File "/Users/
> self.assertEqua
> AssertionError: ' CALL FFV1_2(
>
>
> Which should be related to model optimization include in 2.6.3. I believe that this is fine (amy does not agree?)
>
> Cheers,
>
> Olivier
>
> On 4 Oct 2018, at 23:24, Olivier Mattelaer <<email address hidden> <mailto:<email address hidden>
>
> Hi Rikkert,
>
> The display is actually perfect for QED (see below):
>
>
> The following switches determine which programs are run:
> /================== Description =======
> | 1. Type of perturbative computation | order = NLO | LO |
> | 2. No MC@[N]LO matching / e...
Rikkert Frederix (frederix) wrote : | # |
Hi,
There is another issue that should be fixed. In particular, when requiring e.g.,
p p > j j QED=0 QCD=4 [QED]
the code also includes QCD corrections (i.e., NLO_1), since at the squared order level, they are allowed. To remove them, one needs to set QCD=2.
In my opinion, the QED=0 and QCD=4 should be used to define which LO contributions should be included, and the ones between the square brackets to determine if one should include QCD and/or QED corrections on top of the Born contributions. Hence,
p p > j j QED=0 QCD=4 [QED]
and
p p > j j QED=0 QCD=2 [QED]
should lead to exactly the same results.
Who knows how to fix this?
Cheers,
Rikkert
On that topic,
Would not be a good idea to put somewhere the plot corresponding to NLO_X LO_Y?
This could be very usefull to know what is computed and what is included by the code.
(what about for 3.0.2?)
Cheers,
Olivier
> On 5 Oct 2018, at 10:48, Rikkert Frederix <email address hidden> wrote:
>
> Hi,
>
> There is another issue that should be fixed. In particular, when requiring e.g.,
>
> p p > j j QED=0 QCD=4 [QED]
>
> the code also includes QCD corrections (i.e., NLO_1), since at the squared order level, they are allowed. To remove them, one needs to set QCD=2.
>
> In my opinion, the QED=0 and QCD=4 should be used to define which LO contributions should be included, and the ones between the square brackets to determine if one should include QCD and/or QED corrections on top of the Born contributions. Hence,
>
> p p > j j QED=0 QCD=4 [QED]
> and
> p p > j j QED=0 QCD=2 [QED]
>
> should lead to exactly the same results.
>
> Who knows how to fix this?
>
> Cheers,
> Rikkert
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
marco zaro (marco-zaro) wrote : | # |
ciao Rikkert,
I would prefer not to touch the order business now, as I fear to screw up other things with a quick patch.
I agree that it is not optimal, but we may want to upgrade it for the next release with more calm, possibly allowing the user to specify orders at the diagram or amplitude level in a more flexible way.
What is everybody’s idea here?
Cheers,
Marco
> On 5 Oct 2018, at 10:48, Rikkert Frederix <email address hidden> wrote:
>
> Hi,
>
> There is another issue that should be fixed. In particular, when requiring e.g.,
>
> p p > j j QED=0 QCD=4 [QED]
>
> the code also includes QCD corrections (i.e., NLO_1), since at the squared order level, they are allowed. To remove them, one needs to set QCD=2.
>
> In my opinion, the QED=0 and QCD=4 should be used to define which LO contributions should be included, and the ones between the square brackets to determine if one should include QCD and/or QED corrections on top of the Born contributions. Hence,
>
> p p > j j QED=0 QCD=4 [QED]
> and
> p p > j j QED=0 QCD=2 [QED]
>
> should lead to exactly the same results.
>
> Who knows how to fix this?
>
> Cheers,
> Rikkert
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
Rikkert Frederix (frederix) wrote : | # |
Hi,
Marco: I think you are right. Maybe it's better to wait with this for the next version.
Olivier: I agree with you that for 3.0.2 we should write a better default analysis, which knows about the separate orders, and has a few more plots than just the total cross section.
Cheers,
Rikkert
I was actually not thinking at the analysis level but more at the time of the generation of the diagram
to have the famous bullet plot such that it is simple to see which order are include.
Olivier
> On 5 Oct 2018, at 11:22, Rikkert Frederix <email address hidden> wrote:
>
> Hi,
>
> Marco: I think you are right. Maybe it's better to wait with this for the next version.
>
> Olivier: I agree with you that for 3.0.2 we should write a better default analysis, which knows about the separate orders, and has a few more plots than just the total cross section.
>
> Cheers,
> Rikkert
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
davide.pagani.85 (davide-pagani) wrote : | # |
Hi,
What Rik suggested is important, the example he is quoting is actually
an error that I did and and made loose quite some time to get what was
going on.
On the other hand, I think is more important to release as soon as
possible this new version and this error is actually due to a wrong
usage of the syntax.
So if it takes long, I would do it for next-to-next release.
-------
I think it would be very helpful to add the HwU analysis that Rik wrote
for the results in the paper.
Many times I start from that one or I use it to get fast results.
Do you agree?
Ciao
Davide
On 05/10/18 11:00, marco zaro wrote:
> ciao Rikkert,
> I would prefer not to touch the order business now, as I fear to screw up other things with a quick patch.
> I agree that it is not optimal, but we may want to upgrade it for the next release with more calm, possibly allowing the user to specify orders at the diagram or amplitude level in a more flexible way.
> What is everybody’s idea here?
>
> Cheers,
>
> Marco
>
>
>> On 5 Oct 2018, at 10:48, Rikkert Frederix <email address hidden> wrote:
>>
>> Hi,
>>
>> There is another issue that should be fixed. In particular, when requiring e.g.,
>>
>> p p > j j QED=0 QCD=4 [QED]
>>
>> the code also includes QCD corrections (i.e., NLO_1), since at the squared order level, they are allowed. To remove them, one needs to set QCD=2.
>>
>> In my opinion, the QED=0 and QCD=4 should be used to define which LO contributions should be included, and the ones between the square brackets to determine if one should include QCD and/or QED corrections on top of the Born contributions. Hence,
>>
>> p p > j j QED=0 QCD=4 [QED]
>> and
>> p p > j j QED=0 QCD=2 [QED]
>>
>> should lead to exactly the same results.
>>
>> Who knows how to fix this?
>>
>> Cheers,
>> Rikkert
>>
>> --
>> https:/
>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>
Rikkert Frederix (frederix) wrote : | # |
Hi guys,
Any updates?
Best,
Rikkert
- 947. By Pagani <email address hidden> on 2018-10-26
-
General analysis with options of tagging spefic orders explained
davide.pagani.85 (davide-pagani) wrote : | # |
Hi guys,
sorry for the naive question.
What does it mean merging 3.0.1 into FKS_EW_granny?
Isn't the latter an old version?
Ciao
Davide
On 23/10/18 21:51, Rikkert Frederix wrote:
> Hi guys,
>
> Any updates?
>
> Best,
> Rikkert
>
Rikkert Frederix (frederix) wrote : | # |
FKS_EW_granny is the current public version ---there is no 3.0.0 branch. Hence, this request is to replace the current public version with the 3.0.1 branch.
Best,
Rikkert
davide.pagani.85 (davide-pagani) wrote : | # |
Hi Marco,
I see
942. By marco zaro on 2018-10-04
fixes in amcatnlo_
not fully working yet
in which sense is not fully working?
Concerning the Fixed-Order part, the code is ok for me to be replaced.
Cheers
Davide
On 26/10/18 19:57, Rikkert Frederix wrote:
> FKS_EW_granny is the current public version ---there is no 3.0.0 branch. Hence, this request is to replace the current public version with the 3.0.1 branch.
>
> Best,
> Rikkert
marco zaro (marco-zaro) wrote : | # |
Ciao Davide,
this was fixed in rev 943 by rikkert
cheers,
Marco
> On 28 Oct 2018, at 09:15, davide.pagani.85 <email address hidden> wrote:
>
> Hi Marco,
>
> I see
>
> 942. By marco zaro on 2018-10-04
> fixes in amcatnlo_
> not fully working yet
>
> in which sense is not fully working?
>
> Concerning the Fixed-Order part, the code is ok for me to be replaced.
>
>
> Cheers
> Davide
>
> On 26/10/18 19:57, Rikkert Frederix wrote:
>> FKS_EW_granny is the current public version ---there is no 3.0.0 branch. Hence, this request is to replace the current public version with the 3.0.1 branch.
>>
>> Best,
>> Rikkert
>
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
davide.pagani.85 (davide-pagani) wrote : | # |
Then I am ok for the merging.
Let me know how I can help you.
Ciao
Davide
On 29/10/18 09:21, marco zaro wrote:
> Ciao Davide,
> this was fixed in rev 943 by rikkert
> cheers,
>
> Marco
>
>> On 28 Oct 2018, at 09:15, davide.pagani.85 <email address hidden> wrote:
>>
>> Hi Marco,
>>
>> I see
>>
>> 942. By marco zaro on 2018-10-04
>> fixes in amcatnlo_
>> not fully working yet
>>
>> in which sense is not fully working?
>>
>> Concerning the Fixed-Order part, the code is ok for me to be replaced.
>>
>>
>> Cheers
>> Davide
>>
>> On 26/10/18 19:57, Rikkert Frederix wrote:
>>> FKS_EW_granny is the current public version ---there is no 3.0.0 branch. Hence, this request is to replace the current public version with the 3.0.1 branch.
>>>
>>> Best,
>>> Rikkert
>>
>> --
>> https:/
>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>
Hi Marco,
I realised that you removed that file:
tests/acceptanc
Is this expected?
Olivier
Also it seems to have a bunch of (scary) print statement in
test_fks_base.py at line 246
Related to some bypass of tests...
Would be better to clean that right?
Olivier
marco zaro (marco-zaro) wrote : | # |
Hi Olviier,
all IOtests for the NLO output are in
tests/unit_
feel free to move it to the acceptance tests if it takes too much
cheers,
Marco
> On 9 Nov 2018, at 11:31, Olivier Mattelaer <email address hidden> wrote:
>
> Hi Marco,
>
> I realised that you removed that file:
> tests/acceptanc
>
> Is this expected?
>
> Olivier
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
OK good and concerning the test_fks_base.py?
(print statement that some test are bypassed?)
Cheers,
Olivier
PS: I have found workaround for the lhapdf issue and Mojave issue that I pushed in 2.6.4 (and include those here obviously)
> On 9 Nov 2018, at 12:15, marco zaro <email address hidden> wrote:
>
> Hi Olviier,
> all IOtests for the NLO output are in
> tests/unit_
> feel free to move it to the acceptance tests if it takes too much
>
> cheers,
>
> Marco
>
>> On 9 Nov 2018, at 11:31, Olivier Mattelaer <email address hidden> wrote:
>>
>> Hi Marco,
>>
>> I realised that you removed that file:
>> tests/acceptanc
>>
>> Is this expected?
>>
>> Olivier
>> --
>> https:/
>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
- 952. By marco zaro on 2018-11-09
-
commented sprint statament in test_fks_base
marco zaro (marco-zaro) wrote : | # |
these are commented now (r952)
which LHAPDF issue?
cheers,
Marco
> On 9 Nov 2018, at 12:30, Olivier Mattelaer <email address hidden> wrote:
>
> OK good and concerning the test_fks_base.py?
> (print statement that some test are bypassed?)
>
>
> Cheers,
>
> Olivier
>
>
> PS: I have found workaround for the lhapdf issue and Mojave issue that I pushed in 2.6.4 (and include those here obviously)
>
>> On 9 Nov 2018, at 12:15, marco zaro <email address hidden> wrote:
>>
>> Hi Olviier,
>> all IOtests for the NLO output are in
>> tests/unit_
>> feel free to move it to the acceptance tests if it takes too much
>>
>> cheers,
>>
>> Marco
>>
>>> On 9 Nov 2018, at 11:31, Olivier Mattelaer <email address hidden> wrote:
>>>
>>> Hi Marco,
>>>
>>> I realised that you removed that file:
>>> tests/acceptanc
>>>
>>> Is this expected?
>>>
>>> Olivier
>>> --
>>> https:/
>>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>>
>>
>> --
>> https:/
>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
They were two lhapdf issues:
- it was not compiling on Mojave (the same problem will likely re-appear in a year with NO easy solution this time). The problem is that the yaml parser shipped with lhapdf seems to have issue on mac.
- the download of (any) PDF was crashing. This was due to the change of hepforge.
We were using the ofiicial command (lhapdf install) but that one does not work anymore and after discussing with them they do not seem interested to fix it.
I'm still trying to use that command, but if it fails then I guess the path of the set and do a "simple" wget on that one.
Cheers,
Olivier
PS: The status on the tests are now:
- one unnitest failing
- around 10 acceptance test failing (so far, this is still running)
> On 9 Nov 2018, at 12:42, marco zaro <email address hidden> wrote:
>
> these are commented now (r952)
> which LHAPDF issue?
> cheers,
>
> Marco
>
>> On 9 Nov 2018, at 12:30, Olivier Mattelaer <email address hidden> wrote:
>>
>> OK good and concerning the test_fks_base.py?
>> (print statement that some test are bypassed?)
>>
>>
>> Cheers,
>>
>> Olivier
>>
>>
>> PS: I have found workaround for the lhapdf issue and Mojave issue that I pushed in 2.6.4 (and include those here obviously)
>>
>>> On 9 Nov 2018, at 12:15, marco zaro <email address hidden> wrote:
>>>
>>> Hi Olviier,
>>> all IOtests for the NLO output are in
>>> tests/unit_
>>> feel free to move it to the acceptance tests if it takes too much
>>>
>>> cheers,
>>>
>>> Marco
>>>
>>>> On 9 Nov 2018, at 11:31, Olivier Mattelaer <email address hidden> wrote:
>>>>
>>>> Hi Marco,
>>>>
>>>> I realised that you removed that file:
>>>> tests/acceptanc
>>>>
>>>> Is this expected?
>>>>
>>>> Olivier
>>>> --
>>>> https:/
>>>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>>>
>>>
>>> --
>>> https:/
>>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>>
>>
>> --
>> https:/
>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
Hi Marco,
The following test is also not passing (going trough ok with 2.6.4):
test_madspin_LOonly
Even though this is a madspin designed tests, it actually crash within the LOonly module.
If you just do
geneate p p > w+ [LOonly]
It will lead to a crash.
I have fixed all the other tests (but a couple of IOtests and i still have to run the short paralel test).
Since this is a beta version, we can also decide to not fix this in this version.
marco zaro (marco-zaro) wrote : | # |
Hi Olivier,
it is strange, it seems that the LOonly mode is broken (it always returns zero)
I will have a look on monday, and let you know.
cheers,
Marco
> On 9 Nov 2018, at 21:10, Olivier Mattelaer <email address hidden> wrote:
>
> Hi Marco,
>
> The following test is also not passing (going trough ok with 2.6.4):
> test_madspin_LOonly
>
> Even though this is a madspin designed tests, it actually crash within the LOonly module.
> If you just do
> geneate p p > w+ [LOonly]
> It will lead to a crash.
>
> I have fixed all the other tests (but a couple of IOtests and i still have to run the short paralel test).
>
> Since this is a beta version, we can also decide to not fix this in this version.
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
marco zaro (marco-zaro) wrote : | # |
Hi Again,
actually, doing p p > e+ ve [LOonly] works ok, at LO, NLO, aMC@LO, aMC@NLO
So it may be something relate to the phase-space of 2->1?
the reason why p p > w+ [LOonly] returns zero is because the function passcuts always returns False, exiting here
c Make sure have reasonable 4-momenta
if (p(0,1) .le. 0d0) then
return
endif
with P(0,1) = -99
So clearly something goes wrong in the phase space generation. Rikkert, anything that could be related to the granny stuff?
also note that
p p > w+ [QED] has one test failing (soft test for photon emission off the W), where a lot of NaN’s appear
p p > e+ ve [QCD] seems ok though
Cheers,
Marco
> On 9 Nov 2018, at 21:42, marco zaro <email address hidden> wrote:
>
> Hi Olivier,
> it is strange, it seems that the LOonly mode is broken (it always returns zero)
> I will have a look on monday, and let you know.
>
> cheers,
>
> Marco
>
>> On 9 Nov 2018, at 21:10, Olivier Mattelaer <email address hidden> wrote:
>>
>> Hi Marco,
>>
>> The following test is also not passing (going trough ok with 2.6.4):
>> test_madspin_LOonly
>>
>> Even though this is a madspin designed tests, it actually crash within the LOonly module.
>> If you just do
>> geneate p p > w+ [LOonly]
>> It will lead to a crash.
>>
>> I have fixed all the other tests (but a couple of IOtests and i still have to run the short paralel test).
>>
>> Since this is a beta version, we can also decide to not fix this in this version.
>> --
>> https:/
>> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
Thanks,
Update on my side:
1) the IOTest suite are bugged (not critical for a release) I have ask Valentin to look at it
2) the (fast) parrelel test leads to their own discovery of bug:
2.1) e+ e- > t t~ [real=QCD]
crashes with
FKSProcessError: This process does not have any correction up to NLO in QED,QCD
[ test: test_short_
same for e+ e- > p p p [real=QCD] in test: test_short_
2.2) A division by zero occurs in the jet veto of rik [test_short_
p p > e+ ve [QCD]
generate_events NLO
2.3) The value of some squared order amplitude does not match anymore [test_short_sqso ]
Will look at this one (maybe with Valentin).
Cheers,
Olivier
On 9 Nov 2018, at 22:00, marco zaro <<email address hidden>
Hi Again,
actually, doing p p > e+ ve [LOonly] works ok, at LO, NLO, aMC@LO, aMC@NLO
So it may be something relate to the phase-space of 2->1?
the reason why p p > w+ [LOonly] returns zero is because the function passcuts always returns False, exiting here
c Make sure have reasonable 4-momenta
if (p(0,1) .le. 0d0) then
return
endif
with P(0,1) = -99
So clearly something goes wrong in the phase space generation. Rikkert, anything that could be related to the granny stuff?
also note that
p p > w+ [QED] has one test failing (soft test for photon emission off the W), where a lot of NaN’s appear
p p > e+ ve [QCD] seems ok though
Cheers,
Marco
On 9 Nov 2018, at 21:42, marco zaro <<email address hidden>
Hi Olivier,
it is strange, it seems that the LOonly mode is broken (it always returns zero)
I will have a look on monday, and let you know.
cheers,
Marco
On 9 Nov 2018, at 21:10, Olivier Mattelaer <<email address hidden>
Hi Marco,
The following test is also not passing (going trough ok with 2.6.4):
test_madspin_LOonly
Even though this is a madspin designed tests, it actually crash within the LOonly module.
If you just do
geneate p p > w+ [LOonly]
It will lead to a crash.
I have fixed all the other tests (but a couple of IOtests and i still have to run the short paralel test).
Since this is a beta version, we can also decide to not fix this in this version.
--
https:/
You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
--
https:/
You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
--
https:/
You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
marco zaro (marco-zaro) wrote : | # |
Ciao Olivier,
thanks for looking at this.
Let me answer inline
On Fri, Nov 9, 2018 at 10:30 PM Olivier Mattelaer <
<email address hidden>> wrote:
> Thanks,
>
> Update on my side:
> 1) the IOTest suite are bugged (not critical for a release) I have ask
> Valentin to look at it
> 2) the (fast) parrelel test leads to their own discovery of bug:
>
> 2.1) e+ e- > t t~ [real=QCD]
> crashes with
> FKSProcessError: This process does not have any correction up to NLO in
> QED,QCD
> [ test: test_short_
> same for e+ e- > p p p [real=QCD] in test:
> test_short_
>
> for ee collisions, one has to tell the code
set include_
screen).
The py6isr test should be skipped, as the has_isr flag is not updated
anymore in this branch (there were some print statement about this you
asked me to remove)
If you want to include it, set the
'include_
> 2.2) A division by zero occurs in the jet veto of rik
> [test_short_
>
> p p > e+ ve [QCD]
> generate_events NLO
> set ickkw -1
> set ptj 10
>
>
> the jet_veto is likely to be broken in this branch. There are some message
errors in the logs of the fortran executables about this.
> 2.3) The value of some squared order amplitude does not match anymore
> [test_short_sqso ]
> Will look at this one (maybe with Valentin).
>
I will check this right away
Thanks again!
cheers,
Marco
>
> Cheers,
>
> Olivier
>
> On 9 Nov 2018, at 22:00, marco zaro <<email address hidden><mailto:
> <email address hidden>>> wrote:
>
> Hi Again,
> actually, doing p p > e+ ve [LOonly] works ok, at LO, NLO, aMC@LO, aMC@NLO
> So it may be something relate to the phase-space of 2->1?
> the reason why p p > w+ [LOonly] returns zero is because the function
> passcuts always returns False, exiting here
> c Make sure have reasonable 4-momenta
> if (p(0,1) .le. 0d0) then
> passcuts=.false.
> return
> endif
>
> with P(0,1) = -99
>
> So clearly something goes wrong in the phase space generation. Rikkert,
> anything that could be related to the granny stuff?
>
> also note that
> p p > w+ [QED] has one test failing (soft test for photon emission off the
> W), where a lot of NaN’s appear
> p p > e+ ve [QCD] seems ok though
>
> Cheers,
>
> Marco
>
>
>
> On 9 Nov 2018, at 21:42, marco zaro <<email address hidden><mailto:
> <email address hidden>>> wrote:
>
> Hi Olivier,
> it is strange, it seems that the LOonly mode is broken (it always returns
> zero)
> I will have a look on monday, and let you know.
>
> cheers,
>
> Marco
>
> On 9 Nov 2018, at 21:10, Olivier Mattelaer <<email address hidden>
> <mailto:<email address hidden>>> wrote:
>
> Hi Marco,
>
> The following test is also not passing (going trough ok with 2.6.4):
> test_madspin_LOonly
>
> Even though this is a madspin designed tests, it actually crash within the
> LOonly module.
> If you just do
> geneate p p > w+ [LOonly]
> It will lead to a crash.
>
> I have fixed all the other tests (but a couple of IOtests and i still have
> to run the short ...
Rikkert Frederix (frederix) wrote : | # |
Hi Olivier, Marco,
I looked into the following two issues:
1. The error in the phase-space for the process 'p p > w+ [LOonly=QCD]'.
This is related to the fact that in the 3.0.1 branch the final state W boson is the fks_j particle, while in the 2.6.4 branch it's one of the initial state quarks. However, the phase-space for 2->1 processes with j-fks the massive final state particle does not work. There are divisions by zero everywhere... I'm not sure if there is an easy fix here, apart from telling the code to use an initial state particle as fake j_fks. This will work for the LOonly 2->1 processes. On the other hand, we need to fix this phase-space at some point, since the same is used (and needed!) for the process 'p p > w+ [QED]'.
2. The error for the VETO X-SEC (ickkw=-1).
The whole split-amplitude business has not been implemented for the veto-xsec stuff. I suggest that we do not try to rush this through now, but leave the 3.0.1 code as beta and fix this at a later stage.
Cheers,
Rik
- 953. By marco zaro on 2018-11-12
-
fix for 2->1 processes
- 954. By marco zaro on 2018-11-12
-
unit test for previous push and fix for p p > w+ [LOonly=QCD]
- 955. By marco zaro on 2018-11-16
-
reverted change from revision 613 (related to split orders and WEIGHTED)
added a debug message
marco zaro (marco-zaro) wrote : | # |
Hi all,
I have just noticed this (fks_singular, line 3818)
call Qterms_
it should be instead
call Qterms_
(switch ch_i <--> ch_j), shouldn't it?
It may be that in the end there is no effect, since, for the relevant cases when either ch_i or ch_j ==0 and the other is not one has always Q=0
c g/a ->qqbar splitting
Qterms(1) = 4d0 * TR * z*(1d0-z)**2
Qterms(2) = 4d0 * dble(abs(col1)) * ch1**2 * z*(1d0-z)**2
elseif ((abs(col1).eq.3 .and. col2.eq.8) .or.
& (dabs(ch1).gt.0d0 .and. dabs(ch2).eq.0d0)) then
c q->q g/a splitting
Qterms(1) = 0d0
Qterms(2) = 0d0
Let me know
Cheers,
Marco
marco zaro (marco-zaro) wrote : | # |
sorry, the piece of code i wanted to post is
elseif ((abs(col1).eq.3 .and. col2.eq.8) .or.
& (dabs(ch1).gt.0d0 .and. dabs(ch2).eq.0d0)) then
c q->q g/a splitting
Qterms(1) = 0d0
Qterms(2) = 0d0
elseif ((col1.eq.8 .and. abs(col2).eq.3) .or.
& (dabs(ch1).eq.0d0 .and. dabs(ch2).gt.0d0)) then
c q->g/a q splitting
Qterms(1) = 0d0
Qterms(2) = 0d0
else
> On 21 Nov 2018, at 16:16, marco zaro <email address hidden> wrote:
>
> Review: Needs Fixing
>
> Hi all,
> I have just noticed this (fks_singular, line 3818)
> call Qterms_
> it should be instead
> call Qterms_
> (switch ch_i <--> ch_j), shouldn't it?
>
> It may be that in the end there is no effect, since, for the relevant cases when either ch_i or ch_j ==0 and the other is not one has always Q=0
>
>
> c g/a ->qqbar splitting
> Qterms(1) = 4d0 * TR * z*(1d0-z)**2
> Qterms(2) = 4d0 * dble(abs(col1)) * ch1**2 * z*(1d0-z)**2
>
> elseif ((abs(col1).eq.3 .and. col2.eq.8) .or.
> & (dabs(ch1).gt.0d0 .and. dabs(ch2).eq.0d0)) then
> c q->q g/a splitting
> Qterms(1) = 0d0
> Qterms(2) = 0d0
>
> Let me know
>
> Cheers,
>
> Marco
>
> --
> https:/
> You are reviewing the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
Rikkert Frederix (frederix) wrote : | # |
Hi Marco,
I agree that the current way is wrong, but has no effect on the running of the code whatsoever. Even though, we should replace ch_i and ch_j in the call to the Qterms.
Note that, if there was 'true' bug here, the soft and/or collinear checks and the beginning of any run would not have passed.
Cheers,
Rik
- 956. By marco zaro on 2018-11-21
-
fix in a call to
Qterms_reduced_ timelike
luckiliy harmless
marco zaro (marco-zaro) wrote : | # |
Hi Rik,
thanks for the cross-check
I have pushed the fix into 3.0.1, rev 956
cheers,
Marco
> On 21 Nov 2018, at 16:24, Rikkert Frederix <email address hidden> wrote:
>
> Hi Marco,
>
> I agree that the current way is wrong, but has no effect on the running of the code whatsoever. Even though, we should replace ch_i and ch_j in the call to the Qterms.
> Note that, if there was 'true' bug here, the soft and/or collinear checks and the beginning of any run would not have passed.
>
> Cheers,
> Rik
>
> --
> https:/
> You are reviewing the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
Hi,
I would like to put this quite high priority for this week (i.e. for me Wednesday-friday).
I have rerun the tests and found that some tests are crashing when run via the full script but are working if run alone. So I have run (the very slow script to determine which of the tests had such side effects and the culprint is:
tests.unit_
which has a side effect that lead to the following crash:
FAIL: test_generate_
check that the generate command works as expected.
-------
Traceback (most recent call last):
File "/Users/
self.
AssertionError: 0 != -1
Might be interesting that you take a look. But I think that we should release this version this week independently.
Any objection? comment?
Olivier
- 957. By marco zaro on 2018-12-17
-
tests/unit_
tests/fks/ test_extra_ ew.py has been modified to avoid
side effects - 958. By marco zaro on 2018-12-17
-
fix in amcatnlo_interface to prevent unphysical coupling orders
marco zaro (marco-zaro) wrote : | # |
Hello Olivier,
I agree we should release 3.0.1 before the Christmas break.
concerning the side effect, i reproduced it, and it goes away if I do the following change
class TestAMCatNLOEW(
""" a suite of extra tests for the ew stuff """
- interface = mgcmd.MasterCmd()
+ def setUp(self):
+ self.interface = mgcmd.MasterCmd()
I have pushed the fix into rev 957.
The other bogus behavious was related to the order settings in t-channel single top, which we discussed in a separate email.
I have added an error message that should warn the user to specify the coupling orders in that case (rev 958)
Cheers,
Marco
> On 17 Dec 2018, at 09:23, Olivier Mattelaer <email address hidden> wrote:
>
> Hi,
>
> I would like to put this quite high priority for this week (i.e. for me Wednesday-friday).
>
> I have rerun the tests and found that some tests are crashing when run via the full script but are working if run alone. So I have run (the very slow script to determine which of the tests had such side effects and the culprint is:
> tests.unit_
> which has a side effect that lead to the following crash:
>
> FAIL: test_generate_
> check that the generate command works as expected.
> -------
> Traceback (most recent call last):
> File "/Users/
> self.assertEqua
> AssertionError: 0 != -1
>
> Might be interesting that you take a look. But I think that we should release this version this week independently.
>
> Any objection? comment?
>
> Olivier
>
>
> --
> https:/
> You are reviewing the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
Rikkert Frederix (frederix) wrote : | # |
Hi Olivier,
Thanks! We should really release it before the break. It will remain a beta version and exist along side the main branch, right? I think that would still be better and removing the beta tag.
best,
Rikkert
Hi,
> Thanks! We should really release it before the break. It will remain a beta version and exist along side the main branch, right?
Correct.
> I think that would still be better and removing the beta tag.
It would not make sense to remove the "beta" tag and keep two official version.
And I do not think that we are ready to keep only this version.
Cheers,
Olivier
> On 18 Dec 2018, at 10:33, Rikkert Frederix <email address hidden> wrote:
>
> Hi Olivier,
>
> Thanks! We should really release it before the break. It will remain a beta version and exist along side the main branch, right? I think that would still be better and removing the beta tag.
>
> best,
> Rikkert
>
> --
> https:/
> You are requested to review the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
Rikkert Frederix (frederix) wrote : | # |
Sorry, I forgot a "NOT" in my suggestion :-D
Hence I agree with not removing the beta tag.
Cheers,
Rik
- 959. By olivier-mattelaer on 2018-12-19
-
fixing some additional issue with some test --in particular a real bug for the reweighting--
I have re-run all the tests today (and fix a couple of small stuffs). Except a couple that we have decide to ignore above they all go trough now. So I will make the release tomorrow.
Cheers,
Olivier
Rikkert Frederix (frederix) wrote : | # |
Thanks a lot, Olivier.
Cheers,
Rik
marco zaro (marco-zaro) wrote : | # |
Thanks a lot Olivier!
great that we finally made it!
cheers,
Marco
> On 19 Dec 2018, at 23:42, Rikkert Frederix <email address hidden> wrote:
>
> Thanks a lot, Olivier.
>
> Cheers,
> Rik
>
> --
> https:/
> You are reviewing the proposed merge of lp:~maddevelopers/mg5amcnlo/3.0.1 into lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
- 960. By olivier-mattelaer on 2018-12-20
-
UpdateNotes/Version update
Done!
davide.pagani.85 (davide-pagani) wrote : | # |
Thanks a lot!
Cheers
Davide
On 20/12/18 09:47, Olivier Mattelaer wrote:
> Done!
By the way,
Do you know if we can close the following bug report:
https:/
If not we should at least comment on it (this is one was forbidding ATLAS to use the code)
Cheers,
Olivier
Stefano Frixione (stefano-frixione) wrote : | # |
I have no idea.
Perhaps one should double check with the ATLAS people;
I've never understood how genser works, and their relationship
with experiments.
Cheers, Stefano.
On Fri, 21 Dec 2018, Olivier Mattelaer wrote:
> By the way,
>
> Do you know if we can close the following bug report:
> https:/
>
> If not we should at least comment on it (this is one was forbidding
> ATLAS to use the code)
>
>
> Cheers,
>
> Olivier
> --
> https:/
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/FKS_EW_granny.
>
have we enabled the NLO+PS for QCD only?