Frequently Asked Questions

 

  1. General
  2. Installation and Updating
  3. Running
  4. Development and Debugging

 

General

 

What hardware and software are required to run EUTelescope?

EUTelescope has been found to run under Scientific Linux 5.8 and on Ubuntu 12.04. Other platforms may work, but are unsupported. 32bit and 64bit systems are both supported. A minimal installation will take up about 1.5 GB disk space, a full installation can require up to 4GB space. Your system should have at least 2GB of memory. Check the installation documentation for more information.

 

Will <feature> be included in a future release?

Maybe. You can add features on your own by contributing to the code, thus helping everyone! Have a look at our developer notes for more information. Possibly the feature is already included but not working, in which case you might want to consult the bug tracker.

 

How do I subscribe to the mailing lists?

See the detailed page. If you have a CERN account, you can subscribe to the lists via the e-group system at e-groups.cern.ch. Search for eutelescope-users for the user mailing list, and/or eutelescope-developers for the mailing list with developer information.
If you do not have a CERN account, please notify the site admins via the contact form and they will add your external address.

 

Installation and Updating

 

How to update to the newest release or to the central development branch?

If you need to update an existing installation, please follow the instructions on our update pages.

 

Running

 

EUTelescope appears to run very slow. What can be done to improve the run time?

The data analysis performed by EUTelescope is very CPU and IO intensive, so certain producers will run for considerable amounts of time. Still, there are certain general steps you can take to optimize 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.

 

Development and Debugging

 

Commits fail with the error "svn: E175013: Access to '/public/eutelescope/!svn/[...]' forbidden". What's the problem?

You are accessing the public DESY SVN server which does not support authentification. In order for you to be able to commit your changes back into the SVN repository, you need to use an authenticated access. For this, you should switch your SVN checkout to the authenticated repository e.g. by entering
svn switch --relocate https://svnsrv.desy.de/public/eutelescope/Eutelescope/trunk \
                      https://svnsrv.desy.de/desy/eutelescope/Eutelescope/trunk
Here, the switch is done from public to kerberos authentication on the central development branch (trunk). You can check which branch you are currently using by entering "svn info". Other means of access besides kerberos are documented at http://svnsrv.desy.de/access.html or http://svnbook.red-bean.com/en/1.1/ch04s05.html.

 

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 ..