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

You are not logged in.

#1 Re: Introduce yourself / Présentez vous » Salome meca installation » 2022-08-09 16:59:36

Hi Andrea,

yes, the connection is known to be bad. If you have access to the wget command (very common in Linux/UNIX systems), try using "wget -c URL". It will try to restart the download if it dies. Hopefully that helps.

Regards,
Fer

#2 Re: Salome-Meca installation » Unable to run Salome in GPU mode » 2022-08-06 17:46:10

Hi Ruy,

yes, Glibc being a newer version is most likely causing the issue. However, I intentionally left out a detail in my last message hoping that it would not be required. There is a new version of the Singularity container, you can download it here: code-aster.org/FICHIERS/singularity/salome_meca-lgpl-2021.1.0-1-20220405-scibian-9.sif That is the version that I managed to get running on the new version of Linux Mint. It had the same error as you a few times, but then it managed to work after a few tries. I hope this helps.

Regards,
Fer

#3 Re: Salome-Meca installation » Unable to run Salome in GPU mode » 2022-08-06 09:48:08

Hi Jean-Pierre,

I am not part of the CA team, so I cannot answer your questions regarding their decisions, however, I can shine some light later.

Now, regarding OpenSUSE Leap. Version 15.1 has been EOL (End Of Life) for a while now! Older Leap versions tend to be supported for 9 months (+-) after the new release comes out, so only 15.3 and 15.4 are currently supported. I would assume that you cannot (normally) update your systems as most repositories for version 15.1 have been offline for a while. So you may indeed need to jump to 15.3 and 15.4 directly. This is bad as normally only sequential point upgrades are supported: 15.1 to 15.2, 15.2 to 15.3, etc. So I would expect a bit of pain during the update... Depending on how much data you have in your system and backups, you may want to install 15.4 directly and wipe 15.1, but I leave that decision to you. Nontheless, I would make a backup independently of which option you take.

Regarding graphical problems:
- Most software that we use comes from our operating system's repositories. It is built with the tools that our OS provides. You probably installed GMSH from your repositories and it just works, because it is compiled with the tools and libraries of your system. Even if you compile it locally, it still uses the libraries that your system has, so everything should work nicely.
- Salome (and by extension Salome_Meca) is a very complex and large program. I do not know of any system that actually provides packages for Salome. This means, that the binaries that we can download from this page or Salome's are built with the libraries and tools that the developers chose. This may introduce incompatibilities with your system as your system may not have the same versions as the developers'.
- Singularity was introduced to fix that. Singularity is a container technology. It is basically running an entire operating system internally (that is why the file is so large!). In this case, it runs Scibian 9, which is the Debian version that the CA people seem to work with. The CA people built Salome_Meca in that container in a way that they know works... However, containers are also problematic... Most containers are just like lightweight virtualised systems. This means that programs running on containers are not just simply running in your computer. They run in their own container. The container in turn has to plug itself into the hardware and the underlying operating system for some functionality, such as graphical hardware access...
   - This is where the problem comes... Singularity is a container technology developed for HPC (High Performance Computing). This means it tries to get as much power from the host operating system while it itself consumes the least amount of resources. But at the same time it has to keep the container software from doing weird stuff to the host (due to security, stability, etc). This means that graphical access is not as straight forward as it would seem... Singularity, sadly, only officially supports graphics acceleration for Nvidia and AMD cards, this last one is a bit experimental and not supported by the CA container. Intel cards, which are great in Linux, are not supported by Singularity, as they are not found in HPC environment... This is sad, I know.

I hope this answers some of your questions. Feel free to ask more if I was not clear or more issues pop up.

Regards,
Fer

#4 Re: Salome-Meca installation » Unable to run Salome in GPU mode » 2022-08-06 08:12:12

Hi Jean-Pierre,

as you can see from the output, your graphics provider is Intel, see the first line from "glxinfo | grep -i opengl".

From the output of glxinfo and your wallpaper I think I can infer that you are using OpenSUSE Leap or SLES. Your Mesa driver is quite old (v18) we are already in v22 in bleeding edge Linux distributions (I personally use OpenSUSE Tumbleweed and Leap). In the newest version of OpenSUSE Leap, version 15.4, Mesa is v21.2.

