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

You are not logged in.

#1 Re: Code_Aster usage » [SOLVED] Thermal analysis, sum of exchanged energy » 2021-09-08 11:31:40

mf

Hello,

heat flux can be calculated, but it is a bit tedious. In a previous thread I described what to do:

h_ttps://www.code-aster.org/forum2/viewtopic.php?id=24652

Mario.

#2 Re: Code_Aster usage » Paravis visualization error » 2021-08-31 07:51:31

mf

Hello,

I used your .hdf as it was. I did not change anything, I can confirm that I used the 0.5_0.1mm mesh that was set in Asterstudy (see screenshot).

For the run I set 65536Mb of memory (2048Mb was set in your file), I guess less would also be possible but I did not test that. I do not know about the Windows version, I stopped using Windows many years ago. Also, the Windows version is not as well backed by the community, that is at least my personal feeling. It is not maintained by EDF.

But: if your RAM was not enough, CA would tell you. First it would start calculating 'out_of_core' which means it would start writing to your disk (the simulation would slow down considerably depending on your drive speed). If that is not possible, it would stop (or crash, I have seen that also... :-( ).

Mario.

#3 Re: Code_Aster usage » Paravis visualization error » 2021-08-30 13:18:52

mf

Hello,

the mystery continues: I ran your file (in SM2020 on Linux with CA 14.6) and I do not see any kind of error in your result.

Please find a screenshot attached.

Mario.

#4 Re: Code_Aster usage » How to ramp loads BETWEEN loadsteps? » 2021-08-29 12:18:33

mf

Hello,

if you know your loads before the simulation, why don't you use one single FONC_MULT? Something like:

RAMP = DEFI_FONCTION(NOM_PARA='INST',
                     PROL_DROITE='CONSTANT', PROL_GAUCHE='CONSTANT',
                     VALE=(0.0,0.0,1.0,0.75,2.0,1.0,3.0,0.85,4.0,0.0,),)

I just guessed the factors by eye in your diagram, if you normalize all values to the second step (largest value), you'll get factors similar to this. You'll only need one single loadf (at least for loadf, I dont know if loadr is different. If so, you'd need a second RAMP2 for loadr) instead of many loadf(i).

I don't know if I am missing something, but that should work.

Mario.

#5 Re: Code_Aster usage » Paravis visualization error » 2021-08-27 20:00:02

mf

Hello,

my bad, I should have taken a closer look. I didn't mean t=0, I meant after opening the file and pressing 'Apply', 'Solid Color' should be visible automatically and the model should appear (standard color is white though, not yellow, but this can be changed in the preferences).

Obviously, this is not the case here. You have chosen a result, but, I suppose, 'Solid Color' is still active somehow (yellow is not part of the legend)? Additionally, data different from zero seems to be present, otherwise no data range would be visible (or something like 1e-38 to 1e-38 indicating all zeros). In your preferences under ParaVis-->ParaView Settings-->Color Palette-->Color used when solid... (first entry), which color is stored there? If it is this yellow, this would indicate your ParaVis is stuck in 'Solid Color' somehow.

Could you share your file, to replicate the behaviour on a different installation?

Mario.

#6 Re: Code_Aster usage » Paravis visualization error » 2021-08-25 10:23:42

mf

Hello,

I do not know about your initial conditions, but time is still set to t=0? Is your result empty perhaps?

Access violations are unusual, if graphics drivers are installed correctly,

Mario.

#7 Re: Code_Aster usage » Paravis visualization error » 2021-08-20 13:10:33

mf

Hello,

please show the whole screen,

thank you,

Mario.

#8 Re: Code_Aster usage » Oscillations in transient thermal results THER_NON_LIN » 2021-08-11 06:19:39

mf

Hello Rodrigo,

the timestep is also crucial, because the calculation itself is unstable. If Ansys does this automatically, then your two calculations are clearly not the same. Like miib suggests, a very fine timestep and some kind of automation with DEFI_LIST_INST will perhaps do this (you can also use DEFI_LIST_INST to 'observe' a result and cut the timestep although, at the moment, I cannot imagine how to do this in this case....).

Take a look at slide 9 of the before mentioned document (attached). I imagine Ansys does calculate the necessary timestep like in the 2nd formula, try it by hand for your example and see if you are close with your chosen timestep or not. If not, decrease the timestep. I once programmed a diffusion solver for a handheld device (forward difference solver), even in 1D it is similar, you have to choose your timestep wisely (=automatically :-) before the calculation...),

Mario.

EDIT: or try to find out the timestep in Ansys and use it in CA....if all fails..
EDIT2: in principle, you could also do an automated timestep with a little Python formula! :-)

