From 31f3968b1d7e50bcda3fbb33014d89f80ed6f5ac Mon Sep 17 00:00:00 2001 From: =?utf8?q?C=C3=A9dric=20Aguerre?= Date: Wed, 28 Oct 2015 18:34:45 +0100 Subject: [PATCH] MERGE stage 2: update doc/dev then remove src/MEDCalc/doc --- doc/dev/CMakeLists.txt.BACKUP.5306.txt | 20 ----- doc/dev/CMakeLists.txt.REMOTE.5306.txt | 20 ----- doc/dev/models/{medop.xmi => medcalc.xmi} | 10 +-- doc/dev/sphinx/CMakeLists.txt | 2 +- .../sphinx/_static/{medop.css => medcalc.css} | 0 doc/dev/sphinx/conf.py.in | 14 +-- doc/dev/sphinx/fr/index.rst | 10 +-- ...efinitions.rst => medcalc-definitions.rst} | 0 .../medcalc-develguide.rst} | 64 ++++++------- ...-references.rst => medcalc-references.rst} | 2 +- ...cations.rst => medcalc-specifications.rst} | 26 +++--- ...uide-gui.rst => medcalc-userguide-gui.rst} | 90 ++++++++++--------- .../sphinx/fr/medop-prototype-develguide.rst | 32 +++---- doc/dev/sphinx/fr/medop-prototype-medmem.rst | 46 +++++----- .../sphinx/fr/medop-prototype-overview.rst | 6 +- doc/dev/sphinx/fr/medop-workingnotes-2011.rst | 8 +- doc/dev/sphinx/fr/medop-workingnotes-2012.rst | 4 +- doc/dev/sphinx/index.rst | 10 +-- ...efinitions.rst => medcalc-definitions.rst} | 0 ...-develguide.rst => medcalc-develguide.rst} | 64 ++++++------- ...-references.rst => medcalc-references.rst} | 2 +- ...cations.rst => medcalc-specifications.rst} | 26 +++--- ...uide-api.rst => medcalc-userguide-api.rst} | 62 ++++++------- ...uide-gui.rst => medcalc-userguide-gui.rst} | 56 ++++++------ doc/dev/sphinx/medop-prototype-develguide.rst | 32 +++---- doc/dev/sphinx/medop-prototype-medmem.rst | 46 +++++----- doc/dev/sphinx/medop-prototype-overview.rst | 6 +- doc/dev/sphinx/medop-workingnotes-2011.rst | 8 +- doc/dev/sphinx/medop-workingnotes-2012.rst | 4 +- 29 files changed, 319 insertions(+), 351 deletions(-) delete mode 100644 doc/dev/CMakeLists.txt.BACKUP.5306.txt delete mode 100644 doc/dev/CMakeLists.txt.REMOTE.5306.txt rename doc/dev/models/{medop.xmi => medcalc.xmi} (97%) rename doc/dev/sphinx/_static/{medop.css => medcalc.css} (100%) rename doc/dev/sphinx/fr/{medop-definitions.rst => medcalc-definitions.rst} (100%) rename doc/dev/sphinx/{medop-develguide.rst => fr/medcalc-develguide.rst} (86%) rename doc/dev/sphinx/fr/{medop-references.rst => medcalc-references.rst} (96%) rename doc/dev/sphinx/fr/{medop-specifications.rst => medcalc-specifications.rst} (99%) rename doc/dev/sphinx/fr/{medop-userguide-gui.rst => medcalc-userguide-gui.rst} (94%) rename doc/dev/sphinx/{medop-definitions.rst => medcalc-definitions.rst} (100%) rename doc/dev/sphinx/{fr/medop-develguide.rst => medcalc-develguide.rst} (86%) rename doc/dev/sphinx/{medop-references.rst => medcalc-references.rst} (96%) rename doc/dev/sphinx/{medop-specifications.rst => medcalc-specifications.rst} (99%) rename doc/dev/sphinx/{medop-userguide-api.rst => medcalc-userguide-api.rst} (93%) rename doc/dev/sphinx/{medop-userguide-gui.rst => medcalc-userguide-gui.rst} (94%) diff --git a/doc/dev/CMakeLists.txt.BACKUP.5306.txt b/doc/dev/CMakeLists.txt.BACKUP.5306.txt deleted file mode 100644 index d91183151..000000000 --- a/doc/dev/CMakeLists.txt.BACKUP.5306.txt +++ /dev/null @@ -1,20 +0,0 @@ -# Copyright (C) 2012-2015 CEA/DEN, EDF R&D -# -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU Lesser General Public -# License as published by the Free Software Foundation; either -# version 2.1 of the License, or (at your option) any later version. -# -# This library is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# Lesser General Public License for more details. -# -# You should have received a copy of the GNU Lesser General Public -# License along with this library; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -# -# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com -# - -ADD_SUBDIRECTORY(sphinx) diff --git a/doc/dev/CMakeLists.txt.REMOTE.5306.txt b/doc/dev/CMakeLists.txt.REMOTE.5306.txt deleted file mode 100644 index d91183151..000000000 --- a/doc/dev/CMakeLists.txt.REMOTE.5306.txt +++ /dev/null @@ -1,20 +0,0 @@ -# Copyright (C) 2012-2015 CEA/DEN, EDF R&D -# -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU Lesser General Public -# License as published by the Free Software Foundation; either -# version 2.1 of the License, or (at your option) any later version. -# -# This library is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# Lesser General Public License for more details. -# -# You should have received a copy of the GNU Lesser General Public -# License along with this library; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -# -# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com -# - -ADD_SUBDIRECTORY(sphinx) diff --git a/doc/dev/models/medop.xmi b/doc/dev/models/medcalc.xmi similarity index 97% rename from doc/dev/models/medop.xmi rename to doc/dev/models/medcalc.xmi index 9422c56f0..00fbdb5a4 100644 --- a/doc/dev/models/medop.xmi +++ b/doc/dev/models/medcalc.xmi @@ -31,7 +31,7 @@ - + @@ -136,7 +136,7 @@ - + @@ -183,7 +183,7 @@ - + @@ -289,8 +289,8 @@ - - + + diff --git a/doc/dev/sphinx/CMakeLists.txt b/doc/dev/sphinx/CMakeLists.txt index 7ebd6c6f6..e38aa7beb 100644 --- a/doc/dev/sphinx/CMakeLists.txt +++ b/doc/dev/sphinx/CMakeLists.txt @@ -20,7 +20,7 @@ SALOME_CONFIGURE_FILE(conf.py.in conf.py) SET(_cmd_options -c ${CMAKE_CURRENT_BINARY_DIR} -b html -d doctrees -D latex_paper_size=a4 ${CMAKE_CURRENT_SOURCE_DIR} html) -SALOME_GENERATE_ENVIRONMENT_SCRIPT(_cmd env_script "${SPHINX_EXECUTABLE}" "${_cmd_options}") +SALOME_GENERATE_ENVIRONMENT_SCRIPT(_cmd env_script "${SPHINX_EXECUTABLE}" "${_cmd_options}") ADD_CUSTOM_TARGET(dev_docs ALL COMMAND ${_cmd}) diff --git a/doc/dev/sphinx/_static/medop.css b/doc/dev/sphinx/_static/medcalc.css similarity index 100% rename from doc/dev/sphinx/_static/medop.css rename to doc/dev/sphinx/_static/medcalc.css diff --git a/doc/dev/sphinx/conf.py.in b/doc/dev/sphinx/conf.py.in index bc94c6f51..de917ad04 100644 --- a/doc/dev/sphinx/conf.py.in +++ b/doc/dev/sphinx/conf.py.in @@ -132,7 +132,7 @@ html_theme_options = { # The stylecheet file will be searched within the static path, while # the layout.html file will be searched within the template path # (Note that this parameter can't be used together with html_theme. Exclusive) -html_style = 'medop.css' +html_style = 'medcalc.css' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, @@ -175,7 +175,7 @@ html_copy_source = True #html_file_suffix = '' # Output file base name for HTML help builder. -htmlhelp_basename = 'medopdoc' +htmlhelp_basename = 'medcalcdoc' # Options for LaTeX output @@ -196,11 +196,11 @@ latex_elements = { # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, author, document class [howto/manual]). latex_documents = [ - ('index', 'medop-alldoc.tex', 'Documentation du module MED', 'G. Boulant', 'manual'), - ('medop-specifications', 'medop-specifications.tex', 'Module MED - Specifications', 'G. Boulant', 'manual'), - ('medop-develguide', 'medop-develguide.tex', 'Module MED - Guide de developpement', 'G. Boulant', 'manual'), - ('medop-userguide-gui', 'medop-userguide-gui.tex', 'Module MED - Guide d\'utilisation de l\'interface graphique', 'G. Boulant', 'howto'), - ('medop-userguide-api', 'medop-userguide-api.tex', 'MEDMEM library - Starter guide for users', 'G. Boulant', 'howto') + ('index', 'medcalc-alldoc.tex', 'Documentation du module MED', 'G. Boulant', 'manual'), + ('medcalc-specifications', 'medcalc-specifications.tex', 'Module MED - Specifications', 'G. Boulant', 'manual'), + ('medcalc-develguide', 'medcalc-develguide.tex', 'Module MED - Guide de developpement', 'G. Boulant', 'manual'), + ('medcalc-userguide-gui', 'medcalc-userguide-gui.tex', 'Module MED - Guide d\'utilisation de l\'interface graphique', 'G. Boulant', 'howto'), + ('medcalc-userguide-api', 'medcalc-userguide-api.tex', 'MEDMEM library - Starter guide for users', 'G. Boulant', 'howto') ] # The name of an image file (relative to this directory) to place at the top of diff --git a/doc/dev/sphinx/fr/index.rst b/doc/dev/sphinx/fr/index.rst index cf3fa4b1e..8d2939d2e 100644 --- a/doc/dev/sphinx/fr/index.rst +++ b/doc/dev/sphinx/fr/index.rst @@ -17,23 +17,23 @@ Documentation de référence .. toctree:: :maxdepth: 1 - medop-userguide-gui.rst - medop-userguide-api.rst + medcalc-userguide-gui.rst + medcalc-userguide-api.rst **Documentation technique** .. toctree:: :maxdepth: 1 - medop-specifications.rst - medop-develguide.rst + medcalc-specifications.rst + medcalc-develguide.rst **Documentation annexe** .. toctree:: :maxdepth: 1 - medop-references.rst + medcalc-references.rst Archives documentaires ====================== diff --git a/doc/dev/sphinx/fr/medop-definitions.rst b/doc/dev/sphinx/fr/medcalc-definitions.rst similarity index 100% rename from doc/dev/sphinx/fr/medop-definitions.rst rename to doc/dev/sphinx/fr/medcalc-definitions.rst diff --git a/doc/dev/sphinx/medop-develguide.rst b/doc/dev/sphinx/fr/medcalc-develguide.rst similarity index 86% rename from doc/dev/sphinx/medop-develguide.rst rename to doc/dev/sphinx/fr/medcalc-develguide.rst index 57f826e1c..1984584f8 100644 --- a/doc/dev/sphinx/medop-develguide.rst +++ b/doc/dev/sphinx/fr/medcalc-develguide.rst @@ -2,19 +2,19 @@ :keywords: maillage, champ, manipulation, med, développement :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Module MED: Guide de développement du composant MEDOP -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Module MED: Guide de développement du composant MEDCalc +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Le composant logiciel MEDOP est un élément du module MED. Il fournit +Le composant logiciel MEDCalc est un élément du module MED. Il fournit une interface utilisateur pour la manipulation de maillages et de champs, composée d'une interface texte (TUI) et d'une interface graphique (GUI). L'interface graphique constitue l'interface graphique du module MED. -Ce document est la documentation technique du composant MEDOP. Il +Ce document est la documentation technique du composant MEDCalc. Il fournit les instructions à suivre pour installer le composant en vue d'un travail de développement, puis décrit les éléments de conception. @@ -25,54 +25,54 @@ d'un travail de développement, puis décrit les éléments de conception. Mise en place de l'espace de développement ========================================== -Gestion de configuration du composant MEDOP +Gestion de configuration du composant MEDCalc ------------------------------------------- -Le composant logiciel MEDOP est un package du module SALOME MED, +Le composant logiciel MEDCalc est un package du module SALOME MED, hébergé dans l'espace source au niveau du sous-répertoire -`src/MEDOP`. La gestion des fichiers sources est donc intégrée dans le +`src/MEDCalc`. La gestion des fichiers sources est donc intégrée dans le module SALOME MED. -Organisation des sources du composant MEDOP +Organisation des sources du composant MEDCalc ------------------------------------------- -Le répertoire source `src/MEDOP` distingue les sous-répertoires +Le répertoire source `src/MEDCalc` distingue les sous-répertoires suivants: * cmp: package containing the SALOME components * tui: package containing the python user interface * gui: package containing the graphical user interface (the GUI part of the MED module) -* res: resources files associated to the MEDOP package (icons, config +* res: resources files associated to the MEDCalc package (icons, config files, data files, ...) * exe: additional executable programs that can be launched from the - MEDOP framework + MEDCalc framework -Construction du composant MEDOP +Construction du composant MEDCalc ------------------------------- -Intégré à la construction du module MED. Le composant MEDOP dépend de +Intégré à la construction du module MED. Le composant MEDCalc dépend de MEDCoupling et MEDLoader uniquement. -Exécution des tests unitaires du composant MEDOP +Exécution des tests unitaires du composant MEDCalc ------------------------------------------------ Les tests unitaires peuvent être exécutés au moyen de scripts python lancés depuis une session shell SALOME. Dans un nouveau shell, taper:: $ ./appli/runSession - [NS=mars:2810]$ python appli/bin/salome/med/test_medop_components.py + [NS=mars:2810]$ python appli/bin/salome/med/test_medcalc_components.py L'exécution imprime un rapport détaillant le résultat pour chaque fonction de test:: - + test_Calculator_applyFunc (__main__.MyTestSuite) ... ok test_Calculator_basics (__main__.MyTestSuite) ... ok test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok - test_addDatasource (__main__.MyTestSuite) ... ok + test_loadDatasource (__main__.MyTestSuite) ... ok test_getDataManager (__main__.MyTestSuite) ... ok test_getFieldHandlerList (__main__.MyTestSuite) ... ok test_getFieldRepresentation (__main__.MyTestSuite) ... ok @@ -82,7 +82,7 @@ fonction de test:: Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve: -* ``test_medop_components.py``: test les composants SALOME développés pour +* ``test_medcalc_components.py``: test les composants SALOME développés pour la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``). * ``test_xmed_fieldOperations.py``: test des operations de champs telles qu'elles sont mises en oeuvre depuis l'interface textuelle. @@ -150,7 +150,7 @@ valeurs des champs et les maillages support sont chargés au besoin. Le chargement des métadonnées de description se fait par la méthode:: - addDatasource(const char \*filepath) + loadDatasource(const char \*filepath) @@ -161,19 +161,19 @@ Ecrire un service CORBA qui retourne une sequence de FieldHandler: .. code-block:: cpp - MEDOP::FieldHandlerList * MyFunction(...) { - vector fieldHandlerList; + MEDCALC::FieldHandlerList * MyFunction(...) { + vector fieldHandlerList; ... - + fieldHandlerList.push_back(fieldHandler); - + // Map the resulting list to a CORBA sequence for return: - MEDOP::FieldHandlerList_var fieldHandlerSeq = new MEDOP::FieldHandlerList(); + MEDCALC::FieldHandlerList_var fieldHandlerSeq = new MEDCALC::FieldHandlerList(); int nbFieldHandler = fieldHandlerList.size(); fieldHandlerSeq->length(nbFieldHandler); for (int i=0; iid] = fieldHandler; // >>> WARNING: CORBA struct specification indicates that the @@ -193,7 +193,7 @@ Ecrire un service CORBA qui retourne une structure CORBA: // copy of the structure found in the map and return the copy. The // CORBA struct specification indicates that a deep copy can be // done using the copy constructor. <<< - return new MEDOP::FieldHandler(*fieldHandler); + return new MEDCALC::FieldHandler(*fieldHandler); @@ -212,7 +212,7 @@ ANNEXE B: Traçabilité avec le module XMED ========================================= Le module SALOME de nom XMED est l'espace de développement initial du -composant logiciel MEDOP, intégré aujourd'hui au module MED. Cette +composant logiciel MEDCalc, intégré aujourd'hui au module MED. Cette annexe est la notice technique de ce module, qui reste disponible mais qui n'est plus maintenu. @@ -245,7 +245,7 @@ moyen de la commande:: Cette commande installe un répertoire ``xsalome`` contenant l'ensemble des sources de la bibliothèque XSALOME. - + .. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une simple bibliothèque de fonctions qui complète ou rend plus facile d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS @@ -281,5 +281,5 @@ manipulation de champs:: Cette commande génére un répertoire ``appli`` à l'emplacement où elle est exécutée. Il reste à lancer l'application SALOME au moyen de la commande:: - + $ ./appli/runAppli -k diff --git a/doc/dev/sphinx/fr/medop-references.rst b/doc/dev/sphinx/fr/medcalc-references.rst similarity index 96% rename from doc/dev/sphinx/fr/medop-references.rst rename to doc/dev/sphinx/fr/medcalc-references.rst index 9be8cdc5f..2153884c1 100644 --- a/doc/dev/sphinx/fr/medop-references.rst +++ b/doc/dev/sphinx/fr/medcalc-references.rst @@ -2,7 +2,7 @@ ANNEXE: Références documentaires %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst Documents de référence: diff --git a/doc/dev/sphinx/fr/medop-specifications.rst b/doc/dev/sphinx/fr/medcalc-specifications.rst similarity index 99% rename from doc/dev/sphinx/fr/medop-specifications.rst rename to doc/dev/sphinx/fr/medcalc-specifications.rst index 09ca88cd2..ae152232e 100644 --- a/doc/dev/sphinx/fr/medop-specifications.rst +++ b/doc/dev/sphinx/fr/medcalc-specifications.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, manipulation, med :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Module MED: Spécifications fonctionnelles et techniques @@ -123,11 +123,11 @@ supplémentaire: Par convention, on utilisera par la suite les notations: * **U(t,p,c)** pour désigner la valeur de la composante c d'un champ U - à la position p et prise à l'instant t; + à la position p et prise à l'instant t; * **U(t,p,:)** pour signifier que l'on manipule l'ensemble de toutes les composantes; * **U(t,:,c)** pour signifier que l'on manipule le domaine de - définition spatial complet. + définition spatial complet. Dans une grande majorité des cas d'usage on travaille à temps t fixé et sur un domaine spatiale prédéfini. Aussi on utilisera également la @@ -167,7 +167,7 @@ On formalise donc le concept d'opération par les propriétés suivantes: * L'opérateur est caractérisé par un domaine d'application qui spécifie la portée de l'opération. Ce domaine comporte plusieurs dimensions: - + - Un domaine temporel T qui spécifie les pas de temps sur lesquels l'opération est appliquée; - Un domaine spatial D qui spécifie la limite de portée de @@ -283,13 +283,13 @@ de changer le maillage support M1 d'un champs par un maillage M2 à partir du moment où les maillages M1 et M2 sont identiques géométriquement à une erreur près qu'il est possible de spécifier. -.. note:: +.. note:: D'autres situations limites peuvent être évoquées sous l'angle informatique. Ce sont des situations qui a priori n'ont pas de raison d'exister sur le plan conceptuel mais qui peuvent très bien survenir au niveau du module informatique compte-tenu des particularités du modèle MED. Par exemple: - + * Le nombre et la nature des composantes ne sont pas identiques pour tous les champs d'entrée. Par exemple, U défini ses composantes comme U(:,:,1)=Ux, U(:,:,2)=Uy, U(:,:,3)=Uz et V les @@ -408,14 +408,14 @@ de classer ces opérations en deux catégories: * les **opérations binaires**, qui prennent deux opérandes en argument. C'est le cas des opérations algébriques et des opérations vectorielles. - + A partir de cette classification, il convient de distinguer trois formes d'usage selon la nature des opérandes: * les opérandes sont exclusivement des scalaires (typiquement des valeurs de composantes des champs et des paramètres numériques). Par exemple:: - + W(:,:4) = 1+2xU(:,:,2)+V(:,:,3) * les opérandes sont exclusivement des champs. Par exemple:: @@ -478,7 +478,7 @@ paramètre numérique ou la composante d'un champ): .. warning:: A développer: - + * Analyse dimensionnelle du champ résultats pour adapter l'unité. Par exemple, si on fait UxV où U et V sont exprimés en [m] alors le résultat est en [m2]. @@ -676,7 +676,7 @@ l'interface textuelle: l'utilisateur à spécifier un alias pour la variable python qui va permettre la manipulation du champ dans l'interface textuelle de l'espace de travail (par défaut, le nom complet du champ est - proposé). Ici, l'utilisateur spécifie ``f4``: + proposé). Ici, l'utilisateur spécifie ``f4``: .. image:: images/xmed-gui-datasource-useinworkspace_70pc.png :align: center @@ -709,7 +709,7 @@ Dans le cadre défini ci-dessus, une session d'utilisation type est: conséquent de simplification et d'assistance en ligne). Par exemple, si ``fa`` et ``fb`` désignent deux champs définis dans l'espace de travail, alors on peut en faire la somme par la commande:: - + >>> r=fa+fb * Effectuer les contrôles visuel et les diagnostics en ligne de @@ -727,7 +727,7 @@ Sur cette base, on peut envisager une grande variété de cas d'utilisation: chargée dans le dataspace (l'étude SALOME techniquement) et peut être explorée au niveau de l'arbre d'étude. L'arbre peut faire apparaître: - + - les maillages et les groupes (qui peuvent être utilisés éventuellement pour restreindre le domaine d'application) - les champs dont on peut explorer les composantes et les itérations @@ -777,7 +777,7 @@ fonction de visualisation: choisir l'option "Visualize": .. image:: images/xmed-gui-datasource-visualize_70pc.png - :align: center + :align: center * Cette option déclenche l'affichage d'une carte de champ sur le cadre d'affichage des viewers SALOME: diff --git a/doc/dev/sphinx/fr/medop-userguide-gui.rst b/doc/dev/sphinx/fr/medcalc-userguide-gui.rst similarity index 94% rename from doc/dev/sphinx/fr/medop-userguide-gui.rst rename to doc/dev/sphinx/fr/medcalc-userguide-gui.rst index f09404a64..a90efde32 100644 --- a/doc/dev/sphinx/fr/medop-userguide-gui.rst +++ b/doc/dev/sphinx/fr/medcalc-userguide-gui.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, manipulation, guide utilisateur :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Module MED: Guide d'utilisation de l'interface graphique @@ -16,7 +16,7 @@ champs. .. warning:: Le document est autonome, mais il est vivement conseillé de parcourir au préalable (ou en parallèle) :doc:`le document de - spécifications`, au moins pour fixer les + spécifications`, au moins pour fixer les concepts et la terminologie. .. contents:: Sommaire @@ -331,11 +331,11 @@ champ manoeuvré. Pour cela, on tape simplement le nom de la variable puis retour:: >>> f3 - field name (id) = Pulse (3) - mesh name (id) = Grid_80x80 (0) - discretization = ON_NODES - (iter, order) = (3,-1) - data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med + field name (id) = Pulse (3) + mesh name (id) = Grid_80x80 (0) + discretization = ON_NODES + (iter, order) = (3,-1) + data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med Elle peut également être utilisée comme argument des commandes de gestion disponibles dans l'interface textuelle (dont la liste @@ -363,16 +363,16 @@ commande ``print``:: >>> print f3 Data content : - Tuple #0 : -0.6 - Tuple #1 : -0.1 - Tuple #2 : 0.4 - Tuple #3 : -0.1 - Tuple #4 : 0.4 + Tuple #0 : -0.6 + Tuple #1 : -0.1 + Tuple #2 : 0.4 + Tuple #3 : -0.1 + Tuple #4 : 0.4 ... - Tuple #6556 : 3.5 - Tuple #6557 : 3.3 - Tuple #6558 : 1.5 - Tuple #6559 : 0.3 + Tuple #6556 : 3.5 + Tuple #6557 : 3.3 + Tuple #6558 : 1.5 + Tuple #6559 : 0.3 Tuple #6560 : 0.2 Il est important de noter que les opérations entre champs ne peuvent @@ -661,25 +661,27 @@ Utilisation de l'interface textuelle du module MED (TUI) Toutes les opérations menées au moyen de l'interface graphique peuvent être réalisées (avec plus ou moins de facilité) avec l'interface textuelle. Le module de manipulation de champs peut même être utilisé -exclusivement en mode texte. Pour cela, on lance la commande:: +exclusivement en mode texte. +.. + Pour cela, on lance la commande:: $ /medop.sh - -Cette commande ouvre une console de commandes ``medop>``. Un fichier -med peut être chargé et travaillé, par exemple pour créer des champs à -partir des données du fichier. +.. + Cette commande ouvre une console de commandes ``medop>``. Un fichier + med peut être chargé et travaillé, par exemple pour créer des champs à + partir des données du fichier. Que l'on soit en mode texte pur ou en mode graphique, un séquence de travail type dans la console peut ressembler au jeu d'instructions suivantes:: - >>> load("/path/to/mydata.med") + >>> medcalc.LoadDataSource("/path/to/mydata.med") >>> la id=0 name = testfield1 id=1 name = testfield2 - >>> f1=get(0) - >>> f2=get(1) - >>> ls + >>> f1=accessField(0) + >>> f2=accessField(1) + >>> ls f1 (id=0, name=testfield1) f2 (id=1, name=testfield2) >>> r=f1+f2 @@ -692,37 +694,39 @@ suivantes:: f1 (id=0, name=testfield1) f2 (id=1, name=testfield2) r (id=2, name=toto) - >>> put(r) - >>> save("result.med") + >>> putInWorkspace(r) + >>> saveWorkspace("result.med") Les commandes principales sont: -* ``load``: charge un fichier med dans la base de données (utile +* ``LoadDataSource``: charge un fichier med dans la base de données (utile uniquement en mode texte pur):: - >>> load("/path/to/datafile.med") + >>> LoadDataSource("/path/to/datafile.med") + +* ``LoadImageAsDataSource``: load an image as a med file * ``la``: affiche la liste de tous les champs chargés en base de données ("list all") -* ``get``: définit un champ dans l'espace de travail à partir de son +* ``accessField``: définit un champ dans l'espace de travail à partir de son identifiant (utile plutôt en mode texte pur car l'interface graphique permet de faire cette opération par sélection d'un champ dans le dataspace):: - >>> f=get(fieldId) + >>> f=accessField(fieldId) * ``ls``: affiche la liste des champs présent dans l'espace de travail ("list") -* ``put``: met un champ en référence dans l'*espace de gestion*:: +* ``putInWorkspace``: met un champ en référence dans l'*espace de gestion*:: - >>> put(f) + >>> putInWorkspace(f) -* ``save``: sauvegarde tous les champs référencés dans l'espace de +* ``saveWorkspace``: sauvegarde tous les champs référencés dans l'espace de gestion dans un fichier med:: - >>> save("/path/to/resultfile.med") + >>> saveWorkspace("/path/to/resultfile.med") .. note:: On peut faire à ce stade plusieurs remarques: - * la commande ``load`` charge uniquement les méta-informations + * la commande ``LoadDataSource`` charge uniquement les méta-informations décrivant les maillage et les champs (noms, type de discrétisation, liste des pas de temps). Les maillages et les valeurs physiques des champs sont chargées ultérieurement (et @@ -730,7 +734,7 @@ Les commandes principales sont: opération. Dans tous les cas, les données med (méta-informations et valeurs) sont physiquement stockées au niveau de l'espace *base de données*. - * la commande ``get`` définit en réalité un *manipulateur de champ* + * la commande ``accessField`` définit en réalité un *manipulateur de champ* dans l'espace de travail, c'est-à-dire une variable qui fait la liaison avec le champ physique hébergé dans la base de données. Les données physiques ne circulent jamais entre les @@ -740,9 +744,9 @@ Les commandes principales sont: Les commandes TUI suivantes nécessitent de travailler dans l'environnement graphique: -* ``visu``: afficher une carte de champ pour contrôle visuel rapide - (pas de paramettrage possible) - - >>> view(f) - - +* ``medcalc.MakeDeflectionShape`` +* ``medcalc.MakeIsoSurface`` +* ``medcalc.MakePointSprite`` +* ``medcalc.MakeScalarMap`` +* ``medcalc.MakeSlices`` +* ``medcalc.MakeVectorField`` diff --git a/doc/dev/sphinx/fr/medop-prototype-develguide.rst b/doc/dev/sphinx/fr/medop-prototype-develguide.rst index de2387b74..0bc2eae90 100644 --- a/doc/dev/sphinx/fr/medop-prototype-develguide.rst +++ b/doc/dev/sphinx/fr/medop-prototype-develguide.rst @@ -210,14 +210,14 @@ l'addition de deux champs: import salome salome.salome_init() import SALOME_MED - + medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED") medObj = medComp.readStructFile("myfile.med",salome.myStudyName) medOp = medObj.createMedOperator() - + f1 = medObj.getField("testfield1",-1,-1) f2 = medObj.getField("testfield2",-1,-1) - + somme = medOp.add(f1,f2) Il est à noter qu'une instance de ``SALOME_MED::MEDOP`` est associé à @@ -269,7 +269,7 @@ et le numéro d'iteration: salome.salome_init() import SALOME_MED - medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED") + medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED") medObj = medComp.readStructFile("myfile.med",salome.myStudyName) from xmed import fieldproxy @@ -312,9 +312,9 @@ graphique en images: .. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png .. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png -+---------------+---------------+ ++---------------+---------------+ | |IMG_SELECT| | |IMG_ALIAS| | -+---------------+---------------+ ++---------------+---------------+ L'image de gauche montre la sélection du pas de temps, l'image de droite la boîte de dialogue qui permet la saisie de l'alias avec @@ -353,7 +353,7 @@ un objet CORBA): // We suppose here that we have a CORBA object reference (object of // type *_ptr or *_var), for example a SALOME_MED::MED object. - SALOME_MED::MED_ptr medObj = ... // anything to get this object + SALOME_MED::MED_ptr medObj = ... // anything to get this object // Get the IOR of this object QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj); @@ -363,7 +363,7 @@ un objet CORBA): QStringList commands; commands+="import salome"; commands+=QString("med=salome.orb.string_to_object(\"%1\")").arg(medIOR); - + QStringListIterator it(commands); while (it.hasNext()) { pyConsole->exec(it.next()); @@ -411,9 +411,9 @@ commandes suivantes: from xmed.fieldproxy import getFieldFromMed from xmed.medproxy import getMedProxy - + med = getMedProxy("IOR:010000001700000049444c3a53414c4f4d455f4d45442f4d45443a312e300000010000000000000064000000010102000e0000003133302e39382e37372e313733009e0a0e000000feadc4ca4c00003169000000001100000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100") - + f1=getFieldFromMed(med,"testfield1",-1,-1) Ce jeu d'instructions reconstitue un pointeur vers le servant CORBA @@ -543,9 +543,9 @@ module du champ dans l'exemple implémenté par défaut): .. |IMG_VISU| image:: images/medop-gui-visufield_scale.png .. |IMG_RESULT| image:: images/medop-gui-result_scale.png -+---------------+---------------+ ++---------------+---------------+ | |IMG_VISU| | |IMG_RESULT| | -+---------------+---------------+ ++---------------+---------------+ Cette fonction répond au besoin de contrôle interactif des résultats produits par les opérations de manipulation de champs. @@ -556,7 +556,7 @@ donnée du servant ``SALOME_MED::FIELD`` qui lui est associé (représenté par la variable ``field_ptr`` dans l'exemple ci-dessous): .. code-block:: python - + import salome import VISU @@ -710,11 +710,11 @@ automatiser proprement): et fournit des fonctions de test unitaire (à exécuter ou pour s'en inspirer). Après avoir lancé SALOME via une application virtuelle, on peut taper:: - + $ /runSession [NS=venus:2810] $ python -i test_medoperation.py - >>> - + >>> + - Ceci permet de tester en particulier l'interface ``MedOp`` et son utilisation dans le module python ``fieldproxy.py``. diff --git a/doc/dev/sphinx/fr/medop-prototype-medmem.rst b/doc/dev/sphinx/fr/medop-prototype-medmem.rst index 2302f7b70..9c29fee19 100644 --- a/doc/dev/sphinx/fr/medop-prototype-medmem.rst +++ b/doc/dev/sphinx/fr/medop-prototype-medmem.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, MED, MEDMEM :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Note de travail concernant l'utilisation de MEDMEM @@ -115,7 +115,7 @@ d'entrée/sortie branché sur le fichier (``testfilename`` dans l'exemple): .. code-block:: cpp - + MED *myMed = new MED; MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed); driverIn->open(); @@ -140,7 +140,7 @@ Puis le champ qui lui est associé doit être physiquement chargé pour permettre la mise à jour du support: .. code-block:: cpp - + MESH * mesh = myMed->getMesh(field); mesh->read(); myMed->updateSupport(); @@ -148,7 +148,7 @@ permettre la mise à jour du support: Pour enfin charger les valeurs des composantes du champ: .. code-block:: cpp - + field->read(); La numérotation des éléments de maillage @@ -204,7 +204,7 @@ Pour exemple, le fragment de code ci-dessous, extrait du fichier ``MedDataManager`` dans l'interface: .. code-block:: cpp - + #include "MEDMEM_MedDataManager.hxx" class MedDataManager @@ -212,24 +212,24 @@ Pour exemple, le fragment de code ci-dessous, extrait du fichier public: ~MedDataManager(); void printFieldDouble(FIELD * field); - + %extend { MedDataManager(char * fileName) { - return new MedDataManager(string(fileName)); + return new MedDataManager(string(fileName)); } MedDataManager(MED * med) { return new MedDataManager(med); } - + %newobject getFieldDouble(const char * fieldName, const int dt, const int it); FIELD * getFieldDouble(const char * fieldName, const int dt, const int it) { - return (FIELD *) self->getFieldDouble(string(fieldName), dt, it); + return (FIELD *) self->getFieldDouble(string(fieldName), dt, it); } } - + }; @@ -380,17 +380,17 @@ utilise l'interface swig fournie par MedCorba_Swig). Après l'import d'amorce systématique: .. code-block:: python - + import salome salome.salome_init() - + import SALOME_MED from libSALOME_Swig import * On peut charger le composant SALOME MED: .. code-block:: python - + medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED") grâce auquel les services de chargement de la structure MED peuvent @@ -398,14 +398,14 @@ grâce auquel les services de chargement de la structure MED peuvent structure MED dans l'étude salome passée en argument: .. code-block:: python - + filePathName = "myfile.med" medComp.readStructFileWithFieldType(filePathName,salome.myStudyName) Ce deuxième exemple charge la structure MED mais ne place pas le résultat dans l'étude: .. code-block:: python - + filePathName = "myfile.med" medObj = medComp.readStructFile(filePathName,salome.myStudyName) @@ -418,13 +418,13 @@ verra plus bas) à MEDMEM: fieldIdx = 1 # WRN maybe there is no field of idx=1 iterationIdx = 0 fieldName = medObj.getFieldNames()[fieldIdx] - dtitfield = medObj.getFieldIteration(fieldName,iterationIdx) + dtitfield = medObj.getFieldIteration(fieldName,iterationIdx) it = dtitfield[0] dt = dtitfield[1] fieldObj = medObj.getField(fieldName,it,dt) nbOfFields = medObj.getNumberOfFields() fieldNames = medObj.getFieldNames() - + mesh = fieldObj.getSupport().getMesh() .. note:: @@ -469,22 +469,22 @@ SALOME_MED, ...) sont supposées avoir été faites au préalable (voir les exemples précédents): .. code-block:: python - + # Load the med structure using MED medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED") filePathName = "myfile.med" medComp.readStructFileWithFieldType(filePathName,salome.myStudyName) - + # Get the VISU component import VISU visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU") visuComp.SetCurrentStudy(salome.myStudy) - + # Get the sobject associated to the med object named "Med" aSObject = salome.myStudy.FindObject("Med") isPresent, medSObj = aSObject.FindSubObject(1) - - # Finally, import the med sobject in VISU + + # Finally, import the med sobject in VISU result = visuComp.ImportMed(medSObj) Il est possible de d'aller plus loin et par exemple de déclencher @@ -503,7 +503,7 @@ Notes en vrac Questions: -* Comment obtenir le nom du fichier med à partir d'une structure med? +* Comment obtenir le nom du fichier med à partir d'une structure med? * Peut-on imaginer un moyen de fournir l'objet MEDMEM::MED à partir de la donnée de l'objet CORBA SALOME_MED::MED? diff --git a/doc/dev/sphinx/fr/medop-prototype-overview.rst b/doc/dev/sphinx/fr/medop-prototype-overview.rst index c571c6e6f..5eaa00e08 100644 --- a/doc/dev/sphinx/fr/medop-prototype-overview.rst +++ b/doc/dev/sphinx/fr/medop-prototype-overview.rst @@ -56,11 +56,11 @@ images: .. |IMG_VISU| image:: images/medop-gui-visufield_scale.png .. |IMG_RESULT| image:: images/medop-gui-result_scale.png -+---------------+---------------+ ++---------------+---------------+ | |IMG_SELECT| | |IMG_ALIAS| | -+---------------+---------------+ ++---------------+---------------+ | |IMG_VISU| | |IMG_RESULT| | -+---------------+---------------+ ++---------------+---------------+ La solution technique est construite sur les principes suivants: diff --git a/doc/dev/sphinx/fr/medop-workingnotes-2011.rst b/doc/dev/sphinx/fr/medop-workingnotes-2011.rst index 2c38e64bb..269b63b5a 100644 --- a/doc/dev/sphinx/fr/medop-workingnotes-2011.rst +++ b/doc/dev/sphinx/fr/medop-workingnotes-2011.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, manipulation :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ANNEXE: Note de travail concernant le chantier XMED 2011 @@ -145,7 +145,7 @@ Nouveaux concepts à prendre en compte ------------------------------------- Au démarrage du chantier 2011, on observe que les concepts suivants -sont introduits dans le module MED: +sont introduits dans le module MED: * Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger les fichiers med et obtenir les informations générales sur le @@ -469,5 +469,5 @@ Petites améliorations du DataspaceController: est posé dans le WS. On peut donc proposer en option de lui associer un alias pour manipulation dans la console - - + + diff --git a/doc/dev/sphinx/fr/medop-workingnotes-2012.rst b/doc/dev/sphinx/fr/medop-workingnotes-2012.rst index b6ecb6d37..4a3e10af4 100644 --- a/doc/dev/sphinx/fr/medop-workingnotes-2012.rst +++ b/doc/dev/sphinx/fr/medop-workingnotes-2012.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, manipulation :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ANNEXE: Note de travail concernant le chantier XMED 2012 @@ -80,5 +80,5 @@ peut procéder de la manière suivante: * Eliminer la dépendance à XSALOME * Supprimer la gestion des multiversion SALOME5/6 au niveau de l'engine -.. warning:: TODO: refaire le point sur les tâches initiées en 2011 +.. warning:: TODO: refaire le point sur les tâches initiées en 2011 diff --git a/doc/dev/sphinx/index.rst b/doc/dev/sphinx/index.rst index e291c971c..6560ec984 100644 --- a/doc/dev/sphinx/index.rst +++ b/doc/dev/sphinx/index.rst @@ -15,23 +15,23 @@ References .. toctree:: :maxdepth: 1 - medop-userguide-gui.rst - medop-userguide-api.rst + medcalc-userguide-gui.rst + medcalc-userguide-api.rst **Technical documentation** (**in french**): .. toctree:: :maxdepth: 1 - medop-specifications.rst - medop-develguide.rst + medcalc-specifications.rst + medcalc-develguide.rst **Additional documentation** .. toctree:: :maxdepth: 1 - medop-references.rst + medcalc-references.rst Document archive (in french) ============================ diff --git a/doc/dev/sphinx/medop-definitions.rst b/doc/dev/sphinx/medcalc-definitions.rst similarity index 100% rename from doc/dev/sphinx/medop-definitions.rst rename to doc/dev/sphinx/medcalc-definitions.rst diff --git a/doc/dev/sphinx/fr/medop-develguide.rst b/doc/dev/sphinx/medcalc-develguide.rst similarity index 86% rename from doc/dev/sphinx/fr/medop-develguide.rst rename to doc/dev/sphinx/medcalc-develguide.rst index 57f826e1c..1984584f8 100644 --- a/doc/dev/sphinx/fr/medop-develguide.rst +++ b/doc/dev/sphinx/medcalc-develguide.rst @@ -2,19 +2,19 @@ :keywords: maillage, champ, manipulation, med, développement :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Module MED: Guide de développement du composant MEDOP -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +Module MED: Guide de développement du composant MEDCalc +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Le composant logiciel MEDOP est un élément du module MED. Il fournit +Le composant logiciel MEDCalc est un élément du module MED. Il fournit une interface utilisateur pour la manipulation de maillages et de champs, composée d'une interface texte (TUI) et d'une interface graphique (GUI). L'interface graphique constitue l'interface graphique du module MED. -Ce document est la documentation technique du composant MEDOP. Il +Ce document est la documentation technique du composant MEDCalc. Il fournit les instructions à suivre pour installer le composant en vue d'un travail de développement, puis décrit les éléments de conception. @@ -25,54 +25,54 @@ d'un travail de développement, puis décrit les éléments de conception. Mise en place de l'espace de développement ========================================== -Gestion de configuration du composant MEDOP +Gestion de configuration du composant MEDCalc ------------------------------------------- -Le composant logiciel MEDOP est un package du module SALOME MED, +Le composant logiciel MEDCalc est un package du module SALOME MED, hébergé dans l'espace source au niveau du sous-répertoire -`src/MEDOP`. La gestion des fichiers sources est donc intégrée dans le +`src/MEDCalc`. La gestion des fichiers sources est donc intégrée dans le module SALOME MED. -Organisation des sources du composant MEDOP +Organisation des sources du composant MEDCalc ------------------------------------------- -Le répertoire source `src/MEDOP` distingue les sous-répertoires +Le répertoire source `src/MEDCalc` distingue les sous-répertoires suivants: * cmp: package containing the SALOME components * tui: package containing the python user interface * gui: package containing the graphical user interface (the GUI part of the MED module) -* res: resources files associated to the MEDOP package (icons, config +* res: resources files associated to the MEDCalc package (icons, config files, data files, ...) * exe: additional executable programs that can be launched from the - MEDOP framework + MEDCalc framework -Construction du composant MEDOP +Construction du composant MEDCalc ------------------------------- -Intégré à la construction du module MED. Le composant MEDOP dépend de +Intégré à la construction du module MED. Le composant MEDCalc dépend de MEDCoupling et MEDLoader uniquement. -Exécution des tests unitaires du composant MEDOP +Exécution des tests unitaires du composant MEDCalc ------------------------------------------------ Les tests unitaires peuvent être exécutés au moyen de scripts python lancés depuis une session shell SALOME. Dans un nouveau shell, taper:: $ ./appli/runSession - [NS=mars:2810]$ python appli/bin/salome/med/test_medop_components.py + [NS=mars:2810]$ python appli/bin/salome/med/test_medcalc_components.py L'exécution imprime un rapport détaillant le résultat pour chaque fonction de test:: - + test_Calculator_applyFunc (__main__.MyTestSuite) ... ok test_Calculator_basics (__main__.MyTestSuite) ... ok test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok - test_addDatasource (__main__.MyTestSuite) ... ok + test_loadDatasource (__main__.MyTestSuite) ... ok test_getDataManager (__main__.MyTestSuite) ... ok test_getFieldHandlerList (__main__.MyTestSuite) ... ok test_getFieldRepresentation (__main__.MyTestSuite) ... ok @@ -82,7 +82,7 @@ fonction de test:: Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve: -* ``test_medop_components.py``: test les composants SALOME développés pour +* ``test_medcalc_components.py``: test les composants SALOME développés pour la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``). * ``test_xmed_fieldOperations.py``: test des operations de champs telles qu'elles sont mises en oeuvre depuis l'interface textuelle. @@ -150,7 +150,7 @@ valeurs des champs et les maillages support sont chargés au besoin. Le chargement des métadonnées de description se fait par la méthode:: - addDatasource(const char \*filepath) + loadDatasource(const char \*filepath) @@ -161,19 +161,19 @@ Ecrire un service CORBA qui retourne une sequence de FieldHandler: .. code-block:: cpp - MEDOP::FieldHandlerList * MyFunction(...) { - vector fieldHandlerList; + MEDCALC::FieldHandlerList * MyFunction(...) { + vector fieldHandlerList; ... - + fieldHandlerList.push_back(fieldHandler); - + // Map the resulting list to a CORBA sequence for return: - MEDOP::FieldHandlerList_var fieldHandlerSeq = new MEDOP::FieldHandlerList(); + MEDCALC::FieldHandlerList_var fieldHandlerSeq = new MEDCALC::FieldHandlerList(); int nbFieldHandler = fieldHandlerList.size(); fieldHandlerSeq->length(nbFieldHandler); for (int i=0; iid] = fieldHandler; // >>> WARNING: CORBA struct specification indicates that the @@ -193,7 +193,7 @@ Ecrire un service CORBA qui retourne une structure CORBA: // copy of the structure found in the map and return the copy. The // CORBA struct specification indicates that a deep copy can be // done using the copy constructor. <<< - return new MEDOP::FieldHandler(*fieldHandler); + return new MEDCALC::FieldHandler(*fieldHandler); @@ -212,7 +212,7 @@ ANNEXE B: Traçabilité avec le module XMED ========================================= Le module SALOME de nom XMED est l'espace de développement initial du -composant logiciel MEDOP, intégré aujourd'hui au module MED. Cette +composant logiciel MEDCalc, intégré aujourd'hui au module MED. Cette annexe est la notice technique de ce module, qui reste disponible mais qui n'est plus maintenu. @@ -245,7 +245,7 @@ moyen de la commande:: Cette commande installe un répertoire ``xsalome`` contenant l'ensemble des sources de la bibliothèque XSALOME. - + .. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une simple bibliothèque de fonctions qui complète ou rend plus facile d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS @@ -281,5 +281,5 @@ manipulation de champs:: Cette commande génére un répertoire ``appli`` à l'emplacement où elle est exécutée. Il reste à lancer l'application SALOME au moyen de la commande:: - + $ ./appli/runAppli -k diff --git a/doc/dev/sphinx/medop-references.rst b/doc/dev/sphinx/medcalc-references.rst similarity index 96% rename from doc/dev/sphinx/medop-references.rst rename to doc/dev/sphinx/medcalc-references.rst index 0cc327834..43cb54564 100644 --- a/doc/dev/sphinx/medop-references.rst +++ b/doc/dev/sphinx/medcalc-references.rst @@ -2,7 +2,7 @@ Appendix: Documentation references %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst References: diff --git a/doc/dev/sphinx/medop-specifications.rst b/doc/dev/sphinx/medcalc-specifications.rst similarity index 99% rename from doc/dev/sphinx/medop-specifications.rst rename to doc/dev/sphinx/medcalc-specifications.rst index 09ca88cd2..ae152232e 100644 --- a/doc/dev/sphinx/medop-specifications.rst +++ b/doc/dev/sphinx/medcalc-specifications.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, manipulation, med :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Module MED: Spécifications fonctionnelles et techniques @@ -123,11 +123,11 @@ supplémentaire: Par convention, on utilisera par la suite les notations: * **U(t,p,c)** pour désigner la valeur de la composante c d'un champ U - à la position p et prise à l'instant t; + à la position p et prise à l'instant t; * **U(t,p,:)** pour signifier que l'on manipule l'ensemble de toutes les composantes; * **U(t,:,c)** pour signifier que l'on manipule le domaine de - définition spatial complet. + définition spatial complet. Dans une grande majorité des cas d'usage on travaille à temps t fixé et sur un domaine spatiale prédéfini. Aussi on utilisera également la @@ -167,7 +167,7 @@ On formalise donc le concept d'opération par les propriétés suivantes: * L'opérateur est caractérisé par un domaine d'application qui spécifie la portée de l'opération. Ce domaine comporte plusieurs dimensions: - + - Un domaine temporel T qui spécifie les pas de temps sur lesquels l'opération est appliquée; - Un domaine spatial D qui spécifie la limite de portée de @@ -283,13 +283,13 @@ de changer le maillage support M1 d'un champs par un maillage M2 à partir du moment où les maillages M1 et M2 sont identiques géométriquement à une erreur près qu'il est possible de spécifier. -.. note:: +.. note:: D'autres situations limites peuvent être évoquées sous l'angle informatique. Ce sont des situations qui a priori n'ont pas de raison d'exister sur le plan conceptuel mais qui peuvent très bien survenir au niveau du module informatique compte-tenu des particularités du modèle MED. Par exemple: - + * Le nombre et la nature des composantes ne sont pas identiques pour tous les champs d'entrée. Par exemple, U défini ses composantes comme U(:,:,1)=Ux, U(:,:,2)=Uy, U(:,:,3)=Uz et V les @@ -408,14 +408,14 @@ de classer ces opérations en deux catégories: * les **opérations binaires**, qui prennent deux opérandes en argument. C'est le cas des opérations algébriques et des opérations vectorielles. - + A partir de cette classification, il convient de distinguer trois formes d'usage selon la nature des opérandes: * les opérandes sont exclusivement des scalaires (typiquement des valeurs de composantes des champs et des paramètres numériques). Par exemple:: - + W(:,:4) = 1+2xU(:,:,2)+V(:,:,3) * les opérandes sont exclusivement des champs. Par exemple:: @@ -478,7 +478,7 @@ paramètre numérique ou la composante d'un champ): .. warning:: A développer: - + * Analyse dimensionnelle du champ résultats pour adapter l'unité. Par exemple, si on fait UxV où U et V sont exprimés en [m] alors le résultat est en [m2]. @@ -676,7 +676,7 @@ l'interface textuelle: l'utilisateur à spécifier un alias pour la variable python qui va permettre la manipulation du champ dans l'interface textuelle de l'espace de travail (par défaut, le nom complet du champ est - proposé). Ici, l'utilisateur spécifie ``f4``: + proposé). Ici, l'utilisateur spécifie ``f4``: .. image:: images/xmed-gui-datasource-useinworkspace_70pc.png :align: center @@ -709,7 +709,7 @@ Dans le cadre défini ci-dessus, une session d'utilisation type est: conséquent de simplification et d'assistance en ligne). Par exemple, si ``fa`` et ``fb`` désignent deux champs définis dans l'espace de travail, alors on peut en faire la somme par la commande:: - + >>> r=fa+fb * Effectuer les contrôles visuel et les diagnostics en ligne de @@ -727,7 +727,7 @@ Sur cette base, on peut envisager une grande variété de cas d'utilisation: chargée dans le dataspace (l'étude SALOME techniquement) et peut être explorée au niveau de l'arbre d'étude. L'arbre peut faire apparaître: - + - les maillages et les groupes (qui peuvent être utilisés éventuellement pour restreindre le domaine d'application) - les champs dont on peut explorer les composantes et les itérations @@ -777,7 +777,7 @@ fonction de visualisation: choisir l'option "Visualize": .. image:: images/xmed-gui-datasource-visualize_70pc.png - :align: center + :align: center * Cette option déclenche l'affichage d'une carte de champ sur le cadre d'affichage des viewers SALOME: diff --git a/doc/dev/sphinx/medop-userguide-api.rst b/doc/dev/sphinx/medcalc-userguide-api.rst similarity index 93% rename from doc/dev/sphinx/medop-userguide-api.rst rename to doc/dev/sphinx/medcalc-userguide-api.rst index 6f230abc8..161e0551f 100644 --- a/doc/dev/sphinx/medop-userguide-api.rst +++ b/doc/dev/sphinx/medcalc-userguide-api.rst @@ -1,9 +1,9 @@ .. meta:: - :description: introduction guide for users of the MEDMEM library + :description: introduction guide for users of the MEDMEM library :keywords: mesh, field, med, MEDCoupling, MEDLoader :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MEDMEM library: Starter guide for users @@ -73,11 +73,11 @@ What we call MEDMEM library in this document is represented by the orange packages on this diagram. The white packages reprensent the old deprecated MEDMEM library. The blue packages represent the aditionnal components for field manipulation througth the user interface (TUI and -GUI). +GUI). The MEDMEM library comes also with this set of atomic libraries for advanced users/programmers: - + * :tt:`medcouplingcorba`: this library is designed for cross process exchange of medcoupling objects. * :tt:`medpartitioner`: this library provides functions to split a MED @@ -88,18 +88,18 @@ modules (using the swig binding technology) so that all the data processing can be realized by scripting. .. warning:: It could happen that some parts of the C++ libraries are - not wrapped into python modules. This coverture will be - extend on demand and if the integrity of the concepts is - preserved. + not wrapped into python modules. This coverture will be + extend on demand and if the integrity of the concepts is + preserved. Main concepts of the MEDMEM library =================================== .. warning:: TODO avec Antony. Présenter les structure de données de - MEDCoupling principalement. Describe the MEDMEM data - model, the typical content of a med file, the types of - cell that compose the meshes, the types of spatial - discretization of fields, ... + MEDCoupling principalement. Describe the MEDMEM data + model, the typical content of a med file, the types of + cell that compose the meshes, the types of spatial + discretization of fields, ... Basic usages of the MEDMEM library ================================== @@ -109,9 +109,9 @@ library using python examples. The usage of python is just to have a light syntax that makes more easy the first understanding. .. note:: All code examples here after are parts of the tutorial use - cases located in the folder :tt:`src/MEDOP/tut` in the MED - source directory. These use cases are all working executable - programs and they can be used to initiate your own script. + cases located in the folder :tt:`src/MEDCalc/tut` in the MED + source directory. These use cases are all working executable + programs and they can be used to initiate your own script. Preparing the shell environment ------------------------------- @@ -129,18 +129,18 @@ with a set of instructions that looks like:: export PYTHON_INCLUDE=${PYTHONHOME}/include/python2.6 export PATH=${PYTHONHOME}/bin:${PATH} export LD_LIBRARY_PATH=${PYTHONHOME}/lib:${LD_LIBRARY_PATH} - + #------ hdf5 ------ HDF5HOME= export PATH=${HDF5HOME}/bin:$PATH export LD_LIBRARY_PATH=${HDF5HOME}/lib:${LD_LIBRARY_PATH} export HDF5_DISABLE_VERSION_CHECK=1 - + #------ med ------ MED2HOME= export PATH=${MED2HOME}/bin:${PATH} export LD_LIBRARY_PATH=${MED2HOME}/lib:${LD_LIBRARY_PATH} - + #------ medmem --- MED_ROOT_DIR= export LD_LIBRARY_PATH=${MED_ROOT_DIR}/lib/salome:${LD_LIBRARY_PATH} @@ -153,8 +153,8 @@ Example 01: Explore a med file to get information concerning meshes and fields ------------------------------------------------------------------------------ :objectives: This example illustrates how to get information - concerning meshes and fields from a med file, using the - MEDLoader library. + concerning meshes and fields from a med file, using the + MEDLoader library. The loading of meshes and fields from a med file to a MEDCoupling data structure requires first the knowledge of metadata associated to these @@ -200,7 +200,7 @@ TypeOfField that is an integer value in this list: * :tt:`3 = ON_GAUSS_NE` .. note:: This constant variables are defined by the MEDLoader module - (:tt:`from MEDLoader import ON_NODES`). + (:tt:`from MEDLoader import ON_NODES`). As a consequence, before loading the physical values of a field, we have to determine the types of spatial discretization that come with @@ -239,7 +239,7 @@ Example 02: Load a mesh and a field from a med file --------------------------------------------------- :objectives: This illustrates how to load the physical data of a - specified mesh and a specified field. + specified mesh and a specified field. The metadata read from a med file are required to identify the list of meshes and fields in the med file. We assume in this example that the @@ -277,7 +277,7 @@ Example 03: Manage the MEDCoupling data load from a med file ------------------------------------------------------------ :objectives: Some suggestions for the MEDCoupling objects management, - in a programming context. + in a programming context. In a real programming case, it could be relevant to explore first the med file to load all metadata concerning the whole set of meshes and @@ -337,9 +337,9 @@ Example 04: Simple arithmetic operations with fields ---------------------------------------------------- :objectives: This example illustrates how to load field iterations - from a med file containing a field timeseries and shows - how to use these iterations in simple arithmetic - operations. + from a med file containing a field timeseries and shows + how to use these iterations in simple arithmetic + operations. We consider a med file :tt:`timeseries.med`, containing one single mesh named :tt:`Grid_80x80` that supports a field with values defined @@ -392,7 +392,7 @@ Exemple 07: Manipulate structured mesh -------------------------------------- :objectives: Illustrates the basic usage of the advanced interface of - MEDLoader. + MEDLoader. The MEDLoader frontal interface let you load unstructured meshes: @@ -437,8 +437,8 @@ Exemple 08: Make a projection of a field ---------------------------------------- :objectives: Make the projection of a field from a source mesh to a - target meshe. The source mesh and the target mesh are - two different mesh of the same geometry. + target meshe. The source mesh and the target mesh are + two different mesh of the same geometry. The input data of this use case are: @@ -448,9 +448,9 @@ The input data of this use case are: the figure below) .. note:: The two meshes are displayed side by side on the figure for - convenience reason, but in the real use case they stand at - the same location in 3D space (they describe the same - geometry). + convenience reason, but in the real use case they stand at + the same location in 3D space (they describe the same + geometry). .. image:: images/medop_projection_inputs.png :align: center diff --git a/doc/dev/sphinx/medop-userguide-gui.rst b/doc/dev/sphinx/medcalc-userguide-gui.rst similarity index 94% rename from doc/dev/sphinx/medop-userguide-gui.rst rename to doc/dev/sphinx/medcalc-userguide-gui.rst index 3494402c5..7a5de95c8 100644 --- a/doc/dev/sphinx/medop-userguide-gui.rst +++ b/doc/dev/sphinx/medcalc-userguide-gui.rst @@ -2,7 +2,7 @@ :keywords: mesh, field, manipulation, user guide :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MED module: User guide for graphical interface @@ -13,7 +13,7 @@ shows how to use this module on the basis of a few reference examples, built from use cases identified during requirement analysis stage. .. warning:: This document is self-contained, but it is strongly advised to - read :doc:`the specification document` (in + read :doc:`the specification document` (in french), at least to clarify concepts and terminology. .. contents:: Contents @@ -571,22 +571,23 @@ Using the textual interface (TUI) All operations driven through GUI can be done (more or less easily) using TUI. The field manipulation module can even be used exclusively in textual mode. -For this run the command:: +.. + For this run the command:: $ /medop.sh - -This command opens a command console ``medop>``. A med file can be loaded and -manipulated, for example to create fields from file data. +.. + This command opens a command console ``medop>``. A med file can be loaded and + manipulated, for example to create fields from file data. Whatever textual or graphical mode is used, a typical workflow in console looks like the following instructions:: - >>> load("/path/to/mydata.med") + >>> medcalc.LoadDataSource("/path/to/mydata.med") >>> la id=0 name = testfield1 id=1 name = testfield2 - >>> f1=get(0) - >>> f2=get(1) + >>> f1=accessField(0) + >>> f2=accessField(1) >>> ls f1 (id=0, name=testfield1) f2 (id=1, name=testfield2) @@ -600,50 +601,53 @@ looks like the following instructions:: f1 (id=0, name=testfield1) f2 (id=1, name=testfield2) r (id=2, name=toto) - >>> put(r) - >>> save("result.med") + >>> putInWorkspace(r) + >>> saveWorkspace("result.med") The main commands are: -* ``load``: load a med file in data base (useful in pure textual mode):: +* ``LoadDataSource``: load a med file in data base (useful in pure textual mode):: + + >>> LoadDataSource("/path/to/datafile.med") - >>> load("/path/to/datafile.med") +* ``LoadImageAsDataSource``: load an image as a med file * ``la``: show the list of all fields loaded in data base ("list all") -* ``get``: set a field in workspace from its identifier (useful in pure +* ``accessField``: set a field in workspace from its identifier (useful in pure textual mode ; this operation can be done in GUI selecting a field from data space).:: - >>> f=get(fieldId) + >>> f=accessField(fieldId) * ``ls``: show the list of fields available in workspace ("list") -* ``put``: put a reference to a field in *management space*:: +* ``putInWorkspace``: put a reference to a field in *management space*:: - >>> put(f) + >>> putInWorkspace(f) -* ``save``: save to a med a file all fields referenced in management space:: +* ``saveWorkspace``: save to a med a file all fields referenced in management space:: - >>> save("/path/to/resultfile.med") + >>> saveWorkspace("/path/to/resultfile.med") .. note:: - * the ``load`` command only loads metadata describing meshes and fields + * the ``LoadDataSource`` command only loads metadata describing meshes and fields (names, discretization types, list of time steps). Meshes and physical quantities on fields are loaded later (and automatically) as soon as an operation needs them. In all cases med data (mete-information and values) are physically stored in *data base* environment. - * the ``get`` command defines a *field handler* in workspace, i.e. + * the ``accessField`` command defines a *field handler* in workspace, i.e. a variable that links to the physical field hosted in data base. Physical data never transit between environments but remain centralized in data base. The following TUI commands need to work in graphical environment: -* ``visu``: display a field map for quick visual control (no parametrization - is possible) - - >>> view(f) - +* ``medcalc.MakeDeflectionShape`` +* ``medcalc.MakeIsoSurface`` +* ``medcalc.MakePointSprite`` +* ``medcalc.MakeScalarMap`` +* ``medcalc.MakeSlices`` +* ``medcalc.MakeVectorField`` .. LocalWords: softwares diff --git a/doc/dev/sphinx/medop-prototype-develguide.rst b/doc/dev/sphinx/medop-prototype-develguide.rst index de2387b74..0bc2eae90 100644 --- a/doc/dev/sphinx/medop-prototype-develguide.rst +++ b/doc/dev/sphinx/medop-prototype-develguide.rst @@ -210,14 +210,14 @@ l'addition de deux champs: import salome salome.salome_init() import SALOME_MED - + medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED") medObj = medComp.readStructFile("myfile.med",salome.myStudyName) medOp = medObj.createMedOperator() - + f1 = medObj.getField("testfield1",-1,-1) f2 = medObj.getField("testfield2",-1,-1) - + somme = medOp.add(f1,f2) Il est à noter qu'une instance de ``SALOME_MED::MEDOP`` est associé à @@ -269,7 +269,7 @@ et le numéro d'iteration: salome.salome_init() import SALOME_MED - medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED") + medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED") medObj = medComp.readStructFile("myfile.med",salome.myStudyName) from xmed import fieldproxy @@ -312,9 +312,9 @@ graphique en images: .. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png .. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png -+---------------+---------------+ ++---------------+---------------+ | |IMG_SELECT| | |IMG_ALIAS| | -+---------------+---------------+ ++---------------+---------------+ L'image de gauche montre la sélection du pas de temps, l'image de droite la boîte de dialogue qui permet la saisie de l'alias avec @@ -353,7 +353,7 @@ un objet CORBA): // We suppose here that we have a CORBA object reference (object of // type *_ptr or *_var), for example a SALOME_MED::MED object. - SALOME_MED::MED_ptr medObj = ... // anything to get this object + SALOME_MED::MED_ptr medObj = ... // anything to get this object // Get the IOR of this object QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj); @@ -363,7 +363,7 @@ un objet CORBA): QStringList commands; commands+="import salome"; commands+=QString("med=salome.orb.string_to_object(\"%1\")").arg(medIOR); - + QStringListIterator it(commands); while (it.hasNext()) { pyConsole->exec(it.next()); @@ -411,9 +411,9 @@ commandes suivantes: from xmed.fieldproxy import getFieldFromMed from xmed.medproxy import getMedProxy - + med = getMedProxy("IOR:010000001700000049444c3a53414c4f4d455f4d45442f4d45443a312e300000010000000000000064000000010102000e0000003133302e39382e37372e313733009e0a0e000000feadc4ca4c00003169000000001100000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100") - + f1=getFieldFromMed(med,"testfield1",-1,-1) Ce jeu d'instructions reconstitue un pointeur vers le servant CORBA @@ -543,9 +543,9 @@ module du champ dans l'exemple implémenté par défaut): .. |IMG_VISU| image:: images/medop-gui-visufield_scale.png .. |IMG_RESULT| image:: images/medop-gui-result_scale.png -+---------------+---------------+ ++---------------+---------------+ | |IMG_VISU| | |IMG_RESULT| | -+---------------+---------------+ ++---------------+---------------+ Cette fonction répond au besoin de contrôle interactif des résultats produits par les opérations de manipulation de champs. @@ -556,7 +556,7 @@ donnée du servant ``SALOME_MED::FIELD`` qui lui est associé (représenté par la variable ``field_ptr`` dans l'exemple ci-dessous): .. code-block:: python - + import salome import VISU @@ -710,11 +710,11 @@ automatiser proprement): et fournit des fonctions de test unitaire (à exécuter ou pour s'en inspirer). Après avoir lancé SALOME via une application virtuelle, on peut taper:: - + $ /runSession [NS=venus:2810] $ python -i test_medoperation.py - >>> - + >>> + - Ceci permet de tester en particulier l'interface ``MedOp`` et son utilisation dans le module python ``fieldproxy.py``. diff --git a/doc/dev/sphinx/medop-prototype-medmem.rst b/doc/dev/sphinx/medop-prototype-medmem.rst index 2302f7b70..9c29fee19 100644 --- a/doc/dev/sphinx/medop-prototype-medmem.rst +++ b/doc/dev/sphinx/medop-prototype-medmem.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, MED, MEDMEM :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Note de travail concernant l'utilisation de MEDMEM @@ -115,7 +115,7 @@ d'entrée/sortie branché sur le fichier (``testfilename`` dans l'exemple): .. code-block:: cpp - + MED *myMed = new MED; MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed); driverIn->open(); @@ -140,7 +140,7 @@ Puis le champ qui lui est associé doit être physiquement chargé pour permettre la mise à jour du support: .. code-block:: cpp - + MESH * mesh = myMed->getMesh(field); mesh->read(); myMed->updateSupport(); @@ -148,7 +148,7 @@ permettre la mise à jour du support: Pour enfin charger les valeurs des composantes du champ: .. code-block:: cpp - + field->read(); La numérotation des éléments de maillage @@ -204,7 +204,7 @@ Pour exemple, le fragment de code ci-dessous, extrait du fichier ``MedDataManager`` dans l'interface: .. code-block:: cpp - + #include "MEDMEM_MedDataManager.hxx" class MedDataManager @@ -212,24 +212,24 @@ Pour exemple, le fragment de code ci-dessous, extrait du fichier public: ~MedDataManager(); void printFieldDouble(FIELD * field); - + %extend { MedDataManager(char * fileName) { - return new MedDataManager(string(fileName)); + return new MedDataManager(string(fileName)); } MedDataManager(MED * med) { return new MedDataManager(med); } - + %newobject getFieldDouble(const char * fieldName, const int dt, const int it); FIELD * getFieldDouble(const char * fieldName, const int dt, const int it) { - return (FIELD *) self->getFieldDouble(string(fieldName), dt, it); + return (FIELD *) self->getFieldDouble(string(fieldName), dt, it); } } - + }; @@ -380,17 +380,17 @@ utilise l'interface swig fournie par MedCorba_Swig). Après l'import d'amorce systématique: .. code-block:: python - + import salome salome.salome_init() - + import SALOME_MED from libSALOME_Swig import * On peut charger le composant SALOME MED: .. code-block:: python - + medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED") grâce auquel les services de chargement de la structure MED peuvent @@ -398,14 +398,14 @@ grâce auquel les services de chargement de la structure MED peuvent structure MED dans l'étude salome passée en argument: .. code-block:: python - + filePathName = "myfile.med" medComp.readStructFileWithFieldType(filePathName,salome.myStudyName) Ce deuxième exemple charge la structure MED mais ne place pas le résultat dans l'étude: .. code-block:: python - + filePathName = "myfile.med" medObj = medComp.readStructFile(filePathName,salome.myStudyName) @@ -418,13 +418,13 @@ verra plus bas) à MEDMEM: fieldIdx = 1 # WRN maybe there is no field of idx=1 iterationIdx = 0 fieldName = medObj.getFieldNames()[fieldIdx] - dtitfield = medObj.getFieldIteration(fieldName,iterationIdx) + dtitfield = medObj.getFieldIteration(fieldName,iterationIdx) it = dtitfield[0] dt = dtitfield[1] fieldObj = medObj.getField(fieldName,it,dt) nbOfFields = medObj.getNumberOfFields() fieldNames = medObj.getFieldNames() - + mesh = fieldObj.getSupport().getMesh() .. note:: @@ -469,22 +469,22 @@ SALOME_MED, ...) sont supposées avoir été faites au préalable (voir les exemples précédents): .. code-block:: python - + # Load the med structure using MED medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED") filePathName = "myfile.med" medComp.readStructFileWithFieldType(filePathName,salome.myStudyName) - + # Get the VISU component import VISU visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU") visuComp.SetCurrentStudy(salome.myStudy) - + # Get the sobject associated to the med object named "Med" aSObject = salome.myStudy.FindObject("Med") isPresent, medSObj = aSObject.FindSubObject(1) - - # Finally, import the med sobject in VISU + + # Finally, import the med sobject in VISU result = visuComp.ImportMed(medSObj) Il est possible de d'aller plus loin et par exemple de déclencher @@ -503,7 +503,7 @@ Notes en vrac Questions: -* Comment obtenir le nom du fichier med à partir d'une structure med? +* Comment obtenir le nom du fichier med à partir d'une structure med? * Peut-on imaginer un moyen de fournir l'objet MEDMEM::MED à partir de la donnée de l'objet CORBA SALOME_MED::MED? diff --git a/doc/dev/sphinx/medop-prototype-overview.rst b/doc/dev/sphinx/medop-prototype-overview.rst index c571c6e6f..5eaa00e08 100644 --- a/doc/dev/sphinx/medop-prototype-overview.rst +++ b/doc/dev/sphinx/medop-prototype-overview.rst @@ -56,11 +56,11 @@ images: .. |IMG_VISU| image:: images/medop-gui-visufield_scale.png .. |IMG_RESULT| image:: images/medop-gui-result_scale.png -+---------------+---------------+ ++---------------+---------------+ | |IMG_SELECT| | |IMG_ALIAS| | -+---------------+---------------+ ++---------------+---------------+ | |IMG_VISU| | |IMG_RESULT| | -+---------------+---------------+ ++---------------+---------------+ La solution technique est construite sur les principes suivants: diff --git a/doc/dev/sphinx/medop-workingnotes-2011.rst b/doc/dev/sphinx/medop-workingnotes-2011.rst index 2c38e64bb..269b63b5a 100644 --- a/doc/dev/sphinx/medop-workingnotes-2011.rst +++ b/doc/dev/sphinx/medop-workingnotes-2011.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, manipulation :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ANNEXE: Note de travail concernant le chantier XMED 2011 @@ -145,7 +145,7 @@ Nouveaux concepts à prendre en compte ------------------------------------- Au démarrage du chantier 2011, on observe que les concepts suivants -sont introduits dans le module MED: +sont introduits dans le module MED: * Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger les fichiers med et obtenir les informations générales sur le @@ -469,5 +469,5 @@ Petites améliorations du DataspaceController: est posé dans le WS. On peut donc proposer en option de lui associer un alias pour manipulation dans la console - - + + diff --git a/doc/dev/sphinx/medop-workingnotes-2012.rst b/doc/dev/sphinx/medop-workingnotes-2012.rst index b6ecb6d37..4a3e10af4 100644 --- a/doc/dev/sphinx/medop-workingnotes-2012.rst +++ b/doc/dev/sphinx/medop-workingnotes-2012.rst @@ -2,7 +2,7 @@ :keywords: maillage, champ, manipulation :author: Guillaume Boulant -.. include:: medop-definitions.rst +.. include:: medcalc-definitions.rst %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ANNEXE: Note de travail concernant le chantier XMED 2012 @@ -80,5 +80,5 @@ peut procéder de la manière suivante: * Eliminer la dépendance à XSALOME * Supprimer la gestion des multiversion SALOME5/6 au niveau de l'engine -.. warning:: TODO: refaire le point sur les tâches initiées en 2011 +.. warning:: TODO: refaire le point sur les tâches initiées en 2011 -- 2.39.2