So, here are my recommendations:
- Make sure that you have your NVIDIA drivers installed. I am assuming you do have an NVIDIA graphics card! Luckily, OpenSUSE does have an official NVIDIA repository, but it has to be enabled manually. You can see the instructions here: en.opensuse.org/SDB:NVIDIA_drivers
   - The process is simple and painless, though it may be convoluted in a couple of steps. However, if you have doubts or questions, just ask them.

- Then we need to make sure that your computer actually picks the Nvidia drivers. This is a bit tougher... Since your system is quite old, it will most likely need the bumblebee/prime-select approach. You can read more about it here en.opensuse.org/SDB:NVIDIA_SUSE_Prime
   - Though this step may be a little bit tougher to pull correctly with the expected outcome. If you have any issues, feel free to write me here or directly.

- Afterwards, depending on the method that actually makes your computer use the Nvidia drivers, you should be set and everything should just run.

Best regards,
Fer

#5 Re: Salome-Meca installation » Unable to run Salome in GPU mode » 2022-08-06 07:13:24

Hi Ruy,

run "singularity run --app install salome_meca-lgpl-2021.0.0-2-20211014-scibian-9.sif" as is alone. It should then create a Python excecutable with the same name as the container in that folder. Then run

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia ./salome_meca-lgpl-2021.0.0-2-20211014-scibian-9

It will most likely fail however... Your error is related to GLIBC having issues with the GLX library. It happened to me to a few times. I just tried several times and then it finally worked in a virtualised Linux Mint 21 (same base as Ubuntu 22.04). GLIBC errors are a bit tricky to fix because they are the "core" of the system. If a library has incompatibilities with it... Nonetheless, it should work. Ubuntu 22.04 has a newer GLIBC version that should be compatible as far as I know...

Regards,
Fer

#6 Re: Salome-Meca installation » Unable to run Salome in GPU mode » 2022-08-05 17:22:53

Hello Jean-Pierre,

first things first, thank you for your book, it helped me quite a bit.

Secondly, yes, the output of glxinfo can be overwhelming. I would recommend filtering out with grep. A quick and useful command would be "glxinfo | grep -i vendor" and "glxinfo | grep -i device". The actual useful lines are more or less at the top of the output of glxinfo, under the sections "Extended renderer info" and "OpenGL". You can get a bit more useful output with "glxinfo | grep -i opengl".

Could you copy the output of those commands? That way I can see what graphics driver is being used.

Best regards,
Fer

#7 Re: Introduce yourself / Présentez vous » Salome meca installation » 2022-08-05 17:16:09

Hi Andrea,

I am glad that it runs now. Sadly I have never heard of such error before, however, I did have issues when post processing...

There is a newer version of the container that is available in the code-aster server but it has not been officially put for a download... Maybe it is more stable and it fixes your problem. The link is code-aster.org/FICHIERS/singularity/salome_meca-lgpl-2021.1.0-1-20220405-scibian-9.sif
I would give it a try and see if it is better.

Best regards,
Fer

#8 Re: Introduce yourself / Présentez vous » Salome meca installation » 2022-08-04 21:15:17

Hi Andrea,

the container can only run in GPU mode if you system has an Nvidia GPU... This is a known limitation and it is a bit sad... But that is its current state. If you have an Nvidia GPU in you system, make sure that the drivers are installed and are being used.

Regards,
Fernando Oleo Blanco

#9 Re: Salome-Meca installation » Unable to run Salome in GPU mode » 2022-08-04 20:58:37

Hi Ruy,

It seems that you have the Nvidia drivers installed. The launch script detects /usr/bin/nvidia-smi. However, when it tries to run in graphical mode it seems it cannot connect to the Nvidia drivers. This may be because your computer has a "dual" GPU.

For example, in my laptop, my Intel CPU comes with a low-power GPU (Intel Graphics), but I also have an Nvidia GPU. By default, the Intel drivers are loaded in my system, that allows it to be more power efficient. If this is your case, what you want to do is to make sure your system is using the Nvidia graphics. This, however, varies from system to system and driver version... Since you are using the newest Ubuntu LTS version, I would guess you can use the new recommended method for newer Nvidia drivers:

Prefix your singularity command with: __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia
This will tell your system to activate the Nvidia drivers for such command. You can test this by using the "glxinfo" command (in Ubuntu I do not know what package provides it). Run glxinfo with and without the variables above and see if the Vendor is Intel or Nvidia.

If that does not work, tell me and I can share more info.

Best regards,
Fernando Oleo Blanco

#10 Re: Code_Aster installation » Salome new version? salome_meca-lgpl-2021.1.0-1-20220405-scibian-9.sif » 2022-07-02 21:08:58

Hi, thank you for the info!

I downloaded it with `wget -c` and, eventhough it died a few times and the download was extremely slow at the beginning, it seems it downloaded it correctly!

Here are some hashes

sha256sum salome_meca-lgpl-2021.1.0-1-20220405-scibian-9.sif 
1a2e4901ffa94a11e5ccb76ccf7a255483f39cea5d8af2e83929326a7a7b6cc2  salome_meca-lgpl-2021.1.0-1-20220405-scibian-9.sif

sha1sum salome_meca-lgpl-2021.1.0-1-20220405-scibian-9.sif 
3d5c02a2f5e27dc90c701d3fc848ff6e2d08c475  salome_meca-lgpl-2021.1.0-1-20220405-scibian-9.sif

It feels snappier and less buggy! It still has some graphical glitches in --soft mode, but it seems much better.

Thank you,
Fer

#11 Re: Code_Aster usage » [SOLVED] MFront windows version CA » 2022-06-03 15:13:52

Hello Padr,

Tfel/Mfront is available as a stand alone aplication in Windows. The Tfel webpage indicates how to install it using MSYS2. Once installed you could compile your Mfront material with the MSYS2 version of Tfel and then point CA to use that behaviour.

I must say that I have never done this so I cannot ensure that it will work, but that is how Tfel is supposed to work in Windows.

I hope that helps,
Fer

#12 Re: Code_Aster usage » Extract all elements and assign new mat props to some of them » 2022-05-02 21:41:51

Hi Majnooni,

yes, I wanted to say elements instead of node. Regarding your problem: CA has an operator to define groups, it is called DEFI_GROUP [U4.22.01], which you probably already know. However, after reading it , I could not find anything that could be directly useful to you. However, here is an idea:

You could use a post-processing utility such as POST_RELEVE_T and IMPR_TABLE to extract the values of all the elements in your simulation and create a table out of them. Then, with some Python scripting, create a criteria that selects the elements that you want. And then, use those results to define a new group and assign a different material to such group.

I know this is a bit manual and it would be better if CA had something like a filtering tool to select elements that then could be used for whatever, but I have not seen anything like that. Maybe it does exist and I am just not aware of it. Though I do know that one can define arbitrary Python functions in Aster, but I do not know how to then translate that into a GROUP definition...

Hope it helps,
Fer

#13 Re: Code_Aster usage » CA 15.4 DIVE_RESI bug » 2022-04-29 21:38:26

Hi Mario,

first things first, thank you for your concerns. I will try to answer them in the best possible way.

Re: 1st order elements: thank you for bringing this up. While there is a bit of bending, there is not a lot... But even then, I tried using second order elements but they were having some issues with the contact (contact forces were just wrong). This should not be the case, as CA can deal with second order elements in contact fine, but I did not try to see why this was the case, I just gave up after seeing the terrible results.

Re: timestep output: yes! We are interested in a lot of outputs. Our goal is not to see the final state after load, but see the evolution of the part as it is being loaded (more on that later). We want to see the load-displacement curve and for that, we need quite a few output points. I know there is something like an observation subsystem for the simulation, but I have not looked into it, as I wanted to also get stress evolution etc. I was not trying to be efficient here, I wanted to learn and get as much useful data as possible.

Re: yes, the case is not setup well, thank you for picking that up. The wire that is being bent, has not Z condition! That is no mistake, even if that is what I should have done. My goal was to have a setup as close as possible to reality, for that reason, the bent wire has no BCs touching the Z direction. That conditioning comes from the contact case... I know that numerically this is a bit of a risky choice, but physically speaking, it should just work, and it seems it did smile More on that later.

Re: yes, the mesh is fine, maybe too fine for a wire diameter that is large. For the thinner wire diameter (0.95 mm), I think it was not refined enough around the contact areas. The rest of the wire is not as refined, but maybe it is still too much as you point out. This may be good enough since there is some plasticity that takes place later in the simulation and it is good that that transition is picked up correctly. Also, I performed no mesh sensitivity analysis since we had no time, so I just went with a mesh that seemed good enough...

So, now at the end... Today I gave a presentation about the results. I have attached it with this response. There you can see a summary of what I did and some of the conclusions compared to actual experimental data. You can also see the instability that happens for the thinnest wire. I think that is due to the coarse mesh in the contact area and the fully rigid support and load structures. Also, there is a slide of the BCs which should make things clear, the wire has no condition on the X axis.

If you have any questions or recommendations, please, just say so smile

Thank you very much for your time,
Fer

#14 Re: Code_Aster usage » CA 15.4 DIVE_RESI bug » 2022-04-28 19:33:36

Hi Mario,

thank you for your interest. Here are the files:

- 1st: the Salome Meca hdf file. I would recommend using this file since you can modify the mesh in case you want to run it. The geometry is parametrised, so if you want, you can simulate different diameters of wire (that is the goal, which has been achieved!). File: https:// irvise.xyz/media/documents/Wire_sym.hdf (delete the space inbetween).
- 2nd: the actual files with which I ran the simulation. I am attaching those too since there may be some discrepancies with the Salome files, as I modified them manually. Hopefully the hdf has all the changes that I did to these files. Files: https:// irvise.xyz/media/documents/CA_Diameter_095.zip

Some mayor points:
- It is the simulation of a 3 point bend test of a round wire made of tungsten. The setup is such that different diameters can be easily simulated. Why a round wire? Because... yes... that is what was done, not what was wanted tongue
- It is using the MUMPS solver instead of an iterative solver for robustness. GCPC gave me good results at the beginning, but became quite unstable later down the line.
- The wire's material is being modeled using the Rankine model (perfect elasticity under compression, 0 slope for plastic deformation on tension on the principal stresses). It was chosen since the ENDO_ISOT_BETON is not as simple as I had hoped, but it would be probably better.
- The bug was found for this setup, a wire of 950um diameter. The simulation ended today and I got to see the contact force results. There is clearly some instability, as the total reaction force jumps quite a bit (about ~5-10N), which in relative terms, is quite a lot. The results as seen in the mesh show that the mesh quality is not great. The mesh was created for a wire of 3600um diameter and was left as is...
- It uses the PETITE_REAC geometrical model since Rankine does not have a large displacement/deformation model. This was needed since the smaller diameter wire (the one of the files) was expected to have quite a bit of deformation.
- The support and load bodies for this case, the 950um diameter case, were modeled as solids. In the other cases they were given tungsten as a material and the alternative BCs were used (you can see them in the case setup).


If you have any other question, feel free to ask! Regards,
Fer

#15 Re: Code_Aster usage » Extract all elements and assign new mat props to some of them » 2022-04-27 21:09:43

Hi Majnooni,

how are you creating the mesh? I assume that you are using Salome.

Salome has a renumbering option which may be helpful for your case. Also, how do you know which nodes you want to modify/assign the material? Cannot you create a group of nodes for them? I know this can be quite challenging, if you have any questions about it, just ask smile

Sorry I cannot help you much with this message. Regards,
Fernando

#16 Code_Aster usage » CA 15.4 DIVE_RESI bug » 2022-04-27 20:06:11

Irvise
Replies: 4

Well, as the title says. I believe there is a problem in the DIVE_RESI algorithm...

Below is an extract of a simulation that I am running:

[ 89%] Instant calculé : 4.46624e+00, dernier instant archivé : 
4.40000e+00, au numéro d'ordre :
290
------------------------------------------------------------------------------------------------------------------------
Instant de calcul:  4.480531397457e+00

