Welcome to the forums. Please post in English or French.

You are not logged in.

#1 Re: Code_Aster usage » Masses effectives & analyse modale » 2013-12-10 05:10:12

J'arrive un peu après la bataille mais je rappelle pour ceux qui chercheraient sur ce forum que la commande STANLEY() lance Stanley (logique) qui, en choisissant 1 seul mode (1 seul numéro d'ordre), propose d'animer ce mode dans Gmsh (il y a une checkbox à cocher dans Stanley après avoir sélectionné un mode). Il fait donc automatiquement le "bidouillage" mentionné.
A noter que la norme du champs de "déplacement" n'ayant pas de sens physique, Stanley exporte un champs de déplacement unitaire, qui est probablement bien trop grand pour la visualisation par rapport à la structure si le modèle est en unité SI (structure très déformée). Mais on peut appliquer un facteur de réduction dans les options de Gmsh.

#2 Re: Code_Aster usage » [SOLVED] Bug with MED export // Gmsh ? » 2013-12-02 02:08:30

Hi,
Thanks for the replies. There is indeed a bug in the packaged version of MED (and not Gmsh). I upgraded libmedc1 from 3.0.3-3 to 3.0.6-2 (amd64) and everything works well now. Gmsh was never a problem in the first place.
Closing as solved... even though leaving this kind of bug in a packaged version is awful.

#3 Re: Code_Aster usage » [SOLVED] Bug with MED export // Gmsh ? » 2013-11-29 01:33:24

