Cassiopee Forum
CFD python modules
S'il vous plaît connectez vous ou Enregistrement'.
Date et heure en ce moment : samedi, 21 octobre 2017, 13:53

Cassiopee Forum :: Discussions, suggestions, bug report :: Converter :: Bug Converter.PyTree  :: Page 1 de 2 [ 1  | 2 ]
Sylvain Mouton
Junior Member
Image


Messages: 66
Bug Converter.PyTree (jeudi, 23 juin 2011, 11:29)  
Mon stagiaire rencontre un problème assez inexplicable de lecture / écriture d'arbre CGNS.

Un fichier CGNS (ADF), qui nous semble correct, est lu par Converter.PyTree, puis immédiatement écrit sous un autre nom.

Le fichier écrit est alors illisible par elsAxdt et par l'ADFviewer. Il reste lisible par Converter.
On remarque également que convertFile2PyTree() délivre un arbre CGNS/Python qui contient un float64 pour le libraryVersion au lieu d'un float32, mais cela ne suffit pas à expliquer le problème.

Le cas test est dans /stck5/ggouvern/Public/Bug_convertFile2PyTree

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: Bug Converter.PyTree (jeudi, 23 juin 2011, 11:36)  
Après de nouvelles investigations, selon toute vraisemblance le problème provient de l'install de la 1.8 avec utilisation de CGNS 3.1.
Pour l'instant y a plus rien qui marche ! Comment réaliser la transition vieux cgns -> nouveau cgns please ?

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


Messages: 169
RE: Bug Converter.PyTree (jeudi, 23 juin 2011, 11:43)  
Salut,
Il est possible que tu utilises une version de elsAxdt
generant de l'ADF version 3.1. Cet ADF n'est relisible
par la librairie cgns 2.5 (!). Par contre, la librairie
cgns 3.1 relit le 2.5 (ouf). J'ai installe sur stelvio
une version de Converter compilee avec la libcgns 3.1.
(/home/benoit/Cassiopee/Dist/bin/stv_r8). En esperant
que ca resolve ton probleme.
a+

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


Messages: 66
RE: Bug Converter.PyTree (jeudi, 23 juin 2011, 16:09)  
En fait on utilise toujours la version qui est sur
/tmp_user/stelvio/peron/Cassiopee1.8
et qui n'a pas changée, donc ton installation avec cgns 3.1 ne devrait pas avoir d'impact.

Pourtant on n'est plus capable d'écrire un fichier cgns que l'on puisse relire avec elsAxdt ensuite. Je ne sais pas comment ni pourquoi, mais tous les fichiers que l'on produit sont:
* illisibles avec elsAxdt (celle de la version elsA v3.4.02)
* illisible avec adfviewer (une version sans doute assez ancienne qui traine sur mon pc)
* lisible seulement avec cgnsview (dispo sur stelvio dans le module cgns/cgns3.1.3

Je viens de comprendre :
La version Cassiopee /tmp_user/stelvio/peron/Cassiopee1.8 s'appuie sur la libcgns.so qui se trouve dans /home/benoit/lib. Or cette dernière a changé ce matin (passage 3.1 j'imagine). Du coup je pense que l'on produit des fichiers CGNS 3.1 que l'on ne sait pas relire par la suite. A noter que le 'CGNS library version' indiqué dans les fichiers est toujours à 2.3.
J'ai essayé d'utiliser à la place les librairies cgns dispo sur stelvio mais la cgns/cgns-2.4.6 n'a pas de librairies dynamique et toutes les versions ultérieures ne trouvent pas le symbole H5T_NATIVE_INT32_g (des trucs HDF5 visiblement).

Quelqu'un sait-il encore produire des fichiers utilisables par elsAxdt (c'est le but quand même !) avec une install quelconque de Cassiopee 1.8 ?

Et quelqu'un aurait une aspirine ?

Sylvain


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


Messages: 66
RE: Bug Converter.PyTree (jeudi, 23 juin 2011, 16:52)  
Bonsoir,
Voici la solution trouvée et les explications de Christophe.
Poinot est passé à CGNS 3.1 pour sa version de elsAxdt et a demandé à ce que tout le monde fasse de même. Cassiopee 1.8 est donc passé en 3.1. Dans l'opération, la librairie dynamique libcgns.so chez Benoit, sur laquelle pas mal de monde pointait, s'est retrouvée en 3.1. Du coup on s'est tous retrouvé à écrire du cgns 3.1 sans le savoir. Malheureusement, la version de elsAxdt accompagnant elsA 3.4.02 (la version publique) ne peut pas relire du cgns 3.1 !
Bilan, il faut absolument utiliser elsAxdt de chez Poinot.