------------------------------------------------------------------------------------------------------------------------
|     NEWTON     |     RESIDU     |     RESIDU     |     OPTION     |    CONTACT    |     CONTACT    |     CONTACT    |
|    ITERATION   |     RELATIF    |     ABSOLU     |   ASSEMBLAGE   | NEWTON GENE  |   NEWTON GENE  |    PRESSURE    |
|                          | RESI_GLOB_RELA | RESI_GLOB_MAXI |                | VARI. CONT.  |   CRIT. GEOM.  |    ERROR       |
------------------------------------------------------------------------------------------------------------------------
|     0        X | 1.35659E+00  X | 2.87240E+00    |TANGENTE        |   99        X | 1.92624E-08    | 1.08614E+00    |
|     1        X | 5.00675E-03  X | 2.99552E-02    |TANGENTE        |    0          | 0.00000E+00    | 8.96531E-01    |
|     2        X | 2.55912E-03  X | 1.51403E-02    |TANGENTE        |    0          | 0.00000E+00    | 1.30769E-01    |
|     3        X | 1.45954E-03  X | 8.62130E-03    |TANGENTE        |    0          | 6.20991E-04  X | 2.28499E-02    |
|     4        X | 4.22234E-05    | 2.49355E-04    |TANGENTE        |    0          | 1.70290E-04  X | 1.68888E-04    |
|     5        X | 5.53979E-04  X | 3.27159E-03    |TANGENTE        |    0          | 1.71240E-06    | 1.18192E-04    |
|     6        X | 8.64635E-05    | 5.10621E-04    |TANGENTE        |    0          | 5.39293E-07    | 8.98863E-06    |
------------------------------------------------------------------------------------------------------------------------
<Évènement> Divergence du résidu (DIVE_RESI).

<Action> On essaie de découper le pas de temps.

On utilise la découpe manuelle.
Découpe uniforme à partir de l'instant < 4.466243112249e+00> en <4> pas 
de temps.
                     (soit un incrément constant de < 3.572071302048e-03>)
<Action> On découpe le pas de temps.
------------------------------------------------------------------------------------------------------------------------
<Évènement> Divergence du résidu (DIVE_RESI).

Temps CPU consommé dans ce pas de temps    : 19 min 10 s

* Nombre d'itérations de Newton                     : 7
* Temps total intégration comportement              : 3 min  8 s (8 
intégrations)
* Temps total factorisation matrice                 : 13 min 43 s (7 
factorisations)
* Temps construction second membre                  : 2.624 s
* Temps total résolution K.U=F                      : 1 min 11 s (7 
résolutions)
* Temps appariement contact                         : 2.994 s (7 
appariements)
* Temps préparation données contact                 : 35.271 s (15 
préparations)
* Temps calculs élémentaires contact                : 1.315 s
* Temps assemblage matrice                          : 0.000 s
* Nombre de liaisons de contact                     : 0
* Nombre de cycles de type contact/pas contact      : 0
* Nombre de cycles de type glissement/adhérence     : 0
* Nombre de cycles de type glissement avant/arrière : 0
* Nombre de cycles de type point fixe contact       : 0
* Temps autres opérations                           : 24.387 s
Mémoire (Mo) : 66743.52 / 65294.53 / 19893.10 /  1617.91 (VmPeak / 
VmSize / Optimum / Minimum)

------------------------------------------------------------------------------------------------------------------------

As you can see, the final iteration is all good but the divergence error from the automatic timestepping algorithm still generates an error and undercuts the timestep...

I cannot share with you the files as they are rather big and cannot be added to this post. If you are still interested, I can upload a zip with everything somewhere if there is interest. I must say however, that this is a sizeable simulation which is taking a few days on a 10 core machine with plenty of ram...


Also, regarding DIVE_RESI. Could it be made so that if it detects that a residue (such as contact) is still going down that it takes a more conservative approach? Here is an example of the DIVE_RESI error being raised eventhough the contact kept dropping and the relative error was just about to converge. It also was accepted in iteration 4 but did not fully converge due to the contact resedue... The undercutting could be a little bit less aggressive in these cases:

------------------------------------------------------------------------------------------------------------------------
|     NEWTON     |     RESIDU     |     RESIDU     |     OPTION     |    CONTACT    |     CONTACT    |     CONTACT    |
|    ITERATION   |     RELATIF    |     ABSOLU     |   ASSEMBLAGE   | NEWTON GENE  |   NEWTON GENE  |    PRESSURE    |
|                | RESI_GLOB_RELA | RESI_GLOB_MAXI |                | VARI. CONT.  |   CRIT. GEOM.  |    ERROR       |
------------------------------------------------------------------------------------------------------------------------
|     0        X | 1.04707E+00  X | 2.25050E+00    |TANGENTE        | 101        X | 3.05666E-07    | 1.22831E+00    |
|     1        X | 6.61829E-03  X | 3.59034E-02    |TANGENTE        |    2        X | 0.00000E+00    | 1.04513E+00    |
|     2        X | 2.83019E-03  X | 1.51953E-02    |TANGENTE        |    0          | 0.00000E+00    | 1.07450E-01    |
|     3        X | 7.29505E-04  X | 3.91628E-03    |TANGENTE        |    0          | 4.76131E-04  X | 1.97577E-02    |
|     4        X | 7.16048E-05    | 3.84401E-04    |TANGENTE        |    0          | 1.43272E-04  X | 1.08251E-04    |
|     5        X | 1.11872E-04  X | 6.00574E-04    |TANGENTE        |    0          | 1.38395E-06    | 9.70989E-05    |
|     6        X | 1.71606E-04  X | 9.21246E-04    |TANGENTE        |    0          | 4.58858E-07    | 6.39572E-06    |
------------------------------------------------------------------------------------------------------------------------
<Évènement> Divergence du résidu (DIVE_RESI).

