Adds fetching of particle addresses API to OpenCL implementation

[martinschwinzerl]

Adds API to the track job specialization for OpenCL to fetch the start address of the fields in the Particles instance and allows to directly interact with the data. Cf. examples/python/opencl_cpu_particle_addr.py for an example of using this API

Note: the example is currently only expected to work with CPU devices. There is currently no implementation available to setup pyopencl from the host side to share the particle data via this addresses. libraries implementing the data sharing on the device side in their own kernels would work, though.

[martinschwinzerl]

Introduces changes to the OpenCL controller and track job implementations that no longer hardcode the location of the OpenCL kernels to the CMAKE_SOURCE_DIR/sixtracklib/opencl/kernels directory . This addresses #69 (and should help towards fixing the issues documented in #126)

[martinschwinzerl]

merged PR #130 with PR #132 to allow integration once #132 lands. Passes all tests on my workstation. @aoeftiger : could you please, in your own time, verify whether this version would work for you both with respect to the features of #132 as also with the OpenCL CPU address sharing from #130? Thanks you!

[aoeftiger]

When compiling with CUDA support on, I get the following error upon import:

    import sixtracklib
  File ".../sixtracklib/python/sixtracklib/__init__.py", line 12, in <module>
    from .beam_elements import *
  File ".../sixtracklib/python/sixtracklib/beam_elements.py", line 15, in <module>
    from .stcommon import (
  File ".../sixtracklib/python/sixtracklib/stcommon.py", line 8, in <module>
    sixtracklib = ct.CDLL(stconf.SHARED_LIB)
  File ".../anaconda3/envs/stl_pr130/lib/python3.7/ctypes/__init__.py", line 356, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: .../sixtracklib/python/sixtracklib/libsixtrack.so: undefined symbol: __cudaRegisterLinkedBinary_64_tmpxft_00023082_00000000_6_be_monitors_assign_out_buffer_cpp1_ii_54dd6e05

[aoeftiger]

Besides the CUDA import thing, everything works for me -- both the full SIS100 setup with 'Bunched' and 'Interpolated' mode of space charge as well as the new feature of sharing memory addresses in an openCL trackjob and writing to them from the python level via numpy exposed buffers (just as in your new example mentioned above, just within the SIS100 setup)!

[martinschwinzerl]

Thanks for testing, I'm trying to reproduce the problem with the CUDA API

[martinschwinzerl]

Fixed two minor issues that should however not be the cause for your problem. On my machine (CUDA 10.1), the symbol in question is indeed exported via libsixtrack.so:

nm  sixtracklib/libsixtrack.so | grep "be_monitors_assign_out_buffer"
000000000031546c T __cudaRegisterLinkedBinary_64_tmpxft_00059fce_00000000_6_be_monitors_assign_out_buffer_cpp1_ii_54dd6e05

Stupid question: have you re-run cmake .. before attempting to install? Could you also please verify if the symbol is present in the library located in build/sixtracklib before attempting to perform the python installation? Sorry for the hassles & thanks again for reporting the issue!

[aoeftiger]

Indeed, issue #109 is the explanation -- I had a cmake v3.16.3 due to the host OS ubuntu 20.04! When explicitly installing cmake v3.14.4 via pip, the compilation and import in python works flawlessly. Thanks and sorry for the hassle from my side!

[martinschwinzerl]

@aoeftiger Could you please verify whether the updated PR (especially after commit 1ce557c71d4d80058b84e1e63aa3212454b0e181) would solve the issue with CMake newer than 3.14 for you as well?

[aoeftiger]

Very nice! 1ce557c does solve the issue, I can compile and import in python including the CUDA support without a problem using the system cmake v3.16.3!! Thanks @martinschwinzerl !!

[martinschwinzerl]

Merged into PR #132 ->close