2 \page SALOME_Application SALOME Application Concept
4 <b>Configuration for one or more computers</b>
7 <b> **WORK in PROGRESS, INCOMPLETE DOCUMENT** </b>
9 The following explains how to configure your own application with your list of
10 modules, how to define and run this application on one or more computers.
12 \section S1_sal_appl General principles
14 %A %SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...).
16 %A %SALOME User can define several %SALOME Applications. These applications are
17 runnable from the same user account. These applications may share the same
18 KERNEL and modules. Thus, the application configuration is independant of
19 KERNEL and must not be put in KERNEL_ROOT_DIR.
21 Furthermore, prerequisites may not be the same on all the applications.
23 %A %SALOME Session can run on a several computers.
25 Binary modules and prerequisites are installed on the different computers.
26 There is no need to have all the modules on each computer (the minimum is
29 There is no need of standardization or centralised information on the details
30 of configuration on each computer (PATH, LD_LIBRARY_PATH, environment
31 variables) provided the application modules are version - compatible. Details
32 of configuration stay private to the computer, and are held by scripts on each
35 There is no hierarchy between the computers (for example only one master
36 computer used to launch application).
38 The %SALOME user has an account on all the computers. Access between
39 account@computer is via rsh or ssh and must be configured for use without
40 password (key exchange for ssh). Account may be different on each
43 \section S2_sal_appl Application Directory
45 There are two ways for creation of an application directory, <b>the recommended way is
46 the second, easier to configure.</b>
50 <b>First way - references to different module directories</b>
52 The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an
53 application directory with the given path in parameter. The path given, ${APPLI}, is
56 The directory is only a skeleton, the user has to edit several files to
57 configure his own application. These files are described after, the list is:
60 - env.d/envProducts.sh
62 - CatalogResources.xml
67 <b>Second and easiest way - one single virtual install directory</b>
69 The user must create a %SALOME application configuration file by modifying a
70 copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml.
71 The file describes the list of %SALOME modules used in the application, with
72 their respective installation path. The configuration file also defines the
73 path of an existing script which sets the %SALOME prerequisites,
74 and optionnaly, the path of samples directory (SAMPLES_SRC).
75 The following command::
78 python <KERNEL_ROOT_DIR>/bin/salome/appli_gen.py --prefix=<install directory> --config=<configuration file>
81 creates a virtual installation of %SALOME in the application directory ${APPLI}
82 (bin, lib, doc, share...), with, for each file (executable, script, data,
83 library, resources...), symbolic links to the actual file.
84 <b>Note: it is recommended to set the environment for %SALOME prerequisites
85 before invoking the above command, in order to use the same python as SALOME,
86 otherwise installation may be wrong</b>
88 Providing an existing script for %SALOME prerequisites (the same one
89 used for modules compilation, or given with the modules installation), the
90 installation works without further modification for a single computer (unless
91 some modules needs a special environment not defined in the above script).
92 For a distributed application (several computers), one must copy and adapt
93 CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below).
97 \section S3_sal_appl General rules
99 Directory ${APPLI} must be created on each computer of the application.
100 The easiest way is to use the same relative path (to ${HOME}) on each computer.
101 (Sometimes it is not possible to use the same path everywhere, for instance
102 when ${HOME} is shared with NFS, so it is possible to define different path
103 following the computers).
105 The ${APPLI} directory contains scripts for environment and runs. Environment
106 scripts must be configured (by the user) on each computer. All the environment
107 scripts are in the ${APPLI}/env.d directory.
109 The script ${APPLI}/envd sources **all** the files (\*.sh) in ${APPLI}/env.d
110 in alphanumeric order (after edition, think to remove backup files). the envd
111 script is used by run scripts.
117 With the first way of installation, each user **must define** his own
118 configuration for these scripts, following the above rules.
119 <b>With the virtual installation (second way, above), env.d
120 scripts are built automatically.</b>
122 **The following is only an example proposed by createAppli.sh, (first way of installation) not working as it is**.
125 Sets the computer configuration not directly related to %SALOME,
126 like useful tools, default PATH.
129 Sets the %SALOME prerequisites.
132 Sets all the MODULE_ROOT_DIR that can be used in the %SALOME application.
134 SALOMEAppConfig is also defined by:
137 export SALOMEAppConfig=${HOME}/${APPLI}
140 where SALOMEAppConfig designates the directory containing SALOMEApp.xml.
141 Note that ${APPLI} is already defined by the calling scripts when
142 env.d/envSALOME.sh is sourced.
145 <b>User run scripts</b>
147 The %SALOME user can use 4 scripts:
150 Launches a %SALOME Session
151 (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
152 name to avoid confusions). See parameters below.
155 Launches a shell script in the %SALOME application environment, with access
156 to the current (last launched) %SALOME session (naming service), if any.
157 Without arguments, the script is interactive. With arguments, the script
158 executes the command in the %SALOME application environment.
161 Gives a python console connected to the current %SALOME Session.
162 It is also possible to use runSession, then python.
165 Similar to runSession, used for unit testing, but runSession tries to use an
166 already existing naming service definition from a running session (hostname
167 and port number), and runTests defines a new configuration for naming service
171 <b>%SALOME internal run scripts</b>
174 Sets %SALOME application environment, envd is sourced by other scripts.
176 For remote calls, %SALOME uses one script.
179 This script is mainly used to launch containers. The first 3 arguments
180 define the hostname and port userd for naming service, plus a working directory, the remaining
181 arguments define the command to execute.
184 <b>Other configuration files</b>
187 This file is similar to the default given
188 in ${GUI_ROOT_DIR}/share/SALOME/resources/gui
191 - CatalogRessources.xml
192 This files describes all the computers the application can use. The given
193 example is minimal and suppose ${APPLI} is the same relative path
194 to ${HOME}, on all the computers. %A different directory can be set on a
195 particular computer with a line:
198 appliPath="my/specific/path/on/this/computer"
204 \section S4_sal_appl Examples of use
208 <b>Launch a %SALOME session with a GUI interface</b>
210 Launch is done with a command like::
216 The --logger option means here : collect all the traces from the all the
217 distributed process, via CORBA, in a single file : logger.log.
219 There are a lot of options, a complete list is given by::
225 Note that, without argument, runAppli is a non interactive Python application,
226 and, with arguments, runAppli is an interactive Python interpreter.
228 Several options are already defined by default in SALOMEApp.xml files. Optional
229 arguments given in the command override the SALOMEApp.xml configuration.
231 Several sessions can run simultaneously, each session use a different port for
232 CORBA naming service, so the sessions are totally separated from each other.
234 When the GUI is closed, the different %SALOME servers are still running.
237 <b>Close a %SALOME session, kill all the servers</b>
239 Inside the interactive python interpreter you get when you use runAppli
240 with arguments, you can kill all the servers of your session with::
246 or the servers of all the sessions with::
252 If you have no active Python interpreter connected to your session, you can
253 kill all the %SALOME servers of **all the sessions** on a given computer::
256 ./runSession killSalome.py
259 Remember! it's the same idea in <b>Windows (R) operating system</b> (Microsoft and Windows are either registered trademarks or trademarks of
260 Microsoft Corporation in the United States and/or other countries) :
261 use the start menu to stop...
263 When you use only one session at a time, you don't need more.
265 To kill a given session (when several session are running), one needs
266 the naming service port number::
269 ./runSession killSalomeWithPort 2810
272 Note that the port number of the last launched session can be found on Linux,
273 in the prompt, within a runSession shell (see below).
275 It is also possible to get the Naming Service host and port number of
276 the last launched session with::
279 ./runSession NSparam.py
284 <b>Launch a %SALOME session without GUI interface</b>
286 This is used to launch a %SALOME Python script without GUI
287 (no GUI %server = SALOME_session_server)
289 Example of script (test_session_geom.py):
292 import salome_session
293 salome_session.startSession(modules=["GEOM"])
294 import GEOM_usinggeom
295 raw_input("Press a key and the servers will be killed ...")
298 This script is run in a non interactive way with::
301 ./runSession python test_session_geom.py
304 All the process are automatically killed when Python is closed
305 (with SALOME_session delete).
308 <b>Add an external Python interpretor to a running session</b>
310 It's often easier to develop and try Python scripts outside the GUI embedded
311 Python interpreter. Imagine, for instance, you are writing a script involving
312 geometry and mesh modules.
313 first, launch a %SALOME session with gui, then, on another terminal::
320 Import %SALOME module. salome_init() without arguments creates a new study
321 in the running session (note: SALOME_init(n) attachs to a running session whose
329 An example of script given with SMESH::
332 import ex01_cube2build
335 It is possible to connect the GUI interface to the study created in the above
336 script with the file/connect menu, then browse study and display objects.
337 Further modifications on study can be done either with GUI or external script
338 (use refresh popup in GUI %object browser to see study modifications generated
339 by the external script). **AVOID modifications with GUI when a Python script
340 is running**. Not all the modules are protected against concurrent actions...
343 <b>Different uses of the runSession shell interpreter</b>
345 runSession invoked without arguments gives an interactive shell with the full
346 environment of %SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables).
347 If there are running sessions of the same %SALOME application, runSession
348 connects to the last launched session (i.e. gets the naming service references
349 of the session: hostname and port)
351 On Linux, the shell prompt (bash) gives information on naming service
352 references, hostname and port::
355 [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$
358 If there is no running session, prompt looks like::
361 [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$
364 runSession is useful to launch any script or program which needs the complete
365 %SALOME environment, with or without a session already running.
366 For instance, to launch the ddd debugger interface on the gui %server, first
367 launch a %SALOME session with gui, then, on another terminal::
373 Then attach to the running SALOME_Session_Server process.