X-Git-Url: http://git.salome-platform.org/gitweb/?a=blobdiff_plain;ds=sidebyside;f=doc%2Fsalome%2Fsalome_application.dox;h=c909d4e3b4f0d8ce4ab48a920acfb3bdad481c78;hb=cca842065fd2bb93bae7ed6c32a7de16b06f94d9;hp=bd79433d910aab44bbbf6adca0c3b9ff320f3474;hpb=2040dac9febbf6fe0eb1b6b10818be2027953441;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.
-
-
- -
-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.
-
-
- -
-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).
-
- -
-%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.
-
- -
-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
-
-
-
-
-\section S5_sal_appl Deprecated examples of use
-
-
- -
-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.
-
- -
-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
-
-
- -
-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).
-
- -
-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...
-
- -
-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.
-
-
+The application directory contains the elements required to run %SALOME, for example the \ref salome_command, and some context files in env.d directory.
*/