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

You are not logged in.

#1 Re: Code_Aster installation » CA 12.0 download? » 2013-07-10 11:25:23

AsterO'dactyle wrote:

Given the development cycle of two years, these two versions are identical, only the name changes.

Thanks for the information smile

Bye
Andrea

#2 Code_Aster installation » CA 12.0 download? » 2013-07-10 09:05:52

apalazzi
Replies: 5

Hi,

when the 12.0 package will be available for download? When I go to the download page http://www.code-aster.org/V2/spip.php?article272 both the stable and testing versions are pointing to 11.4.0.

Bye
Andrea

#3 Code_Aster development » [Debian package] MED, _USE_MED_SHORT_INT and 64bits » 2013-02-20 15:07:34

apalazzi
Replies: 1

Hi,

as of today, the 64bit packages for CA can't read MED files - see http://www.code-aster.org/forum2/viewto … 955#p31955 .

I wish you could fix it soon, since I think this is the only thing left before having a really usable code-aster package... Are you planning to fix this bug in the near future?

Bye
Andrea

#4 Code_Aster usage » extract a subset of the test cases » 2013-02-20 14:40:46

apalazzi
Replies: 1

Hi,

I know that I can extract a subset of the test cases with a specific command with as_run --list --all --command=the_command .

Is there something similar to extract a specific keyword, like " RENUM='METIS' " or " FORMAT='MED' "? I see the --filter option but I can't figure out how to use it...

Thanks
Andrea

#5 Re: Code_Aster installation » Why -fno-stack-protector ? » 2013-02-20 14:37:13

courtois wrote:

I'm surprising because a lot of C functions accept characters array passed from fortran with calculated length.
I think that it is what the smashing protection check (possible buffer overflows and stack attacks with bad calculated length).

Tell us if errors occur. It should!

I guess that this kind of option is required for a server application but Code_Aster is not.
And I read there are possible losts of performance...

MC

Hi,

the mumps04a is already rinning fine on my system with -fstack-protector; I'll run the liste_internet and see how it goes, however there will be a lot of failures due to the bug that prevents the loading of MED meshes, and the fact that METIS is disabled.

This option is not (yet) enforced, but is recommended for all packages; for now, since the package is still somewhat under development, I'm enabling it (and all the other hardening options) to see if at least it works; after that, when the package will be fairly usable, I hope to have some feedback from the users and see if there's need to tweak something to improve the performance.

Bye
Andrea

#6 Code_Aster development » Change the default renumerator (disabling METIS) » 2013-02-18 11:23:09

apalazzi
Replies: 1

Hi,

since METIS in Debian is in non-free and linking CA to it would push the package out of main, I'm going to disable METIS.
At this point it should be helpful to change the default renumerator from METIS to another of the avalable; to do this I just have to change all the lines in .capy files from DEFAUT="METIS" do  DEFAUT=some other renumerator an that's all, or there's some other things I have to do? And what about DEFAUT="AUTO" ?

Bye
Andrea

#7 Re: Code_Aster installation » Why -fno-stack-protector ? » 2013-02-18 10:35:27

courtois wrote:

Hi,

Yes, at least there *was* problem.
With this option enabled, it should fail very quickly if the problem still occurs.

MC

I've successfully solved a test case, so it seems that this problem doesn't occur any longer.

Bye
Andrea

#8 Code_Aster installation » Why -fno-stack-protector ? » 2013-02-16 20:25:48

apalazzi
Replies: 4

Hi,

I'm adding some flags to the compilation commands for security reasons (see http://wiki.debian.org/ReleaseGoals/Sec … BuildFlags for details) , and one of the added options is -fstack-protector.

Now, in the default config file there's the flag -fno-stack-protector "for gcc 4.x", why? Is there some problem when enabling -fstack-protector ?

Bye
Andrea

#9 Re: Code_Aster installation » GCC options and convergence issues » 2013-02-11 17:04:25

jphthierry wrote:
apalazzi wrote:

Which config.txt are you using? And the problem disappears when you add USE_OPENMP to the compiler defines?

I added the directive in the config_XX relevant files of the debian directory or in the config.txt file when compiling from source.

It seemed to do the trick for version 10.8.

JPhT

PS: I am still struggling when building 11.3 packages; I'll email you directly if you don't mind.

Sure, no problem. BTW there were some errors in the SVN files, now it should work - at least, it works on my pc. Also note that you need to update code-aster-run and code-aster-gui to the latest packaged version (1.11.0) otherwise it won't build.

