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 :
11 - a set of modules (GEOM, SMESH, ASTER...)
12 - a profile: set of informatic resources (images, documentation, tests...) binding the modules together.
13 - a launcher: python script that creates a context (set of environment variables usable by the SALOME modules) and runs an instance of SALOME.
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 Generation of a profile
45 The user can generate a default profile for its application using the following command:
47 python ${KERNEL_ROOT_DIR}/bin/salome/app-quickstart.py --prefix=<generation directory> --name=<application's name> --modules=<list,of,modules>
50 Likely, the user would like to personalize its application's profile. Then, the profile
51 can be compiled using the standard cmake procedure:
59 This profile can be used within a python launcher - like the \subpage salome_command - by setting
60 context variable <b>SalomeAppConfig</b> to the path where the profile is installed.
63 \section S3_sal_appl Deprecated Application Directory
65 First, the user must create a %SALOME application configuration file by modifying a
66 copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml.
67 The file describes the list of %SALOME modules used in the application, with
68 their respective installation path. The configuration file also defines the
69 path of an existing script which sets the %SALOME prerequisites (tag "prerequisites"),
70 and optionally, the path of samples directory (SAMPLES_SRC) (tag "samples")
71 and the path of a catalog of resources (tag "resources").
73 The following command:
76 python <KERNEL_ROOT_DIR>/bin/salome/appli_gen.py --prefix=<install directory> --config=<configuration file>
79 creates a %SALOME application in the application directory given by the prefix option (local directory
80 by default) with the configuration file given by the config option (config_appli.xml by default).
82 Providing an existing script for %SALOME prerequisites (the same one
83 used for modules compilation, or given with the modules installation), the
84 installation works without further modification for a single computer (unless
85 some modules needs a special environment not defined in the above script).
87 For a distributed application (several computers), one must copy and adapt
88 CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below).
90 \section S4_sal_appl Deprecated general rules
92 The application directory must be created on each computer of the application.
93 The easiest way is to use the same relative path (to ${HOME}) on each computer.
94 (Sometimes it is not possible to use the same path everywhere, for instance
95 when ${HOME} is shared with NFS, so it is possible to define different path
96 following the computers).
98 The application directory contains scripts for environment and runs. Environment
99 scripts must be configured (by the user) on each computer. All the environment
100 scripts are in the env.d subdirectory.
102 The script envd sources \b all the files (*.sh) in subdirectory env.d
103 in alphanumeric order (after edition, think to remove backup files). The envd
104 script is used by run scripts.
110 <b>env.d scripts are built automatically.</b>
112 You can add your own environment scripts in env.d subdirectory, they will be sourced as
113 the generated ones provided they have a .sh extension.
117 <b>User run scripts</b>
119 The %SALOME user can use 4 scripts:
122 Launches a %SALOME Session
123 (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
124 name to avoid confusions). See parameters below.
127 Launches a shell script in the %SALOME application environment, with access
128 to the current (last launched) %SALOME session (naming service), if any.
129 Without arguments, the script is interactive. With arguments, the script
130 executes the command in the %SALOME application environment.
133 Gives a python console connected to the current %SALOME Session.
134 It is also possible to use runSession, then python.
137 Similar to runSession, used for unit testing, but runSession tries to use an
138 already existing naming service definition from a running session (hostname
139 and port number), and runTests defines a new configuration for naming service
143 <b>%SALOME internal run scripts</b>
146 Sets %SALOME application environment, envd is sourced by other scripts.
148 For remote calls, %SALOME uses one script.
151 This script is mainly used to launch containers. The first 3 arguments
152 define the hostname and port userd for naming service, plus a working directory, the remaining
153 arguments define the command to execute.
156 <b>Other configuration files</b>
159 This file is similar to the default given
160 in ${GUI_ROOT_DIR}/share/SALOME/resources/gui
163 - CatalogRessources.xml\n
164 This file describes all the computers the application can use. The given
165 example is minimal and suppose application directory is the same relative path
166 to ${HOME}, on all the computers. %A different directory can be set on a
167 particular computer with a line:
169 appliPath="my/specific/path/on/this/computer"
175 \section S5_sal_appl Deprecated examples of use
179 <b>Launch a %SALOME session with a GUI interface</b>
181 Launch is done with a command like:
187 The --logger option means here : collect all the traces from the all the
188 distributed process, via CORBA, in a single file : logger.log.
190 There are a lot of options, a complete list is given by:
196 Note that, without argument, runAppli is a non interactive Python application,
197 and, with arguments, runAppli is an interactive Python interpreter.
199 Several options are already defined by default in SALOMEApp.xml files. Optional
200 arguments given in the command override the SALOMEApp.xml configuration.
202 Several sessions can run simultaneously, each session use a different port for
203 CORBA naming service, so the sessions are totally separated from each other.
205 When the GUI is closed, the different %SALOME servers are still running.
208 <b>Close a %SALOME session, kill all the servers</b>
210 Inside the interactive python interpreter you get when you use runAppli
211 with arguments, you can kill all the servers of your session with:
217 or the servers of all the sessions with:
223 If you have no active Python interpreter connected to your session, you can
224 kill all the %SALOME servers of <b>all the sessions</b> on a given computer:
227 ./runSession killSalome.py
230 Remember! it's the same idea in <b>Windows (R) operating system</b> (Microsoft and Windows are either registered trademarks or trademarks of
231 Microsoft Corporation in the United States and/or other countries) :
232 use the start menu to stop...
234 When you use only one session at a time, you don't need more.
236 To kill a given session (when several session are running), one needs
237 the naming service port number:
240 ./runSession killSalomeWithPort 2810
243 Note that the port number of the last launched session can be found on Linux,
244 in the prompt, within a runSession shell (see below).
246 It is also possible to get the Naming Service host and port number of
247 the last launched session with:
250 ./runSession NSparam.py
255 <b>Launch a %SALOME session without GUI interface</b>
257 This is used to launch a %SALOME Python script without GUI
258 (no GUI %server = SALOME_session_server)
260 Example of script (test_session_geom.py):
263 import salome_session
264 salome_session.startSession(modules=["GEOM"])
265 import GEOM_usinggeom
266 raw_input("Press a key and the servers will be killed ...")
269 This script is run in a non interactive way with:
272 ./runSession python test_session_geom.py
275 All the process are automatically killed when Python is closed
276 (with SALOME_session delete).
279 <b>Add an external Python interpretor to a running session</b>
281 It's often easier to develop and try Python scripts outside the GUI embedded
282 Python interpreter. Imagine, for instance, you are writing a script involving
283 geometry and mesh modules.
284 first, launch a %SALOME session with gui, then, on another terminal:
291 Import salome module. salome_init() without arguments creates a new study
292 in the running session (note: salome_init(n) attachs to a running session whose
300 An example of script given with SMESH:
303 import ex01_cube2build
306 It is possible to connect the GUI interface to the study created in the above
307 script with the file/connect menu, then browse study and display objects.
308 Further modifications on study can be done either with GUI or external script
309 (use refresh popup in GUI %object browser to see study modifications generated
310 by the external script). <b>AVOID modifications with GUI when a Python script
311 is running</b>. Not all the modules are protected against concurrent actions...
314 <b>Different uses of the runSession shell interpreter</b>
316 runSession invoked without arguments gives an interactive shell with the full
317 environment of %SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables).
318 If there are running sessions of the same %SALOME application, runSession
319 connects to the last launched session (i.e. gets the naming service references
320 of the session: hostname and port)
322 On Linux, the shell prompt (bash) gives information on naming service
323 references, hostname and port:
326 [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$
329 If there is no running session, prompt looks like:
332 [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$
335 runSession is useful to launch any script or program which needs the complete
336 %SALOME environment, with or without a session already running.
337 For instance, to launch the ddd debugger interface on the gui %server, first
338 launch a %SALOME session with gui, then, on another terminal:
344 Then attach to the running SALOME_Session_Server process.