X-Git-Url: http://git.salome-platform.org/gitweb/?a=blobdiff_plain;f=doc%2Fsalome%2Fsalome_application.dox;h=c909d4e3b4f0d8ce4ab48a920acfb3bdad481c78;hb=cca842065fd2bb93bae7ed6c32a7de16b06f94d9;hp=bd79433d910aab44bbbf6adca0c3b9ff320f3474;hpb=e429ce02076e083051c6520e0d7113022bd67b18;p=modules%2Fkernel.git diff --git a/doc/salome/salome_application.dox b/doc/salome/salome_application.dox index bd79433d9..c909d4e3b 100644 --- a/doc/salome/salome_application.dox +++ b/doc/salome/salome_application.dox @@ -1,26 +1,28 @@ /*! - \page SALOME_Application Salome Application Concept + \page SALOME_Application Salome Application Concept The following explains how to configure your own application with your list of modules, how to define and run this application on one or more computers. +You can choose one of the following approaches: +-# use an \ref sec_salome_profile +-# use a \ref sec_virtual_appli \section S1_sal_appl General principles -%A %SALOME application is defined by : +%A %SALOME application is defined by: - a set of modules (GEOM, SMESH, ASTER...) -- a profile: set of informatic resources (images, documentation, tests...) binding the modules together. -- a launcher: python script that creates a context (set of environment variables usable by the SALOME modules) and runs an instance of SALOME. - +- a set of informatic resources (images, documentation, tests...) binding the modules together, also called profile. +- a launcher: a python script that creates a context (set of environment variables usable by the %SALOME modules) and runs an instance of %SALOME. -%A %SALOME User can define several %SALOME Applications. These applications are -runnable from the same user account. These applications may share the same -KERNEL and modules. Thus, the application configuration is independant of +%A %SALOME user can define several %SALOME applications. These applications are +runnable from the same user account. These applications may share the same +KERNEL and modules. Thus, the application configuration is independent of KERNEL and must not be put in KERNEL_ROOT_DIR. Furthermore, prerequisites may not be the same on all the applications. -%A %SALOME Session can run on a several computers. +%A %SALOME session can run on a several computers. Binary modules and prerequisites are installed on the different computers. There is no need to have all the modules on each computer (the minimum is @@ -40,7 +42,8 @@ account@computer is via rsh or ssh and must be configured for use without password (key exchange for ssh). Account may be different on each computer. -\section S2_sal_appl Generation of a profile + +\section sec_salome_profile Application profile The user can generate a default profile for its application using the following command: \code @@ -60,14 +63,14 @@ This profile can be used within a python launcher - like the \subpage salome_com context variable SalomeAppConfig to the path where the profile is installed. -\section S3_sal_appl Deprecated Application Directory +\section sec_virtual_appli Virtual application First, the user must create a %SALOME application configuration file by modifying a copy of ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml. The file describes the list of %SALOME modules used in the application, with their respective installation path. The configuration file also defines the path of an existing script which sets the %SALOME prerequisites (tag "prerequisites"), -and optionally, the path of samples directory (SAMPLES_SRC) (tag "samples") +and optionally, the path of samples directory (SAMPLES_SRC) (tag "samples") and the path of a catalog of resources (tag "resources"). The following command: @@ -87,262 +90,6 @@ some modules needs a special environment not defined in the above script). For a distributed application (several computers), one must copy and adapt CatalogResources.xml from ${KERNEL_ROOT_DIR}/bin/salome/appliskel (see below). -\section S4_sal_appl Deprecated general rules - -The application directory must be created on each computer of the application. -The easiest way is to use the same relative path (to ${HOME}) on each computer. -(Sometimes it is not possible to use the same path everywhere, for instance -when ${HOME} is shared with NFS, so it is possible to define different path -following the computers). - -The application directory contains scripts for environment and runs. Environment -scripts must be configured (by the user) on each computer. All the environment -scripts are in the env.d subdirectory. - -The script envd sources \b all the files (*.sh) in subdirectory env.d -in alphanumeric order (after edition, think to remove backup files). The envd -script is used by run scripts. - -
    -
  1. -env.d scripts - -env.d scripts are built automatically. - -You can add your own environment scripts in env.d subdirectory, they will be sourced as -the generated ones provided they have a .sh extension. - -
    2. -
  2. -User run scripts - -The %SALOME user can use 4 scripts: - -- runAppli\n - Launches a %SALOME Session - (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different - name to avoid confusions). See parameters below. - -- runSession\n - Launches a shell script in the %SALOME application environment, with access - to the current (last launched) %SALOME session (naming service), if any. - Without arguments, the script is interactive. With arguments, the script - executes the command in the %SALOME application environment. - -- runConsole\n - Gives a python console connected to the current %SALOME Session. - It is also possible to use runSession, then python. - -- runTests\n - Similar to runSession, used for unit testing, but runSession tries to use an - already existing naming service definition from a running session (hostname - and port number), and runTests defines a new configuration for naming service - (new port number). -
    3. -
  3. -%SALOME internal run scripts - -- envd\n - Sets %SALOME application environment, envd is sourced by other scripts. - -For remote calls, %SALOME uses one script. - -- runRemote.sh\n - This script is mainly used to launch containers. The first 3 arguments - define the hostname and port userd for naming service, plus a working directory, the remaining - arguments define the command to execute. -
    4. -
  4. -Other configuration files - -- SALOMEApp.xml\n - This file is similar to the default given - in ${GUI_ROOT_DIR}/share/SALOME/resources/gui - - -- CatalogRessources.xml\n - This file describes all the computers the application can use. The given - example is minimal and suppose application directory is the same relative path - to ${HOME}, on all the computers. %A different directory can be set on a - particular computer with a line: - \code -appliPath="my/specific/path/on/this/computer" - \endcode - -
    5. -
