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

You are not logged in.

#1 Re: Salome-Meca usage » Creation of Hexa mesh on 3D CAD geometry » 2021-11-04 09:09:37

Hi mihe,

I have no experience nor a price quote, but from the documentation: docs.salome-platform.org/9/gui/GHS3DPRLPLUGIN/ghs3dprl_hypo_page.html Distene is no more and it is now part of Dassault (click on the link). Regarding the price, it is "Request an evaluation" level of expensive... Though I suppose you could get a temporary license to play with if you ask their PR team. It may be worth it if you need it or if it saves you time (both meshing or simulating).


#2 Re: Salome-Meca usage » Creation of Hexa mesh on 3D CAD geometry » 2021-10-30 21:46:42

Hi mihe and Claws,

I mostly use Hexahedron (i,j,k) for Hexa meshes. It is very sensible to how the geometry is designed, so most of the time, you have to partition your geometry in a way that it will comply with the requirements. Some documentation is here: docs.salome-platform.org/latest/gui/SMESH/basic_meshing_algos.html#basic-meshing-algos-page

Of course, you probably already know this. However, for the 2D algorithm, I prefer to use Quadrangle: Mapping, since I have gotten really good results with it. It generates nice quads at the surface.

I would like to point out that a good control of the 1D hypothesis is also needed for complex geometries. Salome, sadly or luckily requires/gives a lot of control in that regard.

Personally, I tend to find myself using quite a few partitions on my geometry with another few geometry groups to get a nice and clean Hex mesh in relatively simple geometry. For very complex geometries, I would expect the partitioning technique to work, but it would not scale nicely (although it could be scripted maybe).

Once again, you probably already knew this.

GMSH is also quite powerful, and when configured correctly, it can generate relatively good geometry. But it is a large beast and requires some getting used to.
There are the tools provided by OpenFOAM, but those are truly a beast on their own.
There is cfMesh www. sourceforge.net/projects/cfmesh/ and even-though it is mostly designed for CFD, it can generate pretty clean geometry for very complex meshes. Do not mistake it with CF-MESH+ which is not open.
This is related to the question, but not to Hex. There is also the mmg toolsuite: www. mmgtools.org which focuses on tets.


#3 Re: Code_Aster development » If Mercurial a must? » 2021-10-23 08:14:30


you can clone the repository in Sourceforge and make changes locally. You could also use a release and make changes locally (in you case you mention 14.6). All changes happen locally, you will not be changing anything from Sourceforge or other places unless you are allowed to.

I would also recommend that you make your modifications on the latest stable releases. That way you get all the fixes and enhancements that were done. As far as I know, that is 14.8 and 15.4. Anything in the v15 release before 15.4 is considered "beta".


#4 Re: Code_Aster usage » Print by screen[SOLVED] » 2021-10-22 20:49:13

Hi Fabrizio,

I suppose you mean the constitutive law present in u4.43.01.

Solvers support an option to generate observations, literally "OBSERVATION" keyword, see u4.51.03. It can print functions and variables. So I suppose that if you define the inputs for IRRAD3M as functions/lists, you should be able to print those values within the solver. Notice that you may need to create auxiliary tables or fields.

I hope it was useful. Regards,

#5 Re: Code_Aster installation » [SOLVED]'LIBPATH_MFRONT' 、 'LIBPATH_SCOTCH' not yet defined » 2021-08-10 09:56:34

Hi Xiangyang,

After taking a look into the log, I think the problem with TFEL/MFRONT is that it is missing some dependencies:

-- Could NOT find Boost (missing: Boost_INCLUDE_DIR python-py38 numpy-py38) (Required is at least version "1.36.0")
-- Trying to find libboost_python38
-- Could NOT find Boost (missing: Boost_INCLUDE_DIR python38 numpy38) (Required is at least version "1.36.0")
-- Trying to find libboost_python-py3
CMake Warning at /usr/share/cmake-3.16/Modules/FindBoost.cmake:2020 (message):
 No header defined for python-py3; skipping header check (note: header-only
 libraries have no designated component)
Call Stack (most recent call first):
 CMakeLists.txt:324 (find_package)

CMake Warning at /usr/share/cmake-3.16/Modules/FindBoost.cmake:2020 (message):
 No header defined for numpy-py3; skipping header check (note: header-only
 libraries have no designated component)
