MadSTR parameters not properly identified

[Zachary Marshall]

Hi Olivier, all,

I think I've tracked down something funny in the handling of parameters from plugins. There are two issues I've run into (one more serious than the other). I'm putting the second at the bottom clearly marked off — it seems like an out of date patch (fine).

As I mentioned, the first is a little more serious, and I'm struggling with how to fix it.

When we run with a plugin like:

MG5_aMC_v3_5_4/bin/mg5_aMC --mode=MadSTR << EOF
import model loop_sm-no_b_mass
generate p p > t w- [QCD]
add process p p > t~ w+ [QCD]
output -f
EOF

some lines get added to banner.py (I have not attempted to figure out where exactly this is happening, but it seems to be done correctly); in the case of MadSTR those lines are:

5352,5354d5348
< self.add_param('istr', 2)
< self.add_param('str_include_pdf', True)
< self.add_param('str_include_flux', True)

When we run event generation with:

bin/generate_events

it does:

sys.path.append(pjoin(root_path,'bin','internal'))
import amcatnlo_run_interface as run

which then executes this:

try:
    import madgraph
except ImportError:
...
    import internal.banner as banner_mod
...
else:
    # import from madgraph directory
...
    import madgraph.various.banner as banner_mod
...

Now, one thing we do normally — I don't know whether it's required, and guidance is of course welcome. We include our MadGraph5_aMC@NLO installation in our standard PYTHONPATH. You tell me if that's something we should stop doing in the future (I hope with minimal consequences if that's the recommendation...).

The _appending_ of the executing path means that the PYTHONPATH is the first place that MG looks for modules, and it only falls back to the internal copies. However, because in this case (for MadSTR) the banner.py is modified when it is copied locally, the "central" (original) banner.py doesn't have the relevant parameters defined. This then ends up in an ugly looking crash from parameters being mis-defined in fortran (the error looks very similar to https://bugs.launchpad.net/mg5amcnlo/+bug/2001583 ).

So what do we do here? Options include:
- stop including MG5_aMC in our standard PYTHONPATH?
- pick up the internal modules by default
- pick up the internal modules by default only in the case a PLUGIN is used
- pick up the right banner specifically in the case a PLUGIN is used
- add parameters to the banner in another way that doesn't run into this PYTHONPATH problem

I'm sure there are other ways around this, but I'm out of gas now having scratched my head over this thing for too long :)

Any help is very welcome!

Now, the other (easy) report:

################# Second report ######################

wget https://launchpad.net/mg5amcnlo/3.0/3.5.x/+download/MG5_aMC_v3.5.4.tar.gz
tar -xzf MG5_aMC_v3.5.4.tar.gz
git clone <email address hidden>:mg5amcnlo/MadSTR.git
mv MadSTR/MadSTR/ MG5_aMC_v3_5_4/PLUGIN
MG5_aMC_v3_5_4/bin/mg5_aMC --mode=MadSTR << EOF
import model loop_sm-no_b_mass
generate p p > t w- [QCD]
add process p p > t~ w+ [QCD]
output -f
EOF

In the output -f step we get the error:

patching file SubProcesses/fks_singular.f
Hunk #1 FAILED at 3011 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file SubProcesses/fks_singular.f.rej

for info, here is the rejected patch:

--- SubProcesses/fks_singular.f 2018-09-07 11:12:25.000000000 +0200
+++ /dev/null
@@ -3011,22 +3011,6 @@
          wgt=wgt*xi_i_fks**2*(1d0-y_ij_fks)
       endif

- if(wgt.lt.0.d0)then
- icount=icount+1
- if (icount.le.10) then
- write(*,*) 'Warning, numerical problem found in sreal. '/
- $ /'Setting weight to zero',wgt,xi_i_fks,y_ij_fks
- do i=1,nexternal
- write(*,*) 'particle ',i,', ',(pp(j,i),j=0,3)
- enddo
- if (icount.eq.25) then
- write (*,*) 'ERROR 25 problems found... '/
- $ /'stopping the code'
- stop
- endif
- endif
- wgt=0d0
- endif

       return
       end

Cheers,
Zach

[Olivier Mattelaer (olivier-mattelaer)]

Hi,

Concerning the first error (first thanks for the super detailled and cleaned report),

From 3.6.0 (in principle), the support of plugin that need to tune the launch command and define additional
input in the run_card would have a dedicated API. Soon I'm going to visit Marco, and I can try to push MadSTR to use this new API as well. This should make MadSTR compatible with the launch command from the MG5 executable and therefore could be run without loading any of the duplicated file between bin/internal and madgraph.

While the above method is likely to allow to put madgraph in PYTHONPATH but it is not clear if that it will be enough. This is not first time that we receive bug report from people that put madgraph in their PYTHONPATH (to be exact I remember one case from the docker installation of madgraph --maybe correlated to readonly issue--). And yes this is not something that we recommend (or test). Now, I'm fine to (try) to fix the issue when we face them.

For the second issue, I will assign this directly to Marco.

Olivier

[marco zaro (marco-zaro)]

Hi Olivier and Zach,
the second issue is actually kind of trivial. That patch was meant for v2 where, doing only NLO QCD corrections, real emissions were positive definite. This is no longer true in v3, hence that part is not there anymore.
I have just fixed it here
https://github.com/mg5amcnlo/MadSTR/commit/66430ac6f93a24d1d7909673c6971235457556d6
Note that if the error is just printed on screen at the output stage, but MG5_aMC does not crash (ie the output goes on), the produced code is good to be run.

Best,

Marco

[Zachary Marshall (zach-marshall)]

Thank you both! This answers my questions clearly. I'll look forward to seeing what happens with 3.6.0, and in the meantime we have a path (ha) forward.

Best,
Zach