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

You are not logged in.

#1 Re: Code_Aster usage » How to add a time dependent force » 2021-05-31 15:48:10

The problem is accessing the time list during non-linear computation. You can either interrupt the computation when a division of timesteps occours, read out the time list with the help of the aster-python API, but this is quite tedious.

But since you chose division of intervals with a fixed factor, it is actually quite easy for you to extrapolate the current list from the current time. E.g. if you start with timesteps 0,1,2,3, and your function recieves the time 1.25 you KNOW that now aster divided the interval [1,2] by four subparts, and you also logged all the previous steps. So it is easy for you to reconstruct the current timesteps of the list.

Maybe there is a more elegant way to do this, but this is the first I would think on the top of my head.

#2 Re: Code_Aster usage » How to add a time dependent force » 2021-05-26 09:24:31

Hanbin wrote:


I am trying to add a force changing with the time steps.I hope that the external force will update with time steps ,If this can be done?  The time step here includes the time step that is automatically cut when calculated. If there are ways to do this job? For example, F1 at 0s , F2 at 0.2s , If the time is automatically cut into 0, 0.1, 0.2 ,then F2 will be added at 0.1s but not 0.2s.

Have you considered the usage of Python classes?
Contrary to simple Python functions, classes allow you to store values inside of them
and use those values for latercomputations.


class demo:
  def __init__(self, init_val):
    self.times = [init_val]
  def demo_func(self,t,x,y,z):
    # compute stuff and use the last time value from previous computation
    compute_val = t*x*y*z + self.times[-1]
    # update val
    self.times +=[t]
    return compute_val

d = demo(0)
func_to_use = d.demo_func

#3 Code_Aster development » Packing Aster with Flatpak » 2018-01-09 16:27:18

Replies: 1

Good new year everyone!

As pointed out in code-aster.org/forum2/viewtopic.php?pid=49918#p49918 I will switch from rpm to flatpak
for several reasons:

  • It's not distro dependend (works on Debian or Ubuntu too)

  • Unlike docker it should work fine with multiprocessors

  • Because of the sdk system it is possible to predefine a closed clearly defined sandboxed environment which only has to be built once

  • No dependency hell

From this perspective the code_aster team should considering going on flatpak on the long run too:
Although there is some initial work involved by providing flatpaks+sdk it would be lifting a lot
of development work off the shoulder since the flatpak is builded in a sandbox which can be distributed
equally on all distros, which allows to

  • Avoid conflicting libs since completely contained in save environment

  • Provide better user experience by avoiding cumbersome installation procedures