Bye
Andrea

#10 Re: Code_Aster installation » GCC options and convergence issues » 2013-02-11 16:33:16

jphthierry wrote:

Hi,

I am running Linux Mint Debian Edition (equivalent to a Wheezy). I compiled code-aster (10.8) both from source and from debian packages (using the excellent work from Andrea Palazzi). I was facing convergence issues running some of my command files with THER_NON_LINE, STAT_NON_LINE and the MULT_FRONT solver (everything runs smoothly with the LDLT solver).

Replacing "-O2" by "-O" for gcc-4.6 in config.txt solved the issue. Any clue on what can happen or how I can investigate further? One important notice: code-aster dependencies are taken from debian packages; not the aster tarball.

Hi,

I think this can be related to the issue I had here: http://www.code-aster.org/forum2/viewtopic.php?id=17849 ; it seems a debian-specific issue, but I don't know exactly what could be the problem...

Sorry my big mistake: I added the USE_OPENMP directive to the list of gcc options; I did not change the optimization level (that was the second step planned).

Which config.txt are you using? And the problem disappears when you add USE_OPENMP to the compiler defines?

Bye
Andrea

#11 Code_Aster development » Debian package - patches & co » 2013-02-09 20:37:41

apalazzi
Replies: 0

Hi,

well, this is not strictly a development issue, however is somewhat related to it...

In the Debian package there are some patches done on various files: I've inherited from previous packagers and I'm still looking into it to see exactly what they do.

It would be good if those patches were incorporated in the main code: would you like to take a look at them? As far as I can see these are patches to make the package compliant with the Debian policy regarding paths etc; I think most of the patches can be applied in the standard versions without any harm for the end user; for the others, we can try to find a solution that could make everybody happy big_smile

You can see the patches here:
Code Aster: http://anonscm.debian.org/viewvc/debian … n/patches/
ASTK: http://anonscm.debian.org/viewvc/debian … n/patches/
eficas: http://anonscm.debian.org/viewvc/debian … n/patches/
metis-edf: http://anonscm.debian.org/viewvc/debian … n/patches/

Look in the file "series" to see which patch is really applied to the package.

Also, what's the preferred way for me (the package maintainer) to communicate with the developing team? The forum? Or private email?

Bye
Andrea

#12 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-14 10:08:12

Strictly regarding the problem, I've used LIAISON_OBLIQUE instead of DDL_POUTRE and sligtly different BCs; now the result looks much better - see attached image.

However the original question is still there: what's the meaning of "on n'a pas trouve la maille" ? And also, why I get this error when I try to impose this condition on a note supporting more than a beam?

Bye
Andrea

#13 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 19:24:03

Anyway, can someone tell why I'm getting the message "on n'a pas trouve la maille" and what is this error?

Bye
Andrea

#14 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 19:18:23

Tomorrow I'll do some more testing and see if I can get a result I can trust... I'm starting to think that this is somehow related to the problem I had here: http://www.code-aster.org/forum2/viewtopic.php?id=17849 . Maybe I'll also try with a CAELINUX run, and see what I get.

And yes, it's a cable car.

Thanks
Andrea

#15 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 15:08:39

I'm doing some other testing with DDL_POUTRE, and it confirms this "unexpected" (by me) behavior: imposing this other BC on node "fune_t", the solution doesn't seem tobe affected by ANGL_VRIL

T_FUNE=AFFE_CHAR_MECA(MODELE=MODMECA,
                      DDL_POUTRE=_F(GROUP_NO='t_fune',
                                    DY=0.,
                                    ANGL_VRIL=(180-alpha),
                                    ),
                      )

Attached are all the files necessary to run the case... maybe it's a bug in CA?

Bye
Andrea

#16 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 15:02:09

jeanpierreaubry wrote:

in the picture reaction vectors look like oriented in z direction, dont they?
is not it what expected?

Doesn't DDL_POUTRE impose condition on the local directions? If so, in this case I would expect no reaction in the local x direction "from left to right", so to say; in the presented picture, the reaction should be orthogonal to the beam, that is in the local z direction.

Or am I wrong? It's friday and I'm a bit tired, I might be doing some fundamental error somewhere...

Bye
Andrea

#17 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 14:11:00

Johannes_ACKVA wrote:

Why are You surprised? It is normal that at a node which has an enforced displacement a reaction force must exist.
(The values in REAC_NODA are referred the global coordinate system, so they will differ from the values specified in DDL_POUTRE)