#9 Re: Code_Aster usage » Convergence proplem with friction » 2021-08-05 22:35:21

mf

Hello,

this .comm runs, there might be better configurations, though. Convergence in the friction loops is still quite slow,

When bending occurs, you should use 2nd order elements,

Mario.

EDIT: The bad convergence from before occurs when the part snaps back, so another solution for better convergence would be to add small springs to dampen node vibrations/oscillations.

#10 Re: Code_Aster usage » [SOLVED] Increasing number of threads increases computational time » 2021-08-05 11:01:29

mf

Hello,

it also depends on the number of cores your CPU has. From what you write, I conclude, that your CPU doesn't have 16 cores (for such a CPU, 8 OpenMP-threads will give the best results).

Sequential Version: If your CPU has 8 cores set number of threads to 4 or leave the default setting (which should also start 4 OpenMP processes anyway during e.g. STAT_NON_LINE). Also, as Volker has written, turn HT off. This way, your computation will be less interrupted by other running processes (it will be a little slower with 'every-day'-tasks, however).

The CPU in the attached image has 10 cores so I would set it to 5.

With the MPI-version, it is a bit different, though,

Mario.

#11 Re: Code_Aster installation » CA 14.6 problem install whit OPENBLAS » 2021-07-30 09:09:26

mf

Hello,

I do not know the reason for your error, but Hitoricae uses OpenBLAS 0.2.20,

Mario.

#12 Re: Salome-Meca usage » SOLVED Exit Code » 2021-07-26 19:25:23

mf

Hello Roger,

I don't know the exact reason for your error but it was probably FORMULATION=DISCRETE in contact or a memory problem. Please find attached a working  .comm of your example. Here is what I changed:

1) inserted an ORIE_PEAU_3D. Sometimes normal vectors do not always point outwards, which is not good for contact. Your meshes are not very complicated, so it probably also works without it.
2) In DEFI_CONTACT I changed to FORMULATION=CONTINUE as your meshes are not highly compatible. Honestly: I never got DISCRETE to work, so I do not use it. Master = coarse mesh, slave = fine mesh, that was correct.
3) I use a DEFI_LIST_INST, almost always. With it you can sort of automatize if something goes wrong (not the case here). You had ten steps in your 'list' for the simulation time, in a well defined problem (which yours is, it is well defined!) you do not need as many steps, one is enough.
4) The CALC_CHAMP had a different name, give it the same name as the STAT_NON_LINE (or other analysis) or 'reuse input object' in Salome_Meca.

You used an elastic material for your 'concrete'. You are aware that Code_Aster has many very good 'beton' material models also?

Have a nice evening,

Mario.

#13 Re: Code_Aster usage » Mass linked to a rope (cable) » 2021-07-24 13:18:09

mf

Results of your example with extended time (until t=10) and above modification,

Mario.

#14 Re: Code_Aster usage » Mass linked to a rope (cable) » 2021-07-24 13:01:33

mf

Hello,

it is quite simple: you'll need two comportements like

resnonl = DYNA_NON_LINE(identifier='11:1',
                        CARA_ELEM=elemprop,
                        CHAM_MATER=fieldmat,
                        COMPORTEMENT=(_F(DEFORMATION='GROT_GDEP',
                                         GROUP_MA=('rope', ),
                                         RELATION='CABLE'),
                                      _F(DEFORMATION='GROT_GDEP',
                                         GROUP_MA=('mass', ),
                                         RELATION='ELAS')),
                        CONVERGENCE=_F(ITER_GLOB_MAXI=50),
                        EXCIT=(_F(CHARGE=fix),
                               _F(CHARGE=gravity),
                               _F(CHARGE=mass)),
                        INCREMENT=_F(LIST_INST=times),
                        MODELE=model,
                        SCHEMA_TEMPS=_F(FORMULATION='DEPLACEMENT',
                                        SCHEMA='HHT'))

Mario.

#15 Re: Salome-Meca usage » SOLVED Simple Contact » 2021-07-22 10:54:24

mf

