Difference: LHCbSoftwareTrainingBasics (1 vs. 94)

Revision 942014-08-25 - MichaelWilkinson

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 78 to 78
 
  • Check the group associated with your account by giving the command:
echo $GROUP
Changed:
<
<
For an account in the LHCb group the result should be z5.
>
>
For an account in the LHCb group the result should be z5. If it is not, you can request a change to your primary computing group by going to the CERN Resources Portal-->List Services-->LXPLUS and LINUX-->
Computing Groups-->select z5 from the primary group dropdown menu.
 
  • Check which shell you are using, for example using:
echo $0

Revision 932014-07-30 - ChristopherRJones

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 32 to 32
 

Choice of shell

Changed:
<
<
By default, all new accounts for on lxplus are configured to use bash shell. LHCb users are encouraged to change this to the tcsh shell (which was the lxplus default until 15th March 2011), an enhanced version of csh, however LHCb setup scripts are also available for the Bourne family of shells: sh, bash, ksh, zsh. There are subtle and not-so-subtle differences in the functionality of the different shells, and for scripting there are major differences between (t)csh and Bourne-type shells. A useful short summary can be found in:
>
>
By default, all new accounts for on lxplus are configured to use bash shell. An alternative shell is tcsh shell (which was the lxplus default until 15th March 2011), an enhanced version of csh. LHCb setup scripts are available for both the Bourne family of shells: sh, bash, ksh, zsh and (t)csh. There are subtle and not-so-subtle differences in the functionality of the different shells, and for scripting there are major differences between (t)csh and Bourne-type shells. A useful short summary can be found in:
 
Changed:
<
<
A user may redefine the default shell on lxplus by going to https://account.cern.ch/account/Management/MyAccounts.aspx, navigate to "Services" then Linux and AFS services (you will need to login using your CERN username and password). In general, unless you have a strong preference, stick to tcsh as this is better tested.
>
>
A user may redefine the default shell on lxplus by going to https://account.cern.ch/account/Management/MyAccounts.aspx, navigate to "Services" then Linux and AFS services (you will need to login using your CERN username and password).
  In what follows, <script>.[c]sh is used as shorthand for:

Revision 922013-07-09 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 168 to 168
  For a package with name myPackage, CMT itself defines an environment variable MYPACKAGEROOT that contains the package location.
Changed:
<
<
The full set of commands that can be used in a requirements file is described in the CMT manual. Some of the most useful commands are shown below.
>
>
The full set of commands that can be used in a requirements file is described in the CMT manual. Some of the most useful commands are shown below.
 |
# Lines beginning with the symbol '#' are treated as comments. 
# Blank lines are ignored. 

Line: 230 to 230
  Most CMT commands, but not all, operate on requirements files, and must be given from a package's cmt directory. If a requirements file includes lines indicating that other packages are used, then these packages will be searched for in locations specified by the project environment, and the requirements files of each used package is processed in turn.
Changed:
<
<
The CMT manual should be consulted for the full set of CMT commands, but a useful subset is given below.
>
>
The CMT manual should be consulted for the full set of CMT commands, but a useful subset is given below.
 
  • Perform package configuration - that is, create setup files and Make files:
cmt config

Revision 912013-04-29 - HellaSnoek

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 36 to 36
 
Changed:
<
<
A user may redefine the default shell on lxplus by going to https://account.cern.ch/account/Management/MyAccounts.aspx, navigate to "Applications and Resources.." then [Manage] Linux services (you will need to login using your CERN username and password). In general, unless you have a strong preference, stick to tcsh as this is better tested.
>
>
A user may redefine the default shell on lxplus by going to https://account.cern.ch/account/Management/MyAccounts.aspx, navigate to "Services" then Linux and AFS services (you will need to login using your CERN username and password). In general, unless you have a strong preference, stick to tcsh as this is better tested.
  In what follows, <script>.[c]sh is used as shorthand for:

Revision 902013-01-29 - PatrickSKoppenburg

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 389 to 389
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1351148886" name="Environment.ppt" path="Environment.ppt" size="1256960" user="cattanem" version="17"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v23r5"
Changed:
<
<
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v33r0p1"
>
>
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v33r1"

Revision 892012-12-04 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 373 to 373
  You now have the environment to execute the Root application. The version that you will execute is the version compatible with the latest release of Gaudi
  • Now issue the commands:
Changed:
<
<
SetupProject Gaudi v21r4 ROOT
echo $ROOTSYS
which root
>
>
SetupProject Gaudi v23r2 ROOT
echo $ROOTSYS
which root
 
Changed:
<
<
This time the version of Root that has been selected is the version compatible with Gaudi v21r4
>
>
This time the version of Root that has been selected is the version compatible with Gaudi v23r2
 
  • Finally, issue the commands:
Changed:
<
<
SetupProject Gaudi v21r4 ROOT -v 5.24.00
echo $ROOTSYS
which root
>
>
SetupProject Gaudi v23r2 ROOT -v 5.32.00
echo $ROOTSYS
which root
 
Changed:
<
<
This time we have over-ridden the version of Root compatible with Gaudi v21r4, and selected explicitly a different version. This can be useful if you need to over-ride the version of an external library to use a different version from the one with which the application was released.
>
>
This time we have over-ridden the version of Root compatible with Gaudi v23r2, and selected explicitly a different version. This can be useful if you need to over-ride the version of an external library to use a different version from the one with which the application was released.
 

Exercise 8

CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.

Changed:
<
<
-- MarcoCattaneo - 23-Nov-2010
>
>
-- MarcoCattaneo - 04-Dec-2012
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1351148886" name="Environment.ppt" path="Environment.ppt" size="1256960" user="cattanem" version="17"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v22r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v28r1p1"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v23r5"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v33r0p1"

Revision 882012-10-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 387 to 387
  -- MarcoCattaneo - 23-Nov-2010
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1317142237" name="Environment.ppt" path="Environment.pptx" size="181924" stream="Environment.pptx" tmpFilename="/usr/tmp/CGItemp41721" user="cattanem" version="16"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1351148886" name="Environment.ppt" path="Environment.ppt" size="1256960" user="cattanem" version="17"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v22r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v28r1p1"

Revision 872011-11-03 - RoelAaij

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->

Revision 862011-09-27 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 387 to 387
  -- MarcoCattaneo - 23-Nov-2010
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1301050327" name="Environment.ppt" path="Environment.pptx" size="177955" stream="Environment.pptx" tmpFilename="/usr/tmp/CGItemp9316" user="cattanem" version="15"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1317142237" name="Environment.ppt" path="Environment.pptx" size="181924" stream="Environment.pptx" tmpFilename="/usr/tmp/CGItemp41721" user="cattanem" version="16"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v22r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v28r1p1"

Revision 852011-03-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 387 to 387
  -- MarcoCattaneo - 23-Nov-2010
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1291384658" name="Environment.ppt" path="Environment.pptx" size="178257" stream="Environment.pptx" tmpFilename="/usr/tmp/CGItemp7192" user="cattanem" version="14"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1301050327" name="Environment.ppt" path="Environment.pptx" size="177955" stream="Environment.pptx" tmpFilename="/usr/tmp/CGItemp9316" user="cattanem" version="15"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v22r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v28r1p1"

Revision 842011-03-22 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 388 to 388
 -- MarcoCattaneo - 23-Nov-2010

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1291384658" name="Environment.ppt" path="Environment.pptx" size="178257" stream="Environment.pptx" tmpFilename="/usr/tmp/CGItemp7192" user="cattanem" version="14"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r11"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v26r3p2"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v22r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v28r1p1"

Revision 832011-03-22 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 32 to 32
 

Choice of shell

Changed:
<
<
By default, accounts for LHCb users on lxplus are configured to use the tcsh shell, an enhanced version of csh, but LHCb setup scripts are also available for the Bourne family of shells: sh, bash, ksh, zsh. There are subtle and not-so-subtle differences in the functionality of the different shells, and for scripting there are major differences between (t)csh and Bourne-type shells. A useful short summary can be found in:
>
>
By default, all new accounts for on lxplus are configured to use bash shell. LHCb users are encouraged to change this to the tcsh shell (which was the lxplus default until 15th March 2011), an enhanced version of csh, however LHCb setup scripts are also available for the Bourne family of shells: sh, bash, ksh, zsh. There are subtle and not-so-subtle differences in the functionality of the different shells, and for scripting there are major differences between (t)csh and Bourne-type shells. A useful short summary can be found in:
 
Line: 169 to 169
 For a package with name myPackage, CMT itself defines an environment variable MYPACKAGEROOT that contains the package location.

The full set of commands that can be used in a requirements file is described in the CMT manual. Some of the most useful commands are shown below.

Changed:
<
<
# Lines beginning with the symbol # are treated as comments. # Blank lines are ignored. #================================================================== # The following commands describe a package. # Package name. *package myPackage* # Package version, should correspond to SVN tag. *version v1r0* # Structure, i.e. directories to process. # A package must always have: # a cmt directory (for the requirements file) # a doc directory (for the release.notes file) # It may have: # a src directory for source files (.h, .cpp) # a options directory for job options (.opts, .py) # a python directory for python scripts and configurables # a directory with the same name as the package, containing include files that # should be visible outside the package (i.e. the public interface) *branches cmt doc src options myPackage* #================================================================== # The following command specifies packages which the current package # needs for compilation and linking. Put as many lines as necessary. # The keyword is followed by package name and version and, # where applicable, the package group in which the package is placed. # The version can usually be v* (i.e. any version) because the exact version # is usually determined by setting the environment in which a package is built *use DaVinciTools v* Phys* #================================================================== # The following commands tell CMT what to build and how # Build application with the specified file *application myApp ../src/myApp.cpp* # Build a library with the specified files *library myLib ../src/*.cpp* # Define link options and environment variables for loading component library *apply_pattern component_library library=myLib* # Define link options and environment variables for loading linker library *apply_pattern linker_library library=myLib* # Make the public include files visible to the whole project (i.e. copy them to the InstallArea) *apply_pattern install_more_includes more=myPackage* #================================================================== # The following commands define symbols (variables and aliases). # They consist of a keyword followed by a symbol name, and possibly by a value. # Previously defined symbols, including environment variables, can be used in # value assignments by placing brackets - () or {} - around them and a $ in front. # Treat symbol as a Make macro definition. # This can be used to define a symbol as a local variable # (i.e. one that won't be visible from the shell). *macro MYCMTDIR $(HOME)/cmtuser* # Treat symbol as an environment variable. # The symbol will be visible from the shell after executing SetupProject *set LCGDIR /afs/cern.ch/sw/lcg* # Treat symbol as a path variable. # The symbol will be visible from the shell after executing SetupProject # When appending or prepending an item to a path variable not initialised in the # requirements file, it's a good idea to first remove the item, to ensure it occurs only once. # Set path. *path PYTHONPATH $(HOME)/python* # Append item to path. *path_append PYTHONPATH $(HOME)/myPythonPackage* # Remove item from path. *path_remove LD_LIBRARY_PATH $(HOME)/lib* # Prepend item to path. *path_prepend LD_LIBRARY_PATH $(HOME)/lib* # Create alias. # The alias will be visible from the shell after executing SetupProject *alias myApp $(MYPACKAGEROOT)/$(CMTCONFIG)/myApp.exe* #================================================================== 
>
>
# Lines beginning with the symbol '#' are treated as comments. 
# Blank lines are ignored. 