Unless I'm making a big mistake, the BC I specified should block only movement along local y and z direction, leaving free movement along the x direction:

APP_T_1=AFFE_CHAR_MECA(MODELE=MODMECA,
                       DDL_POUTRE=(_F(GROUP_NO=('a_porta1',
                                              ),
                                    DY=0.,
                                    DZ=0.,
                                    GROUP_MA='dir_pou1',
                                    VECT_Y=(0,1,0),
                                    ),
                                 ),
                     )

So, I would expect no reaction in the local x and some reaction in y and z, but that's not the case - see picture attached, representing the zone. The interested nodes are the two at the extremity.

Bye
Andrea

#18 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 13:20:27

I'm attaching an updated .comm file, the previous one had some minor errors in it. Here I've removed the DDL_POUTRE for the nodes supporting more than a single beam, and I've also reduced the load magnitude to 10% (with FONC_MULT=LOADRAMP) otherwise it didn't converge.

However there's a thing unexpected: how does it comes that there's a component of REAC_NODA on the nodes affected by DDL_POUTRE in the local x direction?

Andrea

#19 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 11:56:51

jeanpierreaubry wrote:

if i understand well the doc
you must specify
-one single node with its DDL definition
-one element (MAILLE) if the node belongs to several elements
-the local axis

Update: I've setup 4 BCs, one for each node, and now the first one (on a node belonging to a single beam) works, but the second (on a node belonging to two beams) still fails with the same error.

Any idea?

Bye
Andrea

#20 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 11:38:42

jeanpierreaubry wrote:

if i understand well the doc
you must specify
-one single node with its DDL definition
-one element (MAILLE) if the node belongs to several elements
-the local axis

Thanks for the hint, it wasn't very clear in the documentation and the error message didn't help either.

for the developers: maybe it would be better if CA would raise an error when GROUP_NO contains more than a single node?

Bye
Andrea

#21 Re: Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 11:02:34

jeanpierreaubry wrote:

hello

apalazzi wrote:

In the .mess file it can be seen that the GROUP_MA='dir_pou' has one SEG2 element, so I can't figure out what's the problem
Andrea

but it looks like 'a_portan' contains four nodes!

jean pierre aubry

Yes, all the four nodes have the same behavior; on the other hand, in GROUP_MA must contain a single element.
Do I need to specify a DDL_POUTRE for each node?

Bye
Andrea

#22 Code_Aster usage » DDL_POUTRE: on n'a pas trouve la maille » 2013-01-11 10:27:01

apalazzi
Replies: 17

Hi,

I'm modeling a problem where I want a part of the structure to be able to translate along its local x axis; for this I've used DDL_POUTRE like this:

APP_T=AFFE_CHAR_MECA(MODELE=MODMECA,
                     DDL_POUTRE=(_F(GROUP_NO=('a_portan',
                                              ),
                                    DY=0,
                                    DZ=0,
                                    GROUP_MA='dir_pou',
                                    VECT_Y=(0,1,0),
                                    ),
                                 ),
                     )

The part that should have this boundary condition is made of 4 aligned beams, and all the nodes except the central should be able to translate along the x axis (the central node is free); however I get this error, and I can't find in the documentation the meaning of it:

   APP_T=AFFE_CHAR_MECA(INFO=1,
                       VERI_NORM='OUI',
                       DDL_POUTRE=_F(VECT_Y=(0,1,0,),
                                     GROUP_NO=('a_portan',),
                                     GROUP_MA='dir_pou',
                                     DZ=0,
                                     DY=0),
                       LIAISON_XFEM='NON',
                       MODELE=MODMECA,
                       );

   
   !-----------------------------!
   ! <EXCEPTION> <MODELISA5_34>  !
   !                             !
   ! on n'a pas trouve la maille !
   !-----------------------------!

In the .mess file it can be seen that the GROUP_MA='dir_pou' has one SEG2 element, so I can't figure out what's the problem here...

Bye
Andrea

#23 Code_Aster usage » find the equilibrium position of an underconstrained body » 2013-01-07 11:50:58

apalazzi
Replies: 2

Hi,

is there a way with code-aster to find the equilibrium position of a body under a number of forces that has some degrees of freedom?
More precisely, I have a model that has a rotational DOF, one of the charges is the self weight (PESANTEUR) an I also have another vertical load, and those two will become at equilibrium at a certain rotation.