<Action> On essaie de découper le pas de temps.

On utilise la découpe manuelle.
Découpe uniforme à partir de l'instant < 4.578068352495e+00> en <4> pas 
de temps.
                     (soit un incrément constant de < 2.715604512451e-03>)
<Action> On découpe le pas de temps.
------------------------------------------------------------------------------------------------------------------------
<Évènement> Divergence du résidu (DIVE_RESI).

Temps CPU consommé dans ce pas de temps    : 18 min 16 s

* Nombre d'itérations de Newton                     : 7
* Temps total intégration comportement              : 3 min  6 s (8 
intégrations)
* Temps total factorisation matrice                 : 12 min 47 s (7 
factorisations)
* Temps construction second membre                  : 2.597 s
* Temps total résolution K.U=F                      : 1 min  7 s (7 
résolutions)
* Temps appariement contact                         : 2.901 s (7 
appariements)
* Temps préparation données contact                 : 43.671 s (15 
préparations)
* Temps calculs élémentaires contact                : 1.277 s
* Temps assemblage matrice                          : 0.000 s
* Nombre de liaisons de contact                     : 0
* Nombre de cycles de type contact/pas contact      : 0
* Nombre de cycles de type glissement/adhérence     : 0
* Nombre de cycles de type glissement avant/arrière : 0
* Nombre de cycles de type point fixe contact       : 0
* Temps autres opérations                           : 24.282 s
Mémoire (Mo) : 67285.04 / 65524.87 / 20218.65 /  1617.91 (VmPeak / 
VmSize / Optimum / Minimum)

------------------------------------------------------------------------------------------------------------------------

Regards,
Fer

#17 Re: Salome-Meca usage » Problem in reading CAD Geometry from .step file » 2022-04-15 17:37:56

Hi Decker,

this forum is mostly for Salome_Meca, so the Salome Platform + Code_Aster. Since your question is purely related to Salome, I think it would be better to ask such question in the (new) Salome forum, see https:// discourse.salome-platform.org/ (delete the space between the protocol and the URL).

Nonetheless, I will answer what I think the problem is. Step files are pure geometry. When you export them, you need to set a resolution so that, for example, curves are modeled with enough precision. Have you exported such geometry with enough definition? Could you open that same .step file in another program that can read them and see if they display the same geometry as Salome? I think Blender can read files, and it is libre software. I am saying this since your step file seems to be rather coarse (see the outer curvature, which is quite blocky)

That would be my guess. However, since you say that you have been using using step files for OpenFoam, I would guess that you know what you are doing... Therefore my second guess is that Salome has a limit on the polygons it displays. For example, there is a cap in the Mesh module that prevents heavy meshes from being rendered as to not wreck the memory/GPU. That would be my second guess. If those two thing are not the problem, please, ask in the Salome forums, since they may be better prepared to answer your question. Also, make sure that you are using an up-to-date version. Salome 9.8.0 was released a couple of months ago.

Regards,
Fer

#18 Re: Code_Aster usage » Help with very simple strain calculation » 2022-04-14 15:45:56

Hi,

I suppose you are getting started with FEM in general.

The epsilon term that FEM software outputs is not on the entire part, as it does not know what the beginning or end is in order to measure the elongation. FEM software outputs the deformation of each finite element.

