Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2008:01_17

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:

  1. 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.
  2. 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…
  3. 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).
  4. 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:

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()

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():

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()

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)

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



Romain BOMAN 2008/01/17 10:07

commit/2008/01_17.txt · Last modified: 2016/03/30 15:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki