Modélisation du vortex shedding sous Fluent

[invitea8b39a58]

Bonjour,

Je recherche l'intervalle du nombre de Reynolds où le phénomène du vortex shedding se produit. Je fais cela numériquement avec Fluent afin de le vérifier expérimentalement.

La géométrie est très simple : un rectangle (2 walls, 1 velocity-inlet et 1 pressure-outlet) et un petit cercle à l'intérieur.
Le fluide est de l'eau et il n'y a pas de phénomène thermique.
Je sais que le vortex shedding se produit autour de Re=150.

Mais mon problème se situe au niveau des caractéristiques de l'eau...

Lorsque j'utilise l'eau (water-liq) de la base de données de Fluent, l'écoulement reste parfaitement stationnaire.
Lorsque j'utilise l'air avec la viscosité et la masse volumique de l'eau, cela fonctionne parfaitement !!!!

Quelqu'un aurait-il une explication? un début de réponse? une idée?

Quel fluide dois-je utiliser, sachant que c'est un travail sérieux?

Cordialement
-----

[obi76]

plus ta viscosité est faible, plus ton Reynolds sera grand. Essaye avec de l'air (et puis au risque de me répéter, Fluent si c'est pas obligatoire autant s'en passer...c'est un peu comme Word ou Excel, si c'est obligatoire ben ok, mais il y a mieux et gratuit ailleurs).

EDIT : sinon t'as qu'à augmenter la vitesse...

[invitea8b39a58]

Merci de ta réponse,

Je suis dans une université. Je peux utiliser un canal hydraulique (vitesse faible de l'ordre dde quelques cm/s) et une soufflerie (vitesse élevée de l'ordre de 20 ou 30 m/s).
Mon Reynolds doit être de 150, ça implique une vitesse faible c'est pourquoi j'utilise l'eau.

As-tu une idée du/des caractéristiques de l'air intervenant dans le code Fluent qui annule(nt) mes vortex?

Merci

PS : j'ai pas choisis d'utiliser Fluent

[obi76]

C'est pas compliqué, la viscosité de l'eau à température ambiant c'est à peu près 10^3 kg/ms, celle de l'air 1,7 10^-5. ca fait un facteur 10^8 entre les 2. Pour avoir le même Reynolds, à échelle de calcul identique, il va falloir diminuer ta vitesse par 100 000 000 entre l'eau et l'air pour avoir les mêmes réactions.

Bon courrage

[A voir en vidéo sur Futura]

[invite0c5534f5]

Je profite de ce topic pour faire une demande.
Quelqu'un peut-il me donner le nom d'un logiciel de modélisation en mécanique des fluides mieux que fluent et gratuit?
Car j'adore faire mumuse avec les simulations physique (et pas trop compliqué si possible, car j'ai pas envie de passer une journée pour faire un petit truc juste pour m'amuser )

[obi76]

cf l'autre post : NSC2KE (fais par EM2C). Bon faut pas rêver c'est pas hypersimple, et en plus il te faut un logiciel à coté pour voir les données, mais c'est pas mal (et gratuit)

[invite0c5534f5]

Merci mais j'ai pas trouvé de versions compilés (ni pour NSC2KE ni pour le générateur de amillage EM2C). Et moi le fortran c'est pas mon truc....
Si tu sais où on peut trouver ça ce serait sympa.

[obi76]

Un logiciel scientifique digne de ce nom, c'est en Fortran.

Si tu veux un logiciel de simu de méca flu fait en Basic, je suis désolé mais j'en connais pas (et ça doit pas exister).