In an ideal world (without the Poisson ratio or boundary issues) each element would deform what you expect (0.05) and the complete part would deform itself 0.05 too (since it is the sum of all deformations divided by the total length). However, since Poisson and Boundary conditions exist, that means some finite elements are going to deform more than others depending on the stress configuration. As you can see, the elements on the extremes/corners are deforming more than most, therefore the red areas. However, those on the middle (far from free edges and BCs) have pretty much a deformation of 0.05, which is what we would expect. This is a somewhat good example of the limitation/issues that theoretical analysis and FEM have.

I hope this explained what you wanted to know.

Regards,
Fernando Oleo Blanco

#19 Re: Code_Aster usage » ERROR in documentation » 2022-04-14 14:55:49

Hi again,

I think I have found an undocumented option. In CALC_CHAMP, when I run my simulation, the output generated by CA shows an option named PARALLELISME_TEMPS, which defaults to the value 'NON' (when using the french language). This option is not documented in the CALC_CHAM documentation.

I am using CA v15.4, but this field does also not appear in the documentation for v13. I have also looked into the french documentation and it also does not appear there.

Is this a deprecated option or was it never documented?

Regards,
Fer

#20 Re: Code_Aster usage » GMSH volume - CA interaction » 2022-04-14 13:19:38

I cannot help you directly, but here are a few potential pointers.

You said that you have two volumes. I suppose they have the same material, otherwise, depending on how you prestress the part, that difference would be expected.

Secondly, from your wording I suppose that you have only one set of nodes and that the gallery is just a section of the whole mesh. If you have two meshes that are joined into one, you will first have to fuse them together so that there is interaction between them.

Thirdly, do not use the DEPL_Magnitude representation. If the DEPL field has more subcomponents than just DX, DY, DZ, the Magnitude will be incorrect. This is the case when continuous contact formulation is used, for example, since it adds one extra component to DEPL. I would recommend that you activate the GenerateVectors option when reading the results file and use the Vector representation of DEPL.

These are my two grains of sand. You may also want to share the .comm file so that other people may take a look at it.

Regards,
Fer

#21 Re: Code_Aster usage » Integration of normal contact force with POST_ELEM, wrong result? » 2022-04-14 09:55:08

Hi,

after further testing (with a new case modelling the exact same problem with some improvements) I still get obviously wrong results. Since CA is generating no errors and there is nothing that would indicate that I am doing something incorrectly, could a CA developer take a look into this?

As far as I understand, it is as "easy" as just summing up the indicated field values of the GROUP_MA/NO indicated.

Thank you for your time,
Fer

#22 Re: Salome-Meca usage » [SOLVED] aster study -max_base arguments » 2022-04-14 09:45:23

Hi,

adding to what Stefano said, v15.4 from the Singularity container still has this issue, max_base is NOT increased automatically. I am running a fairly large case and the CALC_CHAMP section always died on me with the warning that the limit has been exceeded and that I needed to increase it manually.

Second, -max_base is deprecated, --max_base is now required (notice that the correct form has two hyphens) . This is the complete command that as_run actually uses for my case that does not generate a deprecation warning:

/opt/python/3.6.5/bin/python3 fort.1 --max_base 500000 --num_job=7540 --mode=interactif --rep_outils=/opt/salome_meca/Salome-V2021-s9/tools/Code_aster_frontend-2021001/outils --rep_mat=/opt/salome_meca/Salome-V2021-s9/tools/Code_aster_frontend-2021001/../Code_aster_stable-1540/share/aster/materiau --rep_dex=/opt/salome_meca/Salome-V2021-s9/tools/Code_aster_frontend-2021001/../Code_aster_stable-1540/share/aster/datg --numthreads=10 --suivi_batch --tpmax=360900.0 --memjeveux=12500.0

Regarding your point, Stephano, you can set it up in a couple of ways:

1. IF USING THE AsterStudy GUI: when you are going to launch the case from the "History View" panel, in the Advance tab (where you can set the maximum number of CPUs) there is a field named "Arguments". In that field I suppose you just have to write something like --max_base 250000

2. IF USING ASTK: similar to the above, just write the same (--max_base XXXXX) in the Arguments field at the bottom of the screen (below where you set up the files)

3. IF YOU SETUP THE export FILE DIRECTLY: write (without quotes) "A args --max_base 500000" or any other number that is high enough in the file. That just adds the text as an argument when launching the as_run command.


Best regards,
Fer