Call Stack (most recent call first):
 CMakeLists.txt:324 (find_package)

-- Could NOT find Boost (missing: Boost_INCLUDE_DIR python-py3 numpy-py3) (Required is at least version "1.36.0")
-- Trying to find libboost_python3
-- Could NOT find Boost (missing: Boost_INCLUDE_DIR python3 numpy3) (Required is at least version "1.36.0")
-- Trying to find libboost_python
-- Could NOT find Boost (missing: Boost_INCLUDE_DIR python numpy) (Required is at least version "1.36.0")
CMake Error at CMakeLists.txt:366 (message):
 Boost python libraries not found.

This is at the bottom of the failure of TFEL.

Since you are using Ubuntu, the -devel packages are not installed by default. Meaning that CA seems to be looking at the -devel packages for boost and boot+python.. Could you search for these packages, install them and see if it works?

Fernando Oleo Blanco

#6 Re: Salome-Meca installation » Can't run SM v. 2020.0.1-1-un. in Debian Linux v.9-based OS » 2021-08-10 09:05:05

Hi msh,

the error you posted does seem to be related to the graphics driver. If you have Nvidia's drivers installed, I would recommend that you use the Nvida card. Newer Linux systems can use Optimus technology, meaning that they may not use the dedicated graphics card (Nvidia) and may use the integrated one.

I think it is worth trying out to see if there is a combination of graphic cards/environment variables that will let V2020 boot.


#7 Re: Salome-Meca installation » Can't run SM v. 2020.0.1-1-un. in Debian Linux v.9-based OS » 2021-08-05 13:30:24

Hi msh,

the 2020 version is known to be quite buggy. I would suggest that you try out v2019.


#8 Re: Code_Aster usage » Error in Run_Case with UMAT » 2021-07-08 09:42:24

Hi Fabrizio,

I think what you need is the SAVE Fortran keyword. Variables "tagged" with the SAVE keyword preserve their values between calls to the function/subroutine/module. So the "first" way you tried, but this would prevent recalculating the same values over and over.

Something in the lines:

logical, save :: firsttime = .true.
double, allocatable, save :: mymaterialproperties

if (firsttime)
  firsttime = .false.
end if


Here you have a deeper explanation stackoverflow.com/questions/2893097/fortran-save-statement


#9 Re: Code_Aster usage » Error in Run_Case with UMAT » 2021-07-07 19:00:47

Hi Fabrizio,

what do you mean by that the UMAT has external libraries/programs? What is it doing exactly?

I am just guessing here, however, it is saying that the library cannot be loaded (look at the path at the end). Is that path/name correctly set up?


#10 Re: Code_Aster installation » Buying a new computer / Choisir sa machine » 2021-06-21 18:54:14

Hi Sadri,

CA is, as far as I know, a CPU based program. If you want to get the most out of it in heavy cases, a CPU with a high clock and fast/fat cache would be best, and the more cores the better. Also, the amount and speed of ram is important if you are handling large problems or running in parallel.

Regarding modern CPUs... AMD is no longer the underdog. Intel and AMD are neck to neck, with AMD usually offering cheaper CPUs with more cores. Here is a page with tons of benchmarks from a ton of CPUs openbenchmarking.org/processors It will all depend on the amount of money you are willing to put.

I hope that helps.


#11 Re: Code_Aster usage » User Subroutine » 2021-06-12 09:46:55

Hi Fabrizo,

Code Aster is libre software, which means you have full access to all the code. You can modify whatever you want in there. You can take a look at the developer documentation to know more about this: code-aster.org/V2/doc/v14/en/index.php?man=D take a look into the "Introduction" documents.

Apart from that, CA allows users to define material subroutines directly.  See code-aster.org/V2/doc/v14/en/man_u/u2/u2.10.01.pdf and code-aster.org/forum2/viewtopic.php?id=25412

I hope that helps. Regards,


EDIT: I just realized you are the same person of the forum thread that I posted smile Sorry about that.

#12 Re: Salome-Meca installation » What means md5/sha1 ? » 2021-04-20 19:59:22

Hi Holger,

the issue with the hashes is known to exist. Other users have reported the same result, see their comments here: code-aster.org/forum2/viewtopic.php?id=25510


#13 Re: Code_Aster usage » Thermo-mechanical simulations using Fourier Elements » 2021-04-20 19:53:12

