Code_Saturne est d'ailleurs utilisé dans le cadre de thèses effectuées au CSTB, qui semblent utiliser et combiner de nombreux logiciels libres (d'après des présentations assez intéressantes au dernier club utilisateur fin 2009). La prochaine version de SYRTHES (code de thermique EDF aussi publié en GPL) intègrera des aspects bâti.
Ce ne sont pas les codes qui manquent, mais ces outils sont dédiés à des études "fines", et semblent certainement trop lourds d'utilisation pour des bureaux d'études ; ils ne pourront être utilisés facilement que lorsque l'on saura générer simplement des maillages de qualité "correcte" de manière très automatique. Par contre, je ne serais pas surpris que l'utilisation de codes 3D "fins" pour les calculs en bâtiment devienne courante d'ici 10 ans (voire moins), et la communauté libre a probablement une carte à jouer à ce niveau, surtout si elle parvient à "tirer en premier". Un maillon manquant serait la jonction entre outils d'architecture et codes de calcul (en gros l'encapsulation de codes existants).
Pour l'aspect CAO 3D, la librairie OpenCascade est libre depuis plusieurs années (http://www.opencascade.org). La société OpenCascade étaait à l'originne une filiale de Matra Datavision (et je crois que la librairie Open Cascade est issue de la librairie Euclid, un concurrent de CATIA il y a quelques années). Je ne sais pas où cette librairie ce situe par rapport à CATIA, ParaSolid, ..., mais elle semble puissante, et capable de CAO paramétrique.
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.
EDF dispose dune participation de près de 25% du CCRT (Centre de Calcul Recherche et Technologies), géré par le CEA DAM à Bruyère-le-Chatel, où une machine Novascale Bull de 43 téraflops est en cours d'installation (c'est une sorte de petit frère de TERA 10, maintenant numéro 2 en Europe et 7 au monde avec 60 téraflops. Code_Saturne est installé sur une partie déjà opérationnelle de cette nouvelle machine, mais nous n'avons pas encore réalisé de calculs majeurs sur cette machine.
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).
Il n'est pas possible d'avoir un site institutionnel EDF en dehors du domaine edf.fr ou edf.com.
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).
La pratique est différente de la théorie, en grande partie du fait que les outils de développement gèrent souvent beaucoup mieux le C que le Fortran ; le Fortran 95 est une solution élégante sur le papier, mais beaucoup de détails posent problème.
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...
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.
Il n'y a pas de possibilités faciles de transfert entre le deux à ma connaissance, à moins de passer par des formats de maillage et de post-traitement gérés par les deux pour ce qui concerne les données.
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.
C'est effectivement un inconvénient pour Code_Saturne, mais historiquement, le code était intégralement en Français. Pour faciliter les développements dans le cadre de collaborations avec des laboratoires d'autres pays, et pour mieux bénéficier du passage en logiciel libre, les développements plus récents (du moins pour la partie C) sont en Anglais. D'autre part, la part de C augmente progressivement, le code ayant été presque 100% Fortran 77 à ses débuts en 1997. Nous avons donc préféré faire évoluer le style de programmation dans des fonctionnalités récentes ou réécrites (la principale règle de programmation étant d'être cohérent, en évitant toujours de mélanger les styles au sein d'un même fichier).
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: ne pas confondre avants projets thermiques et calculs certifiés
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche La réglementation thermique française : outils d'application. Évalué à 3.
Ce ne sont pas les codes qui manquent, mais ces outils sont dédiés à des études "fines", et semblent certainement trop lourds d'utilisation pour des bureaux d'études ; ils ne pourront être utilisés facilement que lorsque l'on saura générer simplement des maillages de qualité "correcte" de manière très automatique. Par contre, je ne serais pas surpris que l'utilisation de codes 3D "fins" pour les calculs en bâtiment devienne courante d'ici 10 ans (voire moins), et la communauté libre a probablement une carte à jouer à ce niveau, surtout si elle parvient à "tirer en premier". Un maillon manquant serait la jonction entre outils d'architecture et codes de calcul (en gros l'encapsulation de codes existants).
[^] # Re: CAO
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. É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: (clusters de PCs, Cray XT-3, IBM Blue Gene...)
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. É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: Adresse Web définitive
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. É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).
[^] # Re: Concurrence
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. É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...
# Adresse Web définitive
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. É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: Concurrence
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. É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.
[^] # Re: Concurrence
Posté par Yvan Fournier (site web personnel) . En réponse à la dépêche EDF libère son Code_Saturne sous licence GPL. É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.