#23 Re: Salome-Meca usage » select body/surface in paravis » 2022-03-29 21:35:18

Hi Jacob,

Code_Aster allows you to do post processing of the generated results on specific areas. Most (if not all) post-processing commands have a GROUP_MA or GROUP_NO to restrict the post processing of whatever you want to that group.

If you are talking about ParaVis/Paraview, you can use the threshold filter. It allows you to get rid of parts of the results depending on your criteria. If you have groups in your mesh, those will be present in the results. In the threshold filter select the filter to be based on FamilyCell or FamilyNode and tweak it to leave only the part that you actually want.

Regards,
Fer

#24 Re: Code_Aster usage » Integration of normal contact force with POST_ELEM, wrong result? » 2022-03-28 18:46:21

I tried uploading the files two times, but both times they went above the file size limit... I am adding all the files except the wire mesh, which uncompressed weights about 28Mb. Everything compressed was only 3.8Mb, but that was still too large for the system.

Sorry for the inconvenience.

Fer

#25 Code_Aster usage » Integration of normal contact force with POST_ELEM, wrong result? » 2022-03-28 18:36:35

Irvise
Replies: 2

Hello everybody,

I am trying a contact simulation for the first time and after a bit of
effort, it is now done.

I am simulating a 3-point bend test of a tungsten wire. The goal is to
analyse the force-displacement curves that are generated depending on
the diameter. See the attached file, which contains the meshes, comm
and a PDF that shows the current results and has the data of which I
will be talking about. I would recommend to see the PDF directly since
that will have all the relevant information with some nice
screen-shots of the result :)

DESCRIPTION OF THE PROBLEM

I would like to get the vertical force that the wire is receiving from
the load. That is "easily" achieved with the output generated from the
contact simulation with the component "RN" and in my case, "RNZ". As
far as I know, this is only generated for the CONTINOUS contact
formulation, which I am using.

Since I am simulating the load and the support as rigid bodies, and I
am controlling the displacement (displacement as BC), there are no
reaction forces. At least, I cannot generate them and POST_RELEV_T
them in a POURSUIT. And I think this is not needed since we already
have the contact reaction forces in the CONT_NOEU set of variables and
the RN field, as stated before.

Following the wonderful example from Mario (see
/forum2/viewtopic.php?id=24652), I used the same technique to
integrate the contact force field. The force needs to be integrated
since the normal reaction forces created in CONT_NOEU are per node and
I want the full force applied, not the force for each node. I
integrated the "RN" and "RNZ" components on the Load-Wire contact
surface (in COMM it is called 'Wire_contact_load'). The relevant code
is below

Tot_forc = POST_ELEM(identifier='19:1',

                     INTEGRALE=_F(GROUP_MA=('Wire_contact_load', ),

                                  NOM_CHAM='CONT_NOEU',

                                  NOM_CMP=('RNZ', 'RN'),

                                  TYPE_MAILLE='2D'),

                     RESULTAT=Nonlin)

Then I printed the generated results into a table. The final load is
about 4N, which is wrong. The results from the table are present in
the PDF (in a quite ugly manner, as I did it pretty quickly). It is
easy to see nodes in the contact that have forces up to 50N. I used
Paraview and a sequence of filters to get the total force. The history
plot generated by Paraview is also present in the PDF. Paraview
outputs a final force of about 720N, which is infinitely closer to what
is expect and makes sense.

QUESTION

Am I making something wrong? Is the POST_ELEM code averaging the
values? Is it taking the Gauss points and since those have little to
no data (maybe) from the reaction force, it just prints some kind of
residue?

How would you solve this? Is this a CA bug? I would not expect so.

I would like CA to generate this data automatically so that I could
speed up greatly my other simulations.

EXTRAS

I would like to automate this since it takes a long time to run and to
post-porcess it manually. We are still finding out the best way to
simulate this case, since tungsten properties for small wires
are... interesting. Also WARNING: this case only runs on the Linux
version, since it seems the Windows version cannot create (or has
issues creating) vola files (temporary files); it always died on me
with the CALC_CHAMP and left no glob files ;-;. Another warning, as it
stands right now, the simulation consumes more than 80Gb using
45GB of hard disk and generates a 6.5Gb output file. If you want to run
it, decrease the simulation time to maybe 0.1.

Best regards,

Fernando Oleo Blanco