From: GERALD NICOLAS Date: Thu, 4 Oct 2018 13:30:51 +0000 (+0200) Subject: Langage pour literalinclude X-Git-Tag: V9_2_0a2~2^2 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=8676b5084f3e3685d3761bf0a61b97d50279bab1;p=modules%2Fhomard.git Langage pour literalinclude --- diff --git a/doc/en/gui_create_yacs.rst b/doc/en/gui_create_yacs.rst index 0a846c58..e14c0827 100644 --- a/doc/en/gui_create_yacs.rst +++ b/doc/en/gui_create_yacs.rst @@ -109,21 +109,25 @@ These tests ares done into the node "Analyse" of the schema, as described in :do The maximal number of iterations is given by the variable `NbCalcMax`: .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 112-112 The value for the test is saved in a list all along the calculations: .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 137-141 and the test is calculated after the second iteration: .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 143-148 If this test is modified, it must be done here. But the instructions when it is converged must be kept to guarantee a good execution: .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 146-148 Examples diff --git a/doc/en/gui_create_yacs_aster.rst b/doc/en/gui_create_yacs_aster.rst index 87660e11..a187fec6 100644 --- a/doc/en/gui_create_yacs_aster.rst +++ b/doc/en/gui_create_yacs_aster.rst @@ -27,11 +27,13 @@ To get back the test value ``V_TEST``, the script fetches in the file ``resu`` a For that purpose, the best way consists in placing the test value in an entitled table ``V_TEST``, for example after an extraction from a result: .. literalinclude:: ../files/yacs_aster_01.comm + :language: python :lines: 53-59 Then print this table for the two parameters ``INTITULE`` and component: .. literalinclude:: ../files/yacs_aster_01.comm + :language: python :lines: 63-64 To drive the adaptation @@ -41,6 +43,7 @@ If the adaptation is driven by a field, it will be necessary to write this field For example : .. literalinclude:: ../files/yacs_aster_01.comm + :language: python :lines: 68-78 The script diff --git a/doc/en/tutorials.rst b/doc/en/tutorials.rst index 983d67cc..a299ad80 100644 --- a/doc/en/tutorials.rst +++ b/doc/en/tutorials.rst @@ -37,6 +37,7 @@ One will make here three successive uniform refinements of the mesh contained in .. literalinclude:: ../files/tutorial_1.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -56,6 +57,7 @@ Refinement by zones One proceeds here to refinement according to zones. To pass from the initial mesh to the mesh 'M_1', one uses a box framing the z=1 plane and a sphere centered on the origin with radius 1.05. Then to pass from the mesh 'M_1' to the mesh 'M_2', one replaces the sphere by a box framing the cube on side 0.5, pointing on the origin and the meshes in the very first zone are unrefined. .. literalinclude:: ../files/tutorial_2.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -75,6 +77,7 @@ One proceeds here to refinement according to a field. The hypotheses are used to To adapt the H_1 mesh resulting from the Iter_1 iteration, two alternatives are applied. In the first, Iter_2, the field is a scalar field of indicators of error and one cuts out the 1.5% of elements where the error is largest. In the second alternative, Iter_2_bis, one is based on a vector field and one examines the jump of this vector between an element and its neighbors: one will cut out where the infinite standard of this jump is higher than the absolute threshold of 0.0001. .. literalinclude:: ../files/tutorial_3.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -98,6 +101,7 @@ The driving of refinement is the following: uniform refinement of all the elemen Scheme YACS carrying out this adaptation is downloadable. .. literalinclude:: ../files/tutorial_4.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -134,6 +138,7 @@ The instructions to adapt a 2D mesh are exactly identical to those necessary to In the case presented here, one for the first time refines all the elements contained in a bored disk, then in one second iteration, all the elements contained in a rectangle. One will note the use of the follow-up of the circular borders of the field. .. literalinclude:: ../files/tutorial_5.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes diff --git a/doc/en/yacs.rst b/doc/en/yacs.rst index e0b1625d..94cbeadc 100644 --- a/doc/en/yacs.rst +++ b/doc/en/yacs.rst @@ -46,6 +46,7 @@ DataInit This box is type PresetNode's elementary node. Its only function is to initialize the variable MeshFile that contains the name of the file of the initial mesh. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 37-41 Study_Initialisation @@ -64,11 +65,13 @@ The box Study_Initialisation launches the component HOMARD inside SALOME. It is The python node StudyCreation initialize the SALOME study that is given through the output: .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 43-59 The service UpdateStudy connects this study to an instance of HOMARD. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 60-64 @@ -93,6 +96,7 @@ Results This box is a node python that takes in input a character string, MessInfo. If everything passed well, this message is empty. A window QT appears to confirm the convergence. If there was a problem, the message contains messages emitted during the calculations. The window QT shows this message. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 398-411 @@ -117,6 +121,7 @@ Computation This box is a node python that is going to drive the calculation. In input, we find the number of the calculation (0 at first) and the name of the file which contains the mesh on which to calculate. In output, we find an integer which represents the error on this calculation (0 so everything goes well) and a dictionary python gathering the results of the calculation. The body of the node is established by the launch of a script python that activates the calculation. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 70-90 In this example, we must define: @@ -157,19 +162,23 @@ Iter_1 This box begins by creating the case HOMARD by calling the CreateCase service. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 200-207 The name of the case CaseName is imposed on "Computation". The name of the case MeshName is imposed on "BOX". The parameters of input FileName arise from the output of the previous calculation. The parameter of output is an instance of case. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 435-438 .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 475-478 The options of this case must be now given. It is made by the node python CaseOptions. It is imperative to give the directory of calculation. We shall look at the description of the functions in :doc:`tui_create_case`. In output, we get back the instance of the iteration corresponding to the initial state of the case. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 208-220 Finally, a hypothesis is created by calling the CreateHypothese service. The parameter of output is an instance of hypothese. @@ -187,31 +196,37 @@ Once initialized, the adaptation can be calculated. It is the goal of the Homard The directory of calculation is recovered. The name of the mesh is given. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 237-242 ../.. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 317-325 The hypothesis transmitted in input parameter characterized (look :doc:`tui_create_hypothese`) : .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 246-270 It is necessary to establish a name for the future iteration. To make sure that the name was never used, one installs a mechanism of incremental naming starting from the name of the initial iteration. As this initial name is the name of the initial mesh, one obtains a succession of names in the form: M_001, M_002, M_003, etc .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 272-282 The iteration is supplemented : hypothesis, future mesh, field (look :doc:`tui_create_iteration`) : .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 284-303 The iteration is calculated. If it were correct, variable OK equals 1: one will be able to continue the execution of the scheme. If there were a problem, variable OK equals 0 to mean that calculation must stop; an error message then is given. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 305-316 After this execution, the process leaves the Adaptation_HOMARD node, then Adaptation node. One arrives then at the node of analysis. @@ -242,6 +257,7 @@ Loop_Stop The Loop_Stop block is present to only make forward variables because the input parameters of the nodes must always be filled. It is a very simple python: .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 165-176 Analysis @@ -255,31 +271,37 @@ Analysis The Analysis block is a script python which ensures the complete control of the process by examining the causes of possible error successively. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 96-108 ../.. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 154-162 One starts by analyzing the return of the computer code: .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 110-115 Checking of the presence of the name of the result file in the dictionary of the results: .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 117-124 Checking of convergence. That supposes that the value to be tested is present in the dictionary under the key 'V_TEST'. Here, one set up a test on the variation of the value of one calculation at the other. With the first passage, nothing is tested. In the following passing, one tests if the relative variation is lower than 1 thousandths. One could have set up an absolute test if one had recovered a total level of error for example. .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 126-146 Lastly, it is checked that a maximum nomber of adaptations is not exceeded: .. literalinclude:: ../files/yacs_01.en.xml + :language: xml :lines: 146-151 diff --git a/doc/files/yacs_01.en.xml b/doc/files/yacs_01.en.xml index 7ce832f3..4d06d149 100644 --- a/doc/files/yacs_01.en.xml +++ b/doc/files/yacs_01.en.xml @@ -302,7 +302,7 @@ Iter.SetMeshFile(MeshFile) FileName = dict_resu["FileName"] Iter.SetFieldFile(FileName) # -# Computationation +# Computation # =========== Error = Iter.Compute(1,1) # diff --git a/doc/fr/gui_create_yacs.rst b/doc/fr/gui_create_yacs.rst index d16ea88d..006fef04 100644 --- a/doc/fr/gui_create_yacs.rst +++ b/doc/fr/gui_create_yacs.rst @@ -110,21 +110,25 @@ Ces tests sont réalisés dans le noeud python "Analyse" du schéma, comme décr Le nombre maximal d'itérations est modifiable par la variable `NbCalcMax` : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 112-112 La valeur de test est stockée dans une liste au fur et à mesure des passages : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 137-141 et le test a lieu à partir du deuxième passage : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 143-148 Si on veut remplacer ce test par un autre, c'est ici qu'il faut le faire. Il faut simplement conserver le contenu produit à la convergence pour assurer la bonne marche de la suite du schéma : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 146-148 Exemples diff --git a/doc/fr/gui_create_yacs_aster.rst b/doc/fr/gui_create_yacs_aster.rst index 3a005b94..0f29d9a8 100644 --- a/doc/fr/gui_create_yacs_aster.rst +++ b/doc/fr/gui_create_yacs_aster.rst @@ -27,11 +27,13 @@ Pour récupérer la valeur de test ``V_TEST``, le script va chercher dans le fic Pour cela, la meilleure façon consiste à placer la valeur à tester dans une table intitulée ``V_TEST``, par exemple après une extraction depuis un résultat : .. literalinclude:: ../files/yacs_aster_01.comm + :language: python :lines: 53-59 puis à imprimer cette table en se limitant aux deux paramètres ``INTITULE`` et composante retenue : .. literalinclude:: ../files/yacs_aster_01.comm + :language: python :lines: 63-64 Le pilotage de l'adaptation @@ -41,6 +43,7 @@ Si on souhaite piloter l'adaptation par un champ, il faudra écrire ce champ dan Par exemple : .. literalinclude:: ../files/yacs_aster_01.comm + :language: python :lines: 68-78 Le script diff --git a/doc/fr/tutorials.rst b/doc/fr/tutorials.rst index 5562fb6f..49caa551 100644 --- a/doc/fr/tutorials.rst +++ b/doc/fr/tutorials.rst @@ -36,6 +36,7 @@ On fera ici trois raffinements uniformes successifs du maillage contenu dans le * le maillage produit porte toujours le même nom. Cela ne pose pas de problème car il est stocké dans des fichiers différents. .. literalinclude:: ../files/tutorial_1.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -54,6 +55,7 @@ Raffinement par des zones On procède ici au raffinement selon des zones. Pour passer du maillage initial au maillage 'M_1', on utilise une boîte encadrant le plan z=1 et une sphère centrée sur l'origine de rayon 1.05. Puis pour passer du maillage 'M_1' au maillage 'M_2', on remplace la sphère par une boîte encadrant le cube de côté 0.5, pointant sur l'origine et on déraffine les mailles contenues dans la toute première zone. .. literalinclude:: ../files/tutorial_2.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -73,6 +75,7 @@ On procède ici au raffinement selon un champ. Les hypothèses servent à défin Pour adapter le maillage H_1 issu de l'itération Iter_1, deux variantes sont appliquées. Dans la première, Iter_2, le champ est un champ scalaire d'indicateurs d'erreur et on découpe les 1.5% de mailles où l'erreur est la plus grande. Dans la seconde variante, Iter_2_bis, on se base sur un champ vectoriel et on examine le saut de ce vecteur entre une maille et ses voisines : on découpera là où la norme infinie de ce saut est supérieure au seuil absolu de 0.0001. .. literalinclude:: ../files/tutorial_3.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -96,6 +99,7 @@ Le pilotage du raffinement est le suivant : raffinement uniforme de toutes les m Le schéma YACS réalisant cette adaptation est téléchargeable. .. literalinclude:: ../files/tutorial_4.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -112,6 +116,7 @@ Si la géométrie sous forme de CAO n'est pas disponible, on peut l'approcher ai des frontières analytiques pour décrire les différentes surfaces des tuyaux et une frontière discrète pour décrire les lignes d'intersection des deux tuyaux. Il suffit de remplacer la définition des frontières. .. literalinclude:: ../files/tutorial_6.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes @@ -133,6 +138,7 @@ Les instructions pour adapter un maillage 2D sont exactement identiques à celle Dans le cas présenté ici, on raffine une première fois toutes les mailles contenues dans un disque percé, puis dans une seconde itération, toutes les mailles contenues dans un rectangle. On notera l'utilisation du suivi des frontières circulaires du domaine. .. literalinclude:: ../files/tutorial_5.py + :language: python :start-after: Début des commandes :end-before: Fin des commandes diff --git a/doc/fr/yacs.rst b/doc/fr/yacs.rst index b2b6f767..ac1e9b15 100644 --- a/doc/fr/yacs.rst +++ b/doc/fr/yacs.rst @@ -46,6 +46,7 @@ DataInit Cette boîte est un noeud élémentaire de type PresetNode. Sa seule fonction est d'initialiser la variable MeshFile qui contient le nom du fichier du maillage initial. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 37-41 Etude_Initialisation @@ -64,11 +65,13 @@ La boîte Etude_Initialisation lance le composant HOMARD dans SALOME. C'est un b Le noeud python StudyCreation sert à initialiser l'étude SALOME qui est fournie en sortie : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 43-59 Le service UpdateStudy affecte cette étude à une instance de HOMARD. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 60-64 @@ -93,6 +96,7 @@ Bilan Cette boîte est un noeud python qui prend en entrée une chaîne de caractères, MessInfo. Si tout s'est bien passé, ce message est vide. Une fenêtre QT apparaît pour confirmer la convergence. S'il y a eu un problème, le message contient les messages émis au cours des calculs. La fenêtre QT affiche ce message. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 398-411 @@ -117,6 +121,7 @@ Calcul Cette boîte est un noeud python qui va piloter le calcul. En entrée, on trouve le numéro du calcul (0 au départ) et le nom du fichier qui contient le maillage sur lequel calculer. En sortie, on trouve un entier qui représente l'erreur sur ce calcul (0 si tout va bien) et un dictionnaire python rassemblant les résultats du calcul. Le corps du noeud est constitué par le lancement d'un script python qui active le calcul. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 70-90 Dans cet exemple, il faut définir : @@ -157,19 +162,23 @@ Iter_1 Cette boîte commence par créer le cas HOMARD en appelant le service CreateCase. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 200-207 Le nom du cas CaseName est imposé à "Calcul". Le paramètre d'entrée MeshName est imposé à "BOX". Le paramètre d'entrée FileName est issu de la sortie du calcul précédent. Le paramètre de sortie est une instance de cas. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 435-438 .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 475-478 Les options de ce cas doivent maintenant être renseignées. C'est fait par le noeud python CaseOptions. Il est impératif de renseigner le répertoire de calcul. On regardera la description des fonctions dans :doc:`tui_create_case`. En sortie, on récupère l'instance de l'itération correspondant à l'état initial du cas. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 208-220 Enfin, une hypothèse est créée en appelant le service CreateHypothese. Le paramètre de sortie est une instance d'hypothèse. @@ -187,31 +196,37 @@ Une fois initialisée, l'adaptation peut être calculée. C'est le but de la bo Le répertoire de calcul est récupéré. Le nom du maillage est rappelé. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 237-242 ../.. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 317-325 L'hypothèse transmise en paramètre d'entrée est caractérisée (voir :doc:`tui_create_hypothese`) : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 246-270 Il faut établir un nom pour la future itération. Pour s'assurer que le nom n'a jamais été utilisé, on met en place un mécanisme de nommage incrémental à partir du nom de l'itération initiale. Comme ce nom initial est le nom du maillage initial, on obtient une succession de noms sous la forme : M_001, M_002, M_003, etc. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 272-282 L'itération est complétée : hypothèse, futur maillage, champ (voir :doc:`tui_create_iteration`) : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 284-303 L'itération est calculée. Si tout s'est bien passé, la variable OK vaut 1 : on pourra continuer l'exécution du schéma. S'il y a eu un problème, la variable OK vaut 0 pour signifier que le calcul doit s'arrêter ; on donne alors un message d'erreur. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 305-316 Après cette exécution, le processus sort du noeud Adaptation_HOMARD, puis du noeud Adaptation. On arrive alors au noeud d'analyse. @@ -242,6 +257,7 @@ Arret_boucle Le bloc Arret_boucle n'est présent que pour faire transiter des variables car les paramètres d'entrée des noeuds doivent toujours être remplis. C'est un python très simple : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 165-176 Analyse @@ -255,31 +271,37 @@ Analyse Le bloc Analyse est un script python qui assure le contrôle complet du processus en examinant successivement les causes d'erreur possible. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 96-108 ../.. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 154-162 On commence par analyser le retour du code de calcul : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 110-115 Vérification de la présence du nom du fichier de résultats dans le dictionnaire des résultats : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 117-124 Vérification de la convergence. Cela suppose que la valeur à tester est présente dans le dictionnaire sous la clé 'V_TEST'. Ici, on a mis en place un test sur la variation de la valeur d'un calcul à l'autre. Au premier passage, on ne teste rien. Aux passages suivants, on teste si la variation relative est inférieure à 1 millième. On aurait pu mettre en place un test absolu si on avait récupéré un niveau global d'erreur par exemple. .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 126-146 Enfin, on vérifie que l'on ne dépasse pas un nombre maximal d'adaptations : .. literalinclude:: ../files/yacs_01.fr.xml + :language: xml :lines: 146-151