I don't know when precisely I will invest more time into this work, since I'm currently switching jobs
(I'm going more into academics again and do more stuff regarding automation not so much in FEA)
but if no one else is gonna do it I will, since I want to get deeper into container technology and aster is a good starting point for experiments
+ I want to use it in future too for numerical experiments  (but not so intense anymore as done till now)

I hope that the code_aster dev team give this some consideration, since it could also change the distribution of Salome(Meca)
in a far easier way and provide better focus on core development than squishing bugs regarding concurrent or outdated libs.


#4 Re: Code_Aster usage » RAM usage in Code Aster » 2017-09-11 09:01:58

rupole1185 wrote:

I use a volume mesh with TETRA10 elements (second order). I made several tests for various mesh dimensions (from 0.1M to 3.5M elements), but the problem is the RAM required to run the simulation. I have 60GB available, and already all of them have been used when the mesh reaches 1M elements .. now I am not an expert, but the RAM used by the solver is more than 600 times the mesh dimension.

... which isn't unsurprising when using direct solvers, since in general if one makes an LU decomposition of a sparse matrix, the LU matrices can be indeed dense, and memory needed scales to the power of 2.

First of all you should check the number of DOFS. This is roughly the number of nodes x 3. It is a far better number for comparison than the number of elements, since it determines the size of the linear systems which have to be solved.

When you have to deal with large models with no contacts you should resort to an iterative solver like PETSC or the default GCPC, since those only use the system matrix for iterations and hence memory scales only linearly, which means you need roughly 1GB per Million DOF.
For an direct solver like mumps this would be a much higher number.

#5 Re: Salome-Meca installation » [SOLVED] Installer doesn't find libs and path » 2017-09-06 11:18:21

Hi Thomas!

Thanks for the quick fix, it worked like a charm!

#6 Salome-Meca installation » [SOLVED] Installer doesn't find libs and path » 2017-09-04 08:14:10

Replies: 2

Hi everyone!

I tried to install the new SalomeMeca2017, but I run into strange troubles during installation, during the post_install script:

Creating salome_meca application in /home/reiterest/Salome_Meca/salome_meca2017/appli_V2017 ...
salome_meca post-installation ...
python: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory
Warning: the directory /home/reiterest/bin is in a path variable but does not exist
Warning: the directory /home/reiterest/bin is in a path variable but does not exist
Warning: the directory /home/reiterest/.cabal/bin is in a path variable but does not exist
Warning: the directory /home/reiterest/bin is in a path variable but does not exist
Warning: the directory /home/reiterest/.cabal/bin is in a path variable but does not exist
python: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory
The salome_meca application was successfully created.
To run the application:

It says successfull but there is no executable in apply. It seems something is wrong with the path variables.

#7 Re: Code_Aster usage » Export a mesh group in DAT format thanks to Python » 2017-09-01 11:28:30

Easy answer: Don't save it as tmpfile, but use a regular filename

#8 Re: Code_Aster usage » Modelling of Hail damaged Car Body Panels » 2017-08-30 19:38:18

Hint for meshing: Instead of meshing the solid take only the surface, mesh it with triangles/quadrangles, and then extrude the mesh (e.g. in Salome) this way you could easily build a solid with fewer elements, than by directly meshing, and the mesh only constists of prisms/hex elements.

#9 Re: Code_Aster usage » *SOLVED* Calculate the gradient of a variable ? » 2017-08-01 06:32:11

Have a look at CREA_CHAMP and Keywords AFFE btw. EVAL. With those you can create quite every field you want
EDIT: Here an example: code-aster.org/forum2/viewtopic.php?id=15015

For the differentation process you can use Python then. If you know the field analytically it's more easy. If not you have to use e.g. difference quotients.
Or CREATE a displacement field and use your method as always

#10 Re: Code_Aster usage » [SOLVED] How to get a FORC_NODA result from a K_TR_D_N element » 2017-07-11 06:34:49

Please someone correct me if I'm wrong, but this shouldn't come as a surprise since the forces shouldn't change, they are determined solely by the statics of the system. Have you also looked at the REAC_NODA field?

#11 Re: Code_Aster usage » modify a 3D-mesh to a 2D-mesh » 2017-07-06 08:08:54

Which mesh format are you using? With .med there are no 2D meshes, and aster accepts it if all coordinates of Z are 0. Normally AFFE_MODELE should take care of the rest.

#12 Re: Code_Aster usage » Dynamic analysis » 2017-06-21 14:00:10

I don't see why you shouldn't be able to do this, since you could define several CALC_CHAR_SEISM and then apply them to the DYNA_TRAN_MODAL.
In the manual you can either choose all (by MONO_APPUI) or selecting specific nodes with MODE_STAT. So you could define several CALC_CHAR_SEISM for different nodes, and provide the different functions of acceleration with FONC_MULT

#13 Re: Code_Aster installation » Compiling development version of Code_Aster » 2017-06-21 13:15:25

Had you already a look on the bitbucket wiki of Code_Aster: bitbucket.org/code_aster/codeaster-src/wiki/Home ?

there you find a tutorial how to make your own patches

#14 Re: Code_Aster installation » SUDO Installation » 2017-06-21 13:11:55

In CAE Linux it is possible. You may try adding the CAE Linux repo to your ubuntu installation

#15 Re: Code_Aster usage » Why HOMARD is not open source? » 2017-06-21 08:02:33

Msegade wrote:
reiteres wrote:

I just checked the Homepage of the Homard project. It seems that they changed their license just recently to LGPL
See: code-aster.org/outils/homard/en/index.html#licence

I think that referes to the salome module to link code aster with homard, but the software itself is proprietary:

I double checked the page refers to Homard, and the version which is in current aster full and salome is still version 11.7 (which has the free use with aster exclusively) while the documentation already refers to 11.8. So there is hope that the next release will be LGPL.

Of course an official statement would be better.

#17 Re: Code_Aster usage » What is the correct way to model contact with a fastener (preload) » 2017-06-20 09:29:52

As far as I know there is no straight forward way to apply a preload. The easist trick is to add a suitable beam Element and

1) Compute the resulting Force/Stress of the preload first. There are formulas for that,
2) Apply a temperature Load on the beam to simulate the tightening. To get the correct temperature
we use the Formulas

