- J'ai modifié l'exportation pour supprimer les Key() en
trop. En effet, malgré mon expérience d'Oofelie, j'avais pas
tout a fait pigé ce qui se passe lorsqu'on construit une Key
a partir d'une Lock. En résumé, il faut des Locks
partout sauf dans les trucs venant d'Oofelie (principalement le FixationSet
et le Material::depend). Il faut également utiliser une
Lock et non une Key dans Metafor::setInitialVelocity.
- Modification de l'interface des courbes (on passe l'intervalle matlab autrement)
- Nettoyage de l'interface python: j'ai ajouté des
#ifndef SWIG un peu partout dans les .h pour éviter
l'exportation de toutes les fonctions publiques vers python. En effet, l'interface
utilisateur (ligne de commande) doit être limitée à quelques
commandes (celles décrites dans la doc). C'est d'autant plus vrai qu'on
n'utilise plus d'interpréteur pour la boucle d'intégration temporelle.
Je vous encourage à jetter un oeil à
vos classes et à séparer (dans la partie publique) ce qui est
exporté et ce qui ne l'est pas. Grâce à
ça, l'interface est plus claire mais aussi (beaucoup) plus légère.
- Ajout d'une classe MetaStrStream qui permet d'éviter les
#ifdef GCC un peu partout dans le code lorsqu'on utilise les stringstreams.
- Déplacement de IoObject::IoOptions dans le namespace de
base pour être accessible par Swig. Attention:
updatez oo_nda !!
- Début de gestion correcte des threads VizWin via des messages.
- Extension des "courbes" pour Hicham: Le but ici
est de permettre l'affichage de courbes en fonction du temps (jusqu'ici, on
était limité à des valeurs scalaires en fonction du temps).
- Ajout d'une classe OnFileDataMatrix : cette classe dérive
de OnFileDataVector et permet de définir une matrice
dont le nombre de colonnes est constant sur disque et son exportation
vers matlab.
- Ajout de la classe VectorToScalarOperator et dérivées
(SumOperator, MeanOperator,...) : ce sont des singletons
qui permettent de définir une opération sur une liste de
vecteur (somme, moyenne, min, max, ...). Les fonctions ValuesManager::define()
prend un opérateur en argument. Par défaut, il est nul (None
sous python) pour des Internalfields et mis à SumOperator pour
les valeurs de DB.
- Ajout des fonctions ValueManager::setName() et ValueManager::setMatlabExportInterval()
qui permettent de changer le noms des courbes et de fixer l'intervale
d'exportation matlab (cet intervale est mis par défaut à
1).
Un chti exemple:
Je veux avoir accès sous matlab à la contrainte j2 et la force
le long de la base du magnifique cas-test "cont2":
dans cont2.py, je définis:
curves.defineTime(1); # time
curves.setName(1,'time');
curves.define_m(2, CURVE_PO, 1, GF|I2|TY,None); # None car mis à "SumOperator.getInstance()
par défaut!
curves.setName(2,'forceOnBaseLine_Y');
curves.define(3, CURVE_PO, 1, SMOOTH_J2);
curves.setName(3,'j2OnBaseLine');
fm_j2OnBaseLine.m est créé. Le problème est que les noeuds
ne sont pas ordonnés. On va les ordonner rapidos. Pour ça, on
va extraire du fac 0 (la config initiale), les coords X des noeuds de la ligne.
le script python est le suivant:
from toolbox.utilities import *
import cont2
loadFac('cont2',0)
curves = cont2.metafor.getValuesManager()
curves.define(99, CURVE_PO, 1, TX|AB, None);
curves.setName(99, 'x')
curves.fillNow(99)
curves.toMatlab(99)
après l'exécution de ce script (via import script.py),
je me retrouve avec un fichier fm_x.m.
Sous Matlab maintenant:
fm_x
fm_j2OnBaseLine
[xs,i] = sort(j2OnBaseLine(1,:));
mesh(j2OnBaseLine(:,i))
Fichiers ajoutés:
- oo_kernel/OnFileDataMatrix.*
- oo_extractors/VectorToScalarOperator.*
- oo_global/MetaStrStream.*
- apps/cleanAll.sh
- oo_viz/vtk/ThreadMessage.*