Hi Alessandro,

I think what you are trying to do is exactly what this video shows. youtube.com/watch?v=1ZNsgykHnGE

If I misunderstood your post, say so.


#14 Re: Code_Aster installation » Problems with installing Code_Aster 15.2 (tfel and mumps) » 2021-03-13 15:55:22

Hi Ali,

I am seeing errors regarding pthreads. Do you have the development files for pthreads installed? This is mostly related to TFEL. I could not find the issue for mumps, but it may be related.

Also, on the topic of Salome_Meca. I understand that you do not want to use CA with it. However, if you have Salome_Meca installed, you can do a

source ./V2019.0.3_universal/salome_prerequisites.sh

in order to source all the binaries and programs used by CA so that they are available to use from the command line. This code should be ran under the installation directory.


#15 Re: Code_Aster installation » Problems with installing Code_Aster 15.2 (tfel and mumps) » 2021-03-12 09:42:24

Hello Ali,

the file that you mention, the setup.log file is nowehere to be found. Did it get attached correctly?

Second, if what you want to do is to try Code_Aster, then I would recommend that you use the Salome_Meca installer, it brings with it CA plus a graphical interface plus a lot of extra tools. I would recommend the 2019 version.

Thirdly, if you want to compile CA, just know that the version 15.2 is not considered stable. In case you want to be sure that you are getting a tested version, use version 14.X (I believe it is 14.6 right now).

Finally, if you still want to compile CA, please, attach the log file that is mentioned in the output that you pasted. Each component gets built independently and they have their own log files, attach the log files of the failing components.



#16 Re: Code_Aster usage » Assign temperature to each node in thermomechanical analysis » 2021-02-18 11:57:31

Hi Paul,

I am answering here since this is the Post which has the topic regarding the node temperature. Try not to ask the same question in different places so that if other people have the same question, they will be able to find it easily.

The way you can assign a "very" controlled field to you nodes is quite varied. The easiest way, which you already know, is from a precomputed thermal simulation.

Another alternative is to use a function to do just that. The documentation to apply a thermal field is found in U4.44.02 -> code-aster.org/V2/doc/v14/en/man_u/u4/u4.44.02.pdf which defines the two ways to define the temperature: either by value directly or using a function. If you want to have a fine control over the temperature field, you probably want to use the function version.
For that you have U4.31.02 (DEFI_FONCTION) -> code-aster.org/V2/doc/v14/en/man_u/u4/u4.31.02.pdf please take a look at it, since it allows you to get access to a lot of information (like the X, Y, Z position of the nodes/mesh)
There is also CALC_FONC_INTERP U4.32.01 -> code-aster.org/V2/doc/v14/en/man_u/u4/u4.32.01.pdf that lets you use a list (as defined by DEFI_LIST_REEL U4.34.01 -> code-aster.org/V2/doc/v14/en/man_u/u4/u4.34.01.pdf) to define temperature values that you can feed to U4.44.02

I hope this helps,


#17 Re: Code_Aster usage » Thermal expansion of a 2D rectangle » 2021-02-17 18:35:35

Hi Paul,

I gave your files a quick look. I do not know if this is the only issue, but there is a problem with the material definition in the thermal case.

In the 3rd stage you define a material that only possess a lambda. If that material has to be deformed by the precomputed pressure field, it will also need the mechanical properties. In de video Cyprien generates various materials to show that you only need to give the minimum information required at each step.

In your case, if I am not mistaken, you are applying a pressure field to a thermal case. Therefore, your material will need _at a minimum_ the E, v (Poisson), alpha and lambda. You can define all these properties in a single material entry and reuse it in the different stages.

Cyprien uses E, v and alpha since those are the required values to run the mechanical simulation + a thermal field (therefore alpha). Also, I think the intermediate step to project the pressure field is not necessary, since it is just a preprocessing thing, I would be surprised if it cannot be done directly.

However, just a question. Why are you running a mechanical simulation first and then the thermal? Do you expect very large deformations that will impact the thermal simulation the most?

Once again, I do not know if that is the only issue, but it is the thing that I noticed skimming through your files.



#18 Re: Code_Aster usage » Thermal expansion of a 2D rectangle » 2021-02-15 15:32:48

Hi Paul,

short answer: yes, it is possible to apply a predefined field on a mesh before a simulation.

