1 ======================================================================
2 SALOME Application Concept. Configuration for one or more computers
3 ======================================================================
5 *html version of this document is produced with docutils*::
7 rst2html doc.txt > doc.html
9 This document corresponds to SALOME2 3.2.0
14 +-------------------------------------------+
15 | **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
16 +-------------------------------------------+
18 -------------------------------------------------------------------------------
20 The following explains how to configure your own application with your list of
21 modules, how to define and run this application on one or more computers.
26 A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...).
28 A SALOME User can define several SALOME Applications. These applications are
29 runnable from the same user account. These applications may share the same
30 KERNEL and modules. Thus, the application configuration is independant of
31 KERNEL and must not be put in KERNEL_ROOT_DIR.
33 Furthermore, prerequisites may not be the same on all the applications.
35 A SALOME Session can run on a several computers.
37 Binary modules and prerequisites are installed on the different computers.
38 There is no need to have all the modules on each computer (the minimum is
41 There is no need of standardization or centralised information on the details
42 of configuration on each computer (PATH, LD_LIBRARY_PATH, environment
43 variables) provided the application modules are version - compatible. Details
44 of configuration stay private to the computer, and are held by scripts on each
47 There is no hierarchy between the computers (for example only one master
48 computer used to launch application).
50 The SALOME user has an account on all the computers. Access between
51 account@computer is via rsh or ssh and must be configured for use without
52 password (key exchange for ssh). Account may be different on each
58 Two ways for creation of an application directory
59 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61 First way - references to different module directories
62 ''''''''''''''''''''''''''''''''''''''''''''''''''''''
64 The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an
65 application directory with the given path in parameter. ${APPLI} is a path
68 The directory is only a skeleton, the user has to edit several files to
69 configure his own application. These files are described after, the list is:
72 - env.d/envProducts.sh
74 - CatalogResources.xml
77 Second way - one single virtual install directory
78 '''''''''''''''''''''''''''''''''''''''''''''''''
80 The user must create an application directory in which he copies
81 appli_install.sh, appli_clean.sh and virtual_salome.py,
82 from ${KERNEL_ROOT_DIR}/bin/salome.
84 appli_install.sh needs to be edited, to define a list of modules with their
86 Then, the script appli_install.sh creates a virtual installation of SALOME
87 in the application directory (bin, lib, doc, share...), with,
88 for each file (executable, script, data,library, resources...),
89 symbolic links to the actual file.
94 Directory ${APPLI} must be created on each computer of the application.
95 The easiest way is to use the same relative path (to ${HOME}) on each computer.
96 (Sometimes it is not possible to use the same path everywhere, for instance
97 when ${HOME} is shared with NFS, so it is possible to define different path
98 following the computers).
100 The ${APPLI} directory contains scripts for environment and runs. Environment
101 scripts must be configured (by the user) on each computer. All the environment
102 scripts are in the ${APPLI}/env.d directory.
104 The script ${APPLI}/envd sources **all** the files (\*.sh) in ${APPLI}/env.d
105 in alphanumeric order (after edition, think to remove backup files). the envd
106 script is used by run scripts.
112 Each user **must define** his own configuration for these scripts, following
113 the above rules. With the virtual installation (second way, above), env.d
114 scripts are built by appli_install.sh (given it's parameters). Otherwise, the
115 scripts must be manually defined.
118 **The following is only an example proposed by createAppli.sh,
119 not working as it is**.
122 Sets the computer configuration not directly related to SALOME,
123 like useful tools, default PATH.
126 Sets the SALOME prerequisites.
129 Sets all the MODULE_ROOT_DIR that can be used in the SALOME application.
131 SalomeAppConfig is also defined by::
133 export SalomeAppConfig=${HOME}/${APPLI}
135 where SalomeAppConfig designates the directory containing SalomeApp.xml.
136 Note that ${APPLI} is already defined by the calling scripts when
137 env.d/envSalome.sh is sourced.
142 The SALOME user can use 4 scripts:
145 Launches a SALOME Session
146 (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
147 name to avoid confusions).
150 Launches a shell script in the SALOME application environment, with access
151 to the current (last launched) SALOME session (naming service), if any.
152 Without arguments, the script is interactive. With arguments, the script
153 executes the command in the SALOME application environment.
156 Gives a python console connected to the current SALOME Session.
157 It is also possible to use runSession, then python.
160 Similar to runSession, used for unit testing. runSession tries to use an
161 already existing naming service definition from a running session (hostname
162 and port number), runTests defines a new configuration for naming service
165 SALOME internal run scripts
166 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
169 Sets SALOME application environment, envd is sourced by other scripts.
171 For remote calls, SALOME uses one script.
174 This script is mainly used to launch containers. The first 2 arguments
175 define the hostname and port userd for naming service, the remaining
176 arguments define the command to execute.
178 Other configuration files
179 ~~~~~~~~~~~~~~~~~~~~~~~~~
182 This file is similar to the default given
183 in ${GUI_ROOT_DIR}/share/salome/resources
186 CatalogRessources.xml
187 This files describes all the computer the application can use. The given
188 example is minimal and suppose ${APPLI} is the same relative path
189 to ${HOME}, on all the computers. A different directory can be set on a
190 particular computer with a line::
192 appliPath="my/specific/path/on/this/computer"
198 Launch a SALOME session with a GUI interface
199 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
201 Launch is done with a command like::
205 The --logger option means here : collect all the traces from the all the
206 distributed process, via CORBA, in a single file : logger.log.
208 There are a lot of options, a complete list is given by::
212 Note that, without argument, runAppli is a non interactive Python application,
213 and, with arguments, runAppli is an interactive Python interpreter.
215 Several options are already defined by default in SalomeApp.xml files. Optional
216 arguments given in the command override the SalomeApp.xml configuration.
218 Several sessions can run simultaneously, each session use a different port for
219 CORBA naming service, so the sessions are totally separated from each other.
221 When the GUI is closed, the different SALOME servers are still running.
223 Close a SALOME session, kill all the servers
224 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
226 Inside the interactive python interpreter you get when you use runAppli
227 with arguments, you can kill all the servers of your session with::
231 or the servers of all the sessions with::
235 If you have no active Python interpreter connected to your session, you can
236 kill all the SALOME servers of **all the sessions** on a given computer::
238 ./runSession killSalome.py
240 Remember! it's the same idea in *Windows (R) operating system* [#]_ :
241 use the start menu to stop...
243 When you use only one session at a time, you don't need more.
245 To kill a given session (when several session are running), one needs
246 the naming service port number::
248 ./runSession killSalomeWithPort 2810
250 Note that the port number of the last launched session can be found on Linux,
251 in the prompt, within a runSession shell (see below).
253 It is also possible to get the Naming Service host and port number of
254 the last launched session with::
256 ./runSession NSparam.py
258 .. [#] Microsoft and Windows are either registered trademarks or trademarks of
259 Microsoft Corporation in the United States and/or other countries.
261 Launch a SALOME session without GUI interface
262 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
264 This is used to launch a SALOME Python script without GUI
265 (no GUI server = SALOME_session_server)
267 Example of script (test_session_geom.py)::
269 import salome_session
270 salome_session.startSession(modules=["GEOM"])
271 import GEOM_usinggeom
272 raw_input("Press a key and the servers will be killed ...")
274 This script is run in a non interactive way with::
276 ./runSession python test_session_geom.py
278 All the process are automatically killed when Python is closed
279 (with salome_session delete).
281 Add an external Python interpretor to a running session
282 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
284 It's often easier to develop and try Python scripts outside the GUI embedded
285 Python interpreter. Imagine, for instance, you are writing a script involving
286 geometry and mesh modules.
287 first, launch a SALOME session with gui, then, on another terminal::
292 Import salome module. salome_init() without arguments creates a new study
293 in the running session (note: salome_init(n) attachs to a running session whose
299 An example of script given with SMESH::
301 import ex01_cube2build
303 It is possible to connect the GUI interface to the study created in the above
304 script with the file/connect menu, then browse study and display objects.
305 Further modifications on study can be done either with GUI or external script
306 (use refresh popup in GUI object browser to see study modifications generated
307 by the external script). **AVOID modifications with GUI when a Python script
308 is running**. Not all the modules are protected against concurrent actions...
311 Different uses of the runSession shell interpreter
312 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
314 runSession invoked without arguments gives an interactive shell with the full
315 environment of SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables).
316 If there are running sessions of the same SALOME application, runSession
317 connects to the last launched session (i.e. gets the naming service references
318 of the session: hostname and port)
320 On Linux, the shell prompt (bash) gives information on naming service
321 references, hostname and port::
323 [NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$
325 If there is no running session, prompt looks like::
327 [NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$
329 runSession is useful to launch any script or program which needs the complete
330 SALOME environment, with or without a session already running.
331 For instance, to launch the ddd debugger interface on the gui server, first
332 launch a SALOME session with gui, then, on another terminal::
336 Then attach to the running SALOME_Session_Server process.
339 -------------------------------------------------------------------------------
341 +----------------------------------+------------------------------------------+
342 | `General KERNEL documentation`_ | `End User KERNEL Doxygen documentation`_ |
343 +----------------------------------+------------------------------------------+
345 .. _`General KERNEL documentation`: ./index.html
346 .. _`End User KERNEL Doxygen documentation`: ./tui/KERNEL/index.html