What hardware and software are required to run EUTelescope?
Will <feature> be included in a future release?
How do I subscribe to the mailing lists?
If you do not have a CERN account, please notify the site admins via the contact form and they will add your external address.
How to update to the newest release or to the central development branch?
EUTelescope appears to run very slow. What can be done to improve the run time?
- make sure all compiler optimizations are active: in the file CMakeLists.txt in the EUTelescope root, set the variable CMAKE_BUILD_TYPE is to Release and recompile EUTelescope;
- if running very verbose producers, set the verbosity level in the steering template/the configuration file to e.g. MESSAGE5 or above;
- if running e.g. the converter producer over many runs, consider removing EUTelCorrelator producer if enabled and not needed for offset correction/prealignment
Why are my runs processed in sometimes out of order when I pass a list or a range of runs to jobsub?
This is in fact not a bug per-se but a result of the data type used for storing the run ranges inside jobsub: for convienience, the Python built-in collection type set is being used which is by design unordered.
If you require certains runs to be processed before others, the easiest is to work around this issue by specifically running jobsub with those runs before processing the remaining runs. If you consider this a significant issue, please file a bug report.
Commits fail with the error "svn: E175013: Access to '/public/eutelescope/!svn/[...]' forbidden". What's the problem?
svn switch --relocate https://svnsrv.desy.de/public/eutelescope/Eutelescope/trunk \ https://svnsrv.desy.de/desy/eutelescope/Eutelescope/trunk
Why are debug messages suppressed even when the verbosity level is set to DEBUG?
How can I enable debugging symbols?
To optimize the run-time, releases are built by default without any debug messages present in the executable. You can change this behavior by setting the variable CMAKE_BUILD_TYPE e.g. to RelWithDebInfo in the file CMakeLists.txt in the EUTelescope root and recompiling EUTelescope. If you set this variable to Debug, all gcc-optimizations are disabled - this is especially useful if you want to use a debugger such as gdb.
How can I fix a corrupted cmake build directory?
In rare circumstances, the cmake cache can be corrupted; in that case, it might be a good idea to set up a clean build directory. For this purpose, please do not source the build_env.sh script in the EUTelescope directory, but start with a fresh shell:
cd /path/to/EUTelescope mv build build.old mkdir build source /path/to/ilcsoft/ILCSoft.cmake.env.sh cd build cmake -C ../../../ILCSoft.cmake ..