One more thing: instead of using ASSE_MAILLAGE in Asterstudy (I also did this for a long time...) it is easier to Build a compound mesh in the mesh module. The result is more or less the same, but additionally you'll be able to click on your groups in Asterstudy instead of typing them in. With contact use 'Build Compound' like in the attached image (without 'Merge coincident nodes..', otherwise possibility of merging nodes in contact-->errors)
With build compound it is also easier to find errors in the mesh, e.g. if Asterstudy tells you N324543 is singular, you are easily able to find this node in the compound mesh in 'Mesh Information'.


Mario.

#16 Re: Salome-Meca usage » SOLVED Simple Contact » 2021-07-22 10:45:36

mf

Hello Roger,

your two bodies are hollow (only 2D surface meshes) and you assigned 3D elements to them, that doesn't work.

If this should be a contact between two 3D bodies, they'll need a 3D mesh (3D meshing of solids, not only 2D mesh of their faces).

Mario.

#17 Re: Code_Aster installation » Code_aster 15.4 MPI installation problem » 2021-07-22 09:02:52

mf

Hello,

if it is of any help: I think there is something wrong with your installation of PETSc. Did you follow the guide of Hitoricae (I saw a filename like in the description below)? I remember, there is a lot to edit when installing PETSc (see link below under PETSc).

I do not know if this

h_ttps://hitoricae.com/2020/10/31/code_aster-14-6-parallel-version-with-petsc/

is still usable with 15.4.

Do you have another (working) installation of an MPI-version? Might be better to start with a 'clean' system. I, personally, will wait for the full working package of 15.4 with all the correct prerequisites and try to build the MPI-version. Sadly, there is no support from EDF for people like you and me. Also, there are people making money with installations of the MPI-version, so it is very unlikely to get help.

Mario.

#18 Re: Code_Aster installation » Planned release date Code_Aster 15.3 (?) » 2021-07-16 17:48:19

mf

Thank you, I will wait for the full package.

Mario.

#19 Re: Code_Aster installation » Planned release date Code_Aster 15.3 (?) » 2021-07-16 13:43:34

mf

I am asking because I get suspicious traffic when I execute above command...

Mario.

#20 Re: Code_Aster installation » Planned release date Code_Aster 15.3 (?) » 2021-07-16 12:14:05

mf

Ok, thank you. I kept looking in

h_ttps://www.code-aster.org/V2/spip.php?article272

where nothing has changed since a long time...

Mario.


EDIT: So I have to do         hg clone h_ttp://hg.code.sf.net/p/codeaster/src codeaster-src               to get this version? I have no clue....:-)

#21 Code_Aster installation » Planned release date Code_Aster 15.3 (?) » 2021-07-16 08:42:54

mf
Replies: 5

Good morning,

is there a planned release date for the new stable version 15, which will possibly be 15.3?

Thank you,

Mario.

#22 Re: Code_Aster usage » [SOLVED] MACR_CARA_POUTRE to AFFE_CARA_ELEM » 2021-07-08 14:39:43

mf

Hello,

if you edit your first post, you are also able to edit the subject matter,

Mario.

#23 Re: Code_Aster installation » Buying a new computer / Choisir sa machine » 2021-07-08 08:50:10

mf

Hello,

only the MPI-version of CA is able to benefit from two CPUs,

Mario.

#24 Re: Code_Aster installation » Connecting MUMPS (Parallel) to Code_Aster » 2021-07-08 08:47:48

mf

Hello,

I was able to build CA 14.6 MPI (also with PETSc) by following this great description:

h_ttps://hitoricae.com/2020/10/31/code_aster-14-6-parallel-version-with-petsc/

There is a slight error in the end though. If I remember correctly, a '/' is missing in the line before '$ASTER_ROOT' (without the ' of course..):

$ ./waf configure --use-config-dir=$ASTER_ROOT/14.6/share/aster --use-config=Ubuntu_gnu_mpi --prefix=$ASTER_ROOT/PAR14.6MUPT

I followed the description EXACTLY (versions and order have to be exact...etc.), I also tried 20.04LTS, but couldn't install superlu correctly from the Ubuntu repos. Maybe this is possible with the now updated U20.04.

Hope it helps,

Mario.

#25 Re: Code_Aster usage » Support grid problem » 2021-07-01 16:31:00

mf

Hello,

I am only guessing here (the error is not clear to me), but 13 million degrees of freedom? If the simulation is with STAT_NON_LINE, do you have more than 512Gb of RAM :-) ?

Mario.