#================================================================== 
# The following commands describe a package. 
# Package name. 
package myPackage 
# Package version, should correspond to SVN tag.
version v1r0
# Structure, i.e. directories to process. 
# A package must always have: 
#    a cmt directory (for the requirements file) 
#    a doc directory (for the release.notes file) 
# It may have: 
#    a src directory for source files (.h, .cpp)
#    a options directory for job options (.opts, .py) 
#    a python directory for python scripts and configurables 
#    a directory with the same name as the package, containing include files that should be visible outside the package (i.e. the public interface)
branches cmt doc src options myPackage
#==================================================================
# The following command specifies packages which the current package needs for compilation and linking. Put as many lines as necessary.
# The keyword is followed by package name and version and, where applicable, the package group in which the package is placed.
# The version can usually be v* (i.e. any version) because the exact version is usually determined by setting the environment in which a package is built
use DaVinciTools v* Phys
#================================================================== 
# The following commands tell CMT what to build and how 
# Build application with the specified file
application myApp ../src/myApp.cpp
# Build a library with the specified files
library myLib ../src/*.cpp
# Define link options and environment variables for loading component library
apply_pattern component_library library=myLib
# Define link options and environment variables for loading linker library
apply_pattern linker_library library=myLib
# Make the public include files visible to the whole project (i.e. copy them to the InstallArea)
apply_pattern install_more_includes more=myPackage
#==================================================================
# The following commands define symbols (variables and aliases).
# They consist of a keyword followed by a symbol name, and possibly by a value.
# Previously defined symbols, including environment variables, can be used in value assignments by placing brackets - () or {} - around them and a $ in front. 
# Treat symbol as a Make macro definition.This can be used to define a symbol as a local variable (i.e. one that won't be visible from the shell).
macro MYCMTDIR $(HOME)/cmtuser
# Treat symbol as an environment variable. The symbol will be visible from the shell after executing SetupProject
set LCGDIR /afs/cern.ch/sw/lcg
# Treat symbol as a path variable. The symbol will be visible from the shell after executing SetupProject
# When appending or prepending an item to a path variable not initialised in the requirements file, it's a good idea to first remove the item, to ensure it occurs only once.
# Set path.
path PYTHONPATH $(HOME)/python
# Append item to path.
path_append PYTHONPATH $(HOME)/myPythonPackage
# Remove item from path.
path_remove LD_LIBRARY_PATH $(HOME)/lib
# Prepend item to path.
path_prepend LD_LIBRARY_PATH $(HOME)/lib
# Create alias. 
# The alias will be visible from the shell after executing SetupProject
alias myApp $(MYPACKAGEROOT)/$(CMTCONFIG)/myApp.exe
#================================================================== 
  Most CMT commands, but not all, operate on requirements files, and must be given from a package's cmt directory. If a requirements file includes lines indicating that other packages are used, then these packages will be searched for in locations specified by the project environment, and the requirements files of each used package is processed in turn.
Line: 204 to 261
  Have a look at the options of gaudirun.py
Changed:
<
<
. Try
>
>
Try
 
cmt run gaudirun.py -h

for help, or

Revision 822010-12-03 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 330 to 330
  -- MarcoCattaneo - 23-Nov-2010
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1285921143" name="Environment.ppt" path="Environment.ppt" size="585216" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp34391" user="cattanem" version="13"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1291384658" name="Environment.ppt" path="Environment.pptx" size="178257" stream="Environment.pptx" tmpFilename="/usr/tmp/CGItemp7192" user="cattanem" version="14"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r11"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v26r3p2"

Revision 812010-12-03 - PatrickSKoppenburg

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 270 to 270
  In this exercise we just execute the released DaVinci application, with default job options
  • Start a new login shell, and execute the following commands:
Changed:
<
<
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py
>
>
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py $APPCONFIGOPTS/DaVinci/DataType-2010.py
  The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the gaudirun.py command.
Line: 298 to 298
 
  • In the existing window type
env | grep DAVINCI
echo ${DAVINCIROOT}
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py'
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py $APPCONFIGOPTS/DaVinci/DataType-2010.py'
env | grep DAVINCI
  Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

Revision 802010-11-23 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
Line: 296 to 296
  This exercise demonstrates an alternative method to opening a new window each time you wish to change the version of project you are working with. This method is recommended if you switch versions frequently, for example if you are comparing the results of a new release with a previous one.
  • In the existing window type
Changed:
<
<
=env grep DAVINCI
echo ${DAVINCIROOT}=
>
>
env | grep DAVINCI
echo ${DAVINCIROOT}
 
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
=setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py'
env
grep DAVINCI=
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py'
env | grep DAVINCI
  Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.
Line: 328 to 328
  CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.
Changed:
<
<
-- MarcoCattaneo - 28-Sep-2010
>
>
-- MarcoCattaneo - 23-Nov-2010
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1285921143" name="Environment.ppt" path="Environment.ppt" size="585216" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp34391" user="cattanem" version="13"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r11"

Revision 792010-11-23 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
Changed:
<
<
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
>
>
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
 

LHCb Software Training: Basics

Deleted:
<
<
This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
 
Added:
>
>
This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
 

Prerequisites

Line: 19 to 18
 These instructions have last been checked against the DaVinci v33r1 (and Gaudi v23r5) environment. Please use this version of DaVinci or a more recent version.

Logging in to lxplus5 (lxplus slc5 cluster)

Added:
>
>
 Remote access to lxplus is via the ssh protocol. Open a connection using the command:
Changed:
<
<
ssh -X <username>@lxplus5.cern.ch
The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config:
>
>
ssh -X <username>@lxplus5.cern.ch

The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config

:

 
ForwardX11 yes
Changed:
<
<
Some sites require trusted X11 forwarding, in this case it is not enough to have -X option, the option -Y is needed or the following line in ${HOME}/.ssh/config:
>
>
Some sites require trusted X11 forwarding, in this case it is not enough to have -X option, the option -Y is needed or the following line in ${HOME}/.ssh/config:
 
ForwardX11Trusted yes

Choice of shell

Line: 33 to 36
 
Changed:
<
<
A user may redefine the default shell on lxplus by going to https://cra.cern.ch and changing the appropriate field. In general, unless you have a strong preference, stick to tcsh as this is better tested.
>
>
A user may redefine the default shell on lxplus by going to https://account.cern.ch/account/Management/MyAccounts.aspx, navigate to "Applications and Resources.." then [Manage] Linux services (you will need to login using your CERN username and password). In general, unless you have a strong preference, stick to tcsh as this is better tested.
  In what follows, <script>.[c]sh is used as shorthand for:
Line: 48 to 53
 For users logging on to lxplus with an account in the LHCb group (z5), the LbLogin script is sourced automatically at startup by one of the group login scripts, which are all equivalent:
  • /afs/cern.ch/group/z5/group_login.[c,z]sh
  • /afs/cern.ch/group/z5/group_[ba,tc,z]rc
Deleted:
<
<
Which script is executed depends on the type of shell, and on how the shell was created (e.g. ssh or spawned from an existing shell).
 
Added:
>
>
Which script is executed depends on the type of shell, and on how the shell was created (e.g. ssh or spawned from an existing shell).
 

LHCb flavour of emacs editor

Added:
>
>
 Customisations to emacs designed to help LHCb users have been written, and are described in the LHCb emacs user guide. Even for users who prefer a different editor (vim, nedit, Joe's own editor, pico, nano, or other), the LHCb flavour of emacs is useful for creating skeleton algorithms and similar.

IMPORTANT : If you are working over a slow network connection, it is sometimes useful to work in a 'terminal mode', where a new X window is not opened. This can be done by running

Line: 56 to 62
  IMPORTANT : If you are working over a slow network connection, it is sometimes useful to work in a 'terminal mode', where a new X window is not opened. This can be done by running
emacs -nw
Added:
>
>
 In this mode, the menu bars are not useful, so it is good to know a few key-strokes :
Changed:
<
<
  1. Open a file with control-X control-F
  2. Save a file with control-X control-S
  3. Exit with control-X control-C
>
>
  1. Open a file with control-X control-F
  2. Save a file with control-X control-S
  3. Exit with control-X control-C
 

Exercise 1

Line: 72 to 81
  For an account in the LHCb group the result should be z5.
  • Check which shell you are using, for example using:
    echo $0
Added:
>
>
  or
echo $SHELL
Changed:
<
<
and optionally change your default shell by going to https://cra.cern.ch (you will need to login using your CERN NICE username and password)
>
>
 
  • Check that the standard LHCb environment has been set. If it has, then you will have seen a message at login time about your CMT settings, and the result of the command:
    env
Added:
>
>
  should contain a number of variables with prefix LHCB (LHCBHOME, LHCBRELEASES and so on), and with prefix CMT (CMTROOT, CMTCONFIG and so on). If this isn't the case then you need to setup the environment yourself.
  • Setup the LHCb flavour of emacs and (optionally) the EDT keyboard emulation by adding the following lines to the ~/.emacs file:
Changed:
<
<
(load (expand-file-name "$EMACSDIR/lhcb"))
(load (expand-file-name "$EMACSDIR/edt"))
>
>
(load (expand-file-name "$EMACSDIR/lhcb"))
(load (expand-file-name "$EMACSDIR/edt"))
  or
cp $EMACSDIR/.emacs ~
Added:
>
>
  LHCb specific emacs commands are documented in the LHCb emacs user guide.

Organisation of LHCb software

Line: 85 to 98
  LHCb specific emacs commands are documented in the LHCb emacs user guide.

Organisation of LHCb software

Added:
>
>
 LHCb software is based on a framework called Gaudi. This framework provides functionality useful in a wide range of contexts, such as file access, histogramming, message printing, and run-time configuration. The run-time configuration is based on job options.
Changed:
<
<
Software in LHCb is developed in the context of CMT packages and CMT projects.
>
>
Software in LHCb is developed in the context of CMT packages and CMT projects.
 
  • A package is a set of files, organised according to some directory structure, which provides some well-defined, circumscribed functionality. It is the basic unit of software development, meaning that all the files in a given package are tagged with the same version number and are released together. Changing just one file in the package implies releasing a new version of the whole package. Most LHCb packages contain code that can be compiled into one or more libraries.
  • Packages with related functionality are collected in groups (or are said to be placed under a hat). The purpose of package groups is simply to group together, in the directory tree, all packages that are related in some way (for example all event model packages under the /Event hat, or all Rich packages under the /Rich hat).
  • A project is a set of packages that are grouped together according to some functionality, for example all Gaudi packages (Gaudi project), most public LHCb header files and base class libraries (LHCb project), all reconstruction packages (Rec project), all packages specific to the simulation application (Gauss project). All packages within a given project are released as a single unit: changing just one package in a project implies a releasing a new version of the whole project. Choosing a given version of a project automatically selects a single version of each of the packages in the project.
Line: 130 to 148
 
  • Rec: components for online (HLT) and offline reconstruction
  • Phys: components for online (HLT) and offline analysis
  • Analysis: components for offline analysis
Changed:
<
<
>
>
  • Stripping: components for offline event selection (stripping)
 

Exercise 2

Added:
>
>
 This exercise is designed to give you some familiarity with the LHCb software organisation. It's fairly open-ended, in that you could spend a very long time exploring all of the LHCb packages. Until you're trying to find something - which is when knowing the organisation is a big help - it's probably not useful to spend more than 5-10 minutes looking around.
  • Move to the LHCb release area: either
    cd ${LHCBRELEASES}
Line: 148 to 169
 For a package with name myPackage, CMT itself defines an environment variable MYPACKAGEROOT that contains the package location.

The full set of commands that can be used in a requirements file is described in the CMT manual. Some of the most useful commands are shown below.

Changed:
<
<
# Lines beginning with the symbol # are treated as comments.
# Blank lines are ignored.
#==================================================================
# The following commands describe a package.

# Package name.
package myPackage

# Package version, should correspond to SVN tag.
version v1r0

# Structure, i.e. directories to process. 
# A package must always have:
#   a cmt directory (for the requirements file)
#   a doc directory (for the release.notes file)
# It may have:
#   a src directory for source files (.h, .cpp)
#   a options directory for job options (.opts, .py)
#   a python directory for python scripts and configurables
#   a directory with the same name as the package, containing include files that 
#             should be visible outside the package (i.e. the public interface)
branches cmt doc src options myPackage

#==================================================================
# The following command specifies packages which the current package
# needs for compilation and linking. Put as many lines as necessary.
# The keyword is followed by package name and version and,
# where applicable, the package group in which the package is placed.
# The version can usually be v* (i.e. any version) because the exact version
# is usually determined by setting the environment in which a package is built
use DaVinciTools v* Phys

#==================================================================
# The following commands tell CMT what to build and how

# Build application with the specified file
application myApp ../src/myApp.cpp

# Build a library with the specified files
library myLib ../src/*.cpp

# Define link options and environment variables for loading component library
apply_pattern component_library library=myLib

# Define link options and environment variables for loading linker library
apply_pattern linker_library library=myLib

# Make the public include files visible to the whole project (i.e. copy them to the InstallArea)
apply_pattern install_more_includes more=myPackage
 
#==================================================================
# The following commands define symbols (variables and aliases).
# They consist of a keyword followed by a symbol name, and possibly by a value.

# Previously defined symbols, including environment variables, can be used in
# value assignments by placing brackets - () or {} - around them and a $ in front.

# Treat symbol as a Make macro definition.
# This can be used to define a symbol as a local variable
# (i.e. one that won't be visible from the shell).
macro MYCMTDIR $(HOME)/cmtuser

# Treat symbol as an environment variable.
# The symbol will be visible from the shell after executing SetupProject
set LCGDIR /afs/cern.ch/sw/lcg

# Treat symbol as a path variable.
# The symbol will be visible from the shell after executing SetupProject
# When appending or prepending an item to a path variable not initialised in the 
# requirements file, it's a good idea to first remove the item, to ensure it occurs only once.

# Set path.
path PYTHONPATH $(HOME)/python

# Append item to path.
path_append PYTHONPATH $(HOME)/myPythonPackage

# Remove item from path.
path_remove LD_LIBRARY_PATH $(HOME)/lib

# Prepend item to path.
path_prepend LD_LIBRARY_PATH $(HOME)/lib

# Create alias.
# The alias will be visible from the shell after executing SetupProject
alias myApp $(MYPACKAGEROOT)/$(CMTCONFIG)/myApp.exe
#==================================================================
>
>
# Lines beginning with the symbol # are treated as comments. # Blank lines are ignored. #================================================================== # The following commands describe a package. # Package name. *package myPackage* # Package version, should correspond to SVN tag. *version v1r0* # Structure, i.e. directories to process. # A package must always have: # a cmt directory (for the requirements file) # a doc directory (for the release.notes file) # It may have: # a src directory for source files (.h, .cpp) # a options directory for job options (.opts, .py) # a python directory for python scripts and configurables # a directory with the same name as the package, containing include files that # should be visible outside the package (i.e. the public interface) *branches cmt doc src options myPackage* #================================================================== # The following command specifies packages which the current package # needs for compilation and linking. Put as many lines as necessary. # The keyword is followed by package name and version and, # where applicable, the package group in which the package is placed. # The version can usually be v* (i.e. any version) because the exact version # is usually determined by setting the environment in which a package is built *use DaVinciTools v* Phys* #================================================================== # The following commands tell CMT what to build and how # Build application with the specified file *application myApp ../src/myApp.cpp* # Build a library with the specified files *library myLib ../src/*.cpp* # Define link options and environment variables for loading component library *apply_pattern component_library library=myLib* # Define link options and environment variables for loading linker library *apply_pattern linker_library library=myLib* # Make the public include files visible to the whole project (i.e. copy them to the InstallArea) *apply_pattern install_more_includes more=myPackage* #================================================================== # The following commands define symbols (variables and aliases). # They consist of a keyword followed by a symbol name, and possibly by a value. # Previously defined symbols, including environment variables, can be used in # value assignments by placing brackets - () or {} - around them and a $ in front. # Treat symbol as a Make macro definition. # This can be used to define a symbol as a local variable # (i.e. one that won't be visible from the shell). *macro MYCMTDIR $(HOME)/cmtuser* # Treat symbol as an environment variable. # The symbol will be visible from the shell after executing SetupProject *set LCGDIR /afs/cern.ch/sw/lcg* # Treat symbol as a path variable. # The symbol will be visible from the shell after executing SetupProject # When appending or prepending an item to a path variable not initialised in the # requirements file, it's a good idea to first remove the item, to ensure it occurs only once. # Set path. *path PYTHONPATH $(HOME)/python* # Append item to path. *path_append PYTHONPATH $(HOME)/myPythonPackage* # Remove item from path. *path_remove LD_LIBRARY_PATH $(HOME)/lib* # Prepend item to path. *path_prepend LD_LIBRARY_PATH $(HOME)/lib* # Create alias. # The alias will be visible from the shell after executing SetupProject *alias myApp $(MYPACKAGEROOT)/$(CMTCONFIG)/myApp.exe* #================================================================== 
  Most CMT commands, but not all, operate on requirements files, and must be given from a package's cmt directory. If a requirements file includes lines indicating that other packages are used, then these packages will be searched for in locations specified by the project environment, and the requirements files of each used package is processed in turn.

Line: 247 to 181
 
  • After configuration, Make commands can be used from the cmt directory:
    • Build the package binaries:
      cmt make
Added:
>
>
  The output of the build operation is placed in a package sub-directory. The name of this sub-directory is given by the value of the environment variable CMTCONFIG.
Added:
>
>
 
    • Build several files in parallel if possible:
      cmt make -j
Added:
>
>
 
    • Delete the package binaries:
      cmt make binclean
Added:
>
>
 
    • Delete all generated files, including copies made to the project InstallArea
      cmt make clean
  • Show all packages used by the current package:
Line: 262 to 201
 
cmt broadcast "cmt config ; cmt make binclean ; cmt make"
  • Execute an executable within the environment of the current project
    cmt run gaudirun.py
Changed:
<
<
Have a look at the options of gaudirun.py. Try
>
>
Have a look at the options of gaudirun.py

. Try

 
cmt run gaudirun.py -h
Added:
>
>
  for help, or
cmt run gaudirun.py -v
Added:
>
>
  for a verbose printout of all options.

To release a new package in the LHCb framework it must be imported into SVN so that getpack can find it. Follow the instructions here.

Line: 278 to 224
  The search path for CMT projects was set up when you logged in. It includes a User_release_area, the LHCb_release_area, the Gaudi_release_area and the LCG_release_area (for external software)
  • Create a CMT project directory in which to work.
    setenvDaVinci v33r1
Added:
>
>
  This command creates a directory ~/cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
  • Look at the cmt/project.cmt file that was created
Changed:
<
<
pwd
cat cmt/project.cmt
The setenv<Project> command places you inside your new CMT project, and creates a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

>
>
pwd
cat cmt/project.cmt

The setenv<Project> command places you inside your new CMT project, and creates a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

 
  • Create a new package in your DaVinci_v33r1 project:
Changed:
<
<
cd ~/cmtuser/DaVinci_v33r1
mkdir -p MyGroup/MyPackage/cmt
cd MyGroup/MyPackage/cmt
>
>
cd ~/cmtuser/DaVinci_v33r1
mkdir -p MyGroup/MyPackage/cmt
cd MyGroup/MyPackage/cmt
 
  • Create a cmt requirements file
    emacs requirements &
Added:
>
>
  Look at the generated file and add the line
use GaudiAlg v*
Added:
>
>
  Save the file. The use statement that you added tells CMT that the files in this package will require to compile and link against files in the GaudiAlg package.
  • Try some basic CMT commands:
Changed:
<
<
cmt show uses
ls
ls ..
cmt config
ls
ls ..
>
>
cmt show uses
ls
ls ..
cmt config
ls
ls ..
 
  • Try creating some different types of files with emacs. Each time, make a small modification to the file and save it
Changed:
<
<
emacs ../doc/release.notes &
emacs ../src/MyAlg.h &
emacs ../src/MyAlg.cpp &
>
>
emacs ../doc/release.notes &
emacs ../src/MyAlg.h &
emacs ../src/MyAlg.cpp &
 
  • Use CMT to compile the files you just created, and make a library out of them
Changed:
<
<
cmt make
ls ..
ls ../x86_64-slc5-gcc43-opt
ls ../$CMTCONFIG
>
>
cmt make
ls ..
ls ../x86_64-slc5-gcc43-opt
ls ../$CMTCONFIG
 
  • Similarly, make the debug version of the library (i.e. containing debug symbols for use with a debugger)
Changed:
<
<
setenv CMTCONFIG $CMTDEB
cmt make
ls ..
ls ../x86_64-slc5-gcc43-dbg
ls ../$CMTCONFIG
>
>
setenv CMTCONFIG $CMTDEB
cmt make
ls ..
ls ../x86_64-slc5-gcc43-dbg
ls ../$CMTCONFIG
 

Running LHCb Applications

Added:
>
>
 When executing an application, the following environment variables are very important:
  • PATH: search path for scripts and executables, e.g. gaudirun.py;
  • LD_LIBRARY_PATH: search path for shared libraries.
Line: 314 to 267
 

Exercise 4

Added:
>
>
 In this exercise we just execute the released DaVinci application, with default job options
  • Start a new login shell, and execute the following commands:
Changed:
<
<
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py
>
>
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py
  The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the gaudirun.py command.
Line: 325 to 279
 gaudirun.py is a generic Gaudi application written in python. It is used as main program for all LHCb applications. The specific behaviour of the application is defined by the options file(s) provided as argument(s). Options files can be written either in the old Gaudi native syntax (.opts) or using python syntax. The python syntax is recommended.

Exercise 5

Added:
>
>
 In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
Changed:
<
<
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/cmt
>
>
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/cmt
 
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application. You could for example add the MyGroup/MyPackage that you created in Exercise 3. Note that the syntax is as follows:
    use <package name> <version> <package group>
  • Install the application
Line: 338 to 293
 

Exercise 6

Added:
>
>
 This exercise demonstrates an alternative method to opening a new window each time you wish to change the version of project you are working with. This method is recommended if you switch versions frequently, for example if you are comparing the results of a new release with a previous one.
  • In the existing window type
Changed:
<
<
env | grep DAVINCI
echo ${DAVINCIROOT}
>
>
=env grep DAVINCI
echo ${DAVINCIROOT}=
 
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py'
env | grep DAVINCI
>
>
=setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py'
env
grep DAVINCI=
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Line: 351 to 309
 Another use of SetupProject is to give access to software external to LHCb. In this exercise we see how to set up the environment for the Root application
  • Start a new terminal window, and issue the following command:
    which root
Added:
>
>
  The Root application is not accessible in the default lxplus login environment
  • Now issue the commands:
Changed:
<
<
SetupProject Gaudi ROOT
echo $ROOTSYS
which root
>
>
SetupProject Gaudi ROOT
echo $ROOTSYS
which root
  You now have the environment to execute the Root application. The version that you will execute is the version compatible with the latest release of Gaudi
  • Now issue the commands:
Changed:
<
<
SetupProject Gaudi v21r4 ROOT
echo $ROOTSYS
which root
>
>
SetupProject Gaudi v21r4 ROOT
echo $ROOTSYS
which root
  This time the version of Root that has been selected is the version compatible with Gaudi v21r4
  • Finally, issue the commands:
Changed:
<
<
SetupProject Gaudi v21r4 ROOT -v 5.24.00
echo $ROOTSYS
which root
>
>
SetupProject Gaudi v21r4 ROOT -v 5.24.00
echo $ROOTSYS
which root
  This time we have over-ridden the version of Root compatible with Gaudi v21r4, and selected explicitly a different version. This can be useful if you need to over-ride the version of an external library to use a different version from the one with which the application was released.

Exercise 8

Line: 368 to 331
 -- MarcoCattaneo - 28-Sep-2010

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1285921143" name="Environment.ppt" path="Environment.ppt" size="585216" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp34391" user="cattanem" version="13"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r10p1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v26r1"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r11"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v26r3p2"

Revision 782010-10-01 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 367 to 367
  -- MarcoCattaneo - 28-Sep-2010
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1268404568" name="Environment.ppt" path="Environment.ppt" size="597504" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp12288" user="cattanem" version="12"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1285921143" name="Environment.ppt" path="Environment.ppt" size="585216" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp34391" user="cattanem" version="13"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r10p1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v26r1"

Revision 772010-09-28 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 100 to 100
 
  • options: job options associated with the package;
  • cmt: information for CMT processing;
  • doc: package documentation.
Changed:
<
<
Package development in LHCb is currently carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. A migration from CVS to Subversion (SVN) is under way and should be completed by the end of 2010. During the migration, a given package will be active in only one of the two repositories, not both.
>
>
Package development in LHCb is currently carried out using the Subversion code versioning system (SVN). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made.
 
Changed:
<
<
With the standard LHCb environment, a user can obtain a copy of any package from the CVS or SVN repositories using the command:
>
>
With the standard LHCb environment, a user can obtain a copy of any package from the SVN repository using the command:
 
getpack <package group>/<package> <version>
Changed:
<
<
The appropriate repository is selected automatically by this tool. If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository and access to the SVN repository require ssh authentication, which is automatic on lxplus if you have a valid AFS token.
>
>
The appropriate repository is selected automatically by this tool. If the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the SVN repository requires ssh authentication, which is automatic on lxplus if you have a valid AFS token.
  New releases of projects are placed in the release area after testing. The standard LHCb environment includes the variable $LHCBRELEASES pointing to the AFS release area.
Changed:
<
<
Instructions for making package modifications and new packages available for inclusion in a release can be found in the documentation for Guidelines for CVS actions in LHCb and Guidelines for SVN actions in LHCb. Web access is available to both the CVS repository and SVN repository and to the release area.
>
>
Instructions for making package modifications and new packages available for inclusion in a release can be found in the documentation for Guidelines for SVN actions in LHCb. Web access is available to the SVN repository and to the release area.
 
Changed:
<
<
As soon as a package update is committed to CVS or SVN, it will be picked up by one of the nightly builds the next night. Nightly builds are used to test new software prior to it being officially released. The nightly build status can be viewed at http://cern.ch/lhcb-nightlies/cgi-bin/nightlies.py. Advanced users wishing to pick up the latest updates can run their software against one of the nightlies, see instructions in the LHCb nightlies documentation
>
>
As soon as a package update is committed to SVN, it will be picked up by one of the nightly builds the next night. Nightly builds are used to test new software prior to it being officially released. The nightly build status can be viewed at http://cern.ch/lhcb-nightlies/cgi-bin/nightlies.py. Advanced users wishing to pick up the latest updates can run their software against one of the nightlies, see instructions in the LHCb nightlies documentation
 

LHCb applications

The LHCb applications are projects that use the Gaudi framework to perform specific tasks. There is a project specific to, and with the same name as, each application. The main applications are:
Line: 157 to 157
 # Package name. package myPackage
Changed:
<
<
# Package version, should correspond to CVS tag.
>
>
# Package version, should correspond to SVN tag.
 version v1r0

# Structure, i.e. directories to process.

Line: 365 to 365
 

Exercise 8

CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.
Changed:
<
<
-- MarcoCattaneo - 27-Jan-2010
>
>
-- MarcoCattaneo - 28-Sep-2010
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1268404568" name="Environment.ppt" path="Environment.ppt" size="597504" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp12288" user="cattanem" version="12"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7p1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v25r2"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r10p1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v26r1"

Revision 762010-03-12 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 367 to 367
  -- MarcoCattaneo - 27-Jan-2010
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1265016240" name="Environment.ppt" path="Environment.ppt" size="590336" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp53671" user="cattanem" version="11"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1268404568" name="Environment.ppt" path="Environment.ppt" size="597504" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp12288" user="cattanem" version="12"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7p1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v25r2"

Revision 752010-03-11 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 369 to 369
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1265016240" name="Environment.ppt" path="Environment.ppt" size="590336" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp53671" user="cattanem" version="11"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7p1"
Changed:
<
<
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v25r1"
>
>
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v25r2"

Revision 742010-03-02 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 368 to 368
 -- MarcoCattaneo - 27-Jan-2010

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1265016240" name="Environment.ppt" path="Environment.ppt" size="590336" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp53671" user="cattanem" version="11"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v24r7p2"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7p1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v25r1"

Revision 732010-02-10 - PatrickSKoppenburg

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 262 to 262
 
cmt broadcast "cmt config ; cmt make binclean ; cmt make"
  • Execute an executable within the environment of the current project
    cmt run gaudirun.py
Added:
>
>
Have a look at the options of gaudirun.py. Try
cmt run gaudirun.py -h
for help, or
cmt run gaudirun.py -v
for a verbose printout of all options.
  To release a new package in the LHCb framework it must be imported into SVN so that getpack can find it. Follow the instructions here.

Revision 722010-02-01 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 362 to 362
  -- MarcoCattaneo - 27-Jan-2010
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1254758780" name="Environment.ppt" path="Environment.ppt" size="602624" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp7950" user="cattanem" version="10"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1265016240" name="Environment.ppt" path="Environment.ppt" size="590336" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp53671" user="cattanem" version="11"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v24r7p2"

Revision 712010-01-27 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 263 to 263
 
  • Execute an executable within the environment of the current project
    cmt run gaudirun.py
Changed:
<
<
To release a new package in the LHCb framework it must be imported into CVS and registered so that getpack can find it. Follow the instructions here.
>
>
To release a new package in the LHCb framework it must be imported into SVN so that getpack can find it. Follow the instructions here.
 

Exercise 3

Line: 351 to 351
 
SetupProject Gaudi ROOT
echo $ROOTSYS
which root
You now have the environment to execute the Root application. The version that you will execute is the version compatible with the latest release of Gaudi
  • Now issue the commands:
Changed:
<
<
SetupProject Gaudi v19r3 ROOT
echo $ROOTSYS
which root
This time the version of Root that has been selected is the version compatible with Gaudi v19r3
>
>
SetupProject Gaudi v21r4 ROOT
echo $ROOTSYS
which root
This time the version of Root that has been selected is the version compatible with Gaudi v21r4
 
  • Finally, issue the commands:
Changed:
<
<
SetupProject Gaudi v19r3 ROOT -v 5.16.00
echo $ROOTSYS
which root
This time we have over-ridden the version of Root compatible with Gaudi v19r3, and selected explicitly a different version. This can be useful if you need to over-ride the version of an external library to use a different version from the one with which the application was released.
>
>
SetupProject Gaudi v21r4 ROOT -v 5.24.00
echo $ROOTSYS
which root
This time we have over-ridden the version of Root compatible with Gaudi v21r4, and selected explicitly a different version. This can be useful if you need to over-ride the version of an external library to use a different version from the one with which the application was released.
 

Exercise 8

CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.
Changed:
<
<
-- MarcoCattaneo - 01 Oct 2009
>
>
-- MarcoCattaneo - 27-Jan-2010
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1254758780" name="Environment.ppt" path="Environment.ppt" size="602624" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp7950" user="cattanem" version="10"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7"

Revision 702010-01-27 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 18 to 18
  These instructions have last been checked against the DaVinci v33r1 (and Gaudi v23r5) environment. Please use this version of DaVinci or a more recent version.
Changed:
<
<

Logging in to lx64slc5 (lxplus slc5 cluster)

>
>

Logging in to lxplus5 (lxplus slc5 cluster)

 Remote access to lxplus is via the ssh protocol. Open a connection using the command:
Changed:
<
<
ssh -X <username>@lx64slc5.cern.ch
>
>
ssh -X <username>@lxplus5.cern.ch
 The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config:
ForwardX11 yes
Line: 41 to 41
 
  • sh,bash,ksh,zsh: <script>.sh

LHCb software environment

Changed:
<
<
The LHCb software environment is set up by sourcing the script LbLogin.[c[sh. For local installations the script resides in the directory defined by the environment variable $MYSITEROOT. For an installation using AFS , such as lxplus, it resides in
>
>
The LHCb software environment is set up by sourcing the script LbLogin.[c]sh. For local installations the script resides in the directory defined by the environment variable $MYSITEROOT. For an installation using AFS , such as lxplus, it resides in
 
  • /afs/cern.ch/lhcb/software/releases/LBSCRIPTS/prod/InstallArea/scripts/LbLogin.[c]sh
LbLogin sets a number of environment variables relevant for working with LHCb software, including setting default PATH, LD_LIBRARY_PATH and PYTHONPATH variables. It also sources CMT.[c]sh, which performs the setup for the Configuration Management Tool (CMT), used in LHCb for building software and for environment setup.
Line: 64 to 64
 

Exercise 1

This is a simple exercise just to check your environment setup.
Changed:
<
<
  • Login to lx64slc5.cern.ch
>
>
  • Login to lxplus5.cern.ch
 
  • Check that X11 connections are enabled, for example by opening emacs:
    emacs &
  • Check the group associated with your account by giving the command:
Line: 100 to 100
 
  • options: job options associated with the package;
  • cmt: information for CMT processing;
  • doc: package documentation.
Changed:
<
<
Package development in LHCb is carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. With the standard LHCb environment, the repository is identified by the variable CVSROOT, and a user can obtain a copy of any package in the repository using the command:
>
>
Package development in LHCb is currently carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. A migration from CVS to Subversion (SVN) is under way and should be completed by the end of 2010. During the migration, a given package will be active in only one of the two repositories, not both.

With the standard LHCb environment, a user can obtain a copy of any package from the CVS or SVN repositories using the command:

 
getpack <package group>/<package> <version>
Changed:
<
<
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires ssh authentication, which is automatic on lxplus if you have a valid AFS token.
>
>
The appropriate repository is selected automatically by this tool. If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository and access to the SVN repository require ssh authentication, which is automatic on lxplus if you have a valid AFS token.
  New releases of projects are placed in the release area after testing. The standard LHCb environment includes the variable $LHCBRELEASES pointing to the AFS release area.
Changed:
<
<
Instructions for making package modifications and new packages available for inclusion in a release can be found in the documentation for Guidelines for CVS actions in LHCb. Web access is available to both the CVS repository and the release area.
>
>
Instructions for making package modifications and new packages available for inclusion in a release can be found in the documentation for Guidelines for CVS actions in LHCb and Guidelines for SVN actions in LHCb. Web access is available to both the CVS repository and SVN repository and to the release area.
 
Changed:
<
<
As soon as a package update is committed to CVS, it will be picked up by one of the nightly builds the next night. Nightly builds are used to test new software prior to it being officially released. The nightly build status can be viewed at http://cern.ch/lhcb-nightlies/cgi-bin/nightlies.py. Advanced users wishing to pick up the latest updates can run their software against one of the nightlies, see instructions in the LHCb nightlies documentation
>
>
As soon as a package update is committed to CVS or SVN, it will be picked up by one of the nightly builds the next night. Nightly builds are used to test new software prior to it being officially released. The nightly build status can be viewed at http://cern.ch/lhcb-nightlies/cgi-bin/nightlies.py. Advanced users wishing to pick up the latest updates can run their software against one of the nightlies, see instructions in the LHCb nightlies documentation
 

LHCb applications

The LHCb applications are projects that use the Gaudi framework to perform specific tasks. There is a project specific to, and with the same name as, each application. The main applications are:
Line: 361 to 363
 -- MarcoCattaneo - 01 Oct 2009

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1254758780" name="Environment.ppt" path="Environment.ppt" size="602624" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp7950" user="cattanem" version="10"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r3"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v24r2p3"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r7"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v24r7p2"

Revision 692009-10-05 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 360 to 360
  -- MarcoCattaneo - 01 Oct 2009
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1245056395" name="Environment.ppt" path="Environment.ppt" size="611840" stream="Environment.ppt" user="Main.MarcoCattaneo" version="10"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1254758780" name="Environment.ppt" path="Environment.ppt" size="602624" stream="Environment.ppt" tmpFilename="/usr/tmp/CGItemp7950" user="cattanem" version="10"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r3"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v24r2p3"

Revision 682009-10-01 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 358 to 358
 

Exercise 8

CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.
Changed:
<
<
-- MarcoCattaneo - 02 Dec 2008
>
>
-- MarcoCattaneo - 01 Oct 2009
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1245056395" name="Environment.ppt" path="Environment.ppt" size="611840" stream="Environment.ppt" user="Main.MarcoCattaneo" version="10"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r3"

Revision 672009-10-01 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 18 to 18
  These instructions have last been checked against the DaVinci v33r1 (and Gaudi v23r5) environment. Please use this version of DaVinci or a more recent version.
Changed:
<
<

Logging in to lxplus (slc5 cluster)

>
>

Logging in to lx64slc5 (lxplus slc5 cluster)

 Remote access to lxplus is via the ssh protocol. Open a connection using the command:
ssh -X <username>@lx64slc5.cern.ch
The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor.
Line: 64 to 64
 

Exercise 1

This is a simple exercise just to check your environment setup.
Changed:
<
<
  • Login to lxplus.
>
>
  • Login to lx64slc5.cern.ch
 
  • Check that X11 connections are enabled, for example by opening emacs:
    emacs &
  • Check the group associated with your account by giving the command:
Line: 285 to 285
 
  • Try some basic CMT commands:
    cmt show uses
    ls
    ls ..
    cmt config
    ls
    ls ..
  • Try creating some different types of files with emacs. Each time, make a small modification to the file and save it
Changed:
<
<
emacs ../doc/release.notes &
emacs ../src/MyAlg.h &
emacs ../src/MyAlg.cpp &
emacs ../src/MyPackage_dll.cpp &
>
>
emacs ../doc/release.notes &
emacs ../src/MyAlg.h &
emacs ../src/MyAlg.cpp &
 
  • Use CMT to compile the files you just created, and make a library out of them
Changed:
<
<
cmt make
ls ..
ls ../slc4_amd64_gcc34
ls ../$CMTCONFIG
>
>
cmt make
ls ..
ls ../x86_64-slc5-gcc43-opt
ls ../$CMTCONFIG
 
  • Similarly, make the debug version of the library (i.e. containing debug symbols for use with a debugger)
Changed:
<
<
setenv CMTCONFIG $CMTDEB
cmt make
ls ..
ls ../slc4_amd64_gcc34_dbg
ls ../$CMTCONFIG
>
>
setenv CMTCONFIG $CMTDEB
cmt make
ls ..
ls ../x86_64-slc5-gcc43-dbg
ls ../$CMTCONFIG
 

Running LHCb Applications

When executing an application, the following environment variables are very important:

Revision 662009-10-01 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 18 to 18
  These instructions have last been checked against the DaVinci v33r1 (and Gaudi v23r5) environment. Please use this version of DaVinci or a more recent version.
Changed:
<
<

Logging in to lxplus

>
>

Logging in to lxplus (slc5 cluster)

 Remote access to lxplus is via the ssh protocol. Open a connection using the command:
Changed:
<
<
ssh -X <username>@lxplus.cern.ch
>
>
ssh -X <username>@lx64slc5.cern.ch
 The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config:
ForwardX11 yes
Line: 65 to 65
 

Exercise 1

This is a simple exercise just to check your environment setup.
  • Login to lxplus.
Changed:
<
<
  • Check that X11 connections are enabled, for example by displaying a clock:
    xclock &
>
>
  • Check that X11 connections are enabled, for example by opening emacs:
    emacs &
 
  • Check the group associated with your account by giving the command:
    echo $GROUP
    For an account in the LHCb group the result should be z5.
Line: 108 to 108
  Instructions for making package modifications and new packages available for inclusion in a release can be found in the documentation for Guidelines for CVS actions in LHCb. Web access is available to both the CVS repository and the release area.
Changed:
<
<
As soon as a package update is committed to CVS, it will be picked up by one of the nightly builds the next night. Nightly builds are used to test new software prior to it being officially released. The nightly build status can be viewed at http://cern.ch/lhcb-nightlies/cgi-bin/nightlies.py. Advanced users wishing to pick up the latest updates can run their software against one of the nightlies, for example following the instructions in the DaVinci FAQ
>
>
As soon as a package update is committed to CVS, it will be picked up by one of the nightly builds the next night. Nightly builds are used to test new software prior to it being officially released. The nightly build status can be viewed at http://cern.ch/lhcb-nightlies/cgi-bin/nightlies.py. Advanced users wishing to pick up the latest updates can run their software against one of the nightlies, see instructions in the LHCb nightlies documentation
 

LHCb applications

The LHCb applications are projects that use the Gaudi framework to perform specific tasks. There is a project specific to, and with the same name as, each application. The main applications are:
Line: 361 to 361
 -- MarcoCattaneo - 02 Dec 2008

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1245056395" name="Environment.ppt" path="Environment.ppt" size="611840" stream="Environment.ppt" user="Main.MarcoCattaneo" version="10"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v23r1p1"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r3"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v24r2p3"

Revision 652009-07-03 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 333 to 333
 

Exercise 6

This exercise demonstrates an alternative method to opening a new window each time you wish to change the version of project you are working with. This method is recommended if you switch versions frequently, for example if you are comparing the results of a new release with a previous one.
  • In the existing window type
Changed:
<
<
env | grep DAVINCI
echo ${DAVINCIROOT}
>
>
env | grep DAVINCI
echo ${DAVINCIROOT}
 
  • Start a new terminal window, and execute the following commands:
    setenvDaVinci v33r1
    cd Phys/DaVinci/cmt
    cmt make
    which gaudirun.py
    echo ${DAVINCIROOT}
    cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py'
    env | grep DAVINCI
Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

Revision 642009-06-22 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->

Revision 632009-06-15 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 309 to 309
 

Exercise 4

In this exercise we just execute the released DaVinci application, with default job options
  • Start a new login shell, and execute the following commands:
Changed:
<
<
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci.py
>
>
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py
  The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the gaudirun.py command.
Line: 336 to 336
 
env | grep DAVINCI
echo ${DAVINCIROOT}
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci.py'
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci-Default.py'
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Line: 361 to 361
  -- MarcoCattaneo - 02 Dec 2008
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1244453577" name="Environment.ppt" path="Environment.ppt" size="608768" stream="Environment.ppt" user="Main.MarcoCattaneo" version="9"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r0"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v23r0p1"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1245056395" name="Environment.ppt" path="Environment.ppt" size="611840" stream="Environment.ppt" user="Main.MarcoCattaneo" version="10"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v23r1p1"

Revision 622009-06-15 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 362 to 362
 -- MarcoCattaneo - 02 Dec 2008

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1244453577" name="Environment.ppt" path="Environment.ppt" size="608768" stream="Environment.ppt" user="Main.MarcoCattaneo" version="9"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v23r1"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r0"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v23r0p1"

Revision 612009-06-08 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 41 to 41
 
  • sh,bash,ksh,zsh: <script>.sh

LHCb software environment

Changed:
<
<
For users logging on to lxplus with an account in the LHCb group (z5), two scripts are sourced automatically at startup:
  • /afs/cern.ch/group/z5/group_env.[c]sh
  • /afs/cern.ch/group/z5/group_login.[c]sh
The only action of the first group script is to source the script:
  • /afs/cern.ch/lhcb/scripts/lhcbsetup.[c]sh
This sets a number of environment variables, mainly identifying directories relevant for working with LHCb software, and creates some aliases. The main action of the second script is to source the script:
  • /afs/cern.ch/lhcb/scripts/CMT.[c]sh
This defines some additional environment variables and aliases, and performs the setup for the Configuration Management Tool (CMT), used in LHCb for building software and for environment setup.
>
>
The LHCb software environment is set up by sourcing the script LbLogin.[c[sh. For local installations the script resides in the directory defined by the environment variable $MYSITEROOT. For an installation using AFS , such as lxplus, it resides in
  • /afs/cern.ch/lhcb/software/releases/LBSCRIPTS/prod/InstallArea/scripts/LbLogin.[c]sh
LbLogin sets a number of environment variables relevant for working with LHCb software, including setting default PATH, LD_LIBRARY_PATH and PYTHONPATH variables. It also sources CMT.[c]sh, which performs the setup for the Configuration Management Tool (CMT), used in LHCb for building software and for environment setup.

For users logging on to lxplus with an account in the LHCb group (z5), the LbLogin script is sourced automatically at startup by one of the group login scripts, which are all equivalent:

  • /afs/cern.ch/group/z5/group_login.[c,z]sh
  • /afs/cern.ch/group/z5/group_[ba,tc,z]rc
Which script is executed depends on the type of shell, and on how the shell was created (e.g. ssh or spawned from an existing shell).
 
Deleted:
<
<
When working in a window in which the group login has not been executed (e.g. in a window started with xterm& on lxplus, or outside lxplus on a Linux machine where AFS is available) the standard LHCb environment may be set using:
source /afs/cern.ch/lhcb/scripts/lhcbsetup.[c]sh
source /afs/cern.ch/lhcb/scripts/CMT.[c]sh
 

LHCb flavour of emacs editor

Customisations to emacs designed to help LHCb users have been written, and are described in the LHCb emacs user guide. Even for users who prefer a different editor (vim, nedit, Joe's own editor, pico, nano, or other), the LHCb flavour of emacs is useful for creating skeleton algorithms and similar.

Revision 602009-06-08 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 364 to 364
 -- MarcoCattaneo - 02 Dec 2008

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1244453577" name="Environment.ppt" path="Environment.ppt" size="608768" stream="Environment.ppt" user="Main.MarcoCattaneo" version="9"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r4"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v22r1"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v21r1"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v23r1"

Revision 592009-06-08 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 363 to 363
  -- MarcoCattaneo - 02 Dec 2008
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1228727052" name="Environment.ppt" path="Environment.ppt" size="583168" stream="Environment.ppt" user="Main.MarcoCattaneo" version="8"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1244453577" name="Environment.ppt" path="Environment.ppt" size="608768" stream="Environment.ppt" user="Main.MarcoCattaneo" version="9"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r4"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v22r1"

Revision 582009-03-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 336 to 336
 This exercise demonstrates an alternative method to opening a new window each time you wish to change the version of project you are working with. This method is recommended if you switch versions frequently, for example if you are comparing the results of a new release with a previous one.
  • In the existing window type
    env | grep DAVINCI
Added:
>
>
echo ${DAVINCIROOT}
 
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
cmt run "gaudirun.py ../options/DaVinci.py"
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run 'gaudirun.py ${DAVINCIROOT}/options/DaVinci.py'
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 572009-03-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 337 to 337
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.py"
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
cmt run "gaudirun.py ../options/DaVinci.py"
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 562009-03-09 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 248 to 248
 
    • Build the package binaries:
      cmt make
      The output of the build operation is placed in a package sub-directory. The name of this sub-directory is given by the value of the environment variable CMTCONFIG.
Added:
>
>
    • Build several files in parallel if possible:
      cmt make -j
 
    • Delete the package binaries:
      cmt make binclean
    • Delete all generated files, including copies made to the project InstallArea

Revision 552009-03-09 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 309 to 309
 

Exercise 4

In this exercise we just execute the released DaVinci application, with default job options
  • Start a new login shell, and execute the following commands:
Changed:
<
<
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts
>
>
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci.py
  The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the gaudirun.py command.
Line: 335 to 335
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.py"
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 542009-03-09 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 361 to 361
 -- MarcoCattaneo - 02 Dec 2008

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1228727052" name="Environment.ppt" path="Environment.ppt" size="583168" stream="Environment.ppt" user="Main.MarcoCattaneo" version="8"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r3"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v21r0"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r4"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v22r1"

Revision 532009-03-04 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 104 to 104
 
  • doc: package documentation.
Package development in LHCb is carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. With the standard LHCb environment, the repository is identified by the variable CVSROOT, and a user can obtain a copy of any package in the repository using the command:
getpack <package group>/<package> <version>
Changed:
<
<
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires kerberos authentication (or ssh on some systems such as Windows or OSX). Kerberos access is automatic on lxplus, but for access over AFS from another machine a kerberos ticket must be obtained. This can be done using the command:
kinit <username>@cern.ch -tmp
or on some systems
kinit.krb <username>@cern.ch
where <username> is the username on lxplus, and the corresponding password will be requested.

Check what tokens you have and when they will expire with the command

tokens
or on some systems
tokens.krb
(These are usually actually the same command).
>
>
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires ssh authentication, which is automatic on lxplus if you have a valid AFS token.
  New releases of projects are placed in the release area after testing. The standard LHCb environment includes the variable $LHCBRELEASES pointing to the AFS release area.

Revision 522008-12-08 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 370 to 370
  -- MarcoCattaneo - 02 Dec 2008
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1228215346" name="Environment.ppt" path="Environment.ppt" size="593408" stream="Environment.ppt" user="Main.MarcoCattaneo" version="7"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1228727052" name="Environment.ppt" path="Environment.ppt" size="583168" stream="Environment.ppt" user="Main.MarcoCattaneo" version="8"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r3"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v21r0"

Revision 512008-12-02 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 116 to 116
 
tokens.krb
(These are usually actually the same command).
Changed:
<
<
New versions of packages, and new packages, are placed in the release area after testing, or may be available in the development area as works in progress. The standard LHCb environment includes the variables:
  • LHCBRELEASES: release area;
  • LHCBDEV: development area.
Instructions for making package modifications and new packages available from the release area can be found in the documentation for Guidelines for CVS actions in LHCb. Web access is available to both the CVS repository and the release area.
>
>
New releases of projects are placed in the release area after testing. The standard LHCb environment includes the variable $LHCBRELEASES pointing to the AFS release area.
 
Added:
>
>
Instructions for making package modifications and new packages available for inclusion in a release can be found in the documentation for Guidelines for CVS actions in LHCb. Web access is available to both the CVS repository and the release area.

As soon as a package update is committed to CVS, it will be picked up by one of the nightly builds the next night. Nightly builds are used to test new software prior to it being officially released. The nightly build status can be viewed at http://cern.ch/lhcb-nightlies/cgi-bin/nightlies.py. Advanced users wishing to pick up the latest updates can run their software against one of the nightlies, for example following the instructions in the DaVinci FAQ

 

LHCb applications

The LHCb applications are projects that use the Gaudi framework to perform specific tasks. There is a project specific to, and with the same name as, each application. The main applications are:
Line: 135 to 134
  Additional projects contain software that is shared by several applications. The main ones are:
  • LHCb: base classes and public include files
Added:
>
>
  • Online: framework extensions and components for running in the online environment
 
  • Lbcom: components common to all applications
  • Hlt: components for online (HLT) reconstruction
  • Rec: components for online (HLT) and offline reconstruction
Line: 150 to 150
 
  • Note the different project directories, and enter the project directory for any one of the projects.
  • Note the different project versions available, and move to the directory for the latest.
  • Note the different package groups, and have a look in two or more of these at what packages are available.
Changed:
<
<
  • Choose any two packages, and for each in turn: move to the directory for the latest version, look at which sub-directories are defined, and have a look at the files that are in each.
  • Look also at the development area:
    cd ${LHCBDEV}
>
>
  • Choose any two packages, and for each in turn look at which sub-directories are defined and have a look at the files that are in each.
 

Configuration Management Tool

CMT is used to specify the compilation and execution environment for packages within a project, the dependencies between projects and between packages, and how each package is built (for example, how to produce executables or libraries from source code). To allow this, a CMT package must have a cmt sub-directory containing a requirements file, where the relevant instructions are given. All LHCb packages developed in the Gaudi framework are CMT packages.
Line: 271 to 269
  Multiple commands need to be separated by semicolons and enclosed in inverted commas. This can be useful, for example, to force rebuilding of all used packages in the user's area:
cmt broadcast "cmt config ; cmt make binclean ; cmt make"
  • Execute an executable within the environment of the current project
Changed:
<
<
cmt run <myExec.exe>
>
>
cmt run gaudirun.py
  To release a new package in the LHCb framework it must be imported into CVS and registered so that getpack can find it. Follow the instructions here.
Line: 304 to 302
 
setenv CMTCONFIG $CMTDEB
cmt make
ls ..
ls ../slc4_amd64_gcc34_dbg
ls ../$CMTCONFIG

Running LHCb Applications

Changed:
<
<
When executing an application, the following two environment variables are very important:
  • PATH: search path for executables;
>
>
When executing an application, the following environment variables are very important:
  • PATH: search path for scripts and executables, e.g. gaudirun.py;
 
  • LD_LIBRARY_PATH: search path for shared libraries.
Added:
>
>
  • PYTHONPATH: search path for configurables
  The environment in which you build and run an application is fully determined by choosing which CMT project you wish to work with, and the value of the CMTPROJECTPATH environment variable.
Line: 327 to 326
 Notice also that you can keep any number of different job options files in your own area, each describing a different configuration of the application (e.g. different cuts), without having to rebuild the standard application. This is recommended if your analysis can be carried out simply by modifying job options (i.e. if you do not need to write your own C++ algorithms).

gaudirun.py is a generic Gaudi application written in python. It is used as main program for all LHCb applications. The specific behaviour of the application is defined by the options file(s) provided as argument(s). Options files can be written either in the old Gaudi native syntax (.opts) or using python syntax. The python syntax is recommended.

Deleted:
<
<
You would get exactly the same program behaviour by calling gaudirun.py instead of the DaVinci.exe executable (try it!):
 

Exercise 5

In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
Line: 335 to 333
 
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/cmt
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application. You could for example add the MyGroup/MyPackage that you created in Exercise 3. Note that the syntax is as follows:
    use <package name> <version> <package group>
Changed:
<
<
  • Build the application
>
>
  • Install the application
 
cmt make
  • Finally repeat the commands of Exercise 4 to run the application. As in Exercise 4 you can run the same executable from any directory, with any number of different options files
Line: 370 to 368
 

Exercise 8

CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.
Changed:
<
<
-- MarcoCattaneo - 09 Jun 2008
>
>
-- MarcoCattaneo - 02 Dec 2008
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1228215346" name="Environment.ppt" path="Environment.ppt" size="593408" stream="Environment.ppt" user="Main.MarcoCattaneo" version="7"
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r3"

Revision 502008-12-02 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 373 to 373
 -- MarcoCattaneo - 09 Jun 2008

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1228215346" name="Environment.ppt" path="Environment.ppt" size="593408" stream="Environment.ppt" user="Main.MarcoCattaneo" version="7"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r2"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v20r1"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r3"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v21r0"

Revision 492008-12-02 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 372 to 372
  -- MarcoCattaneo - 09 Jun 2008
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1221565043" name="Environment.ppt" path="Environment.ppt" size="577536" stream="Environment.ppt" user="Main.MarcoCattaneo" version="6"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1228215346" name="Environment.ppt" path="Environment.ppt" size="593408" stream="Environment.ppt" user="Main.MarcoCattaneo" version="7"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r2"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v20r1"

Revision 482008-11-26 - MatthewCharles

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 283 to 283
  The search path for CMT projects was set up when you logged in. It includes a User_release_area, the LHCb_release_area, the Gaudi_release_area and the LCG_release_area (for external software)
  • Create a CMT project directory in which to work.
    setenvDaVinci v33r1
Changed:
<
<
This command creates a directory ~cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
>
>
This command creates a directory ~/cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
 
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt
    The setenv<Project> command places you inside your new CMT project, and creates a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

    If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

  • Create a new package in your DaVinci_v33r1 project:
Changed:
<
<
cd ~cmtuser/DaVinci_v33r1
mkdir -p MyGroup/MyPackage/cmt
cd MyGroup/MyPackage/cmt
>
>
cd ~/cmtuser/DaVinci_v33r1
mkdir -p MyGroup/MyPackage/cmt
cd MyGroup/MyPackage/cmt
 
  • Create a cmt requirements file
    emacs requirements &
    Look at the generated file and add the line

Revision 472008-11-24 - MatthewCharles

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 94 to 94
 
  • Packages with related functionality are collected in groups (or are said to be placed under a hat). The purpose of package groups is simply to group together, in the directory tree, all packages that are related in some way (for example all event model packages under the /Event hat, or all Rich packages under the /Rich hat).
  • A project is a set of packages that are grouped together according to some functionality, for example all Gaudi packages (Gaudi project), most public LHCb header files and base class libraries (LHCb project), all reconstruction packages (Rec project), all packages specific to the simulation application (Gauss project). All packages within a given project are released as a single unit: changing just one package in a project implies a releasing a new version of the whole project. Choosing a given version of a project automatically selects a single version of each of the packages in the project.
Changed:
<
<
Projects and packages have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: <PROJECT>/<PROJECT>_<version>/<package group>/<package>/<package version>. For example
ls $LHCBRELEASES/DAVINCI/DAVINCI_v33r1/Phys/DaVinci/v33r1/
>
>
Projects and packages have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: <PROJECT>/<PROJECT>_<version>/<package group>/<package>. For example
ls $LHCBRELEASES/DAVINCI/DAVINCI_v33r1/Phys/DaVinci/
 Sub-directories typically found in an LHCb package include:
  • src: source code;
  • <package> (Sub-directory with same name as package): header files;
Line: 288 to 288
 
pwd
cat cmt/project.cmt
The setenv<Project> command places you inside your new CMT project, and creates a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

  • Create a new package in your DaVinci_v33r1 project:
Changed:
<
<
cd ~cmtuser/DaVinci_v33r1
mkdir -p MyGroup/MyPackage/v1r0/cmt
cd MyGroup/MyPackage/v1r0/cmt
>
>
cd ~cmtuser/DaVinci_v33r1
mkdir -p MyGroup/MyPackage/cmt
cd MyGroup/MyPackage/cmt
 
  • Create a cmt requirements file
    emacs requirements &
    Look at the generated file and add the line
Line: 332 to 332
 

Exercise 5

In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
Changed:
<
<
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
>
>
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/cmt
 
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application. You could for example add the MyGroup/MyPackage that you created in Exercise 3. Note that the syntax is as follows:
    use <package name> <version> <package group>
  • Build the application
Line: 347 to 347
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 462008-10-22 - AnatolySolomin

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 327 to 327
 Notice also that you can keep any number of different job options files in your own area, each describing a different configuration of the application (e.g. different cuts), without having to rebuild the standard application. This is recommended if your analysis can be carried out simply by modifying job options (i.e. if you do not need to write your own C++ algorithms).

gaudirun.py is a generic Gaudi application written in python. It is used as main program for all LHCb applications. The specific behaviour of the application is defined by the options file(s) provided as argument(s). Options files can be written either in the old Gaudi native syntax (.opts) or using python syntax. The python syntax is recommended.

Changed:
<
<
You would get exactly the same program behaviour by calling instead the DaVinci.exe executable (try it!):
>
>
You would get exactly the same program behaviour by calling gaudirun.py instead of the DaVinci.exe executable (try it!):
 

Exercise 5

In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.

Revision 452008-10-21 - AnatolySolomin

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 94 to 94
 
  • Packages with related functionality are collected in groups (or are said to be placed under a hat). The purpose of package groups is simply to group together, in the directory tree, all packages that are related in some way (for example all event model packages under the /Event hat, or all Rich packages under the /Rich hat).
  • A project is a set of packages that are grouped together according to some functionality, for example all Gaudi packages (Gaudi project), most public LHCb header files and base class libraries (LHCb project), all reconstruction packages (Rec project), all packages specific to the simulation application (Gauss project). All packages within a given project are released as a single unit: changing just one package in a project implies a releasing a new version of the whole project. Choosing a given version of a project automatically selects a single version of each of the packages in the project.
Changed:
<
<
Projects and packages have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: PROJECT/PROJECT_<version>/<package group>/<package>/<package version>. For example
>
>
Projects and packages have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: <PROJECT>/<PROJECT>_<version>/<package group>/<package>/<package version>. For example
 
ls $LHCBRELEASES/DAVINCI/DAVINCI_v33r1/Phys/DaVinci/v33r1/
Sub-directories typically found in an LHCb package include:
  • src: source code;

Revision 442008-09-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 372 to 372
  -- MarcoCattaneo - 09 Jun 2008
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1221209888" name="Environment.ppt" path="Environment.ppt" size="979968" stream="Environment.ppt" user="Main.MarcoCattaneo" version="5"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1221565043" name="Environment.ppt" path="Environment.ppt" size="577536" stream="Environment.ppt" user="Main.MarcoCattaneo" version="6"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r2"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v20r1"

Revision 432008-09-15 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 319 to 319
 

Exercise 4

In this exercise we just execute the released DaVinci application, with default job options
Changed:
<
<
  • Start a new terminal window, and execute the following commands:
>
>
  • Start a new login shell, and execute the following commands:
 
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts

The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the gaudirun.py command.

Revision 422008-09-12 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 282 to 282
 
echo $CMTPROJECTPATH
The search path for CMT projects was set up when you logged in. It includes a User_release_area, the LHCb_release_area, the Gaudi_release_area and the LCG_release_area (for external software)
  • Create a CMT project directory in which to work.
Changed:
<
<
SetupProject --build-env DaVinci v33r1
>
>
setenvDaVinci v33r1
  This command creates a directory ~cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt
Changed:
<
<
The SetupProject command, when called with the --build-env option, places you inside your new CMT project, and creates a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the SetupProject command, e.g. SetupProject --build-env Brunel. Information about CMT projects, including tips and tricks for working with them, can be found here

>
>
The setenv<Project> command places you inside your new CMT project, and creates a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

 
  • Create a new package in your DaVinci_v33r1 project:
    cd ~cmtuser/DaVinci_v33r1
    mkdir -p MyGroup/MyPackage/v1r0/cmt
    cd MyGroup/MyPackage/v1r0/cmt
  • Create a cmt requirements file
Line: 332 to 332
 

Exercise 5

In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
Changed:
<
<
SetupProject --build-env DaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
>
>
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
 
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application. You could for example add the MyGroup/MyPackage that you created in Exercise 3. Note that the syntax is as follows:
    use <package name> <version> <package group>
  • Build the application
Line: 347 to 347
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
SetupProject --build-env DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 412008-09-12 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 119 to 119
 New versions of packages, and new packages, are placed in the release area after testing, or may be available in the development area as works in progress. The standard LHCb environment includes the variables:
  • LHCBRELEASES: release area;
  • LHCBDEV: development area.
Changed:
<
<
Instructions for making package modifications and new packages available from the release area can be found in the documentation for How to use Gaudi under CMT.
>
>
Instructions for making package modifications and new packages available from the release area can be found in the documentation for Guidelines for CVS actions in LHCb.
 Web access is available to both the CVS repository and the release area.
Line: 127 to 127
 The LHCb applications are projects that use the Gaudi framework to perform specific tasks. There is a project specific to, and with the same name as, each application. The main applications are:
  • Gauss: event generation, using Pythia and EvtGen, and detector simulation based on Geant4;
  • Boole: simulation of detector response (digitisation)
Added:
>
>
  • Moore: high level trigger
 
  • Brunel: event reconstruction
  • DaVinci: event selection and data analysis
  • Panoramix: graphical display of detector and event information
Line: 281 to 282
 
echo $CMTPROJECTPATH
The search path for CMT projects was set up when you logged in. It includes a User_release_area, the LHCb_release_area, the Gaudi_release_area and the LCG_release_area (for external software)
  • Create a CMT project directory in which to work.
Changed:
<
<
setenvDaVinci v33r1
>
>
SetupProject --build-env DaVinci v33r1
  This command creates a directory ~cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt
Changed:
<
<
The setenvDaVinci v33r1 command placed you inside your new CMT project, and created a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

>
>
The SetupProject command, when called with the --build-env option, places you inside your new CMT project, and creates a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the SetupProject command, e.g. SetupProject --build-env Brunel. Information about CMT projects, including tips and tricks for working with them, can be found here

 
  • Create a new package in your DaVinci_v33r1 project:
    cd ~cmtuser/DaVinci_v33r1
    mkdir -p MyGroup/MyPackage/v1r0/cmt
    cd MyGroup/MyPackage/v1r0/cmt
  • Create a cmt requirements file
Line: 325 to 326
  Notice also that you can keep any number of different job options files in your own area, each describing a different configuration of the application (e.g. different cuts), without having to rebuild the standard application. This is recommended if your analysis can be carried out simply by modifying job options (i.e. if you do not need to write your own C++ algorithms).
Changed:
<
<
gaudirun.py is a generic Gaudi application written in python. You would get exactly the same program behaviour by calling instead the DaVinci.exe executable (try it!):
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
We recommend using gaudirun.py because it gives you access to additional functionality not available with the DaVinci.exe executable, in particular the possibility to use python syntax inside the job options files.
>
>
gaudirun.py is a generic Gaudi application written in python. It is used as main program for all LHCb applications. The specific behaviour of the application is defined by the options file(s) provided as argument(s). Options files can be written either in the old Gaudi native syntax (.opts) or using python syntax. The python syntax is recommended. You would get exactly the same program behaviour by calling instead the DaVinci.exe executable (try it!):
 

Exercise 5

In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
Changed:
<
<
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
>
>
SetupProject --build-env DaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
 
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application. You could for example add the MyGroup/MyPackage that you created in Exercise 3. Note that the syntax is as follows:
    use <package name> <version> <package group>
  • Build the application
Line: 347 to 347
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
>
>
SetupProject --build-env DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Line: 373 to 373
 -- MarcoCattaneo - 09 Jun 2008

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1221209888" name="Environment.ppt" path="Environment.ppt" size="979968" stream="Environment.ppt" user="Main.MarcoCattaneo" version="5"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r9"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r13"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v20r2"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v20r1"

Revision 402008-09-12 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 372 to 372
  -- MarcoCattaneo - 09 Jun 2008
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1213968791" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="978944" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="4"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1221209888" name="Environment.ppt" path="Environment.ppt" size="979968" stream="Environment.ppt" user="Main.MarcoCattaneo" version="5"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r9"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r13"

Revision 392008-09-09 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 309 to 309
  The environment in which you build and run an application is fully determined by choosing which CMT project you wish to work with, and the value of the CMTPROJECTPATH environment variable.
Changed:
<
<
The SetupProject script removes the need to set these variables explicitly. It uses CMT to fully define the run time enviroment for a given version of an LHCb application. Documentation on the setting of the run time enviroment in LHCb is available here
>
>
The SetupProject script removes the need to set these variables explicitly. It uses CMT to fully define the run time enviroment for a given version of an LHCb application. See also the SetupProject user guide and FAQ.
  Once the environment is set, the application is executed by simply typing the executable name, giving the name of a job options file as argument. The job options control what the application actually does when it runs. Controlling what happens when the application is run means knowing how to add new code and understanding the job options.

Revision 382008-07-10 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 45 to 45
 
  • /afs/cern.ch/group/z5/group_env.[c]sh
  • /afs/cern.ch/group/z5/group_login.[c]sh
The only action of the first group script is to source the script:
Changed:
<
<
  • /afs.cern.ch/lhcb/scripts/lhcbsetup.[c]sh
>
>
  • /afs/cern.ch/lhcb/scripts/lhcbsetup.[c]sh
 This sets a number of environment variables, mainly identifying directories relevant for working with LHCb software, and creates some aliases. The main action of the second script is to source the script:
Changed:
<
<
  • /afs.cern.ch/lhcb/scripts/CMT.[c]sh
>
>
  • /afs/cern.ch/lhcb/scripts/CMT.[c]sh
 This defines some additional environment variables and aliases, and performs the setup for the Configuration Management Tool (CMT), used in LHCb for building software and for environment setup.

When working in a window in which the group login has not been executed (e.g. in a window started with xterm& on lxplus, or outside lxplus on a Linux machine where AFS is available) the standard LHCb environment may be set using:

Changed:
<
<
source /afs.cern.ch/lhcb/scripts/lhcbsetup.[c]sh
source /afs.cern.ch/lhcb/scripts/CMT.[c]sh
>
>
source /afs/cern.ch/lhcb/scripts/lhcbsetup.[c]sh
source /afs/cern.ch/lhcb/scripts/CMT.[c]sh
 

LHCb flavour of emacs editor

Customisations to emacs designed to help LHCb users have been written, and are described in the LHCb emacs user guide. Even for users who prefer a different editor (vim, nedit, Joe's own editor, pico, nano, or other), the LHCb flavour of emacs is useful for creating skeleton algorithms and similar.

Revision 372008-06-23 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 102 to 102
 
  • options: job options associated with the package;
  • cmt: information for CMT processing;
  • doc: package documentation.
Changed:
<
<
Package development in LHCb is carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. With the standard LHCb environment, the repository is identified by the variable CVSROOT, and a user can obtain a copy of any package in the repository using the command:
>
>
Package development in LHCb is carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. With the standard LHCb environment, the repository is identified by the variable CVSROOT, and a user can obtain a copy of any package in the repository using the command:
 
getpack <package group>/<package> <version>
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires kerberos authentication (or ssh on some systems such as Windows or OSX). Kerberos access is automatic on lxplus, but for access over AFS from another machine a kerberos ticket must be obtained. This can be done using the command:
kinit <username>@cern.ch -tmp

Revision 362008-06-20 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 372 to 372
  -- MarcoCattaneo - 09 Jun 2008
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1205220542" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="977408" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="3"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1213968791" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="978944" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="4"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r9"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r13"

Revision 352008-06-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 347 to 347
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudipython.py
echo ${DAVINCIROOT}
cmt run gaudipython.py ${DAVINCIROOT}/options/DaVinci.opts
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudirun.py
echo ${DAVINCIROOT}
cmt run "gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts"
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 342008-06-13 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 257 to 257
  Note that when a copy of a package is obtained using getpack the package is configured automatically.
  • After configuration, Make commands can be used from the cmt directory:
    • Build the package binaries:
Changed:
<
<
gmake
>
>
cmt make
  The output of the build operation is placed in a package sub-directory. The name of this sub-directory is given by the value of the environment variable CMTCONFIG.
    • Delete the package binaries:
Changed:
<
<
gmake binclean
>
>
cmt make binclean
 
    • Delete all generated files, including copies made to the project InstallArea
Changed:
<
<
gmake clean
>
>
cmt make clean
 
  • Show all packages used by the current package:
    cmt show uses
  • Execute <shell command(s)> in cmt directory of current package and all used packages within the same project:
    cmt broadcast <shell command(s)>
    Multiple commands need to be separated by semicolons and enclosed in inverted commas. This can be useful, for example, to force rebuilding of all used packages in the user's area:
Changed:
<
<
cmt broadcast "cmt config ; gmake binclean ; gmake"
>
>
cmt broadcast "cmt config ; cmt make binclean ; cmt make"
 
  • Execute an executable within the environment of the current project
    cmt run <myExec.exe>
Line: 298 to 298
 
  • Try creating some different types of files with emacs. Each time, make a small modification to the file and save it
    emacs ../doc/release.notes &
    emacs ../src/MyAlg.h &
    emacs ../src/MyAlg.cpp &
    emacs ../src/MyPackage_dll.cpp &
  • Use CMT to compile the files you just created, and make a library out of them
Changed:
<
<
gmake
ls ..
ls ../slc4_amd64_gcc34
ls ../$CMTCONFIG
>
>
cmt make
ls ..
ls ../slc4_amd64_gcc34
ls ../$CMTCONFIG
 
  • Similarly, make the debug version of the library (i.e. containing debug symbols for use with a debugger)
Changed:
<
<
setenv CMTCONFIG $CMTDEB
gmake
ls ..
ls ../slc4_amd64_gcc34_dbg
ls ../$CMTCONFIG
>
>
setenv CMTCONFIG $CMTDEB
cmt make
ls ..
ls ../slc4_amd64_gcc34_dbg
ls ../$CMTCONFIG
 

Running LHCb Applications

When executing an application, the following two environment variables are very important:
Line: 336 to 336
 
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application. You could for example add the MyGroup/MyPackage that you created in Exercise 3. Note that the syntax is as follows:
    use <package name> <version> <package group>
  • Build the application
Changed:
<
<
make
>
>
cmt make
 
  • Finally repeat the commands of Exercise 4 to run the application. As in Exercise 4 you can run the same executable from any directory, with any number of different options files

Sometimes, it may be necessary to work with several different versions of an application. You should be very careful when you do this: if you have setup the environment for a given version of DaVinci using SetupProject, and then you move to a different version, you can end up with the environment variables pointing to the wrong version. At best you will execute the wrong version of the application or of your private package, but more likely you will get inexplicable crashes that are difficult to debug. If you need to switch versions, it is highly recommended that you open a new terminal window and repeat the steps of this exercise for the second version.

Line: 347 to 347
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
which gaudipython.py
echo ${DAVINCIROOT}
cmt run gaudipython.py ${DAVINCIROOT}/options/DaVinci.opts
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
cmt make
which gaudipython.py
echo ${DAVINCIROOT}
cmt run gaudipython.py ${DAVINCIROOT}/options/DaVinci.opts
env | grep DAVINCI
 Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 332008-06-09 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 319 to 319
 

Exercise 4

In this exercise we just execute the released DaVinci application, with default job options
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
SetupProject DaVinci v33r1
which DaVinci.exe
echo ${DAVINCIROOT}
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
>
>
SetupProject DaVinci v33r1
which gaudirun.py
echo ${DAVINCIROOT}
gaudirun.py ${DAVINCIROOT}/options/DaVinci.opts
 
Changed:
<
<
The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the DaVinci.exe command.
>
>
The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the gaudirun.py command.
  Notice also that you can keep any number of different job options files in your own area, each describing a different configuration of the application (e.g. different cuts), without having to rebuild the standard application. This is recommended if your analysis can be carried out simply by modifying job options (i.e. if you do not need to write your own C++ algorithms).
Added:
>
>
gaudirun.py is a generic Gaudi application written in python. You would get exactly the same program behaviour by calling instead the DaVinci.exe executable (try it!):
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
We recommend using gaudirun.py because it gives you access to additional functionality not available with the DaVinci.exe executable, in particular the possibility to use python syntax inside the job options files.
 

Exercise 5

In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
Line: 343 to 347
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
which DaVinci.exe
echo ${DAVINCIROOT}
cmt run ${DAVINCIROOT}/${CMTCONFIG}/DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
env | grep DAVINCI
Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variable required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
which gaudipython.py
echo ${DAVINCIROOT}
cmt run gaudipython.py ${DAVINCIROOT}/options/DaVinci.opts
env | grep DAVINCI
Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variables required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.
  The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.
Line: 366 to 370
 

Exercise 8

CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.
Changed:
<
<
-- MarcoCattaneo - 18 Jul 2007
>
>
-- MarcoCattaneo - 09 Jun 2008
 
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1205220542" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="977408" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="3"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r8"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r11"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r9"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r13"

Revision 322008-04-04 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 279 to 279
 This exercise introduces basic CMT functionality and demonstrates the use of the LHCb flavour of emacs to create different kinds of files.
  • Look at the value of the CMTPROJECTPATH environment variable
    echo $CMTPROJECTPATH
Changed:
<
<
The search path for CMT projects was set up when you logged in. It includes a |=User_release_area=|, the |=LHCb_release_area=|, the |=Gaudi_release_area=| and the |=LCG_release_area=| (for external software)
>
>
The search path for CMT projects was set up when you logged in. It includes a User_release_area, the LHCb_release_area, the Gaudi_release_area and the LCG_release_area (for external software)
  * Create a CMT project directory in which to work.
setenvDaVinci v33r1
This command creates a directory ~cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.

Revision 312008-03-11 - unknown

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->

Revision 302008-03-11 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 368 to 368
  -- MarcoCattaneo - 18 Jul 2007
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1205169401" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="977920" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="2"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1205220542" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="977408" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="3"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r8"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r11"

Revision 292008-03-10 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 368 to 368
  -- MarcoCattaneo - 18 Jul 2007
Changed:
<
<
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1192460530" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="976896" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="1"
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1205169401" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="977920" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="2"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r8"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r11"

Revision 282008-03-10 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->

Revision 272008-03-10 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 91 to 91
  Software in LHCb is developed in the context of CMT packages and CMT projects.
  • A package is a set of files, organised according to some directory structure, which provides some well-defined, circumscribed functionality. It is the basic unit of software development, meaning that all the files in a given package are tagged with the same version number and are released together. Changing just one file in the package implies releasing a new version of the whole package. Most LHCb packages contain code that can be compiled into one or more libraries.
Changed:
<
<
  • Packages with related functionality are collected in groups (or are said to be placed under a hat). The purpose of package groups is simply to group together, in the directory tree, all packages that are related in some way (for example all event model packages under the /Event hat, or all tracking packages under the /Tr hat).
>
>
  • Packages with related functionality are collected in groups (or are said to be placed under a hat). The purpose of package groups is simply to group together, in the directory tree, all packages that are related in some way (for example all event model packages under the /Event hat, or all Rich packages under the /Rich hat).
 
  • A project is a set of packages that are grouped together according to some functionality, for example all Gaudi packages (Gaudi project), most public LHCb header files and base class libraries (LHCb project), all reconstruction packages (Rec project), all packages specific to the simulation application (Gauss project). All packages within a given project are released as a single unit: changing just one package in a project implies a releasing a new version of the whole project. Choosing a given version of a project automatically selects a single version of each of the packages in the project.

Projects and packages have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: PROJECT/PROJECT_<version>/<package group>/<package>/<package version>. For example

Line: 104 to 104
 
  • doc: package documentation.
Package development in LHCb is carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. With the standard LHCb environment, the repository is identified by the variable CVSROOT, and a user can obtain a copy of any package in the repository using the command:
getpack <package group>/<package> <version>
Changed:
<
<
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires kerberos authentication. This is is automatic on lxplus, but for access over AFS from another machine a kerberos ticket must be obtained. This can be done using the command:
>
>
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires kerberos authentication (or ssh on some systems such as Windows or OSX). Kerberos access is automatic on lxplus, but for access over AFS from another machine a kerberos ticket must be obtained. This can be done using the command:
 
kinit <username>@cern.ch -tmp
or on some systems
kinit.krb <username>@cern.ch
Line: 177 to 177
 # a doc directory (for the release.notes file) # It may have: # a src directory for source files (.h, .cpp)
Changed:
<
<
# a options directory for job options (.opts)
>
>
# a options directory for job options (.opts, .py) # a python directory for python scripts and configurables
 # a directory with the same name as the package, containing include files that # should be visible outside the package (i.e. the public interface) branches cmt doc src options myPackage
Line: 276 to 277
 

Exercise 3

This exercise introduces basic CMT functionality and demonstrates the use of the LHCb flavour of emacs to create different kinds of files.
Added:
>
>
  • Look at the value of the CMTPROJECTPATH environment variable
    echo $CMTPROJECTPATH
    The search path for CMT projects was set up when you logged in. It includes a |=User_release_area=|, the |=LHCb_release_area=|, the |=Gaudi_release_area=| and the |=LCG_release_area=| (for external software)
 
  • Create a CMT project directory in which to work.
    setenvDaVinci v33r1
    This command creates a directory ~cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
Deleted:
<
<
  • Look at the value of the CMTPROJECTPATH environment variable
    echo $CMTPROJECTPATH
    The setenvDaVinci command also set up the search path for CMT projects
 
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt
    The setenvDaVinci v33r1 command placed you inside your new CMT project, and created a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

    If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

Line: 297 to 298
 
  • Try creating some different types of files with emacs. Each time, make a small modification to the file and save it
    emacs ../doc/release.notes &
    emacs ../src/MyAlg.h &
    emacs ../src/MyAlg.cpp &
    emacs ../src/MyPackage_dll.cpp &
  • Use CMT to compile the files you just created, and make a library out of them
Changed:
<
<
gmake
ls ..
ls ../slc4_ia32_gcc34
ls ../$CMTCONFIG
>
>
gmake
ls ..
ls ../slc4_amd64_gcc34
ls ../$CMTCONFIG
 
  • Similarly, make the debug version of the library (i.e. containing debug symbols for use with a debugger)
Changed:
<
<
setenv CMTCONFIG $CMTDEB
gmake
ls ..
ls ../slc4_ia32_gcc34_dbg
ls ../$CMTCONFIG
>
>
setenv CMTCONFIG $CMTDEB
gmake
ls ..
ls ../slc4_amd64_gcc34_dbg
ls ../$CMTCONFIG
 

Running LHCb Applications

When executing an application, the following two environment variables are very important:

Revision 262008-03-10 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 368 to 368
 -- MarcoCattaneo - 18 Jul 2007

META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1192460530" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="976896" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="1"
Changed:
<
<
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r4"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r5"
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r8"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r11"

Revision 252008-02-11 - AnatolySolomin

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 334 to 334
 
make
  • Finally repeat the commands of Exercise 4 to run the application. As in Exercise 4 you can run the same executable from any directory, with any number of different options files
Changed:
<
<
Sometimes, it may be necessary to work with several different versions of an application. You should be very careful when you do this: if you have setup the environment for a given version of DaVinci using setupProject, and then you move to a different version, you can end up with the environment variables pointing to the wrong version. At best you will execute the wrong version of the application or of your private package, but more likely you will get inexplicable crashes that are difficult to debug. If you need to switch versions, it is highly recommended that you open a new terminal window and repeat the steps of this exercise for the second version.
>
>
Sometimes, it may be necessary to work with several different versions of an application. You should be very careful when you do this: if you have setup the environment for a given version of DaVinci using SetupProject, and then you move to a different version, you can end up with the environment variables pointing to the wrong version. At best you will execute the wrong version of the application or of your private package, but more likely you will get inexplicable crashes that are difficult to debug. If you need to switch versions, it is highly recommended that you open a new terminal window and repeat the steps of this exercise for the second version.
 

Exercise 6

Line: 343 to 343
 
env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
    setenvDaVinci v33r1
    cd Phys/DaVinci/v33r1/cmt
    make
    which DaVinci.exe
    echo ${DAVINCIROOT}
    cmt run ${DAVINCIROOT}/${CMTCONFIG}/DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
    env | grep DAVINCI
Changed:
<
<
Notice that we didn't execute the setupProject script, and that consequently the environment does not "remember" any of the environment variable required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.
>
>
Notice that we didn't execute the SetupProject script, and that consequently the environment does not "remember" any of the environment variable required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.
  The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

Revision 242008-02-06 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 50 to 50
 
  • /afs.cern.ch/lhcb/scripts/CMT.[c]sh
This defines some additional environment variables and aliases, and performs the setup for the Configuration Management Tool (CMT), used in LHCb for building software and for environment setup.
Changed:
<
<
When not working on lxplus, but on a Linux machine where AFS is available, the standard LHCb environment may be set using:
>
>
When working in a window in which the group login has not been executed (e.g. in a window started with xterm& on lxplus, or outside lxplus on a Linux machine where AFS is available) the standard LHCb environment may be set using:
 
source /afs.cern.ch/lhcb/scripts/lhcbsetup.[c]sh
source /afs.cern.ch/lhcb/scripts/CMT.[c]sh

LHCb flavour of emacs editor

Revision 232007-11-07 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->

Revision 222007-10-15 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 10 to 10
 

Prerequisites

Changed:
<
<
Before doing these exercises, you should look at the slides of the "Overview of LHCb applications and software environment". The most recent version is that presented at CERN on 1st October 2007.
>
>
Before doing these exercises, you should look at the slides of the "Overview of LHCb applications and software environment" [.ppt] attached to this topic. Please feel free to update these slides if you modify them for a future tutorial session.
  The instructions for these exercises assume that they are being executed on the CERN Linux interactive cluster lxplus. However, except for some details of the interactive environment, the exercises should work on any machine where the LHCb software is installed.
Line: 367 to 367
  -- MarcoCattaneo - 18 Jul 2007
Added:
>
>
META FILEATTACHMENT attachment="Environment.ppt" attr="" comment="Slides: %22Overview of LHCb applications and software environment%22" date="1192460530" name="Environment.ppt" path="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" size="976896" stream="C:\Documents and Settings\cattanem\Desktop\Environment.ppt" user="Main.MarcoCattaneo" version="1"
 
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r4"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r5"

Revision 212007-10-02 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 328 to 328
 In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
    setenvDaVinci v33r1
    getpack Phys/DaVinci v33r1
    cd Phys/DaVinci/v33r1/cmt
Changed:
<
<
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application (you could for example add the !MyGroup/MyPackage that you created in Exercise 3.
>
>
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application. You could for example add the MyGroup/MyPackage that you created in Exercise 3. Note that the syntax is as follows:
    use <package name> <version> <package group>
 
  • Build the application
    make
  • Finally repeat the commands of Exercise 4 to run the application. As in Exercise 4 you can run the same executable from any directory, with any number of different options files

Revision 202007-10-01 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 280 to 280
 
setenvDaVinci v33r1
This command creates a directory ~cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
  • Look at the value of the CMTPROJECTPATH environment variable
Changed:
<
<
echo $CMPROJECTPATH
>
>
echo $CMTPROJECTPATH
  The setenvDaVinci command also set up the search path for CMT projects
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt

Revision 192007-09-27 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 367 to 367
 -- MarcoCattaneo - 18 Jul 2007

META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r4"
Changed:
<
<
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r4"
>
>
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r5"

Revision 182007-09-27 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 10 to 10
 

Prerequisites

Added:
>
>
Before doing these exercises, you should look at the slides of the "Overview of LHCb applications and software environment". The most recent version is that presented at CERN on 1st October 2007.
 The instructions for these exercises assume that they are being executed on the CERN Linux interactive cluster lxplus. However, except for some details of the interactive environment, the exercises should work on any machine where the LHCb software is installed.

To get an account on lxplus, please contact the LHCb secretariat. If you already have an lxplus account, but were previously working in another experiment, you should make sure that your account is registered as an LHCb account, in afs group z5 (see Exercise 1).

Revision 172007-09-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 176 to 176
 # It may have: # a src directory for source files (.h, .cpp) # a options directory for job options (.opts)
Changed:
<
<
branches cmt doc src options
>
>
# a directory with the same name as the package, containing include files that # should be visible outside the package (i.e. the public interface) branches cmt doc src options myPackage
  #================================================================== # The following command specifies packages which the current package
Line: 202 to 204
 # Define link options and environment variables for loading linker library apply_pattern linker_library library=myLib
Added:
>
>
# Make the public include files visible to the whole project (i.e. copy them to the InstallArea) apply_pattern install_more_includes more=myPackage

 #================================================================== # The following commands define symbols (variables and aliases). # They consist of a keyword followed by a symbol name, and possibly by a value.

Revision 162007-09-24 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 328 to 328
  Sometimes, it may be necessary to work with several different versions of an application. You should be very careful when you do this: if you have setup the environment for a given version of DaVinci using setupProject, and then you move to a different version, you can end up with the environment variables pointing to the wrong version. At best you will execute the wrong version of the application or of your private package, but more likely you will get inexplicable crashes that are difficult to debug. If you need to switch versions, it is highly recommended that you open a new terminal window and repeat the steps of this exercise for the second version.
Added:
>
>
 

Exercise 6

This exercise demonstrates an alternative method to opening a new window each time you wish to change the version of project you are working with. This method is recommended if you switch versions frequently, for example if you are comparing the results of a new release with a previous one.
  • In the existing window type
Line: 359 to 360
 -- MarcoCattaneo - 18 Jul 2007

META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r4"
Changed:
<
<
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r3"
>
>
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r4"

Revision 152007-08-01 - VanyaBelyaev

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 19 to 19
 

Logging in to lxplus

Remote access to lxplus is via the ssh protocol. Open a connection using the command:
ssh -X <username>@lxplus.cern.ch
Changed:
<
<
The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config:
>
>
The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config:
 
ForwardX11 yes
Added:
>
>
Some sites require trusted X11 forwarding, in this case it is not enough to have -X option, the option -Y is needed or the following line in ${HOME}/.ssh/config:
ForwardX11Trusted yes
 

Choice of shell

By default, accounts for LHCb users on lxplus are configured to use the tcsh shell, an enhanced version of csh, but LHCb setup scripts are also available for the Bourne family of shells: sh, bash, ksh, zsh. There are subtle and not-so-subtle differences in the functionality of the different shells, and for scripting there are major differences between (t)csh and Bourne-type shells. A useful short summary can be found in:

Revision 142007-07-31 - VanyaBelyaev

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 124 to 124
 
  • Brunel: event reconstruction
  • DaVinci: event selection and data analysis
  • Panoramix: graphical display of detector and event information
Added:
>
>
  • Bender: python-based physics analysis
  Additional projects contain software that is shared by several applications. The main ones are:
  • LHCb: base classes and public include files

Revision 132007-07-27 - VanyaBelyaev

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 316 to 316
 In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
    setenvDaVinci v33r1
    getpack Phys/DaVinci v33r1
    cd Phys/DaVinci/v33r1/cmt
Changed:
<
<
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application (you could for example add the !MyGroup/MyPackage that you created in Exercise 3.
>
>
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application (you could for example add the !MyGroup/MyPackage that you created in Exercise 3.
 
  • Build the application
    make
Changed:
<
<
  • Finally repeat the commands of Exercise 4 to run the application. As in Exercise 4 you can run the same executable from any directory, with any number of different options files
>
>
  • Finally repeat the commands of Exercise 4 to run the application. As in Exercise 4 you can run the same executable from any directory, with any number of different options files
  Sometimes, it may be necessary to work with several different versions of an application. You should be very careful when you do this: if you have setup the environment for a given version of DaVinci using setupProject, and then you move to a different version, you can end up with the environment variables pointing to the wrong version. At best you will execute the wrong version of the application or of your private package, but more likely you will get inexplicable crashes that are difficult to debug. If you need to switch versions, it is highly recommended that you open a new terminal window and repeat the steps of this exercise for the second version.

Revision 122007-07-27 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 261 to 261
  To release a new package in the LHCb framework it must be imported into CVS and registered so that getpack can find it. Follow the instructions here.
Added:
>
>
 

Exercise 3

This exercise introduces basic CMT functionality and demonstrates the use of the LHCb flavour of emacs to create different kinds of files.
  • Create a CMT project directory in which to work.
Line: 301 to 302
  In the remaining exercises of this tutorial we will use predefined job options files, and concentrate on different use cases for running applications in the LHCb environment.
Added:
>
>
 

Exercise 4

In this exercise we just execute the released DaVinci application, with default job options
  • Start a new terminal window, and execute the following commands:
    SetupProject DaVinci v33r1
    which DaVinci.exe
    echo ${DAVINCIROOT}
    DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
Added:
>
>
The SetupProject command sets up all the necessary environment to run the application. Notice that you can execute these commands from any directory. The job output goes to your current directory, so you should choose a sensible current directory. Once you have chosen a version and set up the enviroment, the behaviour of the application is determined by the job options file that you supply as the argument of the DaVinci.exe command.

Notice also that you can keep any number of different job options files in your own area, each describing a different configuration of the application (e.g. different cuts), without having to rebuild the standard application. This is recommended if your analysis can be carried out simply by modifying job options (i.e. if you do not need to write your own C++ algorithms).

 

Exercise 5

Changed:
<
<
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
SetupProject DaVinci
which DaVinci.exe
echo ${DAVINCIROOT}
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
>
>
In this exercise we address the case where you also need to modify the application executable, typically by adding your own component library package.
  • Set up the build environment for DaVinci v33r1 and get your version of the application
    setenvDaVinci v33r1
    getpack Phys/DaVinci v33r1
    cd Phys/DaVinci/v33r1/cmt
  • At this point you could modify the requirements file to add your own package to the list of packages to be accessed by the application (you could for example add the !MyGroup/MyPackage that you created in Exercise 3.
  • Build the application
    make
  • Finally repeat the commands of Exercise 4 to run the application. As in Exercise 4 you can run the same executable from any directory, with any number of different options files

Sometimes, it may be necessary to work with several different versions of an application. You should be very careful when you do this: if you have setup the environment for a given version of DaVinci using setupProject, and then you move to a different version, you can end up with the environment variables pointing to the wrong version. At best you will execute the wrong version of the application or of your private package, but more likely you will get inexplicable crashes that are difficult to debug. If you need to switch versions, it is highly recommended that you open a new terminal window and repeat the steps of this exercise for the second version.

 

Exercise 6

Added:
>
>
This exercise demonstrates an alternative method to opening a new window each time you wish to change the version of project you are working with. This method is recommended if you switch versions frequently, for example if you are comparing the results of a new release with a previous one.
 
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
    setenvDaVinci v33r1
    cd Phys/DaVinci/v33r1/cmt
    make
    which DaVinci.exe
    echo ${DAVINCIROOT}
    cmt run ${DAVINCIROOT}/${CMTCONFIG}/DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
    env | grep DAVINCI
Added:
>
>
Notice that we didn't execute the setupProject script, and that consequently the environment does not "remember" any of the environment variable required to run the application. The cmt run command executes the application inside its own shell which is configured according to the environment and requirements file of the directory from which you are issuing the command. In contrast to Exercises 4 and 5, here you have to execute the application from the directory that contains the requirements of the application.

The advantage of this method is that now you can switch to a different project, containing a different version of the application (or even a different application) and simply re-issue the cmt run command to execute the new application, without having to worry about opening a new window and setting up a new environment.

 

Exercise 7

Changed:
<
<
  • Start a new terminal window, and execute the following commands:
    which root
    SetupProject Gaudi ROOT
    which root
    SetupProject Gaudi v19r3 ROOT
>
>
Another use of SetupProject is to give access to software external to LHCb. In this exercise we see how to set up the environment for the Root application
  • Start a new terminal window, and issue the following command:
    which root
    The Root application is not accessible in the default lxplus login environment
  • Now issue the commands:
    SetupProject Gaudi ROOT
    echo $ROOTSYS
    which root
    You now have the environment to execute the Root application. The version that you will execute is the version compatible with the latest release of Gaudi
  • Now issue the commands:
    SetupProject Gaudi v19r3 ROOT
    echo $ROOTSYS
    which root
    This time the version of Root that has been selected is the version compatible with Gaudi v19r3
  • Finally, issue the commands:
    SetupProject Gaudi v19r3 ROOT -v 5.16.00
    echo $ROOTSYS
    which root
    This time we have over-ridden the version of Root compatible with Gaudi v19r3, and selected explicitly a different version. This can be useful if you need to over-ride the version of an external library to use a different version from the one with which the application was released.
 

Exercise 8

Changed:
<
<
This exercise will show how to use the $LHCBDEV area
>
>
CMT projects are very powerful tool for software development. You can find out more by reading the instructions for working with CMT install areas.
  -- MarcoCattaneo - 18 Jul 2007

Revision 112007-07-27 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 306 to 306
 
  • Start a new terminal window, and execute the following commands:
    SetupProject DaVinci v33r1
    which DaVinci.exe
    echo ${DAVINCIROOT}
    DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts

Exercise 5

Changed:
<
<
DaVinciEnv v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
SetupProject DaVinci
which DaVinci.exe
echo ${DAVINCIROOT}
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
>
>
setenvDaVinci v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
SetupProject DaVinci
which DaVinci.exe
echo ${DAVINCIROOT}
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
 

Exercise 6

  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
DaVinciEnv v33r1
cd Phys/DaVinci/v33r1/cmt
make
which DaVinci.exe
echo ${DAVINCIROOT}
cmt run ${DAVINCIROOT}/${CMTCONFIG}/DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
env | grep DAVINCI
>
>
setenvDaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
which DaVinci.exe
echo ${DAVINCIROOT}
cmt run ${DAVINCIROOT}/${CMTCONFIG}/DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
env | grep DAVINCI
 

Exercise 7

  • Start a new terminal window, and execute the following commands:

Revision 102007-07-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
Line: 304 to 304
 

Exercise 4

In this exercise we just execute the released DaVinci application, with default job options
  • Start a new terminal window, and execute the following commands:
Changed:
<
<
SetupProject DaVinci
which DaVinci.exe
echo ${DAVINCIROOT}
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
>
>
SetupProject DaVinci v33r1
which DaVinci.exe
echo ${DAVINCIROOT}
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
 

Exercise 5

Added:
>
>
DaVinciEnv v33r1
getpack Phys/DaVinci v33r1
cd Phys/DaVinci/v33r1/cmt
make
SetupProject DaVinci
which DaVinci.exe
echo ${DAVINCIROOT}
DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
 

Exercise 6

Added:
>
>
  • In the existing window type
    env | grep DAVINCI
  • Start a new terminal window, and execute the following commands:
    DaVinciEnv v33r1
    cd Phys/DaVinci/v33r1/cmt
    make
    which DaVinci.exe
    echo ${DAVINCIROOT}
    cmt run ${DAVINCIROOT}/${CMTCONFIG}/DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
    env | grep DAVINCI
 

Exercise 7

Added:
>
>
  • Start a new terminal window, and execute the following commands:
    which root
    SetupProject Gaudi ROOT
    which root
    SetupProject Gaudi v19r3 ROOT
 

Exercise 8

Added:
>
>
This exercise will show how to use the $LHCBDEV area
  -- MarcoCattaneo - 18 Jul 2007

Revision 92007-07-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"
Added:
>
>
<!-- Note to editors of this page: The following TWiki Variables are defined for this page: GAUDIVERSION and DAVINCIVERSION -->
<!-- They correspond to the last version for which these instructions have been verified, and should be consistent with each other -->
<!-- To change their value, exit edit and go to "More topic actions" -> "Edit settings" -->
 

LHCb Software Training: Basics

This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
Line: 9 to 14
  To get an account on lxplus, please contact the LHCb secretariat. If you already have an lxplus account, but were previously working in another experiment, you should make sure that your account is registered as an LHCb account, in afs group z5 (see Exercise 1).
Changed:
<
<
These instructions have last been checked against the DaVinci v19r3 (and Gaudi v19r4) environment. Please use this version of DaVinci or a more recent version.
>
>
These instructions have last been checked against the DaVinci v33r1 (and Gaudi v23r5) environment. Please use this version of DaVinci or a more recent version.
 

Logging in to lxplus

Remote access to lxplus is via the ssh protocol. Open a connection using the command:
Line: 84 to 89
 
  • A project is a set of packages that are grouped together according to some functionality, for example all Gaudi packages (Gaudi project), most public LHCb header files and base class libraries (LHCb project), all reconstruction packages (Rec project), all packages specific to the simulation application (Gauss project). All packages within a given project are released as a single unit: changing just one package in a project implies a releasing a new version of the whole project. Choosing a given version of a project automatically selects a single version of each of the packages in the project.

Projects and packages have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: PROJECT/PROJECT_<version>/<package group>/<package>/<package version>. For example

Changed:
<
<
ls $LHCBRELEASES/DAVINCI/DAVINCI_v19r3/Phys/DaVinci/v19r3/
>
>
ls $LHCBRELEASES/DAVINCI/DAVINCI_v33r1/Phys/DaVinci/v33r1/
 Sub-directories typically found in an LHCb package include:
  • src: source code;
  • <package> (Sub-directory with same name as package): header files;
Line: 256 to 261
  To release a new package in the LHCb framework it must be imported into CVS and registered so that getpack can find it. Follow the instructions here.
Deleted:
<
<
When executing an application, the following two environment variables are very important:
  • PATH: search path for executables;
  • LD_LIBRARY_PATH: search path for shared libraries.
CMT (and the scripts associated to it, as will be seen in the next exercises) remove the need to set these variables explicitly. The environment in which you build and run an application is fully determined by choosing which CMT project you wish to work with, and the value of the CMTPROJECTPATH environment variable.
 

Exercise 3

This exercise introduces basic CMT functionality and demonstrates the use of the LHCb flavour of emacs to create different kinds of files.
  • Create a CMT project directory in which to work.
Changed:
<
<
setenvDaVinci v19r3
This command creates a directory ~cmtuser/DaVinci_v19r3, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
  • Look at the value of CMTPROJECTPATH
>
>
setenvDaVinci v33r1
This command creates a directory ~cmtuser/DaVinci_v33r1, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
  • Look at the value of the CMTPROJECTPATH environment variable
 
echo $CMPROJECTPATH
The setenvDaVinci command also set up the search path for CMT projects
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt
Changed:
<
<
The setenvDaVinci v19r3 command placed you inside your new CMT project, and created a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v19r3 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel v31r7. Information about CMT projects, including tips and tricks for working with them, can be found here

  • Create a new package in your DaVinci_v19r3 project:
    cd ~cmtuser/DaVinci_v19r3
    mkdir -p MyGroup/MyPackage/v1r0/cmt
    cd MyGroup/MyPackage/v1r0/cmt
>
>
The setenvDaVinci v33r1 command placed you inside your new CMT project, and created a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v33r1 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel. Information about CMT projects, including tips and tricks for working with them, can be found here

  • Create a new package in your DaVinci_v33r1 project:
    cd ~cmtuser/DaVinci_v33r1
    mkdir -p MyGroup/MyPackage/v1r0/cmt
    cd MyGroup/MyPackage/v1r0/cmt
 
  • Create a cmt requirements file
    emacs requirements &
    Look at the generated file and add the line
Line: 288 to 288
 
  • Similarly, make the debug version of the library (i.e. containing debug symbols for use with a debugger)
    setenv CMTCONFIG $CMTDEB
    gmake
    ls ..
    ls ../slc4_ia32_gcc34_dbg
    ls ../$CMTCONFIG
Deleted:
<
<

Exercise 4

 

Running LHCb Applications

Added:
>
>
When executing an application, the following two environment variables are very important:
  • PATH: search path for executables;
  • LD_LIBRARY_PATH: search path for shared libraries.

The environment in which you build and run an application is fully determined by choosing which CMT project you wish to work with, and the value of the CMTPROJECTPATH environment variable.

The SetupProject script removes the need to set these variables explicitly. It uses CMT to fully define the run time enviroment for a given version of an LHCb application. Documentation on the setting of the run time enviroment in LHCb is available here

Once the environment is set, the application is executed by simply typing the executable name, giving the name of a job options file as argument. The job options control what the application actually does when it runs. Controlling what happens when the application is run means knowing how to add new code and understanding the job options.

In the remaining exercises of this tutorial we will use predefined job options files, and concentrate on different use cases for running applications in the LHCb environment.

Exercise 4

In this exercise we just execute the released DaVinci application, with default job options
  • Start a new terminal window, and execute the following commands:
    SetupProject DaVinci
    which DaVinci.exe
    echo ${DAVINCIROOT}
    DaVinci.exe ${DAVINCIROOT}/options/DaVinci.opts
 

Exercise 5

Exercise 6

Exercise 7

Exercise 8

-- MarcoCattaneo - 18 Jul 2007 \ No newline at end of file

Added:
>
>
META PREFERENCE name="GAUDIVERSION" title="GAUDIVERSION" type="Set" value="v19r4"
META PREFERENCE name="DAVINCIVERSION" title="DAVINCIVERSION" type="Set" value="v19r3"

Revision 82007-07-25 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
Line: 266 to 266
 
  • Create a CMT project directory in which to work.
    setenvDaVinci v19r3
    This command creates a directory ~cmtuser/DaVinci_v19r3, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
Added:
>
>
  • Look at the value of CMTPROJECTPATH
    echo $CMPROJECTPATH
    The setenvDaVinci command also set up the search path for CMT projects
 
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt
Changed:
<
<
The setenvDaVinci v19r3 command placed you inside your new CMT project, and created a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v19r3 project. If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel v31r7. Information about CMT projects, including tips and tricks for working with them, can be found here
>
>
The setenvDaVinci v19r3 command placed you inside your new CMT project, and created a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v19r3 project, which is found somewhere on the CMTPROJECTPATH (look for it!).

If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel v31r7. Information about CMT projects, including tips and tricks for working with them, can be found here

 
  • Create a new package in your DaVinci_v19r3 project:
    cd ~cmtuser/DaVinci_v19r3
    mkdir -p MyGroup/MyPackage/v1r0/cmt
    cd MyGroup/MyPackage/v1r0/cmt
  • Create a cmt requirements file

Revision 72007-07-24 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
Line: 113 to 113
 

LHCb applications

Changed:
<
<
The LHCb applications are projects that use the Gaudi framework to perform specific tasks. The main applications are:
>
>
The LHCb applications are projects that use the Gaudi framework to perform specific tasks. There is a project specific to, and with the same name as, each application. The main applications are:
 
  • Gauss: event generation, using Pythia and EvtGen, and detector simulation based on Geant4;
  • Boole: simulation of detector response (digitisation)
  • Brunel: event reconstruction
  • DaVinci: event selection and data analysis
  • Panoramix: graphical display of detector and event information
Changed:
<
<
There is a project specific to, and with the same name as, each application. Additional projects are shared across applications. The main ones are:
>
>
Additional projects contain software that is shared by several applications. The main ones are:
  * LHCb: base classes and public include files
Changed:
<
<
* Lbcom: * Rec: * Phys: * Analysis:
>
>
  • Lbcom: components common to all applications
  • Hlt: components for online (HLT) reconstruction
  • Rec: components for online (HLT) and offline reconstruction
  • Phys: components for online (HLT) and offline analysis
  • Analysis: components for offline analysis
 

Exercise 2

Line: 140 to 142
 
cd ${LHCBDEV}

Configuration Management Tool

Changed:
<
<
CMT is used to specify the compilation and execution environment for packages within a project, and how each package is built (for example, how to produce executables or libraries from source code). To allow this, a CMT package must have a cmt sub-directory containing a requirements file, where the relevant instructions are given. All LHCb packages developed in the Gaudi framework are CMT packages.
>
>
CMT is used to specify the compilation and execution environment for packages within a project, the dependencies between projects and between packages, and how each package is built (for example, how to produce executables or libraries from source code). To allow this, a CMT package must have a cmt sub-directory containing a requirements file, where the relevant instructions are given. All LHCb packages developed in the Gaudi framework are CMT packages.
  For a package with name myPackage, CMT itself defines an environment variable MYPACKAGEROOT that contains the package location.

Revision 62007-07-24 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
Line: 78 to 78
 

Organisation of LHCb software

LHCb software is based on a framework called Gaudi. This framework provides functionality useful in a wide range of contexts, such as file access, histogramming, message printing, and run-time configuration. The run-time configuration is based on job options.
Changed:
<
<
Software in LHCb is developed in the context of packages. Here, a package is essentially a set of files, organised according to some directory structure, and providing some well-defined, circumscribed functionality. Most LHCb packages contain code that can be compiled into (shared) libraries. Packages with related functionality are collected in groups (or are said to be placed under a hat), and package groups are arranged in projects. Projects and packages (but not package groups), have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: PROJECT/PROJECT_<version>/<package group>/<package>/<package version>. For example
>
>
Software in LHCb is developed in the context of CMT packages and CMT projects.
  • A package is a set of files, organised according to some directory structure, which provides some well-defined, circumscribed functionality. It is the basic unit of software development, meaning that all the files in a given package are tagged with the same version number and are released together. Changing just one file in the package implies releasing a new version of the whole package. Most LHCb packages contain code that can be compiled into one or more libraries.
  • Packages with related functionality are collected in groups (or are said to be placed under a hat). The purpose of package groups is simply to group together, in the directory tree, all packages that are related in some way (for example all event model packages under the /Event hat, or all tracking packages under the /Tr hat).
  • A project is a set of packages that are grouped together according to some functionality, for example all Gaudi packages (Gaudi project), most public LHCb header files and base class libraries (LHCb project), all reconstruction packages (Rec project), all packages specific to the simulation application (Gauss project). All packages within a given project are released as a single unit: changing just one package in a project implies a releasing a new version of the whole project. Choosing a given version of a project automatically selects a single version of each of the packages in the project.

Projects and packages have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: PROJECT/PROJECT_<version>/<package group>/<package>/<package version>. For example

 
ls $LHCBRELEASES/DAVINCI/DAVINCI_v19r3/Phys/DaVinci/v19r3/
Sub-directories typically found in an LHCb package include:
  • src: source code;
Line: 89 to 94
 Package development in LHCb is carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. With the standard LHCb environment, the repository is identified by the variable CVSROOT, and a user can obtain a copy of any package in the repository using the command:
getpack <package group>/<package> <version>
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires kerberos authentication. This is is automatic on lxplus, but for access over AFS from another machine a kerberos ticket must be obtained. This can be done using the command:
Changed:
<
<
klog <username>@cern.ch -tmp
>
>
kinit <username>@cern.ch -tmp
 or on some systems
Changed:
<
<
klog.krb <username>@cern.ch
>
>
kinit.krb <username>@cern.ch
 where <username> is the username on lxplus, and the corresponding password will be requested.

Check what tokens you have and when they will expire with the command

Line: 108 to 113
 

LHCb applications

Changed:
<
<
The LHCb applications are sets of packages used within the Gaudi framework to perform specific tasks. The main applications are:
>
>
The LHCb applications are projects that use the Gaudi framework to perform specific tasks. The main applications are:
 
Changed:
<
<
  • Boole: simulation of detector response (digitisation);
  • Brunel: event reconstruction;
  • DaVinci: event selection and data analysis;
  • Panoramix: graphical display of detector and event information.
There is a project specific to, and with the same name as, each application. Additional projects are shared across applications.
>
>
  • Boole: simulation of detector response (digitisation)
  • Brunel: event reconstruction
  • DaVinci: event selection and data analysis
  • Panoramix: graphical display of detector and event information
There is a project specific to, and with the same name as, each application. Additional projects are shared across applications. The main ones are: * LHCb: base classes and public include files * Lbcom: * Rec: * Phys: * Analysis:
 

Exercise 2

This exercise is designed to give you some familiarity with the LHCb software organisation. It's fairly open-ended, in that you could spend a very long time exploring all of the LHCb packages. Until you're trying to find something - which is when knowing the organisation is a big help - it's probably not useful to spend more than 5-10 minutes looking around.
Line: 133 to 144
  For a package with name myPackage, CMT itself defines an environment variable MYPACKAGEROOT that contains the package location.
Deleted:
<
<
In the context of environment setup, there are two path variables that tend to be very important:
  • PATH: search path for executables;
  • LD_LIBRARY_PATH: search path for shared libraries.
 The full set of commands that can be used in a requirements file is described in the CMT manual. Some of the most useful commands are shown below. |
# Lines beginning with the symbol # are treated as comments.

Line: 246 to 254
  To release a new package in the LHCb framework it must be imported into CVS and registered so that getpack can find it. Follow the instructions here.
Added:
>
>
When executing an application, the following two environment variables are very important:
  • PATH: search path for executables;
  • LD_LIBRARY_PATH: search path for shared libraries.
CMT (and the scripts associated to it, as will be seen in the next exercises) remove the need to set these variables explicitly. The environment in which you build and run an application is fully determined by choosing which CMT project you wish to work with, and the value of the CMTPROJECTPATH environment variable.
 

Exercise 3

This exercise introduces basic CMT functionality and demonstrates the use of the LHCb flavour of emacs to create different kinds of files.
  • Create a CMT project directory in which to work.

Revision 52007-07-19 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
Line: 13 to 13
 

Logging in to lxplus

Remote access to lxplus is via the ssh protocol. Open a connection using the command:
Changed:
<
<
ssh -X <username>@lxplus.cern.ch
>
>
ssh -X <username>@lxplus.cern.ch
 The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config:
Changed:
<
<
ForwardX11 yes
>
>
ForwardX11 yes
 

Choice of shell

By default, accounts for LHCb users on lxplus are configured to use the tcsh shell, an enhanced version of csh, but LHCb setup scripts are also available for the Bourne family of shells: sh, bash, ksh, zsh. There are subtle and not-so-subtle differences in the functionality of the different shells, and for scripting there are major differences between (t)csh and Bourne-type shells. A useful short summary can be found in:
Line: 40 to 40
 This defines some additional environment variables and aliases, and performs the setup for the Configuration Management Tool (CMT), used in LHCb for building software and for environment setup.

When not working on lxplus, but on a Linux machine where AFS is available, the standard LHCb environment may be set using:

Changed:
<
<
source /afs.cern.ch/lhcb/scripts/lhcbsetup.[c]sh
source /afs.cern.ch/lhcb/scripts/CMT.[c]sh
>
>
source /afs.cern.ch/lhcb/scripts/lhcbsetup.[c]sh
source /afs.cern.ch/lhcb/scripts/CMT.[c]sh
 

LHCb flavour of emacs editor

Customisations to emacs designed to help LHCb users have been written, and are described in the LHCb emacs user guide. Even for users who prefer a different editor (vim, nedit, Joe's own editor, pico, nano, or other), the LHCb flavour of emacs is useful for creating skeleton algorithms and similar.
Line: 70 to 70
 
env
should contain a number of variables with prefix LHCB (LHCBHOME, LHCBRELEASES and so on), and with prefix CMT (CMTROOT, CMTCONFIG and so on). If this isn't the case then you need to setup the environment yourself.
  • Setup the LHCb flavour of emacs and (optionally) the EDT keyboard emulation by adding the following lines to the ~/.emacs file:
Changed:
<
<
(load (expand-file-name "$EMACSDIR/lhcb"))
(load (expand-file-name "$EMACSDIR/edt"))
>
>
(load (expand-file-name "$EMACSDIR/lhcb"))
(load (expand-file-name "$EMACSDIR/edt"))
  or
cp $EMACSDIR/.emacs ~
LHCb specific emacs commands are documented in the LHCb emacs user guide.
Line: 137 to 137
 
  • PATH: search path for executables;
  • LD_LIBRARY_PATH: search path for shared libraries.
The full set of commands that can be used in a requirements file is described in the CMT manual. Some of the most useful commands are shown below.
Changed:
<
<

>
>
|

 # Lines beginning with the symbol # are treated as comments. # Blank lines are ignored.
Changed:
<
<
#======================================================================== # The following commands consist of a keyword followed by a value. # They are all for information only (i.e. they are disregarded by CMT). # Specify package name.
>
>
#================================================================== # The following commands describe a package.

# Package name.

 package myPackage
Changed:
<
<
# Specify package version.
>
>
# Package version, should correspond to CVS tag.
 version v1r0
Changed:
<
<
# Specify package manager or author. manager A Manager author AN Author #========================================================================
>
>
# Structure, i.e. directories to process. # A package must always have: # a cmt directory (for the requirements file) # a doc directory (for the release.notes file) # It may have: # a src directory for source files (.h, .cpp) # a options directory for job options (.opts) branches cmt doc src options

#================================================================== # The following command specifies packages which the current package # needs for compilation and linking. Put as many lines as necessary. # The keyword is followed by package name and version and, # where applicable, the package group in which the package is placed. # The version can usually be v* (i.e. any version) because the exact version # is usually determined by setting the environment in which a package is built use DaVinciTools v* Phys

#================================================================== # The following commands tell CMT what to build and how

# Build application with the specified file application myApp ../src/myApp.cpp

# Build a library with the specified files library myLib ../src/*.cpp

# Define link options and environment variables for loading component library apply_pattern component_library library=myLib

# Define link options and environment variables for loading linker library apply_pattern linker_library library=myLib

#==================================================================

 # The following commands define symbols (variables and aliases). # They consist of a keyword followed by a symbol name, and possibly by a value.
Changed:
<
<
# Previously defined symbols, including environment variables, can be # used in value assignments by placing brackets - () or {} - around them and a $ in front.
>
>
# Previously defined symbols, including environment variables, can be used in # value assignments by placing brackets - () or {} - around them and a $ in front.
 # Treat symbol as a Make macro definition.
Changed:
<
<
# This can be used to define a symbol as a local variable (i.e. one that won't be visible from the shell).
>
>
# This can be used to define a symbol as a local variable # (i.e. one that won't be visible from the shell).
 macro MYCMTDIR $(HOME)/cmtuser
Changed:
<
<
# Treat symbol as an environent variable. # The symbol will be visible from the shell after sourcing setup.[c]sh.
>
>
# Treat symbol as an environment variable. # The symbol will be visible from the shell after executing SetupProject
 set LCGDIR /afs/cern.ch/sw/lcg
Added:
>
>
 # Treat symbol as a path variable.
Changed:
<
<
# The symbol will be visible from the shell after sourcing setup.[c]sh. # When appending or prepending an item to a path variable not initialised in the requirements file, # it's a good idea to first remove the item, to ensure it occurs only once.
>
>
# The symbol will be visible from the shell after executing SetupProject # When appending or prepending an item to a path variable not initialised in the # requirements file, it's a good idea to first remove the item, to ensure it occurs only once.
 # Set path. path PYTHONPATH $(HOME)/python
Added:
>
>
 # Append item to path. path_append PYTHONPATH $(HOME)/myPythonPackage
Added:
>
>
 # Remove item from path. path_remove LD_LIBRARY_PATH $(HOME)/lib
Added:
>
>
 # Prepend item to path. path_prepend LD_LIBRARY_PATH $(HOME)/lib
Added:
>
>
 # Create alias.
Changed:
<
<
# The alias will be visible from the shell after sourcing setup.[c]sh.
>
>
# The alias will be visible from the shell after executing SetupProject
 alias myApp $(MYPACKAGEROOT)/$(CMTCONFIG)/myApp.exe
Changed:
<
<
#======================================================================== # The following command is used to specify packages on which the current package depends. # The keyword is followed by package name and version and, where applicable, # the hat under which the package is placed. use DaVinciTools v* Phys #======================================================================== # The following commands are for creating Make files, which can be used to build applications and libraries. # They consist of a keyword followed by a name for the result, followed by a list of input files. # Build application. application myApp ../src/myApp.cpp # Build library. library myLib ../src/*.cpp
>
>
#================================================================== |
  Most CMT commands, but not all, operate on requirements files, and must be given from a package's cmt directory. If a requirements file includes lines indicating that other packages are used, then these packages will be searched for in locations specified by the project environment, and the requirements files of each used package is processed in turn.

Line: 213 to 244
 
  • Execute an executable within the environment of the current project
    cmt run <myExec.exe>
Changed:
<
<
To release a new package in the LHCb framework it must be imported to CVS and registered so that getpack can find it. Follow the instructions here.
>
>
To release a new package in the LHCb framework it must be imported into CVS and registered so that getpack can find it. Follow the instructions here.
 

Exercise 3

Added:
>
>
This exercise introduces basic CMT functionality and demonstrates the use of the LHCb flavour of emacs to create different kinds of files.
  • Create a CMT project directory in which to work.
    setenvDaVinci v19r3
    This command creates a directory ~cmtuser/DaVinci_v19r3, containing a file cmt/project.cmt. Any directory tree containing this file is called a CMT project.
  • Look at the cmt/project.cmt file that was created
    pwd
    cat cmt/project.cmt
    The setenvDaVinci v19r3 command placed you inside your new CMT project, and created a file that tells CMT that any CMT command issued from inside this directory tree should use the environment defined by the DAVINCI_v19r3 project. If you want to work with a different application, or with a different version of DaVinci, simply re-issue the setenv<Project> command, e.g. setenvBrunel v31r7. Information about CMT projects, including tips and tricks for working with them, can be found here
  • Create a new package in your DaVinci_v19r3 project:
    cd ~cmtuser/DaVinci_v19r3
    mkdir -p MyGroup/MyPackage/v1r0/cmt
    cd MyGroup/MyPackage/v1r0/cmt
  • Create a cmt requirements file
    emacs requirements &
    Look at the generated file and add the line
    use GaudiAlg v*
    Save the file. The use statement that you added tells CMT that the files in this package will require to compile and link against files in the GaudiAlg package.
  • Try some basic CMT commands:
    cmt show uses
    ls
    ls ..
    cmt config
    ls
    ls ..
  • Try creating some different types of files with emacs. Each time, make a small modification to the file and save it
    emacs ../doc/release.notes &
    emacs ../src/MyAlg.h &
    emacs ../src/MyAlg.cpp &
    emacs ../src/MyPackage_dll.cpp &
  • Use CMT to compile the files you just created, and make a library out of them
    gmake
    ls ..
    ls ../slc4_ia32_gcc34
    ls ../$CMTCONFIG
  • Similarly, make the debug version of the library (i.e. containing debug symbols for use with a debugger)
    setenv CMTCONFIG $CMTDEB
    gmake
    ls ..
    ls ../slc4_ia32_gcc34_dbg
    ls ../$CMTCONFIG
 

Exercise 4

Running LHCb Applications

Exercise 5

Revision 42007-07-18 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
Line: 75 to 75
 
cp $EMACSDIR/.emacs ~
LHCb specific emacs commands are documented in the LHCb emacs user guide.
Added:
>
>

Organisation of LHCb software

LHCb software is based on a framework called Gaudi. This framework provides functionality useful in a wide range of contexts, such as file access, histogramming, message printing, and run-time configuration. The run-time configuration is based on job options.

Software in LHCb is developed in the context of packages. Here, a package is essentially a set of files, organised according to some directory structure, and providing some well-defined, circumscribed functionality. Most LHCb packages contain code that can be compiled into (shared) libraries. Packages with related functionality are collected in groups (or are said to be placed under a hat), and package groups are arranged in projects. Projects and packages (but not package groups), have an associated version number, of the form vXrY, with X and Y integers, and this is incremented when changes are made in package contents. The hierarchy of the software organisation is then: PROJECT/PROJECT_<version>/<package group>/<package>/<package version>. For example

ls $LHCBRELEASES/DAVINCI/DAVINCI_v19r3/Phys/DaVinci/v19r3/
Sub-directories typically found in an LHCb package include:
  • src: source code;
  • <package> (Sub-directory with same name as package): header files;
  • options: job options associated with the package;
  • cmt: information for CMT processing;
  • doc: package documentation.
Package development in LHCb is carried out using the Concurrent Versions System (CVS). This defines a code repository, provides dedicated commands for moving code in and out of the repository, and keeps a record of all changes made. With the standard LHCb environment, the repository is identified by the variable CVSROOT, and a user can obtain a copy of any package in the repository using the command:
getpack <package group>/<package> <version>
If no arguments are specified, a list of all available packages is printed, and if the version is omitted a list of all available versions for the specified package is given. The latest version of a package, (not necessarily a working version!) is always available as the package head. Access to the CVS repository requires kerberos authentication. This is is automatic on lxplus, but for access over AFS from another machine a kerberos ticket must be obtained. This can be done using the command:
klog <username>@cern.ch -tmp
or on some systems
klog.krb <username>@cern.ch
where <username> is the username on lxplus, and the corresponding password will be requested.

Check what tokens you have and when they will expire with the command

tokens
or on some systems
tokens.krb
(These are usually actually the same command).

New versions of packages, and new packages, are placed in the release area after testing, or may be available in the development area as works in progress. The standard LHCb environment includes the variables:

  • LHCBRELEASES: release area;
  • LHCBDEV: development area.
Instructions for making package modifications and new packages available from the release area can be found in the documentation for How to use Gaudi under CMT. Web access is available to both the CVS repository and the release area.
 
Deleted:
<
<

Organisation of LHCb software

 

LHCb applications

Added:
>
>
The LHCb applications are sets of packages used within the Gaudi framework to perform specific tasks. The main applications are:
  • Gauss: event generation, using Pythia and EvtGen, and detector simulation based on Geant4;
  • Boole: simulation of detector response (digitisation);
  • Brunel: event reconstruction;
  • DaVinci: event selection and data analysis;
  • Panoramix: graphical display of detector and event information.
There is a project specific to, and with the same name as, each application. Additional projects are shared across applications.
 

Exercise 2

Added:
>
>
This exercise is designed to give you some familiarity with the LHCb software organisation. It's fairly open-ended, in that you could spend a very long time exploring all of the LHCb packages. Until you're trying to find something - which is when knowing the organisation is a big help - it's probably not useful to spend more than 5-10 minutes looking around.
  • Move to the LHCb release area: either
    cd ${LHCBRELEASES}
    or use the web interface to the release area: http://cern.ch/LHCb-release-area/
  • Note the different project directories, and enter the project directory for any one of the projects.
  • Note the different project versions available, and move to the directory for the latest.
  • Note the different package groups, and have a look in two or more of these at what packages are available.
  • Choose any two packages, and for each in turn: move to the directory for the latest version, look at which sub-directories are defined, and have a look at the files that are in each.
  • Look also at the development area:
    cd ${LHCBDEV}
 

Configuration Management Tool

Added:
>
>
CMT is used to specify the compilation and execution environment for packages within a project, and how each package is built (for example, how to produce executables or libraries from source code). To allow this, a CMT package must have a cmt sub-directory containing a requirements file, where the relevant instructions are given. All LHCb packages developed in the Gaudi framework are CMT packages.

For a package with name myPackage, CMT itself defines an environment variable MYPACKAGEROOT that contains the package location.

In the context of environment setup, there are two path variables that tend to be very important:

  • PATH: search path for executables;
  • LD_LIBRARY_PATH: search path for shared libraries.
The full set of commands that can be used in a requirements file is described in the CMT manual. Some of the most useful commands are shown below.
# Lines beginning with the symbol # are treated as comments.
# Blank lines are ignored.
#========================================================================
# The following commands consist of a keyword followed by a value.
# They are all for information only (i.e. they are disregarded by CMT).
# Specify package name.
package myPackage
# Specify package version.
version v1r0
# Specify package manager or author.
manager A Manager
author AN Author
#========================================================================
# The following commands define symbols (variables and aliases).
# They consist of a keyword followed by a symbol name, and possibly by a value.
# Previously defined symbols, including environment variables, can be
# used in value assignments by placing brackets - () or {} - around them and a $ in front.
# Treat symbol as a Make macro definition.
# This can be used to define a symbol as a local variable (i.e. one that won't be visible from the shell).
macro MYCMTDIR $(HOME)/cmtuser
# Treat symbol as an environent variable.
# The symbol will be visible from the shell after sourcing setup.[c]sh.
set LCGDIR /afs/cern.ch/sw/lcg
# Treat symbol as a path variable.
# The symbol will be visible from the shell after sourcing setup.[c]sh.
# When appending or prepending an item to a path variable not initialised in the requirements file,
# it's a good idea to first remove the item, to ensure it occurs only once.
# Set path.
path PYTHONPATH $(HOME)/python
# Append item to path.
path_append PYTHONPATH $(HOME)/myPythonPackage
# Remove item from path.
path_remove LD_LIBRARY_PATH $(HOME)/lib
# Prepend item to path.
path_prepend LD_LIBRARY_PATH $(HOME)/lib
# Create alias.
# The alias will be visible from the shell after sourcing setup.[c]sh.
alias myApp $(MYPACKAGEROOT)/$(CMTCONFIG)/myApp.exe
#========================================================================
# The following command is used to specify packages on which the current package depends. 
# The keyword is followed by package name and version and, where applicable, 
# the hat under which the package is placed.
use DaVinciTools v* Phys
#========================================================================
# The following commands are for creating Make files, which can be used to build applications and libraries.
# They consist of a keyword followed by a name for the result, followed by a list of input files.
# Build application.
application myApp ../src/myApp.cpp
# Build library.
library myLib ../src/*.cpp

Most CMT commands, but not all, operate on requirements files, and must be given from a package's cmt directory. If a requirements file includes lines indicating that other packages are used, then these packages will be searched for in locations specified by the project environment, and the requirements files of each used package is processed in turn.

The CMT manual should be consulted for the full set of CMT commands, but a useful subset is given below.

  • Perform package configuration - that is, create setup files and Make files:
    cmt config
    Note that when a copy of a package is obtained using getpack the package is configured automatically.
  • After configuration, Make commands can be used from the cmt directory:
    • Build the package binaries:
      gmake
      The output of the build operation is placed in a package sub-directory. The name of this sub-directory is given by the value of the environment variable CMTCONFIG.
    • Delete the package binaries:
      gmake binclean
    • Delete all generated files, including copies made to the project InstallArea
      gmake clean
  • Show all packages used by the current package:
    cmt show uses
  • Execute <shell command(s)> in cmt directory of current package and all used packages within the same project:
    cmt broadcast <shell command(s)>
    Multiple commands need to be separated by semicolons and enclosed in inverted commas. This can be useful, for example, to force rebuilding of all used packages in the user's area:
    cmt broadcast "cmt config ; gmake binclean ; gmake"
  • Execute an executable within the environment of the current project
    cmt run <myExec.exe>

To release a new package in the LHCb framework it must be imported to CVS and registered so that getpack can find it. Follow the instructions here.

 

Exercise 3

Exercise 4

Running LHCb Applications

Line: 89 to 223
 

Exercise 7

Exercise 8

Changed:
<
<
-- MarcoCattaneo - 17 Jul 2007
>
>
-- MarcoCattaneo - 18 Jul 2007

Revision 32007-07-17 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:

Prerequisites

Changed:
<
<
The instructions for these exercises assume that they are being executed on the CERN Linux interactive cluster lxplus. However, except for some details of the interactive environment, the exercises should work on any machine on the LHCb software is installed.
>
>
The instructions for these exercises assume that they are being executed on the CERN Linux interactive cluster lxplus. However, except for some details of the interactive environment, the exercises should work on any machine where the LHCb software is installed.
 
Changed:
<
<
To get an account on lxplus, please contact the LHCb secretariat. If you already have an lxplus account, but were previously working in another experiment, please make sure that your account is registered as an LHCb account, in afs group z5.
>
>
To get an account on lxplus, please contact the LHCb secretariat. If you already have an lxplus account, but were previously working in another experiment, you should make sure that your account is registered as an LHCb account, in afs group z5 (see Exercise 1).
 
Changed:
<
<
These instructions have last been checked against the DaVinci v19r3 (and Gaudi v19r4) environment. Please make sure that you use this version of DaVinci or a more recent version.
>
>
These instructions have last been checked against the DaVinci v19r3 (and Gaudi v19r4) environment. Please use this version of DaVinci or a more recent version.
 

Logging in to lxplus

Remote access to lxplus is via the ssh protocol. Open a connection using the command:
ssh -X <username>@lxplus.cern.ch
Changed:
<
<
The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the line:
>
>
The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the following line in the ssh configuration file, ${HOME}/.ssh/config:
 
ForwardX11 yes
Deleted:
<
<
in the ssh configuration file, ${HOME}/.ssh/config.
 

Choice of shell

Added:
>
>
By default, accounts for LHCb users on lxplus are configured to use the tcsh shell, an enhanced version of csh, but LHCb setup scripts are also available for the Bourne family of shells: sh, bash, ksh, zsh. There are subtle and not-so-subtle differences in the functionality of the different shells, and for scripting there are major differences between (t)csh and Bourne-type shells. A useful short summary can be found in:

A user may redefine the default shell on lxplus by going to https://cra.cern.ch and changing the appropriate field. In general, unless you have a strong preference, stick to tcsh as this is better tested.

In what follows, <script>.[c]sh is used as shorthand for:

  • csh,tcsh: <script>.csh
  • sh,bash,ksh,zsh: <script>.sh
 

LHCb software environment

Added:
>
>
For users logging on to lxplus with an account in the LHCb group (z5), two scripts are sourced automatically at startup:
  • /afs/cern.ch/group/z5/group_env.[c]sh
  • /afs/cern.ch/group/z5/group_login.[c]sh
The only action of the first group script is to source the script:
  • /afs.cern.ch/lhcb/scripts/lhcbsetup.[c]sh
This sets a number of environment variables, mainly identifying directories relevant for working with LHCb software, and creates some aliases. The main action of the second script is to source the script:
  • /afs.cern.ch/lhcb/scripts/CMT.[c]sh
This defines some additional environment variables and aliases, and performs the setup for the Configuration Management Tool (CMT), used in LHCb for building software and for environment setup.

When not working on lxplus, but on a Linux machine where AFS is available, the standard LHCb environment may be set using:

source /afs.cern.ch/lhcb/scripts/lhcbsetup.[c]sh
source /afs.cern.ch/lhcb/scripts/CMT.[c]sh
 

LHCb flavour of emacs editor

Added:
>
>
Customisations to emacs designed to help LHCb users have been written, and are described in the LHCb emacs user guide. Even for users who prefer a different editor (vim, nedit, Joe's own editor, pico, nano, or other), the LHCb flavour of emacs is useful for creating skeleton algorithms and similar.

IMPORTANT : If you are working over a slow network connection, it is sometimes useful to work in a 'terminal mode', where a new X window is not opened. This can be done by running

emacs -nw
In this mode, the menu bars are not useful, so it is good to know a few key-strokes :
  1. Open a file with control-X control-F
  2. Save a file with control-X control-S
  3. Exit with control-X control-C

 

Exercise 1

Added:
>
>
This is a simple exercise just to check your environment setup.
  • Login to lxplus.
  • Check that X11 connections are enabled, for example by displaying a clock:
    xclock &
  • Check the group associated with your account by giving the command:
    echo $GROUP
    For an account in the LHCb group the result should be z5.
  • Check which shell you are using, for example using:
    echo $0
    or
    echo $SHELL
    and optionally change your default shell by going to https://cra.cern.ch (you will need to login using your CERN NICE username and password)
  • Check that the standard LHCb environment has been set. If it has, then you will have seen a message at login time about your CMT settings, and the result of the command:
    env
    should contain a number of variables with prefix LHCB (LHCBHOME, LHCBRELEASES and so on), and with prefix CMT (CMTROOT, CMTCONFIG and so on). If this isn't the case then you need to setup the environment yourself.
  • Setup the LHCb flavour of emacs and (optionally) the EDT keyboard emulation by adding the following lines to the ~/.emacs file:
    (load (expand-file-name "$EMACSDIR/lhcb"))
    (load (expand-file-name "$EMACSDIR/edt"))
    or
    cp $EMACSDIR/.emacs ~
    LHCb specific emacs commands are documented in the LHCb emacs user guide.

 

Organisation of LHCb software

LHCb applications

Exercise 2

Revision 22007-07-17 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

Changed:
<
<
This is hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
>
>
This hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:
 

Prerequisites

Added:
>
>
The instructions for these exercises assume that they are being executed on the CERN Linux interactive cluster lxplus. However, except for some details of the interactive environment, the exercises should work on any machine on the LHCb software is installed.

To get an account on lxplus, please contact the LHCb secretariat. If you already have an lxplus account, but were previously working in another experiment, please make sure that your account is registered as an LHCb account, in afs group z5.

These instructions have last been checked against the DaVinci v19r3 (and Gaudi v19r4) environment. Please make sure that you use this version of DaVinci or a more recent version.

 

Logging in to lxplus

Added:
>
>
Remote access to lxplus is via the ssh protocol. Open a connection using the command:
ssh -X <username>@lxplus.cern.ch
The -X option is needed to enable X11 connections when logging in to lxplus as a remote machine, to be able to open graphics windows and windows for the emacs editor. Alternatively, omit the -X option and include the line:
ForwardX11 yes
in the ssh configuration file, ${HOME}/.ssh/config.
 

Choice of shell

LHCb software environment

LHCb flavour of emacs editor

Revision 12007-07-17 - MarcoCattaneo

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="LHCbSoftwareTutorials"

LHCb Software Training: Basics

This is hands on tutorial should be followed by all newcomers to the LHCb software environment. It covers the following topics:

Prerequisites

Logging in to lxplus

Choice of shell

LHCb software environment

LHCb flavour of emacs editor

Exercise 1

Organisation of LHCb software

LHCb applications

Exercise 2

Configuration Management Tool

Exercise 3

Exercise 4

Running LHCb Applications

Exercise 5

Exercise 6

Exercise 7

Exercise 8

-- MarcoCattaneo - 17 Jul 2007

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback