Cassiopee Forum
CFD python modules
S'il vous plaît connectez vous ou Enregistrement'.
Date et heure en ce moment : mardi, 24 octobre 2017, 06:09

Nouvelle discussion | Répondre
Cassiopee Forum :: Discussions, suggestions, bug report :: Transform :: Outils pour calculs en parallèle  ::
Sylvain Mouton
Junior Member
Image


Messages: 66
Outils pour calculs en parallèle (lundi, 2 mai 2011, 10:41) citation  
Bonjour,

Nos premières expériences font apparaitre un manque cruel d'outils pour splitter proprement des blocs d'un arbre CGNS.
SplitSize découpe effectivement les blocks mais au mépris de la connectivité (qu'elle soit coïncidente, non-coïncidente ou chimère) et avec un bug (au moins) sur les conditions aux limites (voir mon second post).

L'application de connectMatch derrière résoud (de façon lente et peu élégante) le problème des connectivités coïncidentes mais pas les autres. Et encore en admettant que le connectMatch est absolument fiable ce dont on peut douter étant donné le traitement des points dégénérés via la tolérance.

Ce problème va devenir bloquant pour tous le monde très très rapidement. Il me semble qu'il faut d'urgence développer un splitSize fiable, traitant correctement les connectivités et les conditions aux limites.

Sylvain

Ip enregistré Statut: déconnecté Profil | Site Web 
Ordre des réponses: Première réponse en dernier :: Première réponse en premier
Sylvain Mouton
Junior Member
Image


Messages: 66
RE: Outils pour calculs en parallèle (lundi, 2 mai 2011, 15:17) citation  
Il n'a pas fallu attendre longtemps : on a un cas ou connectMatch oublie des morceaux de raccord quelque soit la tolérance utilisée...
Donc c'est la catastrophe, on ne sait pas faire un calcul parallèle alors qu'on vient de nous installer des milliers de processeurs.


Ip enregistré Statut: déconnecté Profil | Site Web 
StephaniePeron
Full Member
Image


Messages: 158
RE: Outils pour calculs en parallèle (jeudi, 5 mai 2011, 13:14) citation  
Salut

Dans ton cas, il y a des facettes dégénérées. C'est un 'coup de bol' que ça passe avant le splitSize, ça doit dépendre du parcours des raccords.
C'est clairement spécifié dans connectMatch qu'on ne prend pas en compte les dégénerescences.

Ip enregistré Statut: déconnecté Profil | Site Web 
ChristopheBenoit
Administrator
Image


Messages: 169
RE: Outils pour calculs en parallèle (jeudi, 5 mai 2011, 14:20) citation  
Nous sommes conscient que le fait que splitSize (ainsi que toutes les fonctions de transform) détruise la connectivité est un gros défaut et que connectMatch ne peut pas toujours
reconstruire la connectivité ensuite (en particulier sur des cas dégénérés ou des maillages comportant des raccords nomatch ou near match). Il serait beaucoup mieux que les
fonctions de transform opèrent correctement sur la connectivité, comme elles opèrent déja sur les conditions aux limites physiques.
Mais un tel développement demande du temps et des moyens...

Ip enregistré Statut: déconnecté Profil | Site Web 
Sylvain Mouton
Junior Member
Image


Messages: 66
RE: Outils pour calculs en parallèle (lundi, 9 mai 2011, 11:41) citation  
Pour résumer, et pour m'assurer que j'ai bien compris :
* splitSize est indispensable pour des calculs parallèles
* splitSize détruit la connectivité
* on ne sait reconstruire la connectivité que si il n'y a pas de dégénérescence
* 90% des maillages que nous traitons possèdent des dégénérescences

Le problème est donc très grave. Je suis conscient de votre charge de travail, mais je vais devoir demander que ce problème passe en priorité car il est absolument bloquant.

Sylvain


Ip enregistré Statut: déconnecté Profil | Site Web 
Thomas Renaud
Administrator
Image


Messages: 43
RE: Outils pour calculs en parallèle (lundi, 9 mai 2011, 14:50) citation  
L'autre possibilité est de faire des maillages sans dégénérescences...

Ip enregistré Statut: déconnecté Profil | Site Web 
Sylvain Mouton
Junior Member
Image


Messages: 66
RE: Outils pour calculs en parallèle (mercredi, 19 octobre 2011, 14:27) citation  
citation:
L'autre possibilité est de faire des maillages sans dégénérescences...

ou d'utiliser un autre code...
ou de se reconvertir dans la conchyliculture...

Plus sérieusement, j'aimerais savoir si des avancées ont été réalisées sur ce point (préservation de la connectivité par splitSize) avant de me lancer sur un gros cas qui comportera à coup sûr des dégénérescence vus certains détails géométriques.

Ip enregistré Statut: déconnecté Profil | Site Web 
StephaniePeron
Full Member
Image


Messages: 158
RE: Outils pour calculs en parallèle (jeudi, 20 octobre 2011, 11:05) citation  
salut Sylvain

Normalement, si tu as défini tes dégénerescences comme des BCDegenerateLine ou Point, alors le connectMatch marche derrière. SplitSize ne détruit que les GridConnectivity de type 'match', 'nearmatch', et 'overset' dans le cas où les attachements sont spécifiés (normal).
Après réflexion, faire un connectMatch ne coûterait pas plus cher que de conserver dans les n iterations de split les connectivités, les nouveaux indices, récupérer le nouveau voisin, s'il a été découpé ou pas (ce qui revient à faire du connectMatch au final...).
a+



Ip enregistré Statut: déconnecté Profil | Site Web 
Sylvain Mouton
Junior Member
Image


Messages: 66
RE: Outils pour calculs en parallèle (mardi, 25 octobre 2011, 14:07) citation  
Ok merci,
Je vais réessayer cela dès que possible.

Ip enregistré Statut: déconnecté Profil | Site Web 
Sylvain Mouton
Junior Member
Image


Messages: 66
RE: Outils pour calculs en parallèle (vendredi, 9 mars 2012, 16:39) citation  
Alors, "dès que possible" n'était pas vraiment le terme approprié mais je reviens sur ce problème de splitSize.

Effectivement, les BCDegenerateLine ou Point ne sont pas détruit par connectMatch, mais les raccord coïncidents adjacents ne sont pas correctement retrouvés. Dans le cas d'une couche limite, l'épaisseur très faible des mailles combinée avec leur convergence vers un point unique (ou une ligne) fait qu'il est impossible de déterminer une tolérance qui permette d'avoir des raccords corrects. Il arrive que ça marche mais c'est un coup de bol.

Je ne suis pas trop d'accord sur le fait que connectMatch ne couterait pas plus cher. En effet, il a besoin d'accéder aux coordonnées puis de tester tous les raccords avec tous les autres blocs, ce qui me parait bien lourd. Si au contraire on exploite proprement les infos de topologies présentes dans le maillage avant le split (au lieu de les mettre à la poubelle), il n'y a pas besoin d'accéder aux coordonnées, et il n'y a pas de risque de se tromper sur ces histoires de tolérance.

En conclusion, je maintiens qu'il faut faire évoluer splitSize vers un outil qui découpe les blocks mais aussi les informations de topologie associées.

Ip enregistré Statut: déconnecté Profil | Site Web 
Nouvelle discussion | Répondre

Software PBLang 4.65 © 2002-2003 by Martin Senftleben
Image