Differences

This shows you the differences between two versions of the page.

--- commit:2013:03_01 [2013/03/01 13:48] – boman
+++ commit:2013:03_01 [2016/03/30 15:23] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== Commit 2013-03-01 ======
+===== Remarques importantes =====
+Je commence par ça sinon vraiment personne ne va me lire...
+  * La visu des éléments AEJ de Vinciane plante (Windows et Linux). Les tests 2D tournent mais "clignotent" bizarrement. Les tests 3D plantent lors de l'ouverture de la fenêtre (pareil chez Luc qui utilise les libdelui). J'ai essayé de debuguer rapidement mais sans succès. J'ai envoyé un mail à Vinciane. Peut-être utilise-t-elle un ''vizwin.conf'' spécifique où une option par défaut serait désactivée?
+  * Le test ''abrawal.testsBattery.frequenciesAnalysisBlade18ER'' (Philippe) produit des fréquences qui varient d'un run à l'autre. On obtient par exemple des résultats différents si on lance avec le script ''battery.py'' ou avec la GUI. Voulant vérifier les valeurs obtenues sous linux, je me suis rendu compte que le script matlab utilisé faisait un syntax error sur une nouvelle fonctionnalité (utilisation d'un tilde pour ignorer un argument retourné par une fonction)! C'est un peu bête de ne pas le signaler (ou d'utiliser une telle fonctionnalité qui supprime la compatibilité avec d'anciennes version). Finalement, j'ai mis à jour matlab (2012a).
+  * Beaucoup de tests ne nettoient pas correctement le workspace lors de la batterie. En fin de batterie le ''workspace'' dans ''bin'' devrait être vide. Plus grave, des fichiers se trouvent dans le répertoire ''bin'' hors de tout ''workspace''. Si chaque test ne reste pas dans son ''workspace'', on ne pourra plus lancer la batterie en parallèle en toute sécurité. Essayez donc de corriger ces problèmes.
+===== Portage Ubuntu 12.04 LTS (x64) =====
+Mon TFiste travaille sur un PC [[http://releases.ubuntu.com/precise/|Ubuntu 12.04LTS]]. J'ai donc décidé de compiler le code sur cet OS. A ma grande surprise, je n'ai rien dû recompiler au niveau des libs. J'ai eu, par contre, un petit problème avec le nouveau compilateur intel (C++ v13.1 du "composer XE 2003 update 2" équipé des MKL 11.0) et le gcc 4.6.
+==== Pour MKL 11.0: ====
+  * Certaines fonctions de ''<mkl_service.h>'' ont été renommées et les anciens noms (utilisés par gaston et sa version 10.1) ne sont plus utilisables. J'ai donc dû bidouiller le source pour que ça marche. On utilise maintenant les nouveaux noms et si ceux-ci ne sont pas dispo (sur gaston), on crée des macros.
+  * MKL 11.0 ne possède plus de lib "solver" dédiée. J'imagine que le DSS est maintenant dans la lib principale nommée ''mkl_intel''. J'ai donc modifié ''CMake/FindMKL.cmake'' pour rechercher cette lib séparement des autres. Si elle n'est pas trouvée, c'est qu'on utilise une nouvelle version des MKL et on ne linke plus avec.
+==== Intel C++ 13.1 ====
+J'utilise la toute dernière version du compilateur Intel puisqu'il est [[http://software.intel.com/en-us/non-commercial-software-development|gratuit en utilisation non-commerciale]].
+  * Problème: certaines fonctions ''friend'' dans nos namespaces ne sont pas reconnues lors de la compilation. Par exemple la fonction ''Gen4::operator<<(std::ostream &out, const Vec &v)'' de ''gen4::Vec'' (fichier ''gen4vec.cpp'') génère le message: ''error: namespace "Gen4" has no member "operator<<"''. On a simultanément un message pour ''Gen4::operator<<(std::ostream &out, const Vec3 &v)''. En ajoutant une déclaration supplémentaire dans le ''.h'' pour la première fonction, on se débarrasse... des deux erreurs!!! Ca commence à sentir le moisi. Continuons dans l'étrange: après avoir trouvé ce premier remède, je décide alors de supprimer cette déclaration un peu moche un peu inutile et d'encapsuler les définitions des deux fonctions problématiques dans une définition de namespace (''namespace Gen4 {'' et ''};''), dans le ''.cpp''. Youpi, le fichier compile... mais la compilation plante plus tard dans ''gen4metric.cpp'' sur ''Gen4::operator<<(std::ostream &out, const Metric &v)'' (??) Cette erreur n'apparait pas si la déclaration magique ajoutée précédemment est présente! Bref, je me demande si c'est pas un bug dans le compilateur. J'ai donc ajouté quelques déclarations de fonctions ''friend'' qui plantaient jusqu'à ce que j'arrive à compiler tout le code. C'est pas terrible mais ça marche...
+Avec ces modifs, le code peut être compilé avec le compilateur Intel.
+==== gcc 4.6 ====
+Problème beaucoup plus drôle avec gcc: le code compile sans problème de A à Z mais il plante au runtime lors de l'utilisation des objets ''Partition'' (un peu après le Sloan). En debug, grâce à l'Intel Debugger (''idb''), je me suis rendu compte que la commande ''new Partition()'' créait un objet de type inconnu qui n'a rien a voir avec notre ''Partition''. Je suspecte les nouvelles extensions "parallèles" du C++11, nouveauté du gcc 4.6. Autre possibilité, un objet nommé ''Partition'' dans une lib annexe de VTK hors de tout namespace (c'est moins probable vu que l'interface graphique n'intervient pas à ce niveau dans le code. J'ai donc décidé de renommer l'objet ''Partition'' en ''mtPartition''. A terme, il sera utile de créer un namespace (''mt'' ou ''mtf'' par exemple) pour protéger tous nos objets. Pour l'instant, on s'en sort avec un nouveau nom pour une seule classe.
+Voilà: portage gcc 4.6 effectué!
+Donc, en conclusion, pour ceux qui voudraient utiliser du Linux sur une nouvelle machine (ou dans une vbox), cet OS est pas mal. Quelques ''apt-get install'' et Metafor tourne.
+ --- //[[romain.boman@gmail.com|Romain BOMAN]] 2013/03/01 12:27//