Blog entries by Nicolas Chauvat [3]

Deuxième hackathon codes libres de mécanique

2014/04/07 by Nicolas Chauvat

Organisation

Le 27 mars 2014, Logilab a accueilli un hackathon consacré aux codes libres de simulation des phénomènes mécaniques. Etaient présents:

  • Patrick Pizette, Sébastien Rémond (Ecole des Mines de Douai / DemGCE)
  • Frédéric Dubois, Rémy Mozul (LMGC Montpellier / LMGC90)
  • Mickaël Abbas, Mathieu Courtois (EDF R&D / Code_Aster)
  • Alexandre Martin (LAMSID / Code_Aster)
  • Luca Dall'Olio, Maximilien Siavelis (Alneos)
  • Florent Cayré, Nicolas Chauvat, Denis Laxalde, Alain Leufroy (Logilab)

DemGCE et LMGC90

Patrick Pizette et Sébastien Rémond des Mines de Douai sont venus parler de leur code de modélisation DemGCE de "sphères molles" (aussi appelé smooth DEM), des potentialités d'intégration de leurs algorithmes dans LMGC90 avec Frédéric Dubois du LMGC et de l'interface Simulagora développée par Logilab. DemGCE est un code DEM en 3D développé en C par le laboratoire des Mines de Douai. Il effectuera bientôt des calculs parallèles en mémoire partagée grâce à OpenMP. Après une présentation générale de LMGC90, de son écosystème et de ses applications, ils ont pu lancer leurs premiers calculs en mode dynamique des contacts en appelant via l'interface Python leurs propres configurations d'empilements granulaires.

Ils ont grandement apprécié l'architecture logicielle de LMGC90, et en particulier son utilisation comme une bibliothèque de calcul via Python, la prise en compte de particules de forme polyhédrique et les aspects visualisations avec Paraview. Il a été discuté de la réutilisation de la partie post/traitement visualisation via un fichier standard ou une bibliothèque dédiée visu DEM.

Frédéric Dubois semblait intéressé par l'élargissement de la communauté et du spectre des cas d'utilisation, ainsi que par certains algorithmes mis au point par les Mines de Douai sur la génération géométrique d'empilements. Il serait envisageable d'ajouter à LMGC90 les lois d'interaction de la "smooth DEM" en 3D, car elles ne sont aujourd'hui implémentées dans LMGC90 que pour les cas 2D. Cela permettrait de tester en mode "utilisateur" le code LMGC90 et de faire une comparaison avec le code des Mines de Douai (efficacité parallélisation, etc.).

Florent Cayré a fait une démonstration du potentiel de Simulagora.

LMGC90 et Code_Aster dans Debian

Denis Laxalde de Logilab a travaillé d'une part avec Rémy Mozul du LMGC sur l'empaquetage Debian de LMGC90 (pour intégrer en amont les modifications nécessaires), et d'autre part avec Mathieu Courtois d'EDF R&D, pour finaliser l'empaquetage de Code_Aster et notamment discuter de la problématique du lien avec la bibliothèque Metis: la version actuellement utilisée dans Code_Aster (Metis 4), n'est pas publiée dans une licence compatible avec la section principale de Debian. Pour cette raison, Code_Aster n'est pas compilé avec le support MED dans Debian actuellement. En revanche la version 5 de Metis a une licence compatible et se trouve déjà dans Debian. Utiliser cette version permettrait d'avoir Code_Aster avec le support Metis dans Debian. Cependant, le passage de la version 4 à la version 5 de Metis ne semble pas trivial.

Voir les tickets:

Replier LibAster dans Code_Aster

Alain Leufroy et Nicolas Chauvat de Logilab ont travaillé à transformer LibAster en une liste de pull request sur la forge bitbucket de Code_Aster. Ils ont présenté leurs modifications à Mathieu Courtois d'EDF R&D ce qui facilitera leur intégration.

Voir les tickets:

Suppression du superviseur dans Code_Aster

En fin de journée, Alain Leufroy, Nicolas Chauvat et Mathieu Courtois ont échangé leurs idées sur la simplification/suppression du superviseur de commandes actuel de Code_Aster. Il est souhaitable que la vérification de la syntaxe (choix des mots-clés) soit dissociée de l'étape d'exécution.

La vérification pourrait s'appuyer sur un outil comme pylint, la description de la syntaxe des commandes de Code_Aster pour pylint pourrait également permettre de produire un catalogue compréhensible par Eficas.

L'avantage d'utiliser pylint serait de vérifier le fichier de commandes avant l'exécution même si celui-ci contient d'autres instructions Python.

