doc/rappels.rst

   1
   2 :tocdepth: 3
   3
   4 .. _rappels:
   5
   6 ================================================================
   7 Rappels sur la plate-forme SALOME
   8 ================================================================
   9
  10 Définitions
  11 ================================================================
  12
  13   - **Module SALOME** : un module SALOME est un regroupement de composants SALOME. Il réside dans un répertoire
  14     dont la structure est standardisée. Ses composants sont décrits dans un fichier XML de nom <module>Catalog.xml.
  15
  16   - **Composant SALOME** : c'est l'équivalent SALOME d'un code de calcul. Il peut prendre la forme d'une bibliothèque dynamique ou
  17     d'un module Python.
  18
  19   - **Service SALOME** : chaque composant a un ou plusieurs services. Un service est l'équivalent d'une subroutine Fortran, d'une
  20     fonction C, d'une méthode C++ ou Python. Seuls les services de composant peuvent être couplés avec le coupleur YACS.
  21     Le couplage est réalisé en connectant les ports d'entrée-sortie dont sont dotés les services.
  22     Ces ports peuvent être de deux types : dataflow ou datastream.
  23
  24   - **Port dataflow** : un port dataflow est un point de connexion pour l'échange de données. Il a un nom qui est le
  25     nom de la variable échangée, un type qui indique le type de donnée (double, long, string, ...) et un sens (entrée
  26     ou sortie). On peut connecter un port dataflow entrant avec un port dataflow sortant d'un type compatible.
  27     La variable portée par le port est échangée en fin de service (port sortant) et en début de service (port entrant).
  28     Aucun échange de donnée n'a lieu pendant l'exécution du service.
  29
  30   - **Port datastream** : un port datastream permet l'échange de données pendant l'exécution. Comme un port dataflow, il
  31     a un nom, un type et un sens mais il a en plus un mode de dépendance itératif (I) ou temporel (T).
  32     On peut connecter un port datastream entrant uniquement avec un port datastream sortant de même type.
  33     Il peut exister plusieurs classes de port datastream.
  34     Ici, on ne traitera que des ports datastream CALCIUM.
  35
  36   - **Coupleur YACS** : c'est un module SALOME qui permet d'éditer et d'exécuter des schémas de couplage qui sont
  37     principalement sous la forme d'un fichier XML. Le module fournit une interface utilisateur graphique pour
  38     éditer un schéma, l'exécuter et suivre son exécution.
  39
  40   - **Instance de composant** : on peut avoir plusieurs exemplaires du même composant qui sont exécutés par SALOME
  41     dans une même session. Pour distinguer ces exemplaires, on parle d'instance de composant. On peut faire un parallèle
  42     avec les termes code de calcul (composant) et exécution (instance de composant).
  43
  44   - **Container** : Processus SALOME qui exécute les composants. Il a la responsabilité de charger (bibliothèque dynamique
  45     ou module Python) et d'enregistrer les composants. Le choix des containers peut avoir de l'importance si on veut
  46     qu'un composant ne soit pas dans le même exécutable qu'un autre.
  47
  48   - **Application SALOME** : ensemble de modules SALOME intégrés dans la plate-forme SALOME. Cette plate-forme
  49     est batie sur les modules de base KERNEL et GUI qui fournissent les services de lancement des composants
  50     et d'intégration dans l'IHM graphique. Une application SALOME fournit plusieurs scripts qui permettent
  51     de lancer l'application (runAppli), de se mettre dans l'environnement de l'application (runSession) et d'autres
  52     plus internes comme le lancement distant (runRemote)
  53
  54 Modules et composants SALOME
  55 ==================================================
  56 Dans son principe, la plate-forme SALOME est décomposée en une plate-forme
  57 de base nommée module KERNEL et une collection de modules divers.
  58
  59 Un module est un produit compilable et installable qui se concrétise par une arborescence source qui doit
  60 respecter les règles générales SALOME et qui comprend une procédure de construction, installation qui
  61 respecte également les règles SALOME.
  62 Chaque module est géré en configuration dans un module CVS
  63 indépendant. Chaque module peut livrer des versions à son rythme dans le respect des règles de
  64 cohérence de SALOME. A chaque module est associée une base de tests de non régression.
  65
  66 Un module a des dépendances avec les autres modules (utilise, est utilisé).
  67 Le module KERNEL constitue la base de la plate-forme SALOME.
  68 Tous les autres modules dépendent du module KERNEL.
  69
  70 ===================================== ========= ============= ==================================
  71 Thèmes                                 Modules    Utilise          Est utilisé par
  72 ===================================== ========= ============= ==================================
  73 Architecture                           KERNEL                  MED, GEOM, SMESH, VISU,YACS
  74 Architecture                           MED       KERNEL         SMESH, VISU
  75 Géométrie                              GEOM      KERNEL         SMESH
  76 Maillage                               SMESH     KERNEL, MED
  77 Supervision                            YACS      KERNEL
  78 Visualisation                          VISU      KERNEL, MED
  79 ===================================== ========= ============= ==================================
  80
  81 Un module contient un ou plusieurs composants SALOME. Un composant SALOME est un objet CORBA qui
  82 respecte les règles SALOME et qui est déclaré à SALOME au moyen d'un catalogue. Un composant SALOME
  83 peut être doté d'une interface utilisateur graphique (GUI) qui doit elle-même respecter les règles
  84 SALOME.
  85
  86 Les containers
  87 ======================
  88 Dans SALOME, les composants sont dynamiquement chargeables. Cette propriété est obtenu
  89 en utilisant un mécanisme de container.
  90
  91 Dans ses grandes lignes, un container est un serveur CORBA dont l'interface dispose
  92 des méthodes nécessaires pour effectuer le chargement déchargement de l'implémentation
  93 d'un composant SALOME. Pour effectuer le chargement d'un composant, on appellera la méthode
  94 load_impl du container.
  95
  96 La mécanique de base du chargement d'un composant est dépendante du langage d'implémentation choisi.
  97
  98 En C++, la plate-forme utilise le chargement dynamique de bibliothèque (dlopen) et un mécanisme de fonction
  99 factory dont le nom doit être <Module>Engine_factory (par exemple GEOMEngine_factory, pour GEOM).
 100 Cette fonction doit retourner l'objet CORBA effectif qui est le composant SALOME.
 101
 102 En Python, la plate-forme utilise le mécanisme d'import de Python (import <Module>) et instancie
 103 le composant SALOME Python en utilisant une classe (ou une factory) de même nom (<Module>) pour
 104 ce faire.
 105
 106 .. _appli:
 107
 108 Construction et utilisation d'une application SALOME
 109 =========================================================
 110 Ce document explique comment configurer, installer et utiliser votre propre
 111 application SALOME à partir d'une liste de modules préinstallés.
 112
 113 Principes
 114 ------------
 115
 116 Une application SALOME est construite à partir d'une liste de modules (GEOM, SMESH, ASTER...) de
 117 base de la plate-forme ou utilisateurs.
 118 Elle consiste en un jeu de scripts shell et de répertoires qui permettent d'exécuter l'application
 119 dans différents contextes.
 120
 121 Un utilisateur peut définir plusieurs applications SALOME. Ces applications
 122 sont utilisables à partir d'un même compte utilisateur. Elles peuvent utiliser
 123 les mêmes modules (KERNEL ou autre). L'application SALOME est indépendante de KERNEL
 124 et **ne doit pas être installée dans KERNEL_ROOT_DIR**.
 125
 126 Les prérequis utilisés par chaque application peuvent être différents.
 127
 128 Une session SALOME lancée à partir d'une application SALOME peut s'exécuter
 129 sur plusieurs calculateurs.
 130
 131 Pour une installation d'application multi-machines, les modules et les prérequis
 132 doivent être installés sur toutes les machines impliquées. Il n'est pas nécessaire
 133 d'installer tous les modules sur toutes les machines à part KERNEL.
 134 L'utilisateur SALOME doit avoir un compte sur chaque machine. L'accès aux machines
 135 distantes est réalisé par rsh ou ssh. Ces accès doivent être configurés pour
 136 un usage sans password. Les comptes peuvent être différents sur les différentes
 137 machines.
 138
 139 .. raw:: latex
 140
 141   \makeatletter
 142   \g@addto@macro\@verbatim\small
 143   \makeatother
 144
 145
 146 Créer une application SALOME
 147 ------------------------------
 148 On crée une application SALOME avec l'outil appli_gen.py que l'on trouve dans l'installation du module KERNEL.
 149 Cet outil construit l'application en partant d'un fichier de configuration au format XML qui décrit la liste
 150 des modules à utiliser (nom, chemin d'installation), le fichier qui positionne l'environnement
 151 pour les prérequis de SALOME et optionnellement le répertoire des exemples SALOME (SAMPLES_SRC).
 152
 153 La commande à utiliser est la suivante::
 154
 155    python <KERNEL_ROOT_DIR>/bin/salome/appli_gen.py --prefix=<install directory> --config=<configuration file>
 156
 157 où <configuration file> est le nom du fichier de configuration et <install directory> est le nom du répertoire
 158 dans lequel on veut créer l'application. <KERNEL_ROOT_DIR> indique le répertoire d'installation du module KERNEL.
 159
 160 On peut créer le fichier de configuration en modifiant une copie du fichier ${KERNEL_ROOT_DIR}/bin/salome/config_appli.xml.
 161
 162
 163 En voici un exemple::
 164
 165   <application>
 166   <prerequisites path="/data/tmplgls/secher/SALOME_V4.1.1_MD08/env_products.sh"/>
 167   <modules>
 168      <!-- variable name <MODULE>_ROOT_DIR is built with <MODULE> == name attribute value -->
 169      <!-- <MODULE>_ROOT_DIR values is set with path attribute value -->
 170      <!-- attribute gui (defaults = yes) indicates if the module has a gui interface -->
 171      <module name="KERNEL"       gui="no"  path="/data/SALOME_V4.1.1/KERNEL_INSTALL"/>
 172      <module name="GUI"          gui="no"  path="/data/SALOME_V4.1.1/GUI_4.1.1"/>
 173      <module name="MED"                    path="/data/SALOME_V4.1.1/MED_4.1.1"/>
 174      <module name="GEOM"                   path="/data/SALOME_V4.1.1/GEOM_4.1.1"/>
 175      <module name="SMESH"                  path="/data/SALOME_V4.1.1/SMESH_4.1.1"/>
 176      <module name="YACS"                   path="/data/SALOME_V4.1.1/YACS_4.1.1"/>
 177      <module name="VISU"                   path="/data/SALOME_V4.1.1/VISU_4.1.1"/>
 178      <module name="HELLO"                  path="/data/SALOME_V4.1.1/HELLO1_4.1.1"/>
 179      <module name="PYHELLO"                path="/data/SALOME_V4.1.1PYHELLO1_4.1.1"/>
 180      <module name="NETGENPLUGIN"           path="/data/SALOME_V4.1.1/NETGENPLUGIN_4.1.1"/>
 181   </modules>
 182   <samples path="/data/SALOME_V4.1.1/SAMPLES/4.1.1/SAMPLES_SRC"/>
 183   </application>
 184
 185 Quelques règles à suivre
 186 ------------------------------
 187
 188 Le répertoire d'application doit être créé sur tous les calculateurs qui devront exécuter des composants de cette application.
 189 La méthode la plus simple est de créer le répertoire d'application en utilisant le même chemin relatif par rapport au
 190 répertoire HOME sur chaque machine. Si ce n'est pas souhaité, il est possible d'utiliser des chemins différents suivant
 191 les calculateurs mais il faudra le préciser dans le fichier de configuration CatalogRessources.xml.
 192
 193 Le répertoire d'application contient des scripts pour initialiser les variables d'environnement et faire des exécutions.
 194
 195 L'environnement est initialisé par des scripts placés dans le sous répertoire env.d. Les scripts pour SALOME sont créés
 196 au moment de la création de l'application mais l'utilisateur peut ajouter ses propres scripts. Il suffit qu'ils aient
 197 comme suffixe .sh. Ces scripts doivent être installés sur toutes les machines de l'application.
 198
 199 L'application SALOME fournit à l'utilisateur 4 scripts d'exécution :
 200
 201   - **runAppli** lance une session SALOME (à la manière de ${KERNEL_ROOT_DIR}/bin/salome/runSalome).
 202   - **runSession** permet de se connecter, dans un shell avec un environnement conforme, à une session SALOME lancée
 203     précédemment. Sans argument, le script ouvre un shell interactif. Avec arguments, il exécute la commande
 204     fournie dans l'environnement de l'application SALOME.
 205   - **runConsole** ouvre une console python connectée à la session SALOME courante. Il est également possible d'utiliser
 206     runSession puis de lancer python.
 207
 208
 209 Les fichiers de configuration de l'application sont :
 210
 211   - **SALOMEApp.xml** : ce fichier est semblable au fichier par défaut qui se trouve dans ${GUI_ROOT_DIR}/share/SALOME/resources/gui.
 212     Il peut être adapté aux besoins de l'utilisateur.
 213   - **CatalogRessources.xml** : ce fichier décrit tous les calculateurs que l'application peut utiliser. Le fichier initial
 214     ne contient que la machine locale. L'utilisateur doit ajouter les machines à utiliser. Si on veut utiliser
 215     des répertoires d'application quelconques sur les différents calculateurs, il faut préciser dans ce fichier
 216     leur localisation avec l'attribut appliPath::
 217
 218         appliPath="my/specific/path/on/this/computer"
 219
 220
 221
 222
 223
 224