Concurrence

• [+] [^]Re: Concurrence

  Posté par pipo_molo () le 08/05/2007 à 14:52. (lien). Évalué à -2.

  Je vois déjà un gros avantage pour OpenFOAM: le code n'est sûrement pas écrit dans un mélange approximatif de français et d'anglais.

  • [^]Re: Concurrence

    Posté par imalip (page perso, ) le 08/05/2007 à 15:09. (lien). Évalué à 3.

    Perso j'y ai deja vu un gros inconvenient (a OpenFOAM). Le systeme de build a base de .bashrc ou .cshrc pour la config, qui exporte une quarantaine de variables, modifie massivement le PATH, LD_LIBRARY_PATH ; CC, CXX, LD, CFLAGS etc... qui sont hardcodés avec des trucs du genre "-m32", "-m64" ou "-melf_i386", et quelques autres joyeusetés du meme genre. Ah, est pas d'équivalent de "make distclean", donc galere infame pour nettoyer.
    
    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é...

    --
    "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

    • [^]Re: Concurrence

      Posté par Sharpshooter () le 08/05/2007 à 17:25. (lien). Évalué à 2.

      C'est écrit dans la présentation : 50% Fortran, 43% C et 7% Python. :)
      
      A noter que les captures d'écran semblent faites sous XFCE (probablement Linux ?).

    • [^]Re: Concurrence

      Posté par Christophe Merlet (page perso, ) le 08/05/2007 à 18:28. (lien). Évalué à 5.

      OpenFOAM est une catastrophe.
      
      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 (page perso, ) le 08/05/2007 à 19:16. (lien). Évalué à 4.

        Je suis en train d'essayer de faire des packages debian propres, sans utiliser les bashrc. Si j'arrive a quelque chose de propre, je te contacte en prive pour voir ce qui est transferable a Fedora, comment, et si ca peut etre inclus upstream.
        
        (comme quoi on peut faire du boulot inter-distros, je fais deja beaucoup ca pour Amaya)

        --
        "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

      • [^]Re: Concurrence

        Posté par Thierry Thomas (Jabber id, page perso, ) le 08/05/2007 à 20:16. (lien). Évalué à 4.

        J'ai un port FreeBSD qui permet de faire ça [ http://www.freshports.org/science/openfoam/ ]
        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...

        --
        Th. Thomas.

        • [^]Re: Concurrence

          Posté par imalip (page perso, ) le 10/05/2007 à 15:51. (lien). Évalué à 2.

          Rapidement, apres avoir jete un oeil aux multiples patches...
          
          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. :)

          --
          "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

          • [^]Re: Concurrence

            Posté par Christophe Merlet (page perso, ) le 10/05/2007 à 15:55. (lien). Évalué à 2.

            C'est ambitieux.
            
            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 (Jabber id, page perso, ) le 10/05/2007 à 16:44. (lien). Évalué à 2.

              Les premiers patches à appliquer sont ceux qui évitent d'installer les versions liées, pour utiliser celles du système à la place.
              
              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 !

              --
              Th. Thomas.

              • [^]Re: Concurrence

                Posté par imalip (page perso, ) le 11/05/2007 à 14:03. (lien). Évalué à 3.

                Je confirme, il y a un bordel sans nom la-dedans...
                
                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 :)

                --
                "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

          • [^]Re: Concurrence

            Posté par Thierry Thomas (Jabber id, page perso, ) le 10/05/2007 à 16:36. (lien). Évalué à 2.

            Ça me fait penser... À chaque version, je soumets tout de même mes patches, avec une petite note explicative ; si ça peut aider, la dernière est là : [ http://openfoam.cfd-online.com/cgi-bin/forum/show.cgi?1/4329 ].
            
            Bon courage !

            --
            Th. Thomas.

    • [^]Re: Concurrence

      Posté par Julien () le 08/05/2007 à 19:38. (lien). Évalué à 10.

      Il faut savoir ce qu'on veut. Quand une entreprise refuse de publier un code sous prétexte qu'il n'est pas assez propre, combien ici trouvent qu'il s'agit d'un argument bidon ?
      
      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 () le 08/05/2007 à 20:05. (lien). Évalué à 3.

        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.

        
        
        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.

        --
        Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.

      • [^]Re: Concurrence

        Posté par imalip (page perso, ) le 08/05/2007 à 20:10. (lien). Évalué à 10.

        Premiere chose, c'est le systeme de build d'OpenFOAM que je critique. Celui fourni par EDF, je n'ai pas encore regarde precisement, mais ca m'a l'air plus propre (difficile de faire pire, remarque).
        
        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.
        
        

        C'est maintenant à la communauté de polir le système d'install

        
        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.

        --
        "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

        • [^]Re: Concurrence

          Posté par Thierry Thomas (Jabber id, page perso, ) le 08/05/2007 à 21:00. (lien). Évalué à 6.

          J'en ai aussi fait un port FreeBSD qui est disponible à [ http://people.freebsd.org/~thierry/ports/Code_Saturne.tgz ] (c'est un tarball à extraire sous /usr/ports/ et qui va donner science/bft, science/ecs, science/fvm, science/ncs et science/ics ; aucun n'est encore committé, d'une part parceque l'arbre des ports est actuellement gelé pour cause de refonte liée à x.org, et d'autre part parceque je n'ai pas encore testé suffisamment...).
          
          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 !

          --
          Th. Thomas.

  • [^]Re: Concurrence

    Posté par Yvan Fournier (page perso, ) le 08/05/2007 à 20:52. (lien). Évalué à 10.

    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: Concurrence

      Posté par Sytoka Modon (page perso, ) le 09/05/2007 à 19:13. (lien). Évalué à 3.

      Quel est l'intérêt d'augmenter la part du C sachant que le Fortran 95 est un langage de plus haut niveau, plus facilement parallélisable /a priori/ (il a été fait pour cela) et surtout que la notion de pointeur est limité au maximum afin de diminuer le risque de bogue.
      
      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 (page perso, ) le 09/05/2007 à 20:55. (lien). Évalué à 10.

        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...

        • [^]Re: Concurrence

          Posté par Sytoka Modon (page perso, ) le 09/05/2007 à 21:11. (lien). Évalué à 2.

          Tout simplement merci.
          
          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 (page perso, ) le 10/05/2007 à 08:38. (lien). Évalué à 2.

            Mon expérience: beaucoup de gens (du moins en physique) ont apris à programmer dans les années 70-80, à la belle époque du Fortran pour l'informatique scientifique. Ils n'ont en général aucune envie de passer à un autre language, et sont donc très satisfaits du Fortran. Ils ont à leur tour formés les plus jeunes au même Fortran (dans mon DEA, le prof d'informatique àtait un ancien du Fortran). Et tous répètent que bien sur, le Fortran est le language le plus adapté à l'informatique scientifique!
            
            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 geoffroy vallee () le 10/05/2007 à 03:28. (lien). Évalué à 1.

          Tres bon justificatif. :-)
          
          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 (page perso, ) le 08/05/2007 à 21:12. (lien). Évalué à 6.

  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.

Adresse Web définitive

• [^]Re: Adresse Web définitive

  Posté par Sytoka Modon (page perso, ) le 09/05/2007 à 19:08. (lien). Évalué à 3.

  J'avoue que j'ai tenté un code-saturne.org comme pour Code_Aster mais le whois ne m'a rien répondu.
  
  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 (page perso, ) le 09/05/2007 à 22:06. (lien). Évalué à 4.

    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).

