====== Commit 2008-01-17 ======

===== Modifs =====

==== Nouvelle interface "toolbox.utilities" ====

=== Contexte ===

Dans le but de clarifier le lancement de tests, j'ai modifié la manière dont on manipule les cas-tests en ligne de commande pour, plus tard, intégrer cette nouvelle manière de faire dans la GUI. Cette manière est le fruit d'une longue réflexion avec Luc pour simplifier la procédure et la rendre plus similaire à ce qu'on peut trouver dans d'autres logiciels EF.

Actuellement, on peut facilement enchainer des commandes qui n'ont rien à voir les unes avec les autres. Pour clarifier ces enchainements, l'idée est de procéder en plusieurs étapes qui seront toujours les mêmes quel que soit le test:
  - chargement d'un module (contenant un ''getMetafor''). Ce module devient LE module courant. Toutes les commandes suivantes n'ont plus besoin de spécifier qu'elles agissent sur ce module. Cette étape "importe" le module. Si vous avez conçu votre test avec une interface paramétrée, aucune analyse Metafor n'est construite à ce moment.
  - changement de répertoire de travail. Cette étape se fait maintenant en python pour éviter que le code C++ s'amuse à gérer des répertoires. Conséquence directe: le code C++ écrit ses fichiers résultats, FACs et autres trucs dans le répertoire courant...
  - instanciation du modèle paramétré contenu dans le module précédemment chargé. Cela consiste à appeler ''getMetafor'' avec d'éventuels paramètres. A ce niveau, les paramètres sont sauvés dans le répertoire de travail (Nouveau).
  - utilisation du module pour intégration (''meta''), ''restart'', ''vizu'', etc

=== Cas-tests basiques ===

Prenons par exemple ''cont2'' et imaginons une seconde qu'il soit bien écrit avec une interface paramétrée. Ca donnerait:

Chargement du module:
  load('apps.qs.cont2')
le module est chargé. On change de répertoire
  setDir(r'c:\mon_rep_de_travail')
on instancie le modèle (on crée le modèle avec les paramètres voulus)
  instance({'Radius':3, 'L':1})
on lance le test:
  meta()

Si on veut travailler avec les paramètres par défaut (répertoire de travail et paramètres du modèle), on peut se passer des 2 commandes intermédiaires:

  load('apps.qs.cont2')
  meta()

L'intérêt de cette nouvelle manière de faire est qu'elle gère correctement les paramètres (ils sont sauvés dans le répertoire de travail. Immaginons qu'on veuille voir les résultats:

  load('apps.qs.cont2')
  loadFac()

Cette dernière commande charge les paramètres avec lesquels le modèle a été instancié.

=== Cas test complexe ===

Dans le cas d'un test complexe (avec restart, avec de l'opti, etc), l'idée est de créer une routine ''main()'' qui sera exécutée par un ''execfile()'' sur le fichier du test:

Imaginons qu'on veuille créer une phase de "restart" pour un test. Le premier fichier ne fera que lancer le test:

<code>
from toolbox.utilities import *
workdir = 'workspace/apps.complex.aleCoin3d'

def getMetafor(p={}):
    import apps.ale.qsCoin3d as m
    return m.getMetafor(p)

def main():
    load(__name__)
    setDir(workdir)
    meta()

if __name__ == "__main__":
    main()
</code>

Ce module peut être lancé par la procédure classique (voir ci-dessus - "''load()''"/"''meta()''") ou par un ''execfile()''.
La phase de restart est identique mis à part qu'on charge un FAC et qu'on appelle ''restart()'' au lieu de ''meta()'':

<code>
from toolbox.utilities import *
import apps.complex.aleCoin3d_1 as m

def getMetafor(p={}):
    return m.getMetafor(p)

def main():
    load(__name__)
    setDir(m.workdir)
    loader = fac.FacManager(instance())
    nt = loader.lookForFile(2)
    loader.eraseAllFrom(nt)   
    restart(nt)

if __name__ == "__main__":
    main()
</code>


==== Interface Nastran (nas2py) ====

J'ai nettoyé l'interface pour que ça marche mieux:
  * possibilité de lancer le test utilisant l'interface ailleurs que dans ''oo_meta'' (ça marche, en particulier à partir du workspace du test).
  * meilleure gestion des noms de fichiers (utilisation de ''os.path'')
  * gestion des erreurs par exceptions (et pas un ''sys.exit()'').





==== Interface Step (utilities.stp2py) ====

  * Pour convertir un fichier stp, il faut maintenant appeler ''toolbox.utilities.stp2py''. Cette fonction va chercher stp2e là où il se trouve (dans votre ''PATH'' ou dans ''oo_meta/../stp2e'', l'exécute et vous renvoie le nom complet du module à importer. C'est beaucoup plus flexible qu'avant.
  * La batterie utilise cette nouvelle fonction (c'est pourquoi vous verrez la bannière Metafor quand vous lancerez le script ''battery.py'').
  * Modification de palplanche en conséquence.

Voilà ce que ça donne en pratique dans un test 

  mod = toolbox.utilities.stp2py(file)
  exec('import %s' % mod)

où ''file'' est un path absolu! - voir ci-dessous pour construire un chemin absolu à partir d'un chemin relatif.

==== Interface Copra (compraImport.tests.copraProfiling5) ====

  * seul changement: le paramètre indiquant le nom du fichier COPRA doit être un chemin absolu. En pratique, python peut se débrouiller en refabriquant un chemin absolu à partir d'un chemin relatif et du chemin absolu du module en cours:

  thedir = os.path.dirname(__file__)
  cfile = os.path.join(thedir, '../../tools/copra5/CpeCre/Ep1R6R6')
  parameters['CopraName'] = os.path.normpath(cfile)


===== Projet ======




===== Fichiers ajoutés/supprimés ======

<code>

</code>


 --- //[[r_boman@yahoo.fr|Romain BOMAN]] 2008/01/17 10:07//