6 Principes généraux de YACS
7 ===============================
8 La construction d'un schéma de calcul s'appuie sur le concept de noeud de calcul.
9 Un noeud de calcul représente un calcul élémentaire qui peut être l'exécution
10 locale d'un script Python ou l'exécution distante d'un service de composant SALOME.
12 Le schéma de calcul est un assemblage de noeuds de calcul plus ou moins complexe.
14 Cet assemblage est réalisé par connexion de ports d'entrée et de sortie de ces noeuds
17 Les données sont échangées entre noeuds via les ports. Elles sont typées.
19 Les noeuds composés : Bloc, Loop, Switch, permettent de modulariser un schéma de calcul
20 et de définir des processus itératifs, des calculs paramétriques ou des débranchements.
22 Enfin les containers permettent de définir où seront exécutés les composants SALOME
23 (sur un réseau ou un cluster).
28 ----------------------
29 Les données échangées entre noeuds de calcul via les ports sont typées.
30 On a 4 catégories de types : les types de base, les références d'objets, les séquences et les
32 Il est possible de définir des types utilisateurs par composition de ces éléments de base.
33 De nombreux types sont prédéfinis soit par YACS soit par les composants utilisés comme GEOM ou SMESH.
37 Les types de base sont au nombre de 5 : int, double, bool, string et file. Ils sont prédéfinis par YACS.
39 ================= =====================================
41 ================= =====================================
43 double pour les réels doubles
44 bool pour les booléens
45 string pour les chaines de caractères
46 file pour les fichiers
47 ================= =====================================
49 Les références d'objet
50 ''''''''''''''''''''''''''
51 Les références d'objet sont utilisées pour typer les objets CORBA gérés par les composants SALOME.
52 En général, ces types sont définis par les composants qui les utilisent.
53 Pour définir un type YACS référence d'objet, il suffit de lui donner un nom et de l'associer
54 au Repository ID CORBA. Voici quelques exemples de types prédéfinis.
56 ================= ==============================
57 Type YACS Repository ID CORBA
58 ================= ==============================
59 Study IDL:SALOMEDS/Study:1.0
60 SObject IDL:SALOMEDS/SObject:1.0
61 GEOM_Shape IDL:GEOM/GEOM_Object:1.0
62 MESH IDL:SALOME_MED/MESH:1.0
63 FIELD IDL:SALOME_MED/FIELD:1.0
64 ================= ==============================
66 Il est possible de définir des relations d'héritage simple ou multiple entre ces types.
67 Voici un exemple extrait du composant MED.
69 ================= ============================== =====================================
70 Type YACS Types de base Repository ID CORBA
71 ================= ============================== =====================================
72 FIELDDOUBLE FIELD IDL:SALOME_MED/FIELDDOUBLE:1.0
73 ================= ============================== =====================================
75 YACS définit également des types pour les ports datastream :
77 ================= =======================================================
78 Type YACS Repository ID CORBA
79 ================= =======================================================
80 CALCIUM_integer IDL:Ports/Calcium_Ports/Calcium_Integer_Port:1.0
81 CALCIUM_real IDL:Ports/Calcium_Ports/Calcium_Real_Port:1.0
82 CALCIUM_double IDL:Ports/Calcium_Ports/Calcium_Double_Port:1.0
83 CALCIUM_string IDL:Ports/Calcium_Ports/Calcium_String_Port:1.0
84 CALCIUM_logical IDL:Ports/Calcium_Ports/Calcium_Logical_Port:1.0
85 CALCIUM_boolean IDL:Ports/Calcium_Ports/Calcium_Logical_Port:1.0
86 CALCIUM_complex IDL:Ports/Calcium_Ports/Calcium_Complex_Port:1.0
87 ================= =======================================================
89 On peut avoir la liste des types disponsibles en consultant les catalogues des composants
90 SALOME : GEOMCatalog.xml, SMESHCatalog.xml, MEDCatalog.xml, etc. Ces catalogues sont au format XML
91 qui est décrit ici : :ref:`schemaxml`. On peut également en avoir une vue dans l'IHM graphique en
92 consultant le catalogue de composants.
96 Un type séquence sert à typer une liste d'éléments homogènes. Le type contenu dans la liste est le même
97 pour tous les éléments.
98 Pour définir un type séquence, on lui donne un nom et on spécifie le type des éléments de la séquence.
100 Le KERNEL de SALOME définit des types séquences pour les types de base.
102 ================= ==============================
103 Type YACS Type des éléments
104 ================= ==============================
109 ================= ==============================
111 Il est possible de définir un type séquence de séquence. Dans ce cas, le type de l'élément est un type séquence.
115 Le type structure sert à typer une donnée structurée comme un struct C. Cette donnée contient des membres nommés
117 Pour définir un type structure, on lui donne un nom et on spécifie la liste des membres (nom, type).
119 Le composant GEOM définit un type structure de nom "BCError" comportant un seul membre de nom "incriminated" et
120 de type "ListOfLong". "ListOfLong" est lui-même une séquence d'"int".
124 Un port peut être considéré comme une interface d'un noeud avec l'extérieur.
125 Il existe trois types de port : les ports de contrôle, les ports de données et les ports datastream.
126 Chacun a une sémantique différente.
128 Les ports de contrôle
129 ''''''''''''''''''''''''
130 Ce type de port est utilisé pour mettre des contraintes sur des enchainements d'exécution de noeuds.
131 Un noeud élémentaire ou composé dispose, en général, d'un port de contrôle entrant et d'un port
133 Un noeud qui a son port de contrôle d'entrée connecté au port de sortie d'un autre noeud ne
134 sera exécuté que lorsque ce deuxième noeud sera terminé.
137 ''''''''''''''''''''''''
138 Ce type de port est utilisé pour définir les données qui seront utilisées par le noeud lors de son exécution
139 et les données qui seront produites par le noeud à la fin de son exécution.
140 Un port de données a un nom, un sens (input, output) et les données qu'il portent ont un type.
141 L'ordre de définition des ports est important car il est utilisé comme ordre des arguments lors de l'appel
142 des services de composants SALOME.
144 De façon générale, l'exécution d'un noeud de calcul élémentaire se passe comme suit :
145 - le contrôle est donné au noeud via le port de contrôle d'entrée
146 - les données d'entrée sont acquises par le noeud via les ports de données d'entrée
148 - les données de sortie sont fournies aux ports de sortie
149 - le contrôle est rendu par le noeud via le port de contrôle de sortie
151 Un port de données d'entrée peut être initialisé ou connecté à un port de données de sortie.
154 ''''''''''''''''''''''''
155 Ce type de port est utilisé pour l'échange de données pendant l'exécution. Tous les noeuds élémentaires ne supportent
156 pas ce type de port. Pour le moment seuls les noeuds liés à des composants SALOME supportent ce type de port.
157 Un port datastream a un nom, un sens (input, output) et un type.
158 Ce type n'est pas directement le type d'une donnée mais plutôt celui d'un objet CORBA qui gère l'échange de
159 données (voir ports DSC pour plus d'informations).
161 Les noeuds de calcul élémentaires
162 -------------------------------------
163 Un noeud de calcul élémentaire représente une fonction de calcul particulière (multiplication de 2 matrices, par exemple).
164 Tout noeud de calcul a un type.
165 On peut avoir un type de noeud qui exécute un service d'un composant Salome et un autre
166 type de noeud qui exécute un bout de script Python.
167 Les noeuds de calcul élémentaires se répartissent en deux catégories : les noeuds inlines
168 qui s'exécutent en local dans le coupleur YACS et les noeuds de service qui s'exécutent à
169 distance et correspondent à la mise en oeuvre de composants SALOME.
171 Tout noeud de calcul a un nom qui sert d'identificateur. Cet identificateur doit etre unique dans son contexte de définition.
172 Un schéma de calcul ou un noeud composé définit un contexte.
174 Un noeud de calcul a un port de contrôle d'entrée et un port de contrôle de sortie.
175 Ces ports de contrôle sont connectés à travers le flot de contrôle.
177 Un noeud de calcul a, en général, des ports de données d'entrée et de sortie.
178 Le nombre et le type des ports de données est déterminé par le type de noeud de calcul.
179 Ces ports de données sont connectés à travers le flot de données.
181 Un noeud de calcul peut avoir des propriétés. Une propriété est un couple (nom, valeur)
182 où nom est le nom de la propriété et valeur une chaine de caractère qui donne sa valeur.
184 Noeud inline script Python
185 ''''''''''''''''''''''''''''''
186 Un noeud script Python exécute du code Python dans un contexte où sont présentes des variables
187 qui ont pour valeur le contenu des ports de données d'entrée au lancement de cette exécution.
188 Par exemple, si le noeud a un port de données d'entrée de nom "matrice", la variable "matrice" sera
189 présente dans le contexte d'exécution du script et aura pour valeur le contenu du port de même nom.
190 En fin d'exécution du script, les ports de données de sortie sont remplis avec les valeurs des variables
191 de même nom présentes dans le contexte d'exécution. Ces variables doivent être obligatoirement présentes.
193 Lorsque ce type de noeud est un noeud interne d'une boucle, le contexte d'exécution est réinitialisé
194 à chaque tour de boucle.
196 Noeud inline fonction Python
197 ''''''''''''''''''''''''''''''
198 Un noeud fonction Python exécute une fonction Python dont les arguments correspondent aux ports de données
199 d'entrée du noeud. Le nom de la fonction à exécuter est donné par un paramètre du noeud.
200 Si un tel noeud a 3 ports de données d'entrée de nom 'a', 'b', 'c' et que le nom de la fonction est 'f', l'exécution
201 du noeud correspondra à l'appel de f(a,b,c) où a, b et c sont les valeurs des ports de données de même nom.
203 Les données de sortie du noeud sont attendues comme un retour de la fonction sous la forme d'un tuple Python.
204 Par exemple, si on a 3 ports de données de sortie de nom 'x', 'y', 'z', la fonction devra se terminer
205 par "return x,y,z" où x,y et z sont les valeurs pour les ports de sortie de même nom.
207 Lorsque ce type de noeud est un noeud interne d'une boucle, le contexte d'exécution est conservé
208 à chaque tour de boucle ce qui permet de réutiliser des variables pendant les itérations.
210 Noeud de service SALOME
211 ''''''''''''''''''''''''''''''
212 Un noeud de service SALOME exécute un service d'un composant SALOME.
213 On peut définir un noeud de service de deux façons :
215 1. en indiquant le type de composant (GEOM, SMESH, ...) et le service à exécuter
216 2. en indiquant un noeud de service existant et le service à exécuter
218 La deuxième forme existe car, dans certains cas, on veut utiliser l'état du composant à la
219 fin de l'exécution du premier service pour exécuter le deuxième service. L'état du composant
220 est conservé dans une instance de composant qui est créée à chaque fois qu'on utilise la
221 première forme. Si on utilise la deuxième forme, on ne crée pas une nouvelle instance de
222 composant mais on réutilise l'instance existante.
224 Un noeud de service a des ports de données d'entrée et de sortie et peut avoir également
225 des ports datastream d'entrée et de sortie.
227 Un noeud de service est chargé et exécuté sur un container SALOME. Ce placement est géré
228 au moyen du concept de container YACS (voir `Les containers`_) qui est une légère abstraction
230 Pour gérer le placement du service SALOME, il est possible de désigner par son nom le container
231 YACS sur lequel on veut qu'il soit placé. Ceci n'est possible qu'avec la première forme de définition
232 du noeud. Si aucune information de placement n'est donnée, le service sera placé sur
233 le container par défaut de la plate-forme SALOME : container FactoryServer sur la machine locale.
235 Les propriétés d'un noeud de service SALOME sont converties en variable d'environnement
236 lors de l'exécution du service.
239 ''''''''''''''''''''''''''''''
240 Un noeud SalomePython est un noeud fonction Python à qui YACS fournit (dans le contexte
241 d'exécution Python) les informations nécessaires pour lancer des composants SALOME et exécuter leurs services.
242 Il s'agit de l'adresse du container sur lequel il faut charger et exécuter le composant. Cette adresse
243 est donnée dans la variable "__container__from__YACS__" qui a la forme <nom machine>/<nom container>.
244 Ce noeud est donc paramétrable avec des informations de placement sur un container comme un noeud
247 Restriction : ce type de noeud ne peut pas exécuter de service SALOME doté de ports datastream. Le noeud
248 est vu par YACS comme un noeud Python. Les ports datastream ne sont pas gérés.
251 ''''''''''''''''''''''''''''''
252 Un noeud Data sert à définir des données (noeud DataIn) ou à collecter des résultats (noeud DataOut)
253 d'un schéma de calcul.
257 Un noeud DataIn a uniquement des ports de données sortants qui servent à définir les données d'entrée
259 Ces données ont un nom (le nom du port), un type (le type du port) et une valeur initiale.
263 Un noeud DataOut a uniquement des ports de données entrants qui servent pour stocker les résultats en sortie
265 Ces résultats ont un nom (le nom du port) et un type (le type du port).
266 Si le résultat est un fichier, on peut donner un nom de fichier dans lequel le fichier résultat sera copié.
268 L'ensemble des valeurs des résultats du noeud peut être sauvegardé dans un fichier en fin de calcul.
271 ''''''''''''''''''''''''''''''
272 Un noeud Study sert à relier les éléments d'une étude SALOME aux données et résultats d'un schéma de calcul.
276 Un noeud StudyIn a uniquement des ports de données sortants. Il sert pour définir les données
277 du schéma de calcul provenant d'une étude SALOME.
278 L'étude associée est donnée par son StudyID SALOME.
280 Un port correspond à une donnée stockée dans l'étude associée. La donnée a un nom (le nom du port),
281 un type (le type du port) et une référence qui donne l'entrée dans l'étude. Cette référence est
282 soit une Entry SALOME (par exemple, 0:1:1:2) soit un chemin dans l'arbre d'étude SALOME (par exemple,
288 Un noeud StudyOut a uniquement des ports de données entrants. Il sert pour ranger des
289 résultats dans une étude SALOME.
290 L'étude associée est donnée par son StudyID SALOME.
292 Un port correspond à un résultat stocké dans l'étude associée. Le résultat a un nom (le nom du port),
293 un type (le type du port) et une référence qui donne l'entrée dans l'étude.
294 Cette référence est soit une Entry SALOME (par exemple, 0:1:1:2) soit un chemin dans l'arbre
295 d'étude SALOME (par exemple, /Geometry/Box_1).
297 L'étude associée peut être sauvegardée dans un fichier en fin de calcul.
301 Les connexions entre ports d'entrée et de sortie des noeuds élémentaires ou composés sont
302 réalisées en établissant des liens entre ces ports.
304 Les liens de contrôle
305 ''''''''''''''''''''''''''''''
306 Les liens de contrôle servent à définir un ordre dans l'exécution des noeuds. Ils relient
307 un port de sortie d'un noeud à un port d'entrée d'un autre noeud. Ces deux noeuds
308 doivent être définis dans le même contexte.
309 La définition du lien se réduit à donner le nom du noeud amont et le nom du noeud aval.
312 ''''''''''''''''''''''''''''''
313 Les liens dataflow servent à définir un flot de données entre un port de données de sortie d'un noeud
314 et un port de données d'entrée d'un autre noeud. Il n'est pas nécessaire que ces noeuds soient définis dans
316 Un lien dataflow ajoute un lien de contrôle entre les deux noeuds concernés
317 ou entre les noeuds parents adéquats pour respecter la règle de définition des liens de
318 contrôle. Le lien dataflow garantit la cohérence entre le flot de données et l'ordre d'exécution.
319 Pour définir le lien, il suffit de donner les noms du noeud et du port amont et les noms du noeud
321 Les types des ports doivent être compatibles (voir `Compatibilité des types de données`_).
324 ''''''''''''''''''''''''''''''
325 Dans quelques cas (boucles principalement), il est utile de pouvoir définir des flots de données
326 sans définir le lien de contrôle associé comme dans le lien dataflow. On utilise alors le lien
328 La définition est identique à celle du lien dataflow.
329 Les types des ports doivent être compatibles (voir `Compatibilité des types de données`_).
332 ''''''''''''''''''''''''''''''
333 Les liens datastream servent à définir un flot de données entre un port datastream sortant d'un noeud et un
334 port datastream entrant d'un autre noeud. Ces deux noeuds doivent être définis dans un même contexte
335 et pouvoir être exécutés en parallèle. Il ne doit donc exister aucun lien de contrôle direct
336 ou indirect entre eux.
337 Pour définir le lien, on donne les noms du noeud et du port sortant et les noms du noeud
338 et du port entrant. La définition des liens datastream peut être complétée par des propriétés
339 qui paramètrent le comportement du port DSC qui réalise l'échange de données (voir ports DSC).
340 Les types des ports doivent être compatibles (voir `Compatibilité des types de données`_).
342 Compatibilité des types de données
343 '''''''''''''''''''''''''''''''''''''''''
344 Un lien data, dataflow ou datastream peut être créé seulement si le type de données du port
345 sortant est compatible avec le type de données du port entrant.
346 Il y a trois formes de compatibilité :
348 - l'identité des types (par exemple double -> double)
349 - la spécialisation des types (par exemple FIELDDOUBLE -> FIELD)
350 - la conversion des types (par exemple int -> double)
352 Compatibilité par conversion
353 +++++++++++++++++++++++++++++++
354 La compatibilité par conversion s'applique uniquement aux types de base et à leurs dérivés
355 (séquence, structure).
356 Les conversions acceptées sont les suivantes :
358 ================= ============================== ====================================
359 Type YACS Conversion possible en Commentaire
360 ================= ============================== ====================================
362 int bool true si int != 0 false sinon
363 ================= ============================== ====================================
365 La conversion s'applique également aux types construits comme une séquence d'int qui
366 peut être convertie en une séquence de double. YACS prend en charge la conversion.
367 Ceci s'applique également aux structures et aux types imbriqués séquence de séquence,
368 structure de structure, séquence de structure, etc.
370 Compatibilité par spécialisation
371 +++++++++++++++++++++++++++++++++++
372 La règle de compatibilité s'exprime différemment pour les liens data (ou dataflow) et les
375 Dans le cas des liens data (ou dataflow), il faut que le type du port de données sortant
376 soit dérivé (ou identique) du type du port de données entrant. Par exemple un port de données
377 sortant avec un type FIELDDOUBLE pourra être connecté à un port de données entrant avec le
378 type FIELD car le type FIELDDOUBLE est dérivé du type FIELD (ou FIELD est type de base de
381 Dans le cas des liens datastream, la règle est l'exact inverse de celle pour les liens data :
382 le type du port datastream entrant doit être dérivé de celui du port sortant. Il n'existe
383 pour le moment aucun type datastream dérivé. La seule règle qui s'applique est donc l'identité
388 Les ports de contrôle supportent les liens multiples, aussi bien 1 vers N que N vers 1.
390 Les ports de données supportent les liens multiples 1 vers N et N vers 1.
391 Les liens 1 vers N ne posent pas de problèmes. Les liens N vers 1 sont à utiliser avec
392 précaution car le résultat final dépend de l'ordre dans lequel sont réalisés les échanges.
393 On réservera ce type de lien pour les rebouclages dans les boucles itératives. Dans ce
394 cas l'ordre de réalisation des échanges est parfaitement reproductible.
396 Les ports datastream supportent également les liens multiples, 1 vers N et N vers 1.
397 Les liens datastream 1 vers N ne posent pas de problèmes particuliers : les échanges de données sont
398 simplement dupliqués pour tous les ports d'entrée connectés.
399 Par contre, pour les liens datastream N vers 1, les échanges de données vont se recouvrir dans
400 l'unique port d'entrée. Le résultat final peut dépendre de l'ordre dans lequel seront réalisés
404 --------------------------------
405 Les noeuds composés sont de plusieurs types : bloc, boucles, noeud-switch.
406 Un noeud composé peut contenir un ou plusieurs noeuds de type quelconque (élémentaires ou composés).
407 Par défaut, l'ensemble des entrées et sorties des noeuds constituant le noeud composé sont accessibles de l'extérieur.
408 On peut dire que les entrées du noeud composé sont constituées de l'ensemble des entrées des noeuds internes.
409 Même chose pour les sorties. C'est le concept de boîte blanche.
413 C'est un regroupement de noeuds avec des liens de dépendance entre les noeuds internes.
414 Le Bloc est une boite blanche (les noeuds internes sont visibles).
415 Un schéma de calcul est un Bloc.
416 Le Bloc se manipule de façon similaire à un noeud élémentaire.
417 Il dispose d'un seul port de contrôle en entrée et d'un seul en sortie.
418 En conséquence, deux blocs raccordés par un lien de donnée dataflow s'exécutent en séquence, tous les noeuds du premier bloc sont exécutés avant de passer au second bloc.
421 ''''''''''''''''''''''
422 Une boucle permet des itérations sur un noeud interne.
423 Ce noeud interne peut être un noeud composé ou un noeud élémentaire.
424 Certaines des sorties du noeud interne peuvent être explicitement rebouclées sur des entrées de ce même noeud interne.
425 Une boucle ForLoop exécute le noeud interne un nombre fixe de fois. Ce nombre est donné par un port
426 de donnée de la boucle de nom "nsteps" ou par un paramètre de la boucle de même nom.
429 ''''''''''''''''''''''
430 Une boucle While exécute le noeud interne tant qu'une condition est vraie. La valeur de la condition
431 est donnée par un port de donnée de la boucle de nom "condition".
434 ''''''''''''''''''''''
435 Le noeud ForEach est également une boucle mais il sert à exécuter, en parallèle, un corps de boucle en itérant
436 sur une et une seule collection de données. Une collection de données est du type séquence.
437 Un port de données d'entrée du noeud ForEach de nom "SmplsCollection" reçoit la collection de données sur laquelle la boucle itère.
438 Cette collection de données est typée. Le type de donnée sur lequel la boucle itère est unique.
439 Le nombre de branches parallèles que la boucle gère est fixé par un paramètre de la boucle. Si la collection est de
440 taille 100 et que ce paramètre est fixé à 25, la boucle exécutera 4 paquets de 25 calculs en parallèle.
441 Le noeud interne a accès à l'itéré courant de la collection de données via le port de données sortant de la boucle
444 En sortie de boucle il est possible de construire des collections de données typées. Il suffit de relier un port de
445 données de sortie du noeud interne à un port de données d'entrée d'un noeud hors de la boucle. La collection de
446 données est contruite automatiquement par la boucle.
449 ''''''''''''''''''''''
450 Le noeud Switch permet l'exécution conditionnelle (parmi N) d'un noeud (composé, élémentaire).
451 Ces noeuds doivent avoir un minimum d'entrées et de sorties compatibles.
452 La condition de switch (entier, réel) permet d'aiguiller l'exécution d'un noeud parmi n.
453 La condition de switch est donné par un port de donnée entrant du noeud Switch de nom "select" ou par un paramètre
454 de ce noeud de même nom.
456 Si les noeuds sont terminaux (rien n'est exécuté à partir de leurs sorties), ils n'ont pas besoin d'avoir des sorties compatibles.
457 Les ports de sortie exploités en sortie du noeud doivent être compatibles entre eux (i.e. dériver d'un type générique commun exploitable par un autre noeud en entrée).
461 ---------------------
462 La plate-forme SALOME exécute ses composants après les avoir chargés dans des containers. Un container SALOME est un
463 processus géré par la plate-forme qui peut être exécuté sur toute machine connue.
465 Un container YACS sert à définir des contraintes de placement des composants sans pour autant définir précisément
466 la machine à utiliser ou le nom du container.
468 Le container YACS a un nom. Les contraintes sont données sous la forme de propriétés du container.
469 La liste actuelle des propriétés est la suivante :
471 =================== ============= =============================================
472 Nom Type Type de contrainte
473 =================== ============= =============================================
474 policy "best", Choisit dans la liste des machines, une fois
475 "first" ou les autres critères appliqués, la meilleure
476 "cycl" ou la première ou la suivante. Par défaut,
477 YACS utilise la politique "cycl" qui
478 prend la machine suivante dans la liste
479 des machines connues.
480 container_name string si donné impose le nom du container SALOME
481 hostname string si donné impose la machine
482 OS string si donné restreint le choix de l'OS
483 parallelLib string ??
484 workingdir string si donné, spécifie le répertoire d'exécution.
485 Par défaut, c'est le répertoire de lancement
486 de YACS sur la machine locale et le $HOME
487 sur les machines distantes.
488 isMPI bool indique si le container doit supporter MPI
489 mem_mb int taille mémoire minimale demandée
490 cpu_clock int vitesse cpu minimale demandée
491 nb_proc_per_node int ??
493 nb_component_nodes int ??
494 =================== ============= =============================================
496 Le catalogue des ressources matérielles
497 ''''''''''''''''''''''''''''''''''''''''''
498 La liste des ressources matérielles (machines) connues de SALOME est donnée par le catalogue des
499 ressources : fichier CatalogResources.xml qui doit se trouver dans le répertoire de l'application SALOME utilisée.
500 Ce fichier est au format XML. Chaque machine est décrite avec le tag machine qui a plusieurs attributs
501 qui permettent de la caractériser.
503 ================================== =========================== ==============================================
504 Caractéristique Attribut XML Description
505 ================================== =========================== ==============================================
506 nom hostname soit le nom complet : c'est la clef
507 qui détermine la machine de manière unique
508 (exemple : "nickel.ccc.cea.fr")
509 alias alias chaine de caractères qui permet d'identifier
510 la machine (exemple : "pluton")
511 protocole d'accès protocol "rsh" (défaut) ou "ssh"
512 type d'accès mode interactif "i" ou batch "b". Par défaut "i"
513 username userName user avec lequel on va se connecter sur
515 système d'exploitation OS
516 taille de la mémoire centrale memInMB
517 fréquence d'horloge CPUFreqMHz
518 nombre de noeuds nbOfNodes
519 nombre de processeurs par noeud nbOfProcPerNode
520 application SALOME appliPath répertoire de l'application SALOME à utiliser
522 implémentation mpi mpi indique quelle implémentation de MPI est
523 utilisée sur cette machine ("lam", "mpich1",
525 gestionnaire de batch batch si la machine doit être utilisée au travers
526 d'un système de batch donne le nom du
527 gestionnaire de batch ("pbs", "lsf", "slurm").
529 ================================== =========================== ==============================================
531 Il est possible d'indiquer également la liste des modules SALOME présents sur la machine.
532 Par défaut, SALOME suppose que tous les composants demandés par YACS sont présents.
533 Chaque module présent est donné par le sous tag modules et son attribut moduleName.
535 Voici un exemple de catalogue de ressources::
537 <!DOCTYPE ResourcesCatalog>
539 <machine hostname="is111790" alias="is111790" OS="LINUX" CPUFreqMHz="2992" memInMB="1024"
540 protocol="rsh" mode="interactif" nbOfNodes="1" nbOfProcPerNode="1" >
542 <machine hostname="is111915" alias="is111915" OS="LINUX" CPUFreqMHz="2992" memInMB="1024"
543 protocol="ssh" mode="interactif" nbOfNodes="1" nbOfProcPerNode="1"
544 appliPath="SALOME43/Run">
545 <modules moduleName="GEOM"/>
552 -----------------------------
553 Au cours de l'édition d'un schéma de calcul, les états possibles d'un noeud sont :
555 =================== =============================================
557 =================== =============================================
558 READY le noeud est valide, prêt à être exécuté
559 INVALID le noeud est invalide, le schéma ne peut
561 =================== =============================================
563 Au cours de l'exécution d'un schéma de calcul, les états possibles d'un noeud sont :
565 =================== =============================================================
567 =================== =============================================================
568 READY le noeud est valide, prêt à être exécuté
569 TOLOAD le composant associé au noeud peut être chargé
570 LOADED le composant associé au noeud est chargé
571 TOACTIVATE le noeud peut être exécuté
572 ACTIVATED le noeud est en exécution
573 DONE l'exécution du noeud est terminée sans erreur
574 ERROR l'exécution du noeud est terminée avec erreur
575 FAILED noeud en erreur car des noeuds précédents sont en erreur
576 DISABLED l'exécution du noeud est désactivée
577 PAUSE l'exécution du noeud est suspendue
578 =================== =============================================================
582 Le nommage contextuel des noeuds
583 -------------------------------------
584 On a vu que les noeuds élémentaires et composés ont un nom unique dans le contexte de définition
585 qui correspond au noeud parent (schéma de calcul ou noeud composé). Pour pouvoir désigner les noeuds
586 dans toutes les situations possibles, on utilise plusieurs sortes de nommage :
588 - le nommage local : c'est le nom du noeud dans son contexte de définition
589 - le nommage absolu : c'est le nom du noeud vu depuis le niveau le plus haut du schéma de calcul
590 - le nommage relatif : c'est le nom du noeud vu d'un noeud composé parent
592 La règle générale est que les noms absolu et relatif sont construits en concaténant les noms locaux
593 du noeud et de ses parents en les séparant par des points.
595 Prenons l'exemple d'un noeud élémentaire de nom "n" défini dans un bloc de nom "b" qui lui même est défini
596 dans un bloc de nom "c" lui même défini au niveau le plus haut du schéma. Le nom local du noeud est "n".
597 Le nom absolu est "c.b.n". Le nom relatif dans le bloc "c" est "b.n". On applique la même règle pour
598 nommer les ports. Si le noeud "n" a un port de nom "p". Il suffit d'ajouter ".p" au nom du noeud
599 pour avoir le nom du port.
601 Il y a une exception à cette règle. Elle concerne le noeud Switch. Dans ce cas, il faut tenir compte du case
602 qui n'est pas un vrai noeud. Si on dit que le bloc "b" de l'exemple précédent est un switch qui a un case avec
603 une valeur de 1 et un default, alors le nom absolu du noeud "n" dans le case sera "c.b.p1_n" et celui dans
604 le default sera "c.b.default_n".
610 Chaque noeud a un rapport d'erreur associé si son état est INVALID, ERROR ou FAILED.
611 Ce rapport est au format XML.
613 Les noeuds élémentaires produisent un rapport simple qui contient un seul tag (error)
616 - node : qui donne le nom du noeud
617 - state : qui indique son état
619 Le contenu du tag est le texte de l'erreur. Pour un noeud script python ce sera la plupart du temps,
620 le traceback de l'exception rencontrée. Pour un noeud de service, ce sera soit le contenu d'une
621 exception SALOME soit le contenu d'une exception CORBA.
623 Les noeuds composés produisent un rapport composite contenu dans un tag de même nom (error) avec
624 les 2 mêmes attributs node et state.
625 Le tag contient l'ensemble des rapports d'erreur des noeuds fils erronés.
627 Voici un exemple de rapport d'erreur pour une division par zéro dans un noeud python
628 contenu dans une boucle::
630 <error node= proc state= FAILED>
631 <error node= l1 state= FAILED>
632 <error node= node2 state= ERROR>
633 Traceback (most recent call last):
634 File "<string>", line 1, in ?
635 ZeroDivisionError: integer division or modulo by zero
643 Pour chaque exécution une trace d'exécution est produite dans un fichier de nom traceExec_<nom du schema>
644 où <nom du schema> est le nom donné au schéma.
646 Chaque ligne du fichier représente un évènement relatif à un noeud. Elle contient deux
647 chaines de caractères. La première est le nom du noeud. La deuxième décrit l'évènement.
649 Voici une trace pour le même exemple que ci-dessus::
660 l1.node2 connectService
662 l1.node2 start execution
663 l1.node2 end execution ABORT, Error during execution
664 l1.node2 disconnectService
666 Exécution des branches concurrentes
667 -------------------------------------
668 YACS peut exécuter simultanément les noeuds de calcul d'un schéma.
669 Cependant l'exécution simultanée d'un grand nombre de noeuds peut saturer le système.
670 Il est possible de controler le nombre maximum
671 d'exécutions simultanées en fixant le nombre maximum de threads utilisés avec
672 la variable d'environnement YACS_MAX_THREADS. Par défaut, cette valeur vaut 50.
676 YACS general architecture
677 ------------------------------
679 YACS module implements API of a full SALOME module only for the schema execution. The schema edition is done in the GUI process alone. For execution, YACS has a CORBA servant that implements Engines::Component CORBA interface (see SALOME 4 KERNEL IDL interfaces). YACS GUI and YACS CORBA engine share YACS core libraries (engine and runtime): GUI uses them at schema design time, then a schema XML file is saved and passed to YACS CORBA API, and finally YACS core libraries execute the schema at YACS CORBA server side.
681 YACS GUI differs from standard full SALOME modules (such as Geometry or Mesh) in that it does not use SALOMEDS objects to create Object Browser representation of its data, and creates this representation in a way light SALOME modules do. This is done in order to avoid publishing lots of objects in SALOMEDS study just to create visual representation of data and thus to improve GUI performance.
683 YACS architecture scheme is shown on the picture below.
685 .. image:: images/general_architecture_0.jpg
688 The YACS module will be developed as a Salome module with one document (study) per desktop.
690 YACS is composed of several packages. The main things are mentioned in the next sections.
693 '''''''''''''''''''''''
694 Bases package contains common base classes (exception, threads, etc.) and constants.
697 '''''''''''''''''''''''
698 Engine package consists of calculation schema generic classes (calculation nodes, control nodes, control and data flow links, etc.) Engine is in charge to
705 graphs independently from the context (i.e. Runtime) the graph is destined to run.
707 SALOME Runtime package
708 '''''''''''''''''''''''
709 Runtime package provides implementation of YACS generic calculation nodes for SALOMR platform. Runtime exists in a given Context. Runtime is in charge to:
711 * treat physically the basic execution of elementary tasks in a given context,
712 * transfer data in this context,
713 * perform the physical deployment of the execution.
715 Runtime simply appears in Engine as an interface that a concrete Runtime must implement to be piloted by Engine.
719 The SALOME Runtime implements following nodes.
721 * Inline function node. A function inline node is implemented by a Python function.
722 * Inline script node. A script inline node is implemented by a Python script.
723 * Component service node. This is a calculation node associated with a component service.
724 * CORBA reference service node. Reference service node for CORBA objects. This is a node that executes a CORBA service.
725 * CPP node. This is a C++ node (in process component), i.e. local C++ implementation - single process.
727 XML file loader package
728 ''''''''''''''''''''''''''''''''
729 This is XML reader for generic calculation schema.
731 XML file loader provides
733 * a possibility to load a calculation schema in memory by reading and parsing a XML file describing it,
734 * an executable named driver that can be used to load and execute (see Using YACS driver) a calculation schema given as a XML file (see Writing XML file).
737 ''''''''''''''''''''''''''''''''
738 Goals of Graphic User Interface design are the following.
740 * Provide a general mechanism for the synchronisation of several views (tree views, 2D canvas views, edition dialogs). For this goal, a subject/observers design pattern is used: several observers can attach or detach themselves to/from the subject. The subject send update events to the lists of observers and does not know the implementation of the observers. The observers correspond to the different views in case of YACS.
741 * Provide an interface of Engine for edition with a general mechanism for undo-redo (future version!).
742 * Be as independent as possible of Qt (and SALOME), to avoid problems in Qt4 migration, and allow a potential re-use of YACS GUI outside SALOME.
