Ce code de calcul permet de modéliser des écoulements incompressibles ou dilatables, avec ou sans turbulence ou transfert de chaleur. Développé par le département recherche et développement d'EDF depuis 1997, Code_Saturne est basé sur une approche Volumes Finis co-localisés qui accepte des maillages de tout type et contenant tout type d'élément.
Plus concrètement, Code_saturne permet, par exemple, de modéliser le transfert des aérosols dans un local ventilé ou d'étudier le comportement des carburants pour les réacteurs refroidis à l'eau (exemples trouvés par google).
Tournant sur quasiment tous les UNIX dont GNU/Linux. Il sait tirer profit du calcul parallèle avec la bibliothèque MPI sur les machines à mémoire distribuée (clusters de PCs, Cray XT-3, IBM Blue Gene...).
Le code source est la propriété d'EDF mais il a été marqué peu avant Noël 2006 du sceau de la licence GPL. Ce n'est que depuis peu qu'il est accessible sur la toile. Espérons qu'il aura droit à son propre site web comme son grand frère Code_Aster, ou qu'il rejoigne celui-ci.
En effet, lors de couplage fluide-structure, il peut être associé au code de Mécanique des Structures Code_Aster (code aux Éléments Finis), lui aussi développé par EDF et libéré sous licence GPL depuis octobre 2001, notamment à travers la plate-forme Salomé.
Aller plus loin
- Page d'accueil de Code_Saturne (300 clics)
- Page de téléchargement (204 clics)
- Présentation générale de Code_Saturne (pdf, 2 pages) (90 clics)
- Présentation de l'initiative Open Source d'EDF pour Code_Saturne (pdf, 2 pages) (39 clics)
# Concurrence
Posté par imalip . Évalué à 4.
[0] http://www.opencfd.co.uk/openfoam/
[^] # Re: Concurrence
Posté par pipo_molo . Évalué à -2.
[^] # Re: Concurrence
Posté par imalip . Évalué à 3.
Sinon, apres un rapide coup d'oeil, Code_Saturne a l'air d'etre quasi entierement en Fortran, et OpenFOAM en C++, donc les échanges croisés, c'est vraiment pas gagné...
[^] # Re: Concurrence
Posté par Sharpshooter . Évalué à 2.
A noter que les captures d'écran semblent faites sous XFCE (probablement Linux ?).
[^] # Re: Concurrence
Posté par Christophe Merlet (site web personnel) . Évalué à 5.
Si quelqu'un connait la recette pour réussir à l'installer proprement pour qu'il soit dispo à tous les utilisateurs du système simplement, je suis preneur.
Même pour réussir à l'installer dans son Home sur un fedora core 6 / Opteron c'est super galère. Il faut modifier les scripts de partout tellement c'ets mal foutu :(((
[^] # Re: Concurrence
Posté par imalip . Évalué à 4.
(comme quoi on peut faire du boulot inter-distros, je fais deja beaucoup ca pour Amaya)
[^] # Re: Concurrence
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
mais j'ai tout de même gardé le système du .bashrc ou du .cshrc.
Ça nécessite une tonne de patches (Cf. [ http://www.freebsd.org/cgi/cvsweb.cgi/ports/science/openfoam(...) ] ) dont certains sont peut être réutilisables pour d'autres systèmes.
À noter toutesfois que les patches sont ignorés par les auteurs...
[^] # Re: Concurrence
Posté par imalip . Évalué à 2.
Je confirme qu'il y a une grosse partie qui peut etre mise en commun. Mon objectif est d'avoir une "architecture" générique qui puisse etre utilisée indifférement sur Linux ou FreeBSD, et de refaire le systeme de config en utilisant un fichier Makefile a la place des .*shrc, éventuellement autoconf par la suite.
Ca progresse. Doucement, mais ca progresse. :)
[^] # Re: Concurrence
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
hier et aujourd'hui encore j'ai dépanné des utilisateurs qui ont leur environnement perturbé par OpenFOAM qui installe ses propres versions de lam mpi,, mets en dur des -m32 sur du 64 bits, affiche des messages sur la console lorsqu'il charge ses fichiers bashrc...
[^] # Re: Concurrence
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
En plus d'un MPI, il y a aussi cmake, mico, ode, metis / parmetis, paraview, java3d, gnulibiberty, VTK (au moins les en-têtes), freefont-ttf, libexecinfo, readline, opendx, éventuellement cgal et cgns, doxygen et graphviz pour la doc, plus les dépendances de chacun (ex. un JDK...). C'est du lourd !
[^] # Re: Concurrence
Posté par imalip . Évalué à 3.
En plus je viens de voir la licence de metis/parmetis, pas exactement "libre" au sens compatible GPL, OSI ou DFSG... Le tout distribué au milieu d'un projet sous GPL, ouch :(
Sinon, état de ma situation :
-metis/parmetis semblent ne pas exporter certaines fonctions, ca casse a l'édition de liens quand on utilise LA lib qui est liée avec les 2.
-flex++ arrete la génération au milieu des fichiers, du coup j'ai temporairement enlevé certains outils de conversion.
A part ca, j'arrive a compiler le truc en tappant juste "make" (et en attendant 3 heures), et j'arrive dans la joie et la bonne humeur a lancer une partie des outils de test, il y en a meme une bonne partie qui passe. \o/
Le tout avec un nombre de patches relativement modéré.
Je crois que je vais avoir le droit de me packager paraview dans la foulée :)
[^] # Re: Concurrence
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
Bon courage !
[^] # Re: Concurrence
Posté par Julien . Évalué à 10.
Quand une entreprise prend la peine de publier son code sous licence GPL, sans qu'à priori, elle n'ait rien à en retirer, les commentaires se plaignent du système d'install qui n'est pas bien foutu ...
Mais merde, si c'est un code de simulation, il devait être installé sur quelques machines à peine. Tout le monde n'a pas besoins de faire des simulations de méchanique des fluides sur son PC ... Alors oui, je pense que le système d'install est mal foutu, mais ça ne me choque vraiment pas.
C'est maintenant à la communauté de polir le système d'install et tout ce qui n'était pas utile chez EDF, mais qui le devient maintenant. Vous vous rappelez, "chacun implémente ce qui lui sert, et au final le logiciel n'en est que meilleur" ...
[^] # Re: Concurrence
Posté par Beretta_Vexee . Évalué à 3.
En fait on sent que le système d'installer consue pour une réplication bourrine sur les machine d'un cluster a grand coup de script. Et non en effet il n'y a pas grand monde qui doit avoir besoin d'un solver de simulation mécanique des fluides turbulente avec de la thermo dedans de grade industriel.
[^] # Re: Concurrence
Posté par imalip . Évalué à 10.
Ensuite, je ne dis pas que c'est mauvais au point que je refuse d'utiliser le code. Si c'etait le cas, je ne serais pas en train de me battre avec pour essayer de le compiler proprement depuis 3 jours. Et c'est une base de code assez importante (554 Mo), donc chaque tentative prend un moment.
Et tu crois que les lignes de compilation qui defilent dans un autre term depuis 30 minutes c'est quoi ? Tu peux aussi constater dans mon post juste au-dessus du tien que je propose de regrouper mes efforts avec Christophe Merlet qui bosse sur Fedora pour essayer d'ameliorer les choses et les voir integrees upstream.
Mais manifestement le fait que je me batte avec le truc pendant des jours ne serait-ce que pour essayer de le compiler sans foutre le bordel dans mon environnement de travail ne me donne pas le droit de dire que le systeme de build est mal foutu.
[^] # Re: Concurrence
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
Déjà, le code est très portable : je n'ai aucun patch lié directement à des problèmes de compilation. Ensuite, c'est d'une taille beaucoup plus petite qu'OpenFoam, ce qui donne des temps de compilation beaucoup plus courts.
Sinon, c'est aussi un logiciel qui a été pensé pour être posé, compilé et installé sous son $HOME, et j'ai dû ré-écrire une cible install: pour le faire rentrer dans le système des packages de FreeBSD. Mais par rapport au système infernal à base de cmake d'OpenFoam, Code_Saturne est beaucoup plus simple et accessible : c'est juste un shell script qui lance un make.
Quant aux fonctionnalités, Code_Saturne semble tout de même plus limité (j'écris semble car je ne suis pas spécialiste de la mécanique des fluides). L'interface en Tkinter est agréable, mais la construction des cas d'études est laborieuse et doit être en grande partie réalisée hors de l'interface (sauf si quelque chose m'a échappé, je suis encore loin d'en avoir fait le tour), et ça manque d'exemples !
[^] # Re: Concurrence
Posté par Yvan Fournier (site web personnel) . Évalué à 10.
A terme, tout devrait passer en Anglais, mais ce prendra du temps. Idem pour la doc, la doc utilisateur de base est passé en Anglais il y a 1 an environ, mais certains éléments de documentation moins critiques sont toujours en Français.
Et pour répondre au post initial, oui, le code aura droit à son propre site Web comme Code_Aster (je crois d'ici quelques mois). La page d'acceuil actuelle n'est que temporaire, en attendant mieux.
[^] # Re: Concurrence
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Surtout que le Fortran 2000 amène la couche objet qui n'est pas dans le C ainsi qu'une interface normalisé pour faire des appels vers le C (un peu comme en Ada).
[^] # Re: Concurrence
Posté par Yvan Fournier (site web personnel) . Évalué à 10.
Lorsque l'écriture du prototype de Code_Saturne a démarré en 1997, les développeurs de l'époque ont choisi le Fortran 77, qu'ils maîtrisaient déjà. Les compilateurs F90 ou F95 étaient encore récents, et pour avoir essayé en 1997 les compilateurs et runtimes Nag ou HP (sur machines HP-UX à l'époque), c'était très décevant, avec à minima des bugs critiques dans les libariaires d'I/O associées.
Dans ces conditions, difficile de convaincre les "anciens" qui préféraient le Fortran 77 que le Fortran 95 était une bonne option. De plus, il n'y avait à l'époque pas de compilateur Fortran 90 ou 95 libre, ce qui était problématique dans la mesure ou l'on souhaitait garder un code portable et déployable facilement, y compris dans des labos externes, sans imposer l'achat d'un compilateur F90.
Pour les opérations associées au pré et post-traitement de maillages (concaténation, recollements de maillages non conformes, ...) il était indispensable de disposer au moins de structures et de mémoire dynamique, et le C faisait très bien l'affaire. Le C a donc progressivement fait son entrée dans le code via les aspects entrées/sorties, et le code C utilisé dans Code_Saturne utilise des notions de constructeur et destructeur (appelés explicitement), et de méthodes (mais pas d'héritage, pas vraiment nécessaire dans ce contexte).
A noter que le C a du faire ses preuves en étant au début mis en oeuvre dans des parties "non critiques" du code, les anciens développeurs s'en méfiant. En fait, en utilisant quelques règles simples (allocations mémoires encapsuleés et instrumentées, pour détecter facilement les fuites mémoire, utilsation fréquente, d'Electric Fence puis Valgrind, C89 avec prototypes évidamment, ...), nous n'avons jamais eu de problèmes liés à l'utilisation du C. Les pointeurs ne constituent pas une si grosse difficulté que l'on dit, et les bugs de type "segmentation fault" sont le plus souvent dus à un tableau mal dimensionné, ou des valeurs de début ou fin de l'indice d'itération non initialisées, ce qui n'est pas plus facile à éviter en Fortran qu'en C (sauf pour des boucles très simples, celles pour lesquelles on ne risque pas beaucoup de se tromper), et l'utilisation d'Electric Fence et de temps en temps Valgrind permet de détecter et corriger ces bogues très facilement.
En ce qui concerne le parallélisme, le Fortran 95 n'a aucun avantage réel sur le C, du moins pour un code utilisant des maillages non structurés, impliquant des tableaux d'indirection dans de nombreuses boucles, qui ne sont plus assez triviales pour utiliser les syntaxes de type A = B + C pour un tableau entier.
Même si l'on se contentait de parallélisme à mémore partagée, le forall du Fortran 95 serait limité à certaines boucles, et l'on aurait aussi besoin de threads ou de OpenMP. Or on utilise MPI, et l'API MPI est plus cohérente en C qu'en Fortran, dans la mesure où les fonctions utilisent des buffers de type void associés à un numéro de type de données. Comme n'existe pas de "void" en Fortran 95, l'API Fortran 95 de MPI ne peut gérer tous les prototypes issus des combinaisons possibles.
Pour en rajouter un couche, le déboggeur gdb gère mal le Fortran (ce n'est pas la faute à ce dernier, mais c'est encore un avantage pratique pour le C), et l'API trop "haut niveau" des entrées/sorties Fortran fait qu'il est difficile de gérer les aspects big-endian/little-endian pour avoir des fichiers binaires portables (en C, il faut le faire soit-même, mais c'est possible, alors qu'en Fortran, on est à la merci de la disponibilité d'options de compilateur adéquates, et le format des fichiers binaires est souvent semblable entre compilateurs, mais pas normalisé).
Finalement, la couche objet permise par le Fortran 2000, c'est bien joli, mais la norme Fortran 2000 n'est jamais sortie (c'est devenu Fortran 2003), et aucun compilateur actuel à ma connaissance (à part peut-être le compilateur Portland Group) ne gère la norme Fortran 2003 dans son ensemble, donc c'est à exclure pour un code qui doit être très facilement porté sur de nombreuses machines différentes.
Le manque de normalisation des appels C/Fortran avant le Fortran 2003 pose aussi un problème pour l'internationalisation via des mécanismes de type gettext (pas de fonctions à arguments variables comme le printf du C en Fortran, les print et write sont des fonctions intrinsèques, non surchargeables). Ce n'est pas critique pour un code scientifique, mais c'est dommage tout de même.
Pour revenir au parallélisme, la norme Fortran 2008 en cours de rédaction devrait intégrer le co-array Fortran (fort intéressant, de la même famille que Unified Parallel C pour le C ou Titanium pour Java), mais dans la mesure où l'on ne peut déjà pas compter sur un compilateur Fortran 2003, je ne serais pas étonné que les langages parallèles "haute productivité" issus des projets DARPA, comme l'X10 d'IBM, le Chape de Cray, ou le Fortress de Sun (ou une probable synthèse de ces langages) arrivent avant ou peu après le Fortran 2008...
[^] # Re: Concurrence
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je ne fait plus de Fortran depuis quelques temps (5ans) mais les chercheurs autour de moi en ont l'air content.
[^] # Re: Concurrence
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
Pour ce qui est des faits, tout d'abord l'immense majorités des physiciens programment en Fortran 77. Les plus avancés se risquent au Fortran 90 (jusqu'à présent, j'étais le seul à faire du C/C++, mais mon nouveau chef fait C/C++/Java). Les techniques de programmations sont en générale anciennes, voir carréments pas propres du tout... Et pour ce qui est des performances, en effet, les outils Fortran sont très à la traine derrière ceux du C (les compilo C sont bien plus optimisés que ceux du Fortran, ce qui signifie que transformer g77 en un front-end Fortran à gcc à été une très bonne nouvelle, de mon humble point de vue).
Mathias
[^] # Re: Concurrence
Posté par gvallee . Évalué à 1.
Une precision mineure tout de meme : ce n'est pas "Chape" de Cray mais "Chapel".
http://chapel.cs.washington.edu/
Au passage, un autre langage interessant : Global Arrays.
http://www.emsl.pnl.gov/docs/global/
[^] # Re: Concurrence
Posté par Yvan Fournier (site web personnel) . Évalué à 6.
Pour le post-traitement, le format EnSight gold (format par défaut pour Code_Saturne) peut être lu par divers outils, dont évidemment EnSight (cher), mais aussi ParaView et Visit pour les outils Libres.
Pour le pré-traitement, je crois que le format Gmsh est utilisable par OpenFoam.
Il serait possible de permettre à Code_Saturne de gérer les formats natifs OpenFoam pour permettre à chaque outil de bénéficier de certains des outils de la chaîne de l'autre, mais ce n'est pas une priorité côté Code_Saturne (nous supportons 3 formats de sortie, dont 2 libres et le troisième docmumenté, et plusieurs formats de pré-traitement). Si quelqu'un voulait s'y lancer, je pourrais lui indiquer ou intervenir dans le code.
# Adresse Web définitive
Posté par Yvan Fournier (site web personnel) . Évalué à 5.
L'adresse du futur site Web est : http://rd.edf.com/code_saturne
Pour l'instant, ce lien est redirigé vers la page citée dans le post initial, mais lorsque le "vrai" site Web sera disponible, l'adresse temporaire disparaîtra, donc mieux vaut utiliser directement la future adresse dans vos liens.
[^] # Re: Adresse Web définitive
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Pourquoi ne pas faire comme pour code_aster ? EDF ne souhaite pas rendre le développement plus communautaire ?
Pourquoi ne pas mettre Code_Saturne dans Code_Aster et ainsi marquer la convergence des deux.
Le numéro un mondial du calcul de structure, ANSYS (s'il est toujours numéro 1) a bien acheté un des gros codes d'élément finis : Fluent. Je pense qu'il a une stratégie d'intégration des deux à long terme.
D'ailleurs, je ne suis pas mécanicien des fluides mais qu'est ce qui distingue Code_Saturne de Fluent ?
[^] # Re: Adresse Web définitive
Posté par Yvan Fournier (site web personnel) . Évalué à 4.
En bref, nous aurions pu avoir un site code-saturne.org avec hébergement non-EDF, mais n'aurions pas pu y utiliser le logo EDF. Le cadre du site institutionnel est plus rigide, mais a aussi un certain nombre d'avantages pour nous.
Code_Aster restera une exception, car il a eu son site il y a plusieurs années, avant que les règles actuelles ne soient en place.
Nous avons étudié la possibilité d'héberger Code_Saturne sur le site Code_Aster, avec l'équipe Aster, mais avons conclu que ce serait dommage pour la visibilité de Code_Saturne, qui se situe sur le même plan que Code_Aster parmi les grands codes EDF, et ne fait pas partie de Code_Aster, même si ces outils peuvent être couplés dans certaines configurations. Chaque code mentionnera l'autre.
Quant à la convergence de Code_Saturne et Code_Aster, elle se fait en partie via des environnements et communs, comme Salome (www.salome-platform.org), ou le format de fichier MED. Les internes des codes sont trop différents pour que l'on puisse simplement "mettre un code dans l'autre".
En mécanique des structures, les maillages utilisés sont généralement beaucoup plus petits que ceux utilisés en mécanique des fluides (souvent quelques centaines à quelques centaines de milliers de mailles, contre quelques millions), mais les modèles associés aux divers éléments peuvent être variés dans un même problème (combinaisions possibles de modèles de poutres 1D et de volumes 3D par exemple), et la souplesse et l'encapsulation sont prioritaires. En mécanique des fluides, on a généralement un même modèle sur un grand nombre d'éléments (cellules), et la simplicité prime sur la souplesse, pour des raisons de performances et de taille mémoire.
Code_Aster a aussi une plus large gamme d'utilisateurs que Code_Saturne, mais sa parallélisation est plus limitée. Bref, les choix techniques de Code_Aster et Code_Saturne sont très différents du à des besoins d'utilisation, et de déploiement différents, et si l'on continue à améliorer l'intéropérabilité de ces outils, l'un ne peut simplement absorber l'autre.
D'après ce que l'on semble observer du côté ANSYS/FLUENT/CFX, suite au rachat de FLUENT par ANSYS, qui avait déjà acheté CFX, certaines parties des chaînes de calcul devraient être fusionnées (plus ou moins l'équivalent de ce qui se fait avec Salomé à EDF), mais les différents codes gardent leur existence propre. A ma connaissance, FLUENT est déjà lui-même issu de la fusion partielle de plusieurs outils, et présente donc une interface unique mais contient plusieurs outils.
Code_Saturne est dédié aux écoulements monophasiques incompressibles ou légèrement compressibles, alors que FLUENT est encore plus généraliste (quitte à utiliser différents modules selon le type d'étude).
Code_Saturne ne peut pas rivaliser avec FLUENT sur l'aspect IHM ou facilité d'utilisation par un débutant, mais la où le fonctionnement de FLUENT est très opaque, Code_Saturne est libre (et même sans lire le code source, sa documentation détaille les algorithmes utilisés, et les messages produits détaillent beaucoup plus le déroulement du calcul).
# (clusters de PCs, Cray XT-3, IBM Blue Gene...)
Posté par CurieuxMj . Évalué à 2.
qui était à ce moment "l'ordinateur" le plus puissant d'Europe, et le 5ième au
monde.
[^] # Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)
Posté par Yvan Fournier (site web personnel) . Évalué à 4.
La machine Blue Gene/L d'EDF comporte 4 armoires, pour 8192 processeurs (et 1 Go/noeud bi-processeur) avec une performance Linpack de 22 téraflops. A titre de comparaison, le numéro 1 mondial est un Blue Gene/L avec 64 armoires, 131 000 processeurs (et 512 Mo/noeud bi-processeur), et une performance Linpack de 280 téraflops (www.top500.org).
[^] # Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)
Posté par gvallee . Évalué à 2.
http://www.hpcwire.com/hpc/701937.html
[^] # Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Sinon, j'aime bien les Altix de SGI car ce sont des machines SMP très performantes et accessible financièrement.
[^] # Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)
Posté par BAud (site web personnel) . Évalué à 3.
# CAO
Posté par Neo_13 . Évalué à 1.
[^] # Re: CAO
Posté par Yvan Fournier (site web personnel) . Évalué à 2.
Plusieurs outils libres sont basés sur cette librairie, dont le module CAO de Salome (http://www.salome-platform.org), qui évolue plutôt bien, même s'il n'est pas capable d'exploiter les aspects "paramétriques". C'est assez simple à prendre en main, et on peut faire un "dump" en Python d'un modèle (ou construire un modèle en Python), ce qui permet un paramétrage "hors IHM".
L'outil de maillage de Salomé progresse bien aussi, et c'est un peu dommage que le site ne soit pas toujours à jour (on on est à la version 3.2.5, bientôt 3.2.6 à EDF et au CEA, mais seule la version 3.2.2 est disponible librement sur le site d'Open Cascade). Si j'ai bien compris, certaines versions intermédiaires le la librairie OpenCascade ne sont pas libres, et seules les versions de Salomé basées sur les versions libres peuvent donc être elle-mêmes libres, d'où le décalage (c'est dommage, car ca n'aide pas à montrer au monde extérieur que cette plate-forme est bien vivante).
D'autres outils (dédiés purement à la CAO) sont aussi basés sur la librairie OpenCascade, mais je ne sais pas bien ce qu'ils valent. Free CAD (http://free-cad.sourceforge.net) a l'air intéressant, mais n'en est qu'au stade alpha.
Pour la DAO, je ne suis d'aucune utilité.
[^] # Re: CAO
Posté par BAud (site web personnel) . Évalué à 2.
il y a blender qui a une communauté de graphistes importante aussi (et pleins de tutoriels pour s'initier à l'interface graphique)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.