Long answer:

1) By your post, I take it that you are doing a "Two stage" simulation. Code_Aster (from now on CA) can easily do this. Please, take a look at the video I am linking. It does exactly what you are trying to do, just in the reverse order. youtube.com/watch?v=1ZNsgykHnGE
CA lets you precalculate some parts of the simulation and apply those results to following steps; all that in a single case. The intermediate steps are known as "Stages". You can extract information at every stage if you wish.

If you want to export fields from CA, the quickest way is to tell CA to output a table of the results that you want to extract. I am mentioning this since you did not include how you transformed the results into a valid excel output. CA allows you to export the data in several different formats, I suppose the easiest one for excel would be to export a CSV file.

2) If you still want to do a simulation, export the results, manipulate those results and feed them back to CA, I am sure that CA has a standardised method to do this. Please, check the documentation to see what commands CA provides for reading inputs and what formats and transformations it allows you to do. This way I am sure that you can easily do what you want. However, I think the first method is much much simpler and quicker.



#19 Re: Salome-Meca usage » Yacs - Openturns - Aster_Study Connection » 2021-02-15 10:45:45

Hi GPSalachs,

you are right. I am sorry I did not write about the path issue with the OT->Python Script! I am aware of the issue, I wanted to make an update video to show how it is made, but for the time being, I have no time smile

The YACS Schema option in OT sets the path with other variables. However, in the case of a Python Script the path has to be hardcoded in the script, and the Path needs to be the one that points to where the .comm file resides (if I remember correctly). There was also the issue that temporary simulations would pollute the directory.

Nevertheless, I am happy that it worked. Hopefully you will get what you want.



#20 Re: Salome-Meca usage » Yacs - Openturns - Aster_Study Connection » 2021-02-12 17:41:45

Hi GPSalachs,

Fernando here (the guy that did the OT videos). My suggestion would be to create the geometry that you want to parametrize and mesh it. Then tell Salome to dump the study. That basically creates a Python script that does what you want. If I remember correctly, this was explained in the YACS series. With that Python script now available, change the values that you want to turn into variables modified by YACS/OT. Then set up your CA case with the variables that you want, if any.

Then, you can do a couple of things.

1) Use OT the way I explain it in the video. However, I would recommend to use the "Python Script" case instead of the "YACS schema" one. Since that is simpler (and faster). Then just copypaste the modified Python script that Salome generated in the script editor of OT. The Python code that you copy should be copied inside a Python function known as _exec(). That function is the one being called by OT. In the function declaration include the variables that are going to be used in you design. And that should be more or less it! Just run the case.

2) All YACS. Same as above, but you create a YACS schema that ends in a Python script that does what OT would do. This gives you a lot more flexibility, but it requires more work and knowledge of OT.



#21 Re: Salome-Meca installation » User feedback on Salome_Meca V2020 » 2021-02-01 21:03:38

Go directly to the AsterStudy section. You may need to update the paths of the mesh and the output table.

#22 Salome-Meca installation » User feedback on Salome_Meca V2020 » 2021-02-01 19:48:11

Replies: 2

Hi everyone, specially the Aster/Salome developers,

In this post I would like to give some feedback of my experience with the new version. Feel free to pin it so that other people may add their own experiences.

Also, this post is subject to heavy editing since the more I use the new version, the more I will write. Operating System: OpenSuse Tumbleweed (very up-to-date, bleeding edge distro)

Version 2020.0.1:

[Date 1/2/21]
YACS: I can launch a schema an compute it. But it "never finishes". It indicates that it has finished, however, it won't let me do anything, as if it were running. And it will not stop even if I tell it to "Shutdown Proc". I do not know if this is just my system or others have the same issue. I cannot run YACS at all in the 2019 version either, so that makes me think it is my system.
          The "tutorial" in the documentation cannot be followed since the entry "Add component" of the Catalog (as indicated in the written tutorial) is no longer present. I do not know if this is intended or a bug.

Persalys: it would have been nice to indicate that it is the "new" OpenTURNS interface wink A quick changelog about the new version would be nice.
                When running a YACS model, the option to run several simulations in parallel is ignored. This is an issue that was already present in the V2019 version.

Calculator: none existent response or data about it in the files. Nothing happens when I click on it and I have not found much about that module within the files.