σ = E ϵ = α T,

and hence

T = E ϵ/α = σ/α

at least that's what I'm doing to perform a simple preloading.
Here is an old example how it can be done: code-aster.org/forum2/viewtopic.php?id=14375

#18 Re: Code_Aster usage » Why HOMARD is not open source? » 2017-06-20 09:07:00

I just checked the Homepage of the Homard project. It seems that they changed their license just recently to LGPL
See: code-aster.org/outils/homard/en/index.html#licence

#19 Re: Code_Aster usage » Erreur numérique(floating point exception) » 2017-06-10 21:08:43


I had a look at your .comm file. I tested it with 13.3. I encountered the same error.
For me just changing the solver from MULT_FRONT to MUMPS did the trick. I suppose there were several changes from 11.6 to earlier versions within the solvers.

#20 Re: Code_Aster usage » Units and precision in Code_Aster » 2017-05-05 15:52:38

I know these problems. I for myself solved this with my unit Calculator Module which can easily imported to aster (actually I invented it for this)
The module  takes human readable input e.g RHO=1.0*kg/m**3 and turns it into the correct unit system you are currently working with.
See: github.com/maldun/UnitCalculator

#21 Re: Code_Aster usage » Master Degree Of Freedom (MDOF) option like A***S » 2017-05-05 15:43:43

I don't think aster has this straightforward implemented. I added a relatively simple macro to realize this.
The trick is to create a discrete Element (I call it master) and use AFFE_CHAR_MECA with LIAISON_DDL to make all desired DOFs having the same value as those of the master. One can realize this simply by some for loops.

#22 Re: Code_Aster usage » [Solved]Get the object movement in Paravis » 2017-05-05 15:39:00

seasoulte wrote:

I have spent one week to learn code_aster and managed to get more and more knowledge of the workflow.

Basically I want to model a ball rebouncing when hitting a plane. After getting a rmed file and opened the file in Paravis, I could get the displacement, velocity and acceleration displayed in coloured objects. However, it is not moving as I expect.

To avoid asking this basic question without self search and learning, I also did an example in the CAELinux wiki (Sorry the forum does not allow to post a link, but I uploaded this example file), a swinging pendulum case. Again, in Paravis I did not get the  animation as expected.

Did I miss writing some infos in the result rmed file? Or some postprocessing is needed before the file is loaded into Paravis?

Thank you All.


Did you make a "deformed shape"-Filter of your Result after importing to paraview? Without this all fields are only displayed as colors on the mesh.

#23 Re: Code_Aster usage » Extract mode shapes to numpy array » 2017-04-11 14:29:04

Yes you can!

Have you already read the document about accessing aster objects with python?

There you find examples to extract dicts/lists. Those can immediately be converted to numpy arrays.

#24 Re: Code_Aster usage » Crack propagation, Failure under fatigue » 2017-04-11 14:05:53

Have you already looked into the training material:



#25 Re: Code_Aster development » Packaging Code_Aster for Fedora » 2017-03-05 18:35:39

hi all, and thank you for the input.

Development of a good packaging system is still under development, but I managed to build now a semi automatic building environment, to install aster packages under fedora. In the meantime I also builded some for centos too.

The reason why I invested a lot of time now, was to that I need aster in work and have apply patches/workarounds on a regular basis. This way I'm able to document these changes, and provide other users with the possibility to use these libs.

On my github account one can find the current build script, which have to be executed in the rpmbuild directory. In variables.sh folder structure and version numbers can be changed to adapt to new versions. The script download.sh downloads the aster-full package and some external libs like petsc.
An important prerequisite is the rpmbuild environment from fedora (or centos). A manual can be found here: https://fedoraproject.org/wiki/How_to_c … PM_package.

The order of execution should then be (and installing the resulting packages after execution):

  1. hdf5.sh

  2. metis.sh

  3. scotch.sh

  4. mumps-stable.sh

  5. mfront.sh

  6. frontend.sh

  7. aster.sh

  8. scalapack.sh

  9. mumps-stable-openmpi.sh

  10. petsc.sh

  11. aster_mpi.sh

for the stable sequential and mpi version of aster. The testing version is also contained.

Link can be found here: https://github.com/maldun/aster-for-fedora I encourage users to contribute. I plan to distribute the packages via github or bitbucket too, since they both now support git large fliesystem, so that hosting of the rpms gets reasonable.