(clusters de PCs, Cray XT-3, IBM Blue Gene...)

• [^]Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)

  Posté par Sytoka Modon (page perso, ) le 09/05/2007 à 19:02. (lien). Évalué à 3.

  Sauf que celui de BULL est unique dans le top 500. J'ai donc choisis dans la longue des machines de ne retenir que trois noms : un cluster car c'est la seule machine accessible aux petits budgets, la machine IBM car elle est très connu et IBM domine le marché des grosses machines, enfin la machine CRAY pour des raisons historiques. Cela fait toujours bien sur une plaquette de dire que son code tourne sur CRAY.

  • [^]Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)

    Posté par Yvan Fournier (page perso, ) le 09/05/2007 à 22:42. (lien). Évalué à 4.

    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).

  • [^]Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)

    Posté par geoffroy vallee () le 10/05/2007 à 03:43. (lien). Évalué à 2.

    Cray n'est pas uniquement a citer pour des raisons historiques, l'une des premieres machines a atteindre le petaflop (performance crete) sera une machine Cray:
    http://www.hpcwire.com/hpc/701937.html

    • [^]Re: (clusters de PCs, Cray XT-3, IBM Blue Gene...)

      Posté par Sytoka Modon (page perso, ) le 10/05/2007 à 06:32. (lien). Évalué à 2.

      Sauf que les dernières CRAY me font bien moins rêver. Les descendantes des CRAY sont les machines NEC mais elles sont hors de portées de la grande majorité d'entres nous.
      
      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 baud123 (Jabber id, page perso, ) le 10/05/2007 à 06:33. (lien). Évalué à 3.

      ce qui en deviendra historique :-)

CAO

• [^]Re: CAO

  Posté par Yvan Fournier (page perso, ) le 11/05/2007 à 16:50. (lien). Évalué à 2.

  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.
  
  Pour la DAO, je ne suis d'aucune utilité.

  • [^]Re: CAO

    Posté par baud123 (Jabber id, page perso, ) le 11/05/2007 à 22:44. (lien). Évalué à 2.

    il y a brl-cad qui est pas mal pour la 3D, http://brlcad.org/ (prendre la version 7.10 sur sourceforge http://sourceforge.net/projects/brlcad/ car la version CVS réclamait tcl8.5a5 alors que je n'ai que la 8.4...).
    
    il y a blender qui a une communauté de graphistes importante aussi (et pleins de tutoriels pour s'initier à l'interface graphique)