Hi,
Thanks for the reply. I tried with Gmsh:
- 2.6.0.dfsg-2 (Ubuntu quantal amd64)
- 2.8.2+dfsg-1 (Ubuntu saucy amd64)
- 2.8.3+dfsg-4 (Ubuntu trusty amd64)
And Christophe Geuzaine just accepted my bug report ticket (see links in my original post; login/password is gmsh/gmsh).
Could you try the attached file with your Gmsh please? Just to see if mine is broken or it's more general...
[ EDIT: I couldn't upload the file here (19Mo). It's uploaded on the Gmsh Trac : https://geuz.org/trac/gmsh/attachment/t … l-calc.med ]
Thanks
- Jerome

#4 Code_Aster usage » [SOLVED] Bug with MED export // Gmsh ? » 2013-11-28 08:51:16

humbert
Replies: 5

Hi,

I'm trying to read back a result file exported from Aster v11.3.0-2 in MED format, but the timesteps are scrambled.
It worked for some times before, but now it doesn't. I'm not quite sure if it's a problem with the exporter or Gmsh.
Basically I checked the result file with ViTables (tool to read HDF5 files) and I see the displacement results.
They are named '000000000XXX000000000XXX' where XXX is the time step (NUME_ORDRE), and there is an associated property PDT (I guess 'Pas De Temps') which has the correct timestep value (INST). However these fields appear in any order in the result file. My guess is that Gmsh simply read back the fields in the order of the file without interpreting any of the associated properties or field name. I end up with a Gmsh post-processing view with correct results, but the timesteps are not ordered.
I can't post a demo here, I use a custom Aster version with a custom behavior law. Sorry :'(
I tried specifying a list of NUME_ORDRE to IMPR_RESU to force the writing order in the file but it didn't work.
I tried upgrading Gmsh from 2.6.0 to 2.8.2 but nothing changed. This is rather annoying. I know it appears like a Gmsh bug, but since  IMPR_RESU in Gmsh native format is not upgraded to v2 "because Gmsh reads MED" (official reason I was given), if the MED export is also unusable, then there is no way to use Gmsh with Code_Aster. Or is there?

Has anybody experienced this before? I couldn't find any information about this "bug".
Thanks.

PS: I have negative timesteps (INST = -1.0) for static preload before the dynamic simulation, maybe it doesn't help (I saw a field '-000000001-000000001' in the MED file).

EDIT: I opened a ticket on Gmsh trac (https://geuz.org/trac/gmsh/ticket/218)

#5 Code_Aster usage » No more GROU_NO in CALC_CHAMP ? » 2013-01-28 02:30:11

humbert
Replies: 1

Hi,

My new install of Code_Aster v11.3.0-2 (testing) complains about GROUP_NO in CALC_CHAMP (to compute REAC_NODA), and indeed it was removed from the catalog (diff with v11.0). But the documentation still list it as a valid option, and I couldn't find any notice about this removal in the changelogs (HISTOR files). Did I miss something? How am I supposed to compute nodal forces/reactions? Could anyone points me to the relevant doc if any?

Thanks

#7 Re: Code_Aster usage » [SOLVED] Bug CREA_TABLE / RESU / NOEUD avec liste de noeud » 2013-01-18 05:41:41

OK I found the reason, which may or may not be considered a bug (your call): my list of strings has strings of type 'numpy.string_' (NumPy strings) and not 'str' (pure Python strings) because I was manipulating arrays with NumPy. I added a conversion str(...) arount the node names and it works.

Now, for the 'bug' nature of the error, I suggest if I may that the behavior would be made consistent between the validator and the Fortran code, which probably both have a different interpretation of whether a NumPy string argument is a valid Fortran string argument (so to speak). And since NumPy is so heavily used by Code_Aster (strong dependency), it could accept NumPy strings in place of regular Python strings.

If you consider this is not a bug please let me know, I'll prepend a [SOLVED] in the forum thread title.

#8 Re: Code_Aster usage » [SOLVED] Bug CREA_TABLE / RESU / NOEUD avec liste de noeud » 2013-01-18 02:00:11

My bad, I messed the indentation in the copy-paste from the forum. The CREA_TABLE was not idented and got outside the function, which then makes it perfectly logical why I had an error. Now this particular example (forma01a) works flawlessly.
Now on why mine do not...

#9 Re: Code_Aster usage » [SOLVED] Bug CREA_TABLE / RESU / NOEUD avec liste de noeud » 2013-01-17 03:04:06

Same error with a fresh new install of version 11.3.0-2 just downloaded:

ERREUR A L'INTERPRETATION DANS ACCAS - INTERRUPTION
>> JDC.py : DEBUT RAPPORT
CR phase d'initialisation
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   ! erreur de syntaxe,  Erreur de nom: name 'RESU' is not defined ligne 6 !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
fin CR phase d'initialisation

>> JDC.py : FIN RAPPORT

#10 Re: Code_Aster usage » [SOLVED] Bug CREA_TABLE / RESU / NOEUD avec liste de noeud » 2013-01-17 01:15:24

Obviously (I could have told by reading the code alone) I've got the undefined error below.
By the way I'm using version 11.1 on Ubuntu 12.04 with Python 2.7.3. You said it runs fine for you, is this got corrected in later versions? Because this behavior (undefined name in function declaration) has always been a big issue for me, whatever the version. I never ran fine any code like this, and so do all people I know on whatever version / platform (below v11.1).


ERREUR A L'INTERPRETATION DANS ACCAS - INTERRUPTION
>> DEBUT RAPPORT
CR phase d'initialisation
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   ! erreur de syntaxe,  Erreur de nom: name 'RESU' is not defined ligne 6 !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
fin CR phase d'initialisation

>> FIN RAPPORT
ERREUR A LA VERIFICATION SYNTAXIQUE - INTERRUPTION
>> DEBUT RAPPORT
DEBUT CR validation : fort.1
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   ! - Il faut au moins un mot-cl parmi : ('DEBUT', 'POURSUITE')                   !
   ! - Il faut au moins un mot-cl parmi : ('FIN',)                                 !
   ! - Il faut qu'au moins un objet de la liste : ('DEBUT', 'POURSUITE') soit suivi !
   ! d'au moins un objet de la liste : ('FIN',)                                     !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   ! erreur de syntaxe,  Erreur de nom: name 'RESU' is not defined ligne 6 !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FIN CR validation :fort.1

>> FIN RAPPORT

#11 Re: Code_Aster usage » [SOLVED] Bug CREA_TABLE / RESU / NOEUD avec liste de noeud » 2013-01-16 08:49:36

Sorry I forgot to mention this but you need to define the Python list at the root of the command script, but call the DEFI_GROUP or CREA_TABLE command inside a Python function. Otherwise indeed it works.

Could you try the following please?


# 1) Define Python list
x = ('N50     ','N116    ','N900    ','N74     ','N100    ','N916    ','N2100   ','N2900   ',)

# 2) Create Python function with a command
def www(MA, xx):
   
    z = []
    for s in xx:
        z.append(s)
   
    MA = DEFI_GROUP(
        reuse    = MA,
        MAILLAGE = MA,
        CREA_GROUP_NO = _F(
            NOM   = 'TMPGRPNO',
            NOEUD = z,
        ),
    )

# 3) Call the Python function
www(MA, x)

-> coredump

#12 Re: Code_Aster usage » [SOLVED] Bug CREA_TABLE / RESU / NOEUD avec liste de noeud » 2013-01-16 06:55:03

Apparemment le problème ne vient pas de CREA_TABLE mais plutôt de "getvtx_": même problème avec une liste Python de noms de noeuds passée à NOEUD dans DEFI_GROUP (c'était une tentative de workaround).


* comm:

    list_no = []
    for no_num in list_no_num:
        list_no.append(node_names[no_num - 1])

    MA = DEFI_GROUP(
        reuse    = MA,
        MAILLAGE = MA,
        CREA_GROUP_NO = _F(
            NOM   = 'TMPGRPNO',
            NOEUD = list_no,
        ),
    )


* mess:

MA=DEFI_GROUP(reuse = MA,
                MAILLAGE=MA,
                CREA_GROUP_NO=_F(NOEUD=('N50     ','N116    ','N900    ','N74     ','N100    ','N916    ','N2100   ','N2900   ',),
                                 NOM='TMPGRPNO'),
                ALARME='OUI',
                );

! Etape  : DEFI_GROUP / CREA_GROUP_NO / NOEUD
! Parent : fort.1
! ERREUR incoherence fortran/catalogue de commande, chaine de caractres attendue et non :
! ['N50     ', 'N116    ', 'N900    ', 'N74     ', 'N100    ', 'N916    ', 'N2100   ', 'N2900   ']
<F> GETVTX : numero d'occurence (IOCC=1)
             commande : DEFI_GROUP
             mot-cle facteur : CREA_GROUP_NO
             mot-cle simple  : NOEUD


* Coredump:

#0  0x00007f243fad1425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64    ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x00007f243fad1425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f243fad4b8b in __GI_abort () at abort.c:91
#2  0x000000000050038b in TraiteMessageErreur (message=0x7597dc0 "/opt/aster/STA11.1/bibc/supervis/astermodule.c 1355 : erreur dans la partie Python") at /opt/aster/STA11.1/bibc/supervis/astermodule.c:263
#3  0x000000000050046e in PRE_myabort (nomFichier=0x2456860 "/opt/aster/STA11.1/bibc/supervis/astermodule.c", numeroLigne=1355, message=0x245683d "erreur dans la partie Python") at /opt/aster/STA11.1/bibc/supervis/astermodule.c:296
#4  0x0000000000502da2 in getvtx_ (motfac=0x7fffcc926d70 "CREA_GROUP_NO   GROUP_MA        &&SSCGNO.LISTE_NOEUDS   \001", motcle=0x24926b0 "NOEUDINTERSECUNIONDIFFEGROUP_MATOUT_GROUP_MAGROUP_NOOPTIONNOMSOUSTRUC_37FLONUTIINTEROUISOUSTRUC_38ALONMAXEENV_SPHEREENV_CYLINDREPLANSEGM_DROI_ORDOTUNNELINCLUSIONNOEUD_ORDOOUVERTVFISS_XFEMCALCULEL6_10."..., iocc=0x7fffcc926de8, iarg=0x7fffcc926e48, mxval=0x24926a8, txval=0x7fffcc926dc0 "MA      -\364\035", nbval=0x7fffcc926d58, lfac=16, lcle=5, ltx=8) at /opt/aster/STA11.1/bibc/supervis/astermodule.c:1355
#5  0x000000000093e136 in sscgno (ma=..., nbgnin=6, _ma=8) at /opt/aster/STA11.1/bibfor/soustruc/sscgno.f:90
#6  0x00000000006ec380 in op0104 () at /opt/aster/STA11.1/bibfor/soustruc/op0104.f:163
etc...

#13 Code_Aster usage » [SOLVED] Bug CREA_TABLE / RESU / NOEUD avec liste de noeud » 2013-01-15 10:08:36

humbert
Replies: 13

Enjoy!


    depl_tab = CREA_TABLE(
        RESU = _F(
            RESULTAT   = U1,
            NOM_CHAM   = 'DEPL',
            #TOUT_ORDRE = 'OUI',
            NOM_CMP    = ('DX','DY','DZ','DRX','DRY','DRZ'),
            NOEUD      =  voir ci-dessous...,
        ),
    )




  # ------------------------------------------------------------------------------------------
  # Commande No :  0029            Concept de type : table_sdaster
  # ------------------------------------------------------------------------------------------
  depl_tab=CREA_TABLE(TYPE_TABLE='TABLE',
                      RESU=_F(NOEUD=('N50     ','N116    ','N900    ','N74     ','N100    ','N916    ','N2100   ','N2900   ',),
                              CRITERE='RELATIF',
                              RESULTAT=U1,
                              NOM_CHAM='DEPL',
                              NOM_CMP=('DX','DY','DZ','DRX','DRY','DRZ',),
                              PRECISION=1.E-06),
                      );

! Etape  : CREA_TABLE / RESU / NOEUD
! Parent : fort.1
! ERREUR incoherence fortran/catalogue de commande, chaine de caractres attendue et non :
! ('N50     ', 'N116    ', 'N900    ', 'N74     ', 'N100    ', 'N916    ', 'N2100   ', 'N2900   ')
<F> GETVTX : numero d'occurence (IOCC=1)
             commande : CREA_TABLE
             mot-cle facteur : RESU
             mot-cle simple  : NOEUD
/opt/aster/STA11.1/bibc/supervis/astermodule.c 1355 : erreur dans la partie Python
Traceback (most recent call last):
  File "./Python/Build/B_ETAPE.py", line 228, in getvtx
    raise AssertionError
AssertionError
Aborted (core dumped)


Differents tests:

1) NOEUD = ('N50     ','N116', etc...),  => ok

x = ('N50     ','N116', etc...)
2) NOEUD = x,   => coredump
3) NOEUD = (x), => ok
4) NOEUD = (x,),   => coredump