I'm looking ad DYNA_LINE_TRAN, is it the right command? Otherwise I could add some "virtual" constraint imposing a displacement on a node, and iterate until the REAC_NODA in this point is null, but I'd rather use a native command, if available.

Bye
Andrea

#24 Re: Code_Aster installation » happy new year to all, and what about gcc 4.7? » 2013-01-03 23:20:48

Hi,

I've just run the short test suite with 11.3/gcc-4.7 and it seems to work; I didn't examine the errors and abormal aborts, but I think that there should be NOOK results or hangs if there were problems, no?

PS: I've added the compile option -fno-tree-dse that worked with gcc-4.6 but not with gcc-4.7; setup.py warned me about the problem anyway, but it seems to run fine.

Bye
Andrea

forma12a     (1/42)     OK                    26.66     0.80    27.46    28.15
forma03c     (2/42)     OK                    48.64     1.13    49.77    50.79
forma01c     (4/42)     OK                     5.42     2.20     7.62     8.22
forma12b     (3/42)     OK                    94.32     4.02    98.34    99.41
forma01a     (6/42)     OK                     2.80     1.00     3.80     4.37
forma06a     (7/42)     OK                    11.96     1.61    13.57    14.61
forma02b     (5/42)     OK                   129.86     6.49   136.35   139.25
forma11b     (9/42)     <F>_ABNORMAL_ABORT    11.09     1.28    12.37    13.73
forma08a     (10/42)    <F>_ABNORMAL_ABORT     5.64     1.53     7.17     8.09
forma05a     (11/42)    OK                     5.56     1.21     6.77     7.68
forma07a     (12/42)    OK                    31.26     1.37    32.63    33.89
forma30b     (13/42)    <S>_ERROR              5.80     1.13     6.93     7.48
forma21b     (14/42)    <A>_ALARM             37.17     1.89    39.06    42.94
forma12e     (8/42)     OK                   234.07     6.84   240.91   243.68
forma08b     (16/42)    <F>_ABNORMAL_ABORT    16.58     1.39    17.97    18.82
forma10b     (17/42)    <S>_ERROR              1.91     1.07     2.98     3.87
forma04b     (15/42)    OK                    69.32     1.85    71.17    73.93
forma02d     (18/42)    OK                    16.96     1.18    18.14    19.22
forma04c     (19/42)    OK                    41.77     1.15    42.92    43.33
forma02a     (21/42)    OK                    24.36     0.76    25.12    26.11
forma03b     (20/42)    OK                    52.82     2.56    55.38    58.22
forma02c     (23/42)    OK                     3.11     1.98     5.09     5.35
forma21a     (22/42)    <A>_ALARM             29.25     1.31    30.56    36.29
forma41a     (24/42)    OK                    67.02     2.59    69.61    70.35
forma10a     (26/42)    <S>_ERROR              1.98     0.62     2.60     3.46
forma12d     (27/42)    OK                    34.39     1.34    35.73    37.22
forma03d     (28/42)    <S>_ERROR             35.73     2.20    37.93    39.45
forma40a     (29/42)    OK                    63.18     2.12    65.30    66.62
forma20a     (30/42)    <A>_ALARM             25.45     1.61    27.06    29.91
forma11c     (25/42)    <A>_ALARM            742.96     6.88   749.84   756.48
forma41b     (31/42)    <S>_CPU_LIMIT        608.38     7.43   615.81   620.65
forma12c     (33/42)    OK                    28.25     1.44    29.69    31.49
forma20b     (34/42)    <A>_ALARM             39.87     2.31    42.18    45.51
forma01b     (35/42)    OK                     3.97     1.73     5.70     6.84
forma30a     (36/42)    OK                     3.55     1.84     5.39     6.56
forma20c     (37/42)    <A>_ALARM             11.72     2.26    13.98    15.92
forma11a     (38/42)    OK                     8.86     1.98    10.84    12.24
forma07b     (32/42)    OK                   372.40     6.82   379.22   388.69
forma40b     (39/42)    OK                     7.67     1.84     9.51    10.37
forma11d     (40/42)    OK                    54.48     1.89    56.37    59.84
forma04a     (41/42)    OK                    28.43     0.99    29.42    30.46
forma03a     (42/42)    OK                     4.18     1.36     5.54     6.70

#25 Re: Code_Aster installation » happy new year to all, and what about gcc 4.7? » 2013-01-03 13:28:16

Happy new year big_smile

I haven't yet tested it personally, but the current testing version should be ok with gcc-4.7; so I think the next stable will also build correctly with it.

Bye
Andrea