Allocation mémoire dans Code_Aster

Mickaël Abbas d'EDF R&D s'est intéressé à la modernisation de l'allocation mémoire dans Code_Aster et a listé les difficultés techniques à surmonter ; l'objectif visé est un accès facilité aux données numériques du Fortran depuis l'interface Python. Une des difficultés est le partage des types dérivés Fortran en Python. Rémy Mozul du LMGC et Denis Laxalde de Logilab ont exploré une solution technique basée sur Cython et ISO-C-Bindings. De son côté Mickaël Abbas a contribué à l'avancement de cette tâche directement dans Code_Aster.

Doxygen pour documentation des sources de Code_Aster

Luca Dall'Olio d'Alneos et Mathieu Courtois ont testé la mise en place de Doxygen pour documenter Code_Aster. Le fichier de configuration pour doxygen a été modifié pour extraire les commentaires à partir de code Fortran (les commentaires doivent se trouver au dessus de la déclaration de la fonction, par exemple). La configuration doxygen a été restituée dans le depôt Bitbucket. Reste à évaluer s'il y aura besoin de plusieurs configurations (pour la partie C, Python et Fortran) ou si une seule suffira. Une configuration particulière permet d'extraire, pour chaque fonction, les points où elle est appelée et les autres fonctions utilisées. Un exemple a été produit pour montrer comment écrire des équations en syntaxe Latex, la génération de la documentation nécessite plus d'une heure (seule la partie graphique peut être parallélisée). La documentation produite devrait être publiée sur le site de Code_Aster.

La suite envisagée est de coupler Doxygen avec Breathe et Sphinx pour compléter la documentation extraite du code source de textes plus détaillés.

La génération de cette documentation devrait être une cible de waf, par exemple waf doc. Un aperçu rapide du rendu de la documentation d'un module serait possible par waf doc file1.F90 [file2.c [...]].

Voir Code Aster #18 configure doxygen to comment the source files

Catalogue d'éléments finis

Maximilien Siavelis d'Alneos et Alexandre Martin du LAMSID, rejoints en fin de journée par Frédéric Dubois du LMGC ainsi que Nicolas Chauvat et Florent Cayré de Logilab, ont travaillé à faciliter la description des catalogues d'éléments finis dans Code_Aster. La définition de ce qui caractérise un élément fini a fait l'objet de débats passionnés. Les points discutés nourriront le travail d'Alexandre Martin sur ce sujet dans Code_Aster. Alexandre Martin a déjà renvoyé aux participants un article qu'il a écrit pour résumer les débats.

Remontée d'erreurs de fortran vers Python

Mathieu Courtois d'EDF R&D a montré à Rémy Mozul du LMGC un mécanisme de remontée d'exception du Fortran vers le Python, qui permettra d'améliorer la gestion des erreurs dans LMGC90, qui a posé problème dans un projet réalisé par Denis Laxalde de Logilab pour la SNCF.

Voir aster_exceptions.c

Conclusion

Tous les participants semblaient contents de ce deuxième hackathon, qui faisait suite à la première édition de mars 2013 . La prochaine édition aura lieu à l'automne 2014 ou au printemps 2015, ne la manquez pas !


Réseau social ouvert et distribué avec CubicWeb

2012/07/18 by Nicolas Chauvat

Qu'est-ce qu'un réseau social ?

  • descriptions de personnes (profil, histoire, etc)
  • liens avec les autres membres (carnet adresses, etc)
  • création de groupes
  • partage de contenu (photos, vidéos, présentations, etc)
  • discussion (blog, commentaires, forums, messages, microblog)
  • mise en relation (boulot, ludo, dodo, etc)
  • recommandation (lien, livre, achat, film, music, etc)
  • présence (fait quoi, avec qui, où, etc)

Et l'interopérabilité ?

  • nombreuses applications / plate-formes
  • en majorité centralisées et fermées
  • ouverture progressive: protocoles et API en cours de dév
  • réseaux ouverts et distribués: appleseed, diaspora, onesocialweb, etc.
  • pourrait-on faire autrement ?

API: openstack

  • découverte / discovery = xrd
  • identité / identity = openid
  • contrôle d'accès / access control = oauth
  • activités / streams = activity streams
  • personnes / people = portable contacts
  • applications = opensocial

Et en utilisant les standards du Web ?

Architecture ouverte et distribuée

  • vocabulaires RDF et protocole HTTP + REST
  • chacun son serveur
  • GET et éventuellement copie locale
  • abonnement si nécessaire (pubsub, xmpp, atom ?)
  • permissions gérées localement

=> social semantic network

