euh... aurais tu les fichiers textes obtenus avec les deux methodes
stp. Cela me permettrait de voir si le pb vient de la fonction
d'import ou si cela vient de la fonction d'export.
merci
Luc
Le 2 décembre 2010 18:32, luc scholtes <lscholtes63@xxxxxxxxx
<mailto:lscholtes63@xxxxxxxxx>> a écrit :
Ok, merci pour tes eclaircissements.
Effectivement, executer la simu a la suite de l'identification est
une solution qui evite les erreurs de lecture/ouverture de
fichiers. J'ai vu que la definition de onJ ne marchait pas...
C'est le fait que les normales correspondantes etaient differentes
qui me sauvait jusqu'a present... hum... Par contre, je ne
comprends tjrs pas la difference de 4%... D'apres ce que j'ai pu
tester, la methode de detection ne donne pas de resultats
aleatoires... La, il y a un truc a creuser... Si je comprends
bien, c'est comme si certaines spheres etaient "zappees" dans mon
import...Ca m'inquiete un peu...
Concernant ton idee de regrouper les etapes dans le meme script,
cela me parait plutot bon, mais par contre, si cette methode
semble judicieuse pour le cas ou il y a tres peu de spheres et
tres peu de joints, je me demande ce que cela donnera avec bcp de
spheres et bcp de joints. En effet, le temps de detection peut
etre long et dans ce cas la, mieux vaudra distinguer les deux
etapes, d'autant plus si l'on veut faire une etude parametrique
avec la meme configuration (refaire la meme identification pour
lancer un calcul dans lequel change seulement une propriete
mecanique comme l'angle de frottement du joint par exemple ne
parait pas tres pratique)... Bref, pas vraiment de reponse a te
donner ici... Mais j'adhere assez a l'idee de n'avoir qu'un
fichier regroupant toutes les infos.
J'essaie de m'y plonger un peu plus pour trouver d'ou vient ce 4%...
++
Le 1 décembre 2010 23:04, Jerome Duriez <duriez@xxxxxxxxxxxxxxx
<mailto:duriez@xxxxxxxxxxxxxxx>> a écrit :
Bon alors finalement tout ceci ne sera peut être plus d'actualité.
Je viens de me rendre compte qu'on pouvait apparemment
faire très bien sans export/ymport. Je viens de mettre sur
Launchpad, une version du script IdentificationSpheresOnJoint
ne contenant uniquement que les opérations de détection. Tu
peux l'appeler depuis n'importe quel autre script par :
execfile('IdentificationSpheresOnJoint.py')
Je me suis donc rendu compte que je pouvais très bien dans
un même script définir mes sphères (la géométrie du massif),
leur affecter les propriétés mécaniques que je veux (avec un
JCFpmMat adéquat), et exécuter ensuite le script, puis
commencer réellement la simulation.
Je viens de retrouver que tu m'avais dit que tu voulais
séparer l'étape de détection des simulations. Ici on va dire
qu'elles le sont à moitié puisque les instructions sont
écrites dans deux scripts différents, mais que ceux ci sont
exécutés directement à la suite l'un de l'autre. Qu'en penses
tu ? (plus d'histoire d'ymport/export, dans ce cas...)
Jérôme
Le 01/12/2010 11:32, Jerome Duriez a écrit :
Salut Luc,
Je vais essayer d'être un peu plus clair.
- Sur export / ymport. Je me suis dit (on en avait
parlé un peu à Paris) que c'était dommage d'avoir à
utiliser deux fichier : un Bloc.spheres, et un
Bloc_JCFpm.spheres. J'ai donc essayé de faire en sorte de
n'avoir à en utiliser qu'un.
Premièrement j'ai donc modifié la fonction export,
exactement comme tu le dis toi même :
en modifiant legerement la fonction export, on peut
arriver a creer un fichier texte avec toutes les infos
necessaires (x,y,z,r,onJ,nj,j11,etc...).
Deuxièmement, il fallait modifier la fonction ymport.
Ce que j'ai fait (cf code sur launchpad :
http://bazaar.launchpad.net/~yslopeusers/yslope/trunk/annotate/head%3A/py/ymport.py#L44
<http://bazaar.launchpad.net/%7Eyslopeusers/yslope/trunk/annotate/head%3A/py/ymport.py#L44>).
Avec cette nouvelle fonction ymport.textExt, en une
importation (via ymport.textExt, on n'utilise plus
ymport.text), on a les positions des billes, leurs rayons,
et toutes les variables onJ,nj,j11..... Car en fait, tu
pourras remarquer que l'instance matériau est définie
directement dans cette ymport.textExt.
Le problème est que dans le matériau, il n'y a pas que
onJ,nj, j11... mais aussi "density", "young".... Et que,
tel que c'est écrit actuellement dans ymport.textExt, ce
sont les valeurs par défaut de ces autres paramètres qui
sont utilisées lors de la création des sphères. Hormis
"density", c'est assez facile de changer à la main ces
valeurs, une fois que les bodies existent (une fois qu'on
a fait l'importation avec ymport.textExt). Pour density
c'est un peu plus pénible, puisque il faudrait changer en
plus "mass" et "inertia" (variables des bodies, découlant
de la variable "density" du matériau). Et que donc j'ai
décidé d'écrire dans ymport.textExt, que density = 2400
(afin que ce soit bien 2400 qui soit utilisé, et pas la
valeur par défaut = 1000). Pour une autre valeur de
density, il faudrait modifier à cet endroit.
En résumé, je te conseillerais de jeter un coup d'oeil
au script ci - joint. Tu ne pourras pas l'exécuter, mais
les commentaires devraient t'aider à voir la démarche (si
les nouvelles explications plus haut sont toujours aussi
peu claires). Et donc en particulier, maintenant j'écris
plus (comme toi avant) :
def sphereMat(): return
JCFpmMat(type=1,young=10e9,frictionAngle=radians(30),density=2400)
et
O.bodies.append(ymport.text(O.tags['id']+'.spheres',scale=1.,shift=[0,0,0],material=sphereMat))
- Passons ensuite à cette "comparaison". Une fois que
j'ai fait tout ça, j'ai voulu vérifier que je trouvais
bien la même chose que toi. Effectivement l'identification
en elle même n'a rien à voir avec l'export et "l'ymport";
mais on peut très bien bien identifier, si après lors des
étapes d'export et "d'ymport" il y a des erreurs,
l'échantillon final sera quand même "pas bon"...
J'ai donc pris l'exemple du bloc avec fissure à 30 degrés.
Premièrement, avec l'ancienne méthode (ce que tu
faisais), j'ai identifié, j'ai exporté (dans deux fichiers
: .spheres, et _JCFpm.spheres), puis j'ai utilisé ces deux
fichiers comme toi : avec ymport.text, et la boucle python
pour lire (et affecter aux sphères) onJ, nj, j11.... => Ca
donne BlocAvecOldImport.xml.
La remarque sur le booleen onJ, c'est que, en faisant
ça directement avec les scripts que tu m'avais envoyés (où
il y avait marqué onJ = _*bool*_(line.split()[1]) ), je
n'ai eu finalement pour les sphères que des onJ = 0. Alors
que dans le fichier _JCFpm.spheres, il y avait bien des
"1" aussi. Et que j'ai donc dû changer onJ =
_*bool*_(line.split()[1]) par onJ =
_*int*_(line.split()[1]) dans le script pour que ça marche.
Deuxièmement, j'ai cherché à utiliser les nouvelles
versions d'export/ymport. A la fin de l'identification (la
même), j'exporte donc un seul fichier, avec export.textExt
(version modifiée, cf launchpad). Puis (cf d'ailleurs
TestPrNewExportSuite.py), j'importe uniquement ce fichier,
avec ymport.textExt, la version modifiée toujours. Reste
encore alors à affecter les mêmes prop mécaniques, que je
fais à la main, plutôt qu'en affectant une instance
précise de "Material".
J'obtiens donc un 2d échantillon => BlocAvecNewImport.xml
Je compare donc finalement les 2 échantillons, et c'est
là où j'ai 4% d'erreur, sans que je ne puisse trop
l'expliquer (à part une différence dans les 2 méthodes,
due à une erreur, est-ce qu'il y aurait un caractère
légèrement aléatoire de l'identification ? je n'ai pas
regardé ça)
Bon je reconnais que tout ça est un peu inutile,
puisque tu avais un truc qui t'allait apparemment. Mais je
trouvais cette histoire de "deux fichiers" pas à mon goût,
c'est pour ça que j'ai fait ça. Maintenant on a plus qu'un
fichier, mais c'est vrai que c'est peut être moins
pratique pour définir young, frictionAngle, density...
J'espère dans tous les cas avoir été plus clair !
Jérôme
_______________________________________________
Mailing list: https://launchpad.net/~yslopeusers
<https://launchpad.net/%7Eyslopeusers>
Post to : yslopeusers@xxxxxxxxxxxxxxxxxxx
<mailto:yslopeusers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yslopeusers
<https://launchpad.net/%7Eyslopeusers>
More help : https://help.launchpad.net/ListHelp
--
Jérôme Duriez
ATER Polytech' Grenoble - Laboratoire 3S-R
04.56.52.86.49 (ne pas laisser de messages sur le répondeur)
_______________________________________________
Mailing list: https://launchpad.net/~yslopeusers
<https://launchpad.net/%7Eyslopeusers>
Post to : yslopeusers@xxxxxxxxxxxxxxxxxxx
<mailto:yslopeusers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~yslopeusers
<https://launchpad.net/%7Eyslopeusers>
More help : https://help.launchpad.net/ListHelp