x = []
x.append('N50     ')
x.append('N116    ')
etc...
5) NOEUD = x,   => coredump
6) NOEUD = (x), => coredump
7) NOEUD = (x,),   => coredump

2 et 5 devraient marcher...
3 est complètement aberrant
j'ai essaye aussi en forçant le type avec tuple(x) ou list(x), ça change rien.

Conclusion: si on écrit la liste a la main dans le .comm ça passe, si on la crée iterativement avec Python ça coredump.

#14 Re: Code_Aster usage » Modélisation amortissement en DYNA_NON_LINE » 2012-06-14 10:51:02

As I understand the Alarm, the problem is that in nonlinear simulation the stiffness matrix will change due to nonlinearities. Therefore the linear combination of Rayleigh alpha*K+beta*M also changes and need to be re-evaluated every step. At the global scale, for whatever reason, this is disabled in DYNA_NON_LINE. At the local scale, this is available via the AMOR_ALPHA and AMOR_BETA keywords in the material definition.
Wild guess:
The global scale path is as follow: compute the local stiffness and mass matrices of the elements, assemble everything to get the global K and M, and then compute C as a linear combination of those two (huge) matrices. Yet this last step is easily and efficiently performed using the blas/lapack math library, which  use the latest available CPU instructions to vectorize the operation, at least if the library if optimized.
The local path, on the other hand, needs to perform the linear combination per element, as the local stiffness matrix can vary. Then and only then does it assemble K, M, and also C (A in Code_Aster notation). However these operations are not easily optimized and consume more CPU. Therefore the alarm.
That does not answer the question though, sorry. But I'm curious to see if my guess is right. In this case indeed the Alarm may be overalarming for the user provided a heavy nonlinear model and therefore some time-consuming behavior law integration. But is it always the case? Remember Code_Aster is a fairly general FE code.

