Shared libraries + Bridge + Cleaner Makefiles

[valassi]

This is a WIP PR to follow up on

• shared libraries (replacing PR create shared libraries #361 ?)
• cleaning up Makefiles a bit (Cleanup of Makefiles #362)
• complete Bridge (Keep Bridge state across several calls? #329, Clarify roles of Parameters_sm, CPPProcess and MatrixElementKernels #356 etc)

For the momente there is only one commit, ficing the conflicts in #361.

[valassi]

The dependency of check.exe and runTest.exe on the shared libraries is not ideal now.

First problem, the executables are now not statically built so one needs an LD_LIBRARY_PATH (ok maybe that's what we want...)

[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt/SubProcesses/P1_Sigma_sm_gg_ttx> ./check.exe 
./check.exe: error while loading shared libraries: libmodel_sm.so: cannot open shared object file: No such file or directory
[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt/SubProcesses/P1_Sigma_sm_gg_ttx> ./runTest.exe 
./runTest.exe: error while loading shared libraries: libmodel_sm.so: cannot open shared object file: No such file or directory

Second problem, there seem to be some hardcoded paths

[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt/SubProcesses/P1_Sigma_sm_gg_ttx> ldd ../../lib/libmg5amc_cu.so 
        linux-vdso.so.1 =>  (0x00007ffcf6796000)
        ../../lib/libmodel_sm.so (0x00007f6e95b5e000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f6e95817000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6e955fb000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f6e953f7000)
        libstdc++.so.6 => /cvmfs/sft.cern.ch/lcg/releases/gcc/10.2.0-c44b3/x86_64-centos7/lib64/libstdc++.so.6 (0x00007f6e95222000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6e94f20000)
        libgcc_s.so.1 => /cvmfs/sft.cern.ch/lcg/releases/gcc/10.2.0-c44b3/x86_64-centos7/lib64/libgcc_s.so.1 (0x00007f6e95b23000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6e94b52000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6e95a1f000)
[avalassi@itscrd70 gcc10.2/cvmfs] /data/avalassi/GPU2020/madgraph4gpuX/epochX/cudacpp/gg_tt/SubProcesses/P1_Sigma_sm_gg_ttx> ldd ./check.exe 
        linux-vdso.so.1 =>  (0x00007ffcc37b7000)
        ../../lib/libmg5amc_cxx.so (0x00007f7fd9dcb000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f7fd99bf000)
        libmodel_sm.so => not found
        libcurand.so.10 => /usr/local/cuda-10.2/lib64/libcurand.so.10 (0x00007f7fd591c000)
        libstdc++.so.6 => /cvmfs/sft.cern.ch/lcg/releases/gcc/10.2.0-c44b3/x86_64-centos7/lib64/libstdc++.so.6 (0x00007f7fd5747000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f7fd5445000)
        libgcc_s.so.1 => /cvmfs/sft.cern.ch/lcg/releases/gcc/10.2.0-c44b3/x86_64-centos7/lib64/libgcc_s.so.1 (0x00007f7fd9d90000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7fd5229000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f7fd4e5b000)
        ../../lib/libmodel_sm.so (0x00007f7fd9d7d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7fd9bc3000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f7fd4c53000)

I would be tempted to have the libmodel embedded inside the libcxx/libcuda. This actually means replicating some symbos, but for the moment I guess we WITHER use one OR the other? Eventually if we have all of them together we should have them inside a single library?... Something to be clarified related to heterogeneous apps #318

[roiser]

Hi @valassi concerning the having one shared library or many, I kept them on purpose separately as the duplication of the symbols didn't make too much sense to me. Best

[valassi]

Ok all tests are finally succeeding in the CI, after fixing a few CI related issues.

Amongst the latest changes in this PR in the last few days:

• I implemented a test (also run through the CI make check) that computes an ME average for a fixed small number of events both through the C++ standalone executable (check or gcheck) and through the Fortran+Bridge standalone executable (fcheck or fgcheck) and compares the outputs using some basic python. The results have to agree within a given tolerance.
• In this test, the Fortran always uses double precision, but I also implemented the option of having the MEs in CUDA/C++ in single precision (see Use single precision or even half precision #5 and Single precision average ME is not the same for CUDA and C++ in single-precision (ggttgg and eemumu) #212)
• The tolerance had to be adapted, because especially with float precision the results of the two chains can differen quite a lot. I think it is now a 2E-4, which is already huge. This is enough for float ggttgg tests, but would fail float ggttggg tests where the difference is even larger. The root causes of this are probably a combination of the fact that momenta are converted float to double back to float in the Fortran version, and maybe also of the more complex (and hopefully more precise) way in which the c+ executable computes ME averages uing EventStatistics.h

I am just running a few more tests to commit some logs, but otherwise this is ready to go

[valassi]

Hi @roiser @oliviermattelaer this is now complete, I am about to merge it - sorry for the delay

[valassi]

All checks have passed. Self merging.