J'ai commité les modifs liées à la compilation Mac OS X venant du Mac de Kim. En particulier, un fichier OSX-student.cmake a été créé pour la configuration.

Kim a installé SWIG 3 au lieu de SWIG 2. J'ai été surpris que tout compile normalement. C'est à l'exécution qu'arrivent les problèmes. En fait, SWIG 3 rend explicites tous les arguments des shadow classes (c'est lié à python 3, si j'ai bien compris). L'inconvénient, c'est que les arguments des fonctions sont maintenant traités entièrement en python. Et ca coince avec les arguments par défaut lorsque ceux-ci sont des énums définies dans d'autres modules python.

Par exemple, GAUSSQUADRATURE est défini dans mtShapeFunctions. Si une routine d'intégration dans mtGeo utilise un argument par défaut qui vaut GAUSSQUADRATURE, alors SWIG note f(arg=GAUSSQUADRATURE) au lieu de f(arg=mtShapeFunctions.GAUSSQUADRATURE). C'est un vrai bug que j'ai contourné en n'interfaçant plus les fonctions en question (elles n'étaient pas utilisées en pratique).

Si j'avais le temps, je posterais le bug dans la mailing list de SWIG… à faire plus tard.

Pour info, toutes les machines de batterie utilisent toujours SWIG 2.

J'ai commité les mini-modifs faites pour David Thomas pour son algo FSI.

Dans la foulée, j'ai intégré les modifs récentes de Marco pour le couplage PFEM: maintenant le StageManager n'imprime plus les stages du passé lors d'un restart. Vu que chaque pas de temps est un stage dans le cas du couplage FSI, ça faisait beaucoup trop de sorties à l'écran lorsque le nombre de pas devenait important.

J'ai supprimé presque tous les warnings apparaissant lors de la compilation clang du code sous Ubuntu. Parmi ceux-ci se trouvaient de vrais bugs du type if(a=0) au lieu de if(a==0). Un petit exemple:

J'ai par contre eu un problème en ajoutant un destructeur virtuel des classes Time (il y en a une dans mtGlobal et une dans fwk. J'ai l'impression que SWIG s'emmele les pinceaux et prend une classe pour l'autre.

— boman 2016/09/12 17:46