#15 Re: Code_Aster usage » [SOLVED] "No Nodes in MED mesh" (gmsh post-processor) » 2012-05-21 04:48:42

Note that the last version of gmsh as found in Ubuntu Precise Pangolin (12.04) and later or Debian testing/sid is compiled against MED 3.0.3, so no need for a nightly build anymore.

#16 Re: Code_Aster usage » generation of artificial accelerograms » 2011-10-05 11:48:39

boyere wrote:

The advantage of a Response Spectrum is that the statistical nature of the earthquake is already taken into account in its definition.

No, it is not. The spectrum itself, be it from a natural event, synthetic, and/or from design codes, does not account for future events (which are unpredictable -- otherwise Japan wouldn't be in such a distress), and may be (e.g. in design codes) an envelope.
I would say that in either case the response spectrum as well as the accelerogram are both random by nature, and numerous studies exist on the challenging topic of modeling earthquake signals, none of them being AFAIK acknowledge to be the "best" one.
Using either of those depends mainly of what type of simulation you want to achieve and what kind of result you are looking for about your structure.

An interesting reference, the PhD thesis of Guillaume Pousse (mainly in French, with a bit of English):
* Pousse G., Analyse de données accélérométriques de K-net et Kik-net: implications pour la prédiction du mouvement sismique- et la prise en compte des effets de site non-linéaire, Thèse, Université J. Fourier, Grenoble, 257 p., (2005).

#17 Re: Code_Aster usage » generation of artificial accelerograms » 2011-10-04 08:38:13

TEOL11 wrote:

Hello,

I wonder if there exists in code aster a command to synthesize an accelerogram (time history) from a pseudo-acceleration spectrum.

thank you for any info

No, and the reason is there is an infinity of accelerograms corresponding to a single pseudo-acceleration spectrum.
Some methods exist though (one was proposed above), but none can ensure you that the generated accelerogram will cover "all" loading cases.
They can (at least most of them) only ensure you that the generated accelerogram's spectrum will match the target input spectrum.
Indeed as you (may) know the "shape" of the accelerogram has an effect on structures, and similar accelerograms may be more or less severe to a same structure.
If you need to cover "all" possible cases of loadings (I mean a significant part) then you need either a parametric study with a recommanded value of n >= 30 accelerograms (can't remember the exact reference here sorry), or use a probabilistic modelling of the input loading. In either case this is a long and complex process though.
To conclude, from the engineering point of view, these methods are not applicable (for evident reasons of time and complexity), and one often simply generate one or a few synthetic accelerograms based on a summation of hundreds of sinusoidal signals with pseudo-random frequency and amplitude. The accelerogram is then modified to match the target spectrum. This is not a precise definition but you can get the idea. Unfortunately I do not know the implementation details of such method.

PS: I'm sorry if this response is not quite accurate in a scientific/mathematical point of view (e.g. "all", "shape", ...) but this is more to get the general concept rather than to give a proof.

#18 Re: Code_Aster usage » Exception JEVEUX1_33 répertoire des noms saturé = ??? » 2011-09-30 15:13:42

Merci, j'ai bien compris votre raisonnement, mais sur le coup je ne suis pas le responsable, c'est Cast3m et son format MGIB qui sont déficients.
Je DOIS avoir des mailles confondues supportées par les mêmes noeuds, or le format MGIB ne permet pas ça.
Donc je visualise bien mes mailles séparées dans Cast3m, mais à la sortie cette information est perdue. Je suis donc bloqué.
Je cherche une autre alternative donc, peut-etre via d'autres formats de sortie de maillage (Abaqus/AVS?), pour le transfert Cast3m => Code_Aster.
Salutations,
Jérôme

#19 Re: Code_Aster usage » Exception JEVEUX1_33 répertoire des noms saturé = ??? » 2011-09-29 16:06:50

Bien, merci pour cette réponse claire et structurée.
Je pense effectivement qu'il y a un soucis niveau communication sur le site, en particulier au niveau des pages de téléchargement et de documentation. Pourquoi ne pas faire carrément sur le modèle des distributions Debian et Ubuntu des alias "stable" et "unstable" (ou "testing", ou "development") pour les versions et les appeler comme ça en particulier sur les pages du site en question? Autre exemple l'URL de la doc v11 (http://www.code-aster.org/V2/doc/default/fr/) contient "default", ce qui est assez troublant quand on sait qu'un utilisateur lambda devrait plutôt s'orienter par défaut sur la v10 qui est la version stable. Pourquoi pas http://www.code-aster.org/V2/doc/stable/fr/ avec un lien vers la doc de la version stable (actuellement la v10) et http://www.code-aster.org/V2/doc/dev/fr/ avec un lien vers la doc de la version de dev (actuellement la v11)? Ce serait infiniment plus clair à mon sens. Pareil pour la page de téléchargement à bien scinder entre la version stable et la version de dev, cette dernière ne devant pas être facilement visible (elle ne concerne pas tant de gens que ça après tout, si?). Après c'est mon opinion, vous en faites ce que vous voulez.

Christophe Durand wrote:

Ah, j'oubliais !

Si Code_Aster devait être un outil important pour le L3SR et ses partenaires, pourquoi ne pas adhérer au réseau Pronet ? Le forum est certes un outil précieux de structuration de la communauté. Mais les discussions - quand elles relèvent comme ici de la politique de code (et de sa diffusion) et non de simple assistance - seraient mieux traitées dans ce cadre d'échanges entre institutionnels.

Je vais faire remonter l'info, merci.

Sinon pour en revenir au bug sur le répertoire des noms, je l'ai reproduit en version 10.3 (la stable téléchargée ce matin sur le site), et également avec/sans surcharge, et avec une compilation du maillage avec le Cast3m 2011 officiel ou avec le gibi.x intégré à Code_Aster. Dans tous les cas ça plante strictement pareil.

#20 Re: Code_Aster usage » Exception JEVEUX1_33 répertoire des noms saturé = ??? » 2011-09-29 12:49:44

Réponse hors sujet. Je développe depuis 20 ans, et suis sous Debian depuis 10 ans, je sais ce qu'est une version stable et unstable, ce n'est pas la question. Encore heureux que Code_Aster évolue. Je ne parle pas du fait qu'il y ait une version stable et unstable, ça c'est normal. Par contre que je sois amené à modifier plusieurs fois mes .comm sur 4 ans d'utilisation, là je trouve que ça l'est moins. Vous vous imaginez formater vos machines et réinstaller Ubuntu tous les 6 mois parce que la version 11.10 est pas compatible avec la version 11.4?

#21 Re: Code_Aster usage » Exception JEVEUX1_33 répertoire des noms saturé = ??? » 2011-09-29 10:39:06

Bonjour,

Merci pour cette réponse éclairée.
Une petite suggestion : je pense que si vous avez le temps, pas mal de ces infos auraient leur place en page de téléchargement par exemple, plutôt qu'au fond du forum.

Thomas DE SOZA wrote:
humbert wrote:

En attendant je fais comment?

Pas de contournement identifié à ce jour mais le bug devrait être corrigé rapidement, ça a pas l'air trop méchant.

Update via as_run --auto_update? Je vais regarder ça, mais j'ai un délai assez serré pour faire le calcul en question.

Thomas DE SOZA wrote:

Le plus simple : lorsqu'une vraie version stable est disponible sur le site (par exemple la future 11.1 à la fin de l'année) se contenter de celle là et ne pas faire de mises à jour. La doc U4 pour cette version sera dispo via Eficas, la doc en ligne continuant d'évoluer, c'est donc un petit peu gênant mais acceptable à mon sens.

C'est ce que je faisais jusqu'au paquet v11...

Thomas DE SOZA wrote:

Je vous renvois vers ce post en anglais qui explique la situation (en particulier pourquoi on a fait une exception et sorti une version packagée non stable) : http://www.code-aster.org/forum2/viewto … 720#p29720

Thomas DE SOZA wrote:
humbert wrote:

PS: Aucun reproche ou intention d'agressivité dans ce message, juste une demande d'éclaircissement et de conseil. Je précise, on ne sait jamais...

OK. Bien que comprenant votre position on ne peut pas répondre plus à des plaintes ou autres râleries venant du forum, on n'est pas payé pour ça !

TdS

Oui, je sais bien, et je précise d'avance que la réponse ci-après n'a rien de personnel envers vous TdS, mais il faudrait prendre conscience (probablement pas à votre niveau mais peut-être un peu plus haut chez EDF, vous pourrez leur faire passer le message) que faire de l'open source permet certes d'avoir des retours et bug reports "gratuits", mais sous réserve que les utilisateurs jouent le jeu. Et pour qu'ils jouent le jeu il faut avoir un minimum de respect envers eux, c'est à dire pas changer d'avis tous les 4 matins, par exemple comme le font remarquer d'autres utilisateurs sur votre lien en supprimant la rétro-compatibilité d'une version sur l'autre, ce qui en plus est aberrant vu que ça coûte pas grand chose de la laisser (et d'ailleurs même remarque pour Salomé). Là honnêtement tant en tant que développeur par ailleurs sur d'autres projets qu'en tant qu'utilisateur de Code_Aster je trouve que ça fait pas très sérieux. A mon humble avis vous vous tirez une balle dans le pied avec ce genre de pratique. Et pour tout dire malgré le fait que je défende d'habitude plutôt Code_Aster par rapport à d'autres codes EF, je commence à plus vraiment avoir envie de le conseiller à quiconque vu le temps que j'ai passé dans les 4 dernières années à faire des mise-à-jour de mes fichiers comm pour faire tourner exactement le même calcul. Enfin, pour rappel moi non plus, je suis pas payé pour préparer à EDF des fichiers de commande et maillage pour les bug report pour qu'il puisse corriger son code. Et pourtant je le fais. Donc ce genre d'argument est un peu facile il me semble, et n'est en tout cas pas du tout dans la philosophie de l'open source.

Salutations,

Jérôme Humbert

#22 Re: Code_Aster usage » Python Code in *.comm - full Python possible? » 2011-09-29 09:16:43

mattia wrote:
humbert wrote:

Try also using Python arrays to store Code_Aster concepts created by commands (e.g. "a[5] = DEFI_LIST_INST(...)") and you will end up with a variable (here "a_5") being defined automatically. And since concept names are limited to 8 characters (variable names in real Python are not limited in length) then your array name is here limited to 6 characters only (+ 1 for '_' and 1 for the index '5' = 8 characters in total).

Hi humbert,

do you mean that I can't create a Python array with data calculated with Code_Aster? That would be a big problem for me, since it is actually what I was planning to do!

Mattia

No, I mean that your array must have a very short name (5~6 characters) because the number of digits of the index of your array will be counted in the 8-character limit of Code_Aster for names of concepts. For example if you have an array of 50 elements then each item in the array will be refered to in Python as "arrayname[index]" but will internally to Code_Aster be refered to as "arrayname_index", which must have a length <= 8 character. In this case if index <= 50 then you must have length(arrayname) <= 5 characters.
Note however that if the items of your array do not hold a Code_Aster concept (as returned by e.g. DEFI_xxx functions) then the array is a regular Python array with regular items, and without this limitation.

For short:

mylongarrayname[25] = DEFI_xxx()   # FAIL: "mylongarrayname_25 = DEFI_xxx()"

res[25] = DEFI_xxx()               # OK  : "res_25 = DEFI_xxx()"

#23 Re: Code_Aster usage » Exception JEVEUX1_33 répertoire des noms saturé = ??? » 2011-09-28 12:59:22

Bonjour,

Merci de votre suivi et bon courage pour le bug.

En attendant je fais comment?
Je m'explique: j'ai téléchargé la version 11 en pensant que c'était la version stable, trompé par le fait que :
1) ce n'était pas précisé dans le tableau avec les liens de téléchargement, seulement dans le texte en dessous que je ne lis plus trop vu que c'est environ la 5ième version que j'installe et qu'il me semblait de plus (mais je peux me tromper) que seules les versions stables étaient packagées et que les versions de dev étaient seulement accessibles via une mise à jour avec ASTK; et
2) la documentation de la version 10 a disparu du site, ce qui laisse à penser que la version 11 est la version préférentielle pour les nouveaux utilisateurs et donc probablement stable. (EDIT: Je viens de voir que la doc v10 a remplacé la doc v9)
On se retrouve ainsi si j'ai bien suivi avec une version stable 9.x (trop ancienne et trop différente des 10.x) et une version 11.0 en dev seulement, et de surcroît avec une documentation v11 qui n'est même pas toujours en accord avec le code (cf. DEFI_LIST_INST par exemple) ce qui n'est pas choquant pour une version de dev mais fort peu pratique niveau utilisation quotidienne pour une application non développement.
Donc si quelqu'un pouvait m'indiquer la marche à suivre (au moins dans l'esprit) pour avoir à ce jour une version stable en accord avec la politique de développement d'EDF R&D, je lui en serait reconnaissant. J'avoue avoir un peu de mal à suivre dernièrement, et autant je peux éventuellement me permettre de changer pas trop difficilement de version, autant les partenaires de projet derrière moi sont beaucoup plus retissant, ce qui ne facilite pas l'échange des fichiers (en particulier .comm) qui ne sont pas compatibles entre versions.

Merci d'avance pour vos explications et conseils,
Sincères salutations,

Jérôme

PS: Aucun reproche ou intention d'agressivité dans ce message, juste une demande d'éclaircissement et de conseil. Je précise, on ne sait jamais...

#24 Re: Code_Aster usage » Exception JEVEUX1_33 répertoire des noms saturé = ??? » 2011-09-27 16:42:52

Bonjour,

C'était le maillage qui était prévu (mgib) pas le mess, mais je me suis trompé en allant trop vite.
Ci-joint le maillage.

Merci d'avance
Jérôme

#25 Re: Code_Aster usage » Exception JEVEUX1_33 répertoire des noms saturé = ??? » 2011-09-27 10:33:37

Bonjour,

Merci pour votre réactivité. Voici ci-joint le modèle en question.
Le calcul est lancé sur une Ubuntu 10.04 en 32bits, Code_Aster version 11.00.10

D'avance merci,
Jérôme