Pour finir je source à présent, dans cet ordre :
echo "Sourcing elsA from /tmp_user/stelvio/poinot/FFD/install"
. /tmp_user/stelvio/poinot/FFD/install/Dist/bin/stelvio/source.me
CASSIOPEE=/tmp_user/stelvio/benoit/Cassiopee1.8
echo "Sourcing Cassiopee from $CASSIOPEE"
. $CASSIOPEE/Dist/sh_Cassiopee_r8

et ça a l'air de marcher...
Sylvain

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


Messages: 66
RE: Bug Converter.PyTree (jeudi, 23 juin 2011, 17:27)  
ça avait l'air de marcher pour ce qui concerne CGNS et elsAxdt, mais pour elsA c'est autre chose :

/tmp_user/stelvio/poinot/FFD/install/Dist/bin/stelvio/elsA.x: symbol lookup error: /tmp_user/stelvio/poinot/FFD/install/Dist/bin/stelvio/libeChim.so: undefined symbol: _ZN5E_PCM4MinIE

J'en peux plus, je me tire... Bon courage à tous



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


Messages: 66
RE: Bug Converter.PyTree (lundi, 27 juin 2011, 10:11)  
Je continue à alimenter en info pour ceux que ça intéresserait.
Il y a incompatibilité entre l'environnement CGNS 3.1 utilisé par Cassiopée et celui utilisé par elsAxdt chez Poinot.
Le premier s'appuie sur la librairie dynamique libcgns.so compilée par Christophe (dans /tmp_user/stelvio/benoit/lib/), le second par celle de l'environnement stelvio (dans appliadm, obtenu par la commande module load).
Ces deux librairies n'ont visiblement pas été compilées avec le même compilateur, du coup Cassiopée ne fonctionne QUE avec la librairie chez Christophe et elsAxdt QUE avec celle de stelvio. Suivant la première apparaissant dans le LD_LIBRARY_PATH, l'un ou l'autre des logiciels fonctionne, mais jamais les deux.
Christophe va recompiler Cassiopée dans la semaine pour s'appuyer sur la librairie de stelvio.


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


Messages: 43
RE: Bug Converter.PyTree (mardi, 28 juin 2011, 16:51)  
problème similaire pour moi. Quelque soit la version de Cassiopée utilisée, le CGNS généré n'est pas lisible par la version elsA de Marc Poinot.
Ce qui serait bien, c'est que l'on sache quand il y a de tels changements pour que l'on sache quand on peut s'arrêter de travailler...

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


Messages: 66
RE: Bug Converter.PyTree (mardi, 28 juin 2011, 17:42)  
Merci Thomas,
On commençait à se dire que l'on était les seuls à utiliser elsAxdt, voire elsA tout court. Pour t'encourager, je te signale que même si tu arrivait à lire tes fichiers avec elsAxdt, tu ne pourrais pas les visualiser avec tecplot (sauf avec la version 2001r2 beta qui vient d'être installée sur fulvio uniquement).
Bon, je suggère que l'on arrête les frais avec CGNS 3.1 en attendant que tout cela murisse et que l'on repasse d'urgence en 2.5. Je vais faire un (second) mail à Marc Poinot dans ce sens.


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


Messages: 43
RE: Bug Converter.PyTree (mercredi, 29 juin 2011, 11:24)  
en fait, c'est la version du repertoire poinot/FFD qui est obsolete. Il faut utiliser celle du repertoire poinot/SCons.201105. Encore fallait-il avoir eu l'info!

Celle-ci compilée en CGNS 3.1 marche a priori correctement avec les dernieres versions Cassiopee.

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


Messages: 169
RE: Bug Converter.PyTree (mercredi, 29 juin 2011, 14:08)  
Bonjour,
Les problemes qui surviennent aujourd'hui proviennent tous du fait qu'il n'existe pas une installation cohérente de elsA/elsAxdt/Cassiopée récente (la dernière production
remonte à novembre avec elsA 3.4.02). Du coup, chacun
a évolué de son coté, utilisant des librairies et des
installations différentes.
Je pense qu'il serait vraiment préférable d'accélerer le rythme de production des installations de la suite elsA
(par exemple tous les 2 mois).
Si c'était le cas, il suffirait d'utiliser cette installation, plutot que de fabriquer des install avec des
bouts compilés séparément.
Bien sur, ca introduit un petit délai pour utiliser un nouveau développement, mais ca augmenterait la robustesse du processus.
Qu'en pensez vous?

Ip enregistré Statut: déconnecté Profil | Site Web 
Page 1 de 2 [ 1  | 2 ]Nouvelle discussion - Discussion barrée, pas de réponse possible

Software PBLang 4.65 © 2002-2003 by Martin Senftleben
Image