Pourquoi CubicWeb ?

  • plate-forme pour web sémantique (semantic web framework)
  • conçu pour avoir composants à assembler
  • chacun peut définir son application sur mesure
  • fait pour publier html et rdf en parallèle
  • fait pour exporter et importer données
  • déjà foaf, skos, sioc, doap, rss, atom, etc.

Exemple

  • (micro)blog + book + link + file
  • pourrait ajouter: musique, photos, etc.
  • mais aussi: journal, recherche appartement, etc.

Et ensuite ?

Il y a bien longtemps...

  • découverte = who et cat /etc/passwd | cut -d: -f1
  • identité = login
  • contrôle accès = chmod, chgrp, su
  • activités = .plan
  • personnes = .addressbook
  • applications = vim ~/public_html/me.html

Note

Ce texte a été présenté en août 2010, lors de la conférence française des utilisateurs de Python (PyCon-Fr 2010)


12 ans de l'April: bilan et objectifs

2009/04/05 by Nicolas Chauvat
http://www.april.org/themes/zen/zen_april/images/logo.png

L'April fête cette année ses douze ans. L'association de promotion et de défense du logiciel libre approche maintenant les 5000 membres, toutes catégories confondues: personnes physiques, entreprises commerciales, collectivités, associations. Elle vient de publier son rapport moral 2008 et sa feuille de route 2014 qui fixe des objectis pour les cinq années à venir. On notera en particulier la lutte contre les quatre dangers que sont les brevets sur les algorithmes, les dispositifs de contrôle d'usage, la vente liée et l'informatique déloyale. Consultez le site de l'April pour en savoir plus sur ses actions et n'hésitez pas à adhérer ou à donner quelques heures de votre temps.


Fusionner dans le bon sens avec mercurial

2008/11/27 by Nicolas Chauvat
http://www.selenic.com/hg-logo/logo-droplets-50.png

Contrairement à ce que l'on pourrait penser a priori, il y a un bon et un mauvais sens pour fusionner deux têtes dans en entrepôt mercurial.

Prenons un exemple et admettons que l'on parte d'une révision 123. Alfred, Barnabé et Coruscant font des changements qui produisent l'arbre suivant:

123 -> 124 -> 125 ---> 126 -> 129 --> 130
                   \-> 127 -> 128 /

Si dans le même temps, Zoé part de la révision 123 et produit l'arbre:

123 -> 131

quand Zoé va vouloir faire son hg push sur l'entrepôt partagé, elle va avoir le message "ça crée des têtes, est-ce que vous êtes sûr de vouloir faire ce push". Zoé va se dire qu'il vaut mieux commencer par un 'pull' et un 'merge', mais c'est là qu'il faut se méfier.

En effet, si Zoé est sur la révision 131 et qu'elle fusionne avec 130, le changeset sera énorme car il contiendra tous les changements qui permettent de passer de 123 à 130. En revanche, si Zoé passe sur la 130 et fusionne avec la 131, elle n'aura que les changements qu'elle vient d'apporter. Dans le premier cas, le 'merge' sera difficile à comprendre, alors qu'il sera bien plus simple dans le second.

Au final, comment faire la fusion dans le "bon" sens ?

1/ hg push -> ah tient, ça crée des têtes, donc je ne le fais pas

2/ hg pull -u ou hg pull suivi de hg merge -> y'a eu un merge

3/ hg status -> beaucoup de fichiers modifiés... oulàlà, c'est bizarre je vais regarder

4/ hgview -> ah oui, sur l'autre tête y'a beaucoup plus de changements, donc je vais plutôt faire le 'merge' dans l'autre sens

5/ hg up -C ab123_autre_tete -> je me retrouve sur l'autre tête

6/ hg merge cd456_ma_tete -> un joli 'merge'

7/ hg status -> seulement quelques fichiers modifés, voilà qui est mieux

8/ hg ci -m merge -> youpi, je valide cette fusion

9/ hg push -> tagada, je partage avec mes voisins

Moralité: faites des hg status et des hgview aussi souvent que nécessaire pour préparer vos commits et parvenir à un historique facile à comprendre.

Remarque: on peut aussi remplacer les étapes 5, 6 et 7 par hg diff -r ab123_autre_tete -r cd456_ma_tete pour afficher le diff de ma_tete par rapport à autre_tete, car l'opération de fusion doit être symétrique et donner le même résultat qu'on la lance depuis l'une ou l'autre tête, même si l'affichage par défaut de hg status et hg diff dépend de la tête qui constitue le premier parent (l'étape 5 ayant justement pour effet de changer ce premier parent).