2 ======================================================================
3 SALOME Application Concept. Configuration for one or more computers
4 ======================================================================
6 *html version of this document is produced with docutils*::
8 rest2html < doc.txt > doc.html
10 This document corresponds to SALOME2 3.1. (alpha version)
12 +-------------------------------------------+
13 | **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
14 +-------------------------------------------+
16 The following explains how to configure your own application with your list of
17 modules, how to define and run this application on one or more computers.
22 `1. General principles`_
24 `2. Application Directory`_
26 `2.1 Proposal for env.d scripts`_
28 `2.2 User run scripts`_
30 `2.3 SALOME internal run script`_
32 `2.4 Other configuration files`_
37 A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...).
39 A SALOME User can define several SALOME Applications. These applications are
40 runnable from the same user account. These applications may share the same
41 KERNEL and modules. Thus, the application configuration is independant of
42 KERNEL and must not be put in KERNEL_ROOT_DIR.
44 Furthermore, prerequisites may not be the same on all the applications.
46 A SALOME Session can run on a several computers.
48 Binary modules and prerequisites are installed on the different computers.
49 There is no need to have all the modules on each computer (the minimum is
52 There is no need of standardization or centralised information on the details
53 of configuration on each computer (PATH, LD_LIBRARY_PATH, environment
54 variables) provided the application modules are version - compatible. Details
55 of configuration stay private to the computer, and are held by scripts on each
58 There is no hierarchy between the computers (for example only one master
59 computer used to launch application).
61 The SALOME user has an account on all the computers. Access between
62 account@computer is via rsh or ssh and must be configured for use without
63 password (key exchange for ssh). Account may be different on each
66 2. Application Directory
67 ------------------------
69 The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an
70 application directory with the given path in parameter. ${APPLI} is a path
73 The directory is only a skeleton, the user has to edit several files to
74 configure his own application. These files are described after, the list is:
77 - env.d/envProducts.sh
79 - CatalogResources.xml
82 Directory ${APPLI} must be created on each computer of the application.
83 The easiest way is to use the same relative path (to ${HOME}) on each computer.
84 (Sometimes it is not possible to use the same path everywhere, for instance
85 when ${HOME} is shared with NFS, so it is possible to define different path
86 following the computers).
88 The ${APPLI} directory contains scripts for environment and runs. Environment
89 scripts must be configured (by the user) on each computer. All the environment
90 scripts are in the ${APPLI}/env.d directory.
92 The script ${APPLI}/envd sources **all** the files in ${APPLI}/env.d in
93 alphanumeric order (after edition, think to remove backup files). the envd
94 script is used by run scripts.
97 2.1 Proposal for env.d scripts
98 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
99 Each user **must define** his own configuration for these scripts, following
100 the above rules. **The following is only an example not working as it is**.
103 Sets the computer configuration not directly related to SALOME,
104 like useful tools, default PATH.
107 Sets the SALOME prerequisites.
110 Sets all the MODULE_ROOT_DIR that can be used in the SALOME application.
112 SalomeAppConfig is also defined by::
114 export SalomeAppConfig=${HOME}/${APPLI}
116 where SalomeAppConfig designates the directory containing SalomeApp.xml.
117 Note that ${APPLI} is already defined by the calling scripts when
118 envSALOME.sh is sourced.
123 The SALOME user can use 4 scripts:
126 Launches a SALOME Session
127 (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
128 name to avoid confusions).
131 Launches a shell script in the SALOME application environment, with access
132 to the current SALOME session (naming service), if any.
133 Without arguments, the script is interactive. With arguments, the script
134 executes the command in the SALOME application environment.
137 Gives a python console connected to the current SALOME Session.
138 It is also possible to use runSession, then python.
141 Similar to runSession, used for unit testing. runSession tries to use an
142 already existing naming service definition from a running session (hostname
143 and port number), runTests defines a new configuration for naming service
146 2.3 SALOME internal run script
147 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
149 For remote calls, SALOME uses one script.
152 This script is mainly used to launch containers. The first 2 arguments
153 define the hostname and port userd for naming service, the remaining
154 arguments define the command to execute.
156 2.4 Other configuration files
157 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
160 This file is similar to the default given in $GUI_ROOT_DIR
162 CatalogRessources.xml
163 This files describes all the computer the application can use. The given
164 example is minimal and suppose ${APPLI} is the same relative path
165 to ${HOME}, on all the computers. A different directory can be set on a
166 particular computer with a line::
168 appliPath="my/specific/path/on/this/computer"