2 \page SALOME_Application Salome Application Concept
5 The following explains how to configure your own application with your list of
6 modules, how to define and run this application on one or more computers.
8 \section S1_sal_appl General principles
10 %A %SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...). %A %SALOME application
11 lives in an application directory.
12 %A %SALOME application is a virtual installation of %SALOME in the application directory
13 (bin, lib, doc, share...), with, for each file (executable, script, data,
14 library, resources...), symbolic links to the actual files.
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 First, the user must create a %SALOME application configuration file by modifying a
46 copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml.
47 The file describes the list of %SALOME modules used in the application, with
48 their respective installation path. The configuration file also defines the
49 path of an existing script which sets the %SALOME prerequisites,
50 and optionnaly, the path of samples directory (SAMPLES_SRC).
51 The following command:
54 python <KERNEL_ROOT_DIR>/bin/salome/appli_gen.py --prefix=<install directory> --config=<configuration file>
57 creates a %SALOME application in the application directory given by the prefix option (local directory
58 by default) with the configuration file given by the config option (config_appli.xml by default).
60 Providing an existing script for %SALOME prerequisites (the same one
61 used for modules compilation, or given with the modules installation), the
62 installation works without further modification for a single computer (unless
63 some modules needs a special environment not defined in the above script).
65 For a distributed application (several computers), one must copy and adapt
66 CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below).
68 \section S3_sal_appl General rules
70 The application directory must be created on each computer of the application.
71 The easiest way is to use the same relative path (to ${HOME}) on each computer.
72 (Sometimes it is not possible to use the same path everywhere, for instance
73 when ${HOME} is shared with NFS, so it is possible to define different path
74 following the computers).
76 The application directory contains scripts for environment and runs. Environment
77 scripts must be configured (by the user) on each computer. All the environment
78 scripts are in the env.d subdirectory.
80 The script envd sources \b all the files (*.sh) in subdirectory env.d
81 in alphanumeric order (after edition, think to remove backup files). The envd
82 script is used by run scripts.
88 <b>env.d scripts are built automatically.</b>
90 You can add your own environment scripts in env.d subdirectory, they will be sourced as
91 the generated ones provided they have a .sh extension.
95 <b>User run scripts</b>
97 The %SALOME user can use 4 scripts:
100 Launches a %SALOME Session
101 (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
102 name to avoid confusions). See parameters below.
105 Launches a shell script in the %SALOME application environment, with access
106 to the current (last launched) %SALOME session (naming service), if any.
107 Without arguments, the script is interactive. With arguments, the script
108 executes the command in the %SALOME application environment.
111 Gives a python console connected to the current %SALOME Session.
112 It is also possible to use runSession, then python.
115 Similar to runSession, used for unit testing, but runSession tries to use an
116 already existing naming service definition from a running session (hostname
117 and port number), and runTests defines a new configuration for naming service
121 <b>%SALOME internal run scripts</b>
124 Sets %SALOME application environment, envd is sourced by other scripts.
126 For remote calls, %SALOME uses one script.
129 This script is mainly used to launch containers. The first 3 arguments
130 define the hostname and port userd for naming service, plus a working directory, the remaining
131 arguments define the command to execute.
134 <b>Other configuration files</b>
137 This file is similar to the default given
138 in ${GUI_ROOT_DIR}/share/SALOME/resources/gui
141 - CatalogRessources.xml\n
142 This file describes all the computers the application can use. The given
143 example is minimal and suppose application directory is the same relative path
144 to ${HOME}, on all the computers. %A different directory can be set on a
145 particular computer with a line:
147 appliPath="my/specific/path/on/this/computer"
153 \section S4_sal_appl Examples of use
157 <b>Launch a %SALOME session with a GUI interface</b>
159 Launch is done with a command like:
165 The --logger option means here : collect all the traces from the all the
166 distributed process, via CORBA, in a single file : logger.log.
168 There are a lot of options, a complete list is given by:
174 Note that, without argument, runAppli is a non interactive Python application,
175 and, with arguments, runAppli is an interactive Python interpreter.
177 Several options are already defined by default in SALOMEApp.xml files. Optional
178 arguments given in the command override the SALOMEApp.xml configuration.
180 Several sessions can run simultaneously, each session use a different port for
181 CORBA naming service, so the sessions are totally separated from each other.
183 When the GUI is closed, the different %SALOME servers are still running.
186 <b>Close a %SALOME session, kill all the servers</b>
188 Inside the interactive python interpreter you get when you use runAppli
189 with arguments, you can kill all the servers of your session with:
195 or the servers of all the sessions with:
201 If you have no active Python interpreter connected to your session, you can
202 kill all the %SALOME servers of <b>all the sessions</b> on a given computer:
205 ./runSession killSalome.py
208 Remember! it's the same idea in <b>Windows (R) operating system</b> (Microsoft and Windows are either registered trademarks or trademarks of
209 Microsoft Corporation in the United States and/or other countries) :
210 use the start menu to stop...
212 When you use only one session at a time, you don't need more.
214 To kill a given session (when several session are running), one needs
215 the naming service port number:
218 ./runSession killSalomeWithPort 2810
221 Note that the port number of the last launched session can be found on Linux,
222 in the prompt, within a runSession shell (see below).
224 It is also possible to get the Naming Service host and port number of
225 the last launched session with:
228 ./runSession NSparam.py
233 <b>Launch a %SALOME session without GUI interface</b>
235 This is used to launch a %SALOME Python script without GUI
236 (no GUI %server = SALOME_session_server)
238 Example of script (test_session_geom.py):
241 import salome_session
242 salome_session.startSession(modules=["GEOM"])
243 import GEOM_usinggeom
244 raw_input("Press a key and the servers will be killed ...")
247 This script is run in a non interactive way with:
250 ./runSession python test_session_geom.py
253 All the process are automatically killed when Python is closed
254 (with SALOME_session delete).
257 <b>Add an external Python interpretor to a running session</b>
259 It's often easier to develop and try Python scripts outside the GUI embedded
260 Python interpreter. Imagine, for instance, you are writing a script involving
261 geometry and mesh modules.
262 first, launch a %SALOME session with gui, then, on another terminal:
269 Import salome module. salome_init() without arguments creates a new study
270 in the running session (note: salome_init(n) attachs to a running session whose
278 An example of script given with SMESH:
281 import ex01_cube2build
284 It is possible to connect the GUI interface to the study created in the above
285 script with the file/connect menu, then browse study and display objects.
286 Further modifications on study can be done either with GUI or external script
287 (use refresh popup in GUI %object browser to see study modifications generated
288 by the external script). <b>AVOID modifications with GUI when a Python script
289 is running</b>. Not all the modules are protected against concurrent actions...
292 <b>Different uses of the runSession shell interpreter</b>
294 runSession invoked without arguments gives an interactive shell with the full
295 environment of %SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables).
296 If there are running sessions of the same %SALOME application, runSession
297 connects to the last launched session (i.e. gets the naming service references
298 of the session: hostname and port)
300 On Linux, the shell prompt (bash) gives information on naming service
301 references, hostname and port:
304 [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$
307 If there is no running session, prompt looks like:
310 [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$
313 runSession is useful to launch any script or program which needs the complete
314 %SALOME environment, with or without a session already running.
315 For instance, to launch the ddd debugger interface on the gui %server, first
316 launch a %SALOME session with gui, then, on another terminal:
322 Then attach to the running SALOME_Session_Server process.