- -\section S5_sal_appl Deprecated examples of use - -
    -
  1. -Launch a %SALOME session with a GUI interface - -Launch is done with a command like: - -\code -./runAppli --logger -\endcode - -The --logger option means here : collect all the traces from the all the -distributed process, via CORBA, in a single file : logger.log. - -There are a lot of options, a complete list is given by: - -\code -./runAppli --help -\endcode - -Note that, without argument, runAppli is a non interactive Python application, -and, with arguments, runAppli is an interactive Python interpreter. - -Several options are already defined by default in SALOMEApp.xml files. Optional -arguments given in the command override the SALOMEApp.xml configuration. - -Several sessions can run simultaneously, each session use a different port for -CORBA naming service, so the sessions are totally separated from each other. - -When the GUI is closed, the different %SALOME servers are still running. -
    2. -
  2. -Close a %SALOME session, kill all the servers - -Inside the interactive python interpreter you get when you use runAppli -with arguments, you can kill all the servers of your session with: - -\code ->>> killLocalPort() -\endcode - -or the servers of all the sessions with: - -\code ->>> killAllPorts() -\endcode - -If you have no active Python interpreter connected to your session, you can -kill all the %SALOME servers of all the sessions on a given computer: - -\code -./runSession killSalome.py -\endcode - -Remember! it's the same idea in Windows (R) operating system (Microsoft and Windows are either registered trademarks or trademarks of - Microsoft Corporation in the United States and/or other countries) : -use the start menu to stop... - -When you use only one session at a time, you don't need more. - -To kill a given session (when several session are running), one needs -the naming service port number: - -\code -./runSession killSalomeWithPort 2810 -\endcode - -Note that the port number of the last launched session can be found on Linux, -in the prompt, within a runSession shell (see below). - -It is also possible to get the Naming Service host and port number of -the last launched session with: - -\code -./runSession NSparam.py -\endcode - -
    3. -
  3. -Launch a %SALOME session without GUI interface - -This is used to launch a %SALOME Python script without GUI -(no GUI %server = SALOME_session_server) - -Example of script (test_session_geom.py): - -\code -import salome_session -salome_session.startSession(modules=["GEOM"]) -import GEOM_usinggeom -raw_input("Press a key and the servers will be killed ...") -\endcode - -This script is run in a non interactive way with: - -\code -./runSession python test_session_geom.py -\endcode - -All the process are automatically killed when Python is closed -(with SALOME_session delete). -
    4. -
  4. -Add an external Python interpretor to a running session - -It's often easier to develop and try Python scripts outside the GUI embedded -Python interpreter. Imagine, for instance, you are writing a script involving -geometry and mesh modules. -first, launch a %SALOME session with gui, then, on another terminal: - -\code -./runSession -python -\endcode - -Import salome module. salome_init() without arguments creates a new study -in the running session (note: salome_init(n) attachs to a running session whose -studyId is n): - -\code -import salome -salome.salome_init() -\endcode - -An example of script given with SMESH: - -\code -import ex01_cube2build -\endcode - -It is possible to connect the GUI interface to the study created in the above -script with the file/connect menu, then browse study and display objects. -Further modifications on study can be done either with GUI or external script -(use refresh popup in GUI %object browser to see study modifications generated -by the external script). AVOID modifications with GUI when a Python script -is running. Not all the modules are protected against concurrent actions... -
    5. -
  5. -Different uses of the runSession shell interpreter - -runSession invoked without arguments gives an interactive shell with the full -environment of %SALOME (PATH, LD_LIBRARY_PATH, PYTHONPATH, other variables). -If there are running sessions of the same %SALOME application, runSession -connects to the last launched session (i.e. gets the naming service references -of the session: hostname and port) - -On Linux, the shell prompt (bash) gives information on naming service -references, hostname and port: - -\code -[NS=cli76cc:2811]prascle@cli76cc:~/SALOME2/Run/Virtual$ -\endcode - -If there is no running session, prompt looks like: - -\code -[NS=:]prascle@cli76cc:~/SALOME2/Run/Virtual$ -\endcode - -runSession is useful to launch any script or program which needs the complete -%SALOME environment, with or without a session already running. -For instance, to launch the ddd debugger interface on the gui %server, first -launch a %SALOME session with gui, then, on another terminal: - -\code -./runSession ddd -\endcode - -Then attach to the running SALOME_Session_Server process. -
    6. -
+The application directory contains the elements required to run %SALOME, for example the \ref salome_command, and some context files in env.d directory. */