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).
[^] # Re: Adresse Web définitive
Posté par Yvan Fournier . 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).