I cannot open the documentation from the Help menu, that also happens in V2019 (to me). Nonetheless the files are available in the installation directory.

I did not have to delete the usual Debian files on my system. So thank you for having fixed that smile


As indicated in code-aster.org/forum2/viewtopic.php?id=25443 it would be very, very, very nice to have a more up-to-date Salome version, mostly because of the the new sweet features. The current one is 9.4.0 with some modules being 9.3.0, such as Persalys and ADAO as indicated in the About tab. 9.5.0 is already 6 months old and has quite a few nice improvements. Plus there was already a new version already, 9.6.0. And I also understand that 9.6.0 may be a bit too "new" for a release.


Finally, this is more on a personal note. Apart from me wishing that Salome 9.5.0 was used, I fully understand the requirements and the efforts necessary to build/test/run such a massive piece of software. I would like to thank your efforts (developers, R&D and libre software people) for your work that we can use for free.

However, a side of me wishes that there was more commitment or efforts put in the open release. And I think the community could be leveraged more on that one. The Code_Saturne people started adding tutorials on their youtube and have written tutorials in their webpage. I think CA/SM could use some of those ideas. It is very nice that some people took the initiative and create formative material on the net (think Cyprien Rusu or Aether Engineering), but I think you (the developers) can ask the community for some more help.

For example, in testing newer versions for you, so that people who want to use newer features can get them (without any form of warranty, as if there were already one). While people who need a more solid release could get the "normal" one. This way the issues that took place on the V2019 release could have been minimized. Also, the community could be the one tasked with writing a "Notable changes" type of changelog. And official "tutorials" in the youtube channel done by the community could be a very nice addition.

Of course, this is a work of passion, and the software is given as is. I just think that CA could use the community a bit more on its favour. I personally spend a few hours a month helping people here on the forums to make the learning experience less bitter and created the OpenTURNS tutorials since there was next to nothing in the documentation, which the community could help with too wink

(BTW, I am also giving a talk this Sunday in FOSDEM about libre mechanical software, and of course, you are highly featured there. Bringing awareness in my humble opinion is also useful)


Anyhow, I am very glad for your continuous work and commitment to helping others in an altruistic manner. Thank you very, very, a lot, very, more than very much for the new release!

Kind regards,


[EDIT 1]: added another bug/issue to Persalys/OpenTURNS
[EDIT 2]: also, I just noticed that you have added a parametric tab in the "History View" section for Persalys and ADAO, that is very, very nice. Thank you. I really need to get my hands on ADAO and HOMRAD to start doing some topology optimization! A nice written guide would be very much appreciated wink
[EDIT 2.5]: I have tried to give the parametric study tab a try. I cannot run any parametric study since it keeps telling me that I am lacking a "NOM_PARA" in the "IMPR_TABLE" when I clearly have one. It is the same file I used in the video. Since this is and edit, I cannot upload the file, I will make a new comment.

#23 Re: Salome-Meca usage » Direct link Shaper <--> Mesh Module » 2021-02-01 16:29:54

Hi Cacciatorino,

I have just downloaded the new version and as you say, it is 9.4.0. However, the Shaper module is available. It sits to the right of the AsterStudy module.

I will open now a thread to give feedback to the developers.



#24 Re: Salome-Meca usage » YACS usage ? » 2021-01-26 14:35:55

Hi lskrinjar, and lelorrain if you are still arround.

You can find more info about the YACS module by following the video series done by Cyprien Rusu [ youtube.com/watch?v=Yqp_dW1JuJA&list=PLvkU6i2iQ2frHUfTg-YYjKRwUuMK_Rg9k ]. There is also a couple of videos on OpenTURNS in his channel done by me [ youtube.com/watch?v=1Z1S3kmKjhQ&list=PLvkU6i2iQ2fr2SmkmNt_OtYRAssgrZpzj ]


Fernando Oleo Blanco

#25 Re: Salome-Meca usage » Direct link Shaper <--> Mesh Module » 2021-01-21 13:08:16

Hi Cacciatorino,

I believe that this feature was added to Salome 9.5.0 https:// files.salome-platform.org/Salome/Salome9.5.0/SALOME_9_5_0_Release_Notes.pdf
So hopefully, the new version of Salome_Meca will have it. And if you want to work with it now, then you could download the latest Salome.


Fernando Oleo Blanco