Bon courage, mais je pense pas que tu trouvera mieux (OpenFOAM aussi mais c'est en fortran aussi je crois).

pour compiler tout ça sous linux t'as gfortran qui est gratuit et qui marche bien.

Si EN PLUS t'es sous windaube, et que tu veux pas de fortran, bon bah là désolé je peux plus rien pour toi.

[invite0c5534f5]

Un logiciel scientifique digne de ce nom, c'est en Fortran.

Et le C/C++ ?

Si tu veux un logiciel de simu de méca flu fait en Basic, je suis désolé mais j'en connais pas (et ça doit pas exister).

Non merci


En fait j'aurais juste voulu savoir si quelqu'un avait mis les binaires (pour win32) sur le net. Apparemment non
JE vais essayé de me débrouiller avec ça, merci

[obi76]

Le C n'est pas un langage fait POUR faire du scientifique. Comme (presque) tous les langages il peut le faire, mais sous fortran ça ira 10 fois plus vite...

[invitea8b39a58]

C'est pas compliqué, la viscosité de l'eau à température ambiant c'est à peu près 10^3 kg/ms, celle de l'air 1,7 10^-5. ca fait un facteur 10^8 entre les 2. Pour avoir le même Reynolds, à échelle de calcul identique, il va falloir diminuer ta vitesse par 100 000 000 entre l'eau et l'air pour avoir les mêmes réactions.

Bon courrage

J'apprécie tes réponses mais je n'ai pas de problème pour atteindre Re=150. Avec ma géométrie, le matériel à ma disposition et certains impératifs, je dois utiliser l'eau. Je gère parfaitement cette partie.

Je me suis sans doute mal fait comprendre. Mon problème provient de Fluent et de l'interface chaise/clavier.
Lorsque je définis l'eau comme fluide dans Fluent, le phénomène n'apparaît pas.
Par contre, lorsque je choisis l'air avec la viscosité et la masse volumique de l'eau, là ça fonctionne.

Le vortex shedding est régit par les équations de Navier Stokes (je me trompe peut-être) dans lesquelles seules la viscosité et la masse volumique du fluide interviennent comme caractéristiques de ce fluide. Alors pourquoi j'obtiens deux résultats différents?

En espérant que quelqu'un vol à mon secours, bon week-end

[obi76]

Les seuls choses qui vont changer dans NS en fonction du fluide que tu utilises, c'est la visco, la masse volumique et la Diffusion (et les termes de réactions chimique mais fluent gère pas ça).

Si ça marche pas pour moi c'est un problème de Fluent.

L'inconvénient de Fluent est que si ton système diverge ou fais n'importe quoi, lui il a comme instruction de te donner un résultat, même s'il est foireux. C'est bien pour ça qu'on ne l'utilise que très peu. Si tu ne vois pas ça apparaître à même Reynolds c'est un problème du logiciel.

[invitea8b39a58]

C'est bien ce que je craignais.
Quand je pense au prix annuel de la licence et qu'il y a déjà une erreur au niveau du fluide, je suis heureux de savoir que c'est pas mon argent mais ça me déçoit de ne pas pouvoir faire confiance à un tel logiciel.
Il ne me reste plus qu'à passer en mode programmation.
Merci pour tes réponses.

[obi76]

Quand je pense au prix annuel de la licence et qu'il y a déjà une erreur au niveau du fluide, je suis heureux de savoir que c'est pas mon argent mais ça me déçoit de ne pas pouvoir faire confiance à un tel logiciel.

Quand on voit la nationalité de ce logiciel, il faut pas s'étonner.
Sinon la prog c'est une très bonne solution (surtout que sans diffusion etc c'est assez rapide à faire)

[invited7275bd2]

Réponse à Tibule86.

J'arrive sans doute alors que tu as fini ton travail. Mais pour infos, que tu utilises de l'eau ou de l'air le vortex shedding doit apparaître. Le shedding autour de cylndre apparaît vers Re>=50. Primo, c'est vérifié expérimentalement et deuxio ça répond tout simplement à la similitude de Reynolds, qui est indépendante du fluide. Donc, le souci que tu rencontres ne peut provenir que du logiciel. C'est surprenant tout de même qu'il fasse une erreur aussi énorme !

Existe-t-il un code CFD gratuit ? oui. En fait certainement plusieurs, mais il est inutile de tous les connaître. Il existe Code_Saturne développé par EDF R&D que je connais très bien. Tu peut trouver cela en libre téléchargement via google par exemple à l'aide de ces mots clés. Par contre, c'est intégralement en fortran. Donc il te faudra linux.

Aussi, puisque tu fais tes calculs en régime turbulent, ne cherches pas à avoir un seul résultat. Je veux dire que si tu fais du k-epsilon, k-omega, R_ij-epsilon, ... tu auras à chaque fois des résultats différents. Certains pourront néanmoins être proches les uns des autres. Les seuls résultats qui te permettront de trancher sont l'expérience et/ou la simulation numérique directe qu'on appelle plus couramment DNS (mais je ne suis pas certain que cela existe pour des écoulements autour de cylindre).

Pour résumer, la turbulence est un problème qui ne sera pas résolu de sitôt ! Dans certains cas, il est très difficile d'évaluer la pertinence des résultats que tu obtiens lorsque tu utilises des modèles RANS : entre les erreurs numériques et les limites de modélisation, t'es pas sorti...

J'espère que cela aura pu répondre à certaines interrogations. Si tu as des questions, n'hésites pas.

ZoSo1944.

ps : je suis un "turbulencier", donc mes remarques ne viennent pas de n'importe où, mais notamment de mes travaux de thèse ainsi que de la bibliographie. J'ai aussi travaillé sur le vortex shedding autour de cylindre circulaire.

[invitea8b39a58]

Merci ZoSo1944 de ta réponse.

C'est vrai que je suis passé sur le problème il y a un certain temps maintenant.
Depuis je me suis aussi frotté aux "pourquoi des résultats différents?" et "alors lequel est correct?".

La seule réponse à cette dernière question est l'expérience. Mes simulations sont un début de thèse pour un autre étudiant qui manipulera et pourra comparer ses résultats aux miens.

J'ai bien compris comment le phénomène se produit, mais sais-tu pourquoi et comment le phénomène apparaît? En d'autres termes, quel est le déclencheur et à quel terme de NS il correspond?

Je ne t'en voudrai pas si tu n'arrives pas à me répondre, même la NASA n'a pas réussi !!! ... (http://daac.gsfc.nasa.gov/oceancolor...vortices.shtml)

[invited7275bd2]

le vortex shedding est particulièrement compliqué. DIsons qu'en gros personne n'a la réponse à cette question. Seul existent des pistes.

En fait, différents mécanismes (instabilités) et certaines imbrications peuvent être responsables d'un lâcher tourbillonnaire. Je dirai, que pour commencer, il faut cibler ton nombre de Reynolds. Comme tu es à 150, ton écoulement appartient au régime laminaire instationnaire (en anglais ça correspond à laminar vortex shedding). L'allée tourbillonnaire, dite aussi allée de (Von) Kàrmàn, est dûe à une instabilité absolue dans le proche sillage du cylindre mais son facteur déclenchant semble être une instabilité convective dans le siilage lointain. Ces observations sont vérifiées expérimentalement, mais aussi numériquement. Le "paramètre" déclenchant est pour moi la viscosité puisque sans elle, pas de turbulence !
Au besoin, je peux te faire parvenir des noms d'auteurs, voire des articles. Quant à la définition instabilité absolue/convective, si tu es intéressé, je te joins un rapport de thésard que j'ai rapidement regardé. Ça a l'air d'être bien expliqué.

[invitea8b39a58]

En lisant ton message une question m'est venue à l'idée : Comment peut-il y avoir une instabilité dans un écoulement NUMERIQUEMENT laminaire?
Si tu veux bien me faire parvenir les documents je suis bien sûr preneur.
Merci beaucoup.

[obi76]

En lisant ton message une question m'est venue à l'idée : Comment peut-il y avoir une instabilité dans un écoulement NUMERIQUEMENT laminaire?
Si tu veux bien me faire parvenir les documents je suis bien sûr preneur.
Merci beaucoup.

Je me suis aperçu que mes réponses précédentes étaient dépourvues de politesse, je m'en excuse

pour répondre à ta question : dans la mesure ou les équations de NS sont différentielles et non linéaires, une instabilité numérique (donc de l'ordre de l'arrondi) suffira à faire diverger ton système.

Exemple plus flagrant (mais ça revient au même...)

tu pose x = 1/3
tu fais une boucle un petit millier de fois ou tu fais :
x=1-2*x

x est censé garder la même valeur, pourtant il explose... même principe.

Pour éviter ce genre de chose il faut mettre en place des système de vérification pour la conservation de la masse, éviter de dépasser un CFL de 0,5 etc, mais Fluent (hem) ne gère pas ça non plus il me semble...

[invited7275bd2]

Je ne comprends pas pk tu parles de "numériquement" laminaire.
La dénomination du régime semble internationale. Mais les choses qui s'y passe en son sein indiquent, d'après ma bibliographie de thèse, que le sillage est pleinement turbulent dès Re~150. Donc il me paraît incertain de faire un calcul en laminaire pour cette valeur du nombre de Reynolds. Si je devais faire ce calcul j'utiliserais un modèle de turbulence (ou plusieurs modèles en fait que je comparerais avec plusieurs expés dans la mesure du possible). Quant à l'envoi d'articles bibliographiques, l'envoi est ici limité. Dans un premier temps dis-moi si tu es toujours en contact avec le thésard. Si oui je te dresserai une liste et avec les accès de votre labo tu pourras certainement t'en sortir. Pour certains articles "récalcitrants", on verra en temps utiles.

Des instabilités numériques, tu en auras toujours. Certaines fois elles peuvent même influer ta solution. Une thèse de 2008 montre que le raffinement de maillage conduit la solution d'un cas d'école vers une solution stationnaire. Le fait de déraffiner excite numériquement une instabilité physique et conduit à une solution dépendante du temps. Dis-toi qu'en RANS, tu ne pourras sans doute jamais atteindre LA solution, sauf en statistiquement stationnaire. Au mieux, tu t'affranchiras des erreurs numériques de discrétisation mais au prix d'un maillage très fin, donc d'un temps de calcul important.

L'analogie que fait obi76 me semble dangereuse : son opération fait appel à la manière dont l'ordinateur (et plus exactement le langage qu'il va utiliser pour effectuer le calcul : fortran, C, python, ...) va coder les float. Je ne suis pas un génie de l'info mais déjà peut-on affirmer qu'en réalisant ce calcul en fortran 77 par exemple le fait de faire du "simple precision" ou du "double precision" conduira au même résultat sur un temps très long ? Je n'en suis pas convaincu.
Parler de CFL fait référence à la manière dont tu tronques tes schémas numériques et ce indépendamment de la gestion des entiers, des décimaux, ... Après, il y a bien ce problème d'encodage je suis d'accord.
Le fait de parler de CFL=0.5, c'est relatif au schéma de convection utilisé et donc très théorique ! Je peux vous dire que j'ai vu des trucs d'industriels hallucinants pendant ma courte période de recherche : genre CFL=120 ! Même moi, j'en revenais pas. Ce critère de stabilité numérique est manipuler avec précaution tout de même. Ça veut dire quoi 'Fluent ne gère pas...' ? ne crois-tu pas, Obi76, très difficile sinon impossible d'établir des critères de sécurité sur une batterie de cas très différents les uns des autres ? C'est à l'utilisateur de prendre des précautions ! C'est pour ça que la CFD n'est pas et NE DOIT pas être du simple clic-bouton !

[obi76]

Des instabilités numériques, tu en auras toujours. Certaines fois elles peuvent même influer ta solution. Une thèse de 2008 montre que le raffinement de maillage conduit la solution d'un cas d'école vers une solution stationnaire. Le fait de déraffiner excite numériquement une instabilité physique et conduit à une solution dépendante du temps.

C'est vicieux les schémas numériques

Dis-toi qu'en RANS, tu ne pourras sans doute jamais atteindre LA solution, sauf en statistiquement stationnaire. Au mieux, tu t'affranchiras des erreurs numériques de discrétisation mais au prix d'un maillage très fin, donc d'un temps de calcul important.

C'est sans doute pour ça qu'à chaque fois que j'ai vu du RANS tourner, c'est plus pour faire des comparaisons avec des statistiques Eulériennes (obtenues par PIV ou par des traitements diphasiques en Eulérien). Le RANS constitue une approche d'une solution, mais je n'ai jamais vu une solution au moins approximée comme on pourrai en avoir en LES ou DNS...

L'analogie que fait obi76 me semble dangereuse : son opération fait appel à la manière dont l'ordinateur (et plus exactement le langage qu'il va utiliser pour effectuer le calcul : fortran, C, python, ...) va coder les float. Je ne suis pas un génie de l'info mais déjà peut-on affirmer qu'en réalisant ce calcul en fortran 77 par exemple le fait de faire du "simple precision" ou du "double precision" conduira au même résultat sur un temps très long ? Je n'en suis pas convaincu.

Effectivement qu'on soit en SP ou en DP changera la vitesse de divergence. Néanmoins c'était un exemple qui je pense n'est pas si loin de la réalité. A une infime erreur, on lui attribue une opération non linéaire (1-2*x appliquée 1000 fois c'est polynomial), et ça explose. Les instabilités, même en DNS, viennent entre autre de ces erreurs d'arrondis (qui seront par ailleur d'autant plus importants que le CFL est grand...).

Parler de CFL fait référence à la manière dont tu tronques tes schémas numériques et ce indépendamment de la gestion des entiers, des décimaux, ... Après, il y a bien ce problème d'encodage je suis d'accord.
Le fait de parler de CFL=0.5, c'est relatif au schéma de convection utilisé et donc très théorique !

Effectivement c'est relatif, en DNS j'ai l'habitude de tourner en CFL=0,4 pour avoir peu de divergence lors de l'avancement en temps, mais effectivement c'est en dépit du temps calcul...

Je peux vous dire que j'ai vu des trucs d'industriels hallucinants pendant ma courte période de recherche : genre CFL=120 ! Même moi, j'en revenais pas. Ce critère de stabilité numérique est manipuler avec précaution tout de même.

Si tu utilise des équations de NS où les paramètres tendent à ce que ces équations deviennent quasi-linéaires, alors oui tu peux augmenter énormément le CFL, la discrétisation influera peu sur le résultat (et sur l'erreur).

Ça veut dire quoi 'Fluent ne gère pas...' ? ne crois-tu pas, Obi76, très difficile sinon impossible d'établir des critères de sécurité sur une batterie de cas très différents les uns des autres ? C'est à l'utilisateur de prendre des précautions ! C'est pour ça que la CFD n'est pas et NE DOIT pas être du simple clic-bouton !

Je suis tout à fait d'accord, néanmoins (et je pense que c'est bien là l'inconvénient des sources fermées) des batteries de cas, on peu en sortir une quantité astronomique, avec chacune son optimisation et chacune son point d'orgue.
Réussir à faire une simulation rapide sur un cas particulier revient dans la majorité des cas à adapter le code, donc à avoir ses sources...

Ce débat, je le sens intéressant

[invited7275bd2]

C'est sans doute pour ça qu'à chaque fois que j'ai vu du RANS tourner, c'est plus pour faire des comparaisons avec des statistiques Eulériennes (obtenues par PIV ou par des traitements diphasiques en Eulérien). Le RANS constitue une approche d'une solution, mais je n'ai jamais vu une solution au moins approximée comme on pourrai en avoir en LES ou DNS...

Là, je te trouve très dur : la première chose à considérer quand tu fais du RANS ce sont les statistiques, donc des champs moyens. j'ai vu des résultats RANS proches de résultats LES et/ou DNS et au besoin je cite mes sources. Certes, il s'agit de cas statistiquement stationnaire genre canal plan ou conduite cylindrique. Ensuite, il faut distinguer le niveau de fermeture des modèles RANS qui aura un impact considérable sur la qualité de la solution obtenue.

Effectivement c'est relatif, en DNS j'ai l'habitude de tourner en CFL=0,4 pour avoir peu de divergence lors de l'avancement en temps, mais effectivement c'est en dépit du temps calcul...


Je comprends mieux ce que tu disais. Il est évident, avec un peu d'expérience, que le choix de la CFL sera relatif au type de solution que tu voudras avoir, en faisant abstraction de tout problème potentiel dû aux schémas numériques. J'ai déjà fait des calculs avec CFL=20 et ça fonctionne très bien. Mais la solution est indépendante du temps, cela va sans dire.

Si tu utilise des équations de NS où les paramètres tendent à ce que ces équations deviennent quasi-linéaires, alors oui tu peux augmenter énormément le CFL, la discrétisation influera peu sur le résultat (et sur l'erreur).

Je n'ai jamais vu cela, mais cela me semble plausible. Je te fais confiance

Je suis tout à fait d'accord, néanmoins (et je pense que c'est bien là l'inconvénient des sources fermées) des batteries de cas, on peu en sortir une quantité astronomique, avec chacune son optimisation et chacune son point d'orgue.
Réussir à faire une simulation rapide sur un cas particulier revient dans la majorité des cas à adapter le code, donc à avoir ses sources...

Sur ce point au moins, nous sommes au diapason. Il sera très difficile de se diriger vers de l'open source intégralement pour des raisons évidentes de gros sous, mais je ne me risque pas à lancer un débat politique... Il est clair que tous ces codes commerciaux sont des boîtes noires. Exemple : j'ai lu, sur la doc CFX, que la discrétisation des conditions au limites des variables turbulentes n'étaient d'aucun intêret pour l'utilisateur ! On croit rêver. Je ne jette pas la pierre sur ce code mais sur certains arguments dénués de sens qui visent à prendre les gens pour des débiles profonds.

[obi76]

Exemple : j'ai lu, sur la doc CFX, que la discrétisation des conditions au limites des variables turbulentes n'étaient d'aucun intêret pour l'utilisateur ! On croit rêver. Je ne jette pas la pierre sur ce code mais sur certains arguments dénués de sens qui visent à prendre les gens pour des débiles profonds.

c'est la première fois que j'entends un truc pareil mais effectivement c'est assez représentatif du problème.

Par contre pour conclure, des codes en opensource que je qualifierai "de base" (càd résolution de NS, avec la diffusion etc) en DNS (donc pas de modèle de sous-maille), ça existe. Je pense particulièrement à OpenFOAM ou NSC2KE (pour pas faire de pub, de toutes façons c'est du libre ) qui contiennent un solveur très bien fait. Pour le reste, c'est à toi d'adapter...

EDIT : pour les équations de NS qui tendent vers le linéaire, c'est une déduction que j'ai faite, une CFL de 120 sur une équation non linéaire ça ne peut pas marcher (ou alors ça ne convergera jamais).

[invite5afa330c]

Bonjour,

Je recherche l'intervalle du nombre de Reynolds où le phénomène du vortex shedding se produit. Je fais cela numériquement avec Fluent afin de le vérifier expérimentalement.

La géométrie est très simple : un rectangle (2 walls, 1 velocity-inlet et 1 pressure-outlet) et un petit cercle à l'intérieur.
Le fluide est de l'eau et il n'y a pas de phénomène thermique.
Je sais que le vortex shedding se produit autour de Re=150.

Mais mon problème se situe au niveau des caractéristiques de l'eau...

Lorsque j'utilise l'eau (water-liq) de la base de données de Fluent, l'écoulement reste parfaitement stationnaire.
Lorsque j'utilise l'air avec la viscosité et la masse volumique de l'eau, cela fonctionne parfaitement !!!!

Quelqu'un aurait-il une explication? un début de réponse? une idée?

Quel fluide dois-je utiliser, sachant que c'est un travail sérieux?

Cordialement

Pour les simulations instationnaires, la condition d'entrée doit être pertubée pour obtenir les allées de Von Karmann dans le sillage. Si la vitesse à l'infini est maintenue parfaitement constante au cours de la simulation, les instabilités naissant dans les couches de cisaillement proches de la paroi du cylindre ne parviendront pas à se développer. Alors l'écoulement obtenu fera toujours apparaître deux zones de recirculation attachées au cylindre, même pour des nombres de Reynolds supérieurs à 50.
Il est donc indispensable de créer une pertubation numérique au moins sur un court laps de temps.Cette pertubation existe toujours expérimentalement et peut être causée par la rugosité du cylindre, un profil de vitesse d'entrée non uniforme ...
Deux types de pertubations(au moins) existent.Elles consistent à doubler la vitesse sur un certain nombre d'itérations ; la première sur toute la face ouest et sur la moitié de la surface pour la seconde.
Après l'arrêt de la pertubation, les allées de VK persistent et prennent une allure similaire quelque soit le type de pertubation adoptée.
Ceci signifie qu'elle intervient uniquement pour déclencher l'instabilité et ne modifie en aucun cas la physique du problème.

Il me semble que parmi les autres pertubations possibles il y a : une brève rotation du cylindre pendant quelques instants et décentrer légèrement la position verticale du cylindre par rapport au domaine d'étude

[obi76]

peut être (je rajoute) que Fluent gère de même les spectres énergétiques de la turbulence que l'on veut injecter (en k^-3/2 ou 5/2). Si c'est le cas le sillage initiale sera nettement plus proche de la réalité.

[invite5afa330c]

Précisons que :
_dès que l'on dépasse Re > 190(environ), les effets 3D sont à prendre en compte
_ pour Re > 300, le sillage des tourbillons est complètement turbulent(la transition vers la turbulence commence vers Re = 250 environ..)
_ les allées de VK apparaissent vers Re = 47(environ)

donc il y a de déjà de quoi s'amuser avec les allées de VK pour 50< Re < 150 avec un écoulement 2D laminaire.

[invited7275bd2]

Pour les simulations instationnaires, la condition d'entrée doit être pertubée pour obtenir les allées de Von Karmann dans le sillage. Si la vitesse à l'infini est maintenue parfaitement constante au cours de la simulation, les instabilités naissant dans les couches de cisaillement proches de la paroi du cylindre ne parviendront pas à se développer. Alors l'écoulement obtenu fera toujours apparaître deux zones de recirculation attachées au cylindre, même pour des nombres de Reynolds supérieurs à 50.
Il est donc indispensable de créer une pertubation numérique au moins sur un court laps de temps.Cette pertubation existe toujours expérimentalement et peut être causée par la rugosité du cylindre, un profil de vitesse d'entrée non uniforme ...
Deux types de pertubations(au moins) existent.Elles consistent à doubler la vitesse sur un certain nombre d'itérations ; la première sur toute la face ouest et sur la moitié de la surface pour la seconde.
Après l'arrêt de la pertubation, les allées de VK persistent et prennent une allure similaire quelque soit le type de pertubation adoptée.
Ceci signifie qu'elle intervient uniquement pour déclencher l'instabilité et ne modifie en aucun cas la physique du problème.

Il me semble que parmi les autres pertubations possibles il y a : une brève rotation du cylindre pendant quelques instants et décentrer légèrement la position verticale du cylindre par rapport au domaine d'étude

Pourquoi dis-tu qu'en simulations instationnaires, la condition d'entrée doit être perturbée ? Cela me paraît très dangeureux comme manière de faire : dans un cas quelconque, peux-tu prouver qu'en perturbant ta condition d'entrée tu ne bifurqueras pas vers une solution différente que si tu laissais ton calcul se dérouler sans "intrusion" ? Personnellement, je ne suis donc pas convaincu par les artefacts que tu suggères.

A priori, si dans le régime 50<Re<150, ton résultat de calcul ne donne pas d'allée de VK, alors le modèle de turbulence que tu utilises est à incrimier car physiquement, l'allée est auto-entretuenue par un système d'instabilités qui fait apparaître de la turbulence. Rien ne prouve qu'en raffinant à mort ton sillage tu obtiendras le même résultat ! Car en RANS (ou URANS), tu ne résolveras pas plus de structures. Au mieux, tu finiras par t'affranchir des erreurs de discrétisation et tu feras apparaître les limitations du modèle de turbulence utilisé.

[invited7275bd2]

peut être (je rajoute) que Fluent gère de même les spectres énergétiques de la turbulence que l'on veut injecter (en k^-3/2 ou 5/2). Si c'est le cas le sillage initiale sera nettement plus proche de la réalité.

Que veux-tu dire par k^-3/2 ou 5/2 ? est-ce k^(-5/3) avec k le nombre d'onde ? Si oui, tu fais déjà de la LES (ou des modèles hybrides) et non plus du RANS. Attention... Mais il faudra que tu précises si tu souhaites qu'on (ou que "je") te suive.

[invited7275bd2]

Précisons que :
_dès que l'on dépasse Re > 190(environ), les effets 3D sont à prendre en compte
_ pour Re > 300, le sillage des tourbillons est complètement turbulent(la transition vers la turbulence commence vers Re = 250 environ..)
_ les allées de VK apparaissent vers Re = 47(environ)

donc il y a de déjà de quoi s'amuser avec les allées de VK pour 50< Re < 150 avec un écoulement 2D laminaire.

l'écoulement laminaire me surprend. As-tu fait le test en vérifiant qu'avec deux calculs, un turbulent et un laminaire, tu obtiens la même solution ? J'ai du mal à être convaincu. Mais sans doute parce que je ne les ai jamais réalisés.
Pour tout ce qui concerne la transition vers la turbulence, je pense qu'on peut affirmer que les modèles RANS sont incapables de reproduire cela en raison des hypothèses utilisées lors de leur conception ainsi lors de leur calibration. Il faut introduire des termes supplémentaires, voire des équations supplémentaires. D'ailleurs, quand on fait des recherches bibliographiques, je crois que ce n'est pas un hasard si tous ces calculs sont réalisés avec la LES.

[invite5afa330c]

Pourquoi dis-tu qu'en simulations instationnaires, la condition d'entrée doit être perturbée ? Cela me paraît très dangeureux comme manière de faire : dans un cas quelconque, peux-tu prouver qu'en perturbant ta condition d'entrée tu ne bifurqueras pas vers une solution différente que si tu laissais ton calcul se dérouler sans "intrusion" ? Personnellement, je ne suis donc pas convaincu par les artefacts que tu suggères.

A priori, si dans le régime 50<Re<150, ton résultat de calcul ne donne pas d'allée de VK, alors le modèle de turbulence que tu utilises est à incrimier car physiquement, l'allée est auto-entretuenue par un système d'instabilités qui fait apparaître de la turbulence. Rien ne prouve qu'en raffinant à mort ton sillage tu obtiendras le même résultat ! Car en RANS (ou URANS), tu ne résolveras pas plus de structures. Au mieux, tu finiras par t'affranchir des erreurs de discrétisation et tu feras apparaître les limitations du modèle de turbulence utilisé.

Je précise que mon post faisait référence au cas d'écoulement laminaire dans le régime 50 < Re < 150 . Je n'ai jamais parlé de modèle de turbulence.Dans le cas d'un écoulement autour d'un cylindre fixe, le sillage ne devient complètement turbulent qu'à partir de Re > 300 donc pour le régime considéré(50 < Re < 150), un écoulement laminaire est parfaitement envisageable.

Comme je l'ai déjà dit :

Précisons que :
_dès que l'on dépasse Re > 190(environ), les effets 3D sont à prendre en compte
_ pour Re > 300, le sillage des tourbillons est complètement turbulent(la transition vers la turbulence commence vers Re = 250 environ..)
_ les allées de VK apparaissent vers Re = 47(environ)
donc il y a de déjà de quoi s'amuser avec les allées de VK pour 50< Re < 150 avec un écoulement 2D laminaire.

et dans ce cas là, il faut introduire une pertubation numérique pour faire apparaître les allées de VK(cf mon post sur les types de pertubations).