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

You are not logged in.

#1 Re: Salome-Meca installation » salome meca 2021 installation problems » 2021-11-16 20:31:21

Hi!

for me help EnKiNekiDela hint about bulding executable in the desktop and running through xfce4 window (Thanks!). Trying to run salome_meca through wsl terminal indirectly ends with failure though. Working through xfce has unfortunately some inconvienient lags : /

@ k_zurawski - I assume you are Polish too - don't hesitate to write me message in any question, I'll be glad to help.

Best regards,
Filjan

Edit:
PS: I forgot to mention that this time I've used Ubuntu 18.04.

#2 Re: Code_Aster usage » Store last converged step » 2021-11-11 15:32:09

APereira wrote:

Hello,

In order to debug my simulation, I want to save the last converged step in my rmed before the simulation crashs. Is it possible to do so in Salome Meca / Code_aster ?

Thanks a lot for your help

Adrien

Hi!

Add in .comm python clause try/except, like:

try:
    res = STAT_NON_LINE
   ....
except:
    pass

Regards

#3 Re: Code_Aster usage » Help with first problem » 2021-10-28 20:30:44

Consider practice with some essential examples from web and books like Thakore's guide https hmm/www.amazon.com/Finite-Element-Analysis-Source-Software-ebook/dp/B07J9X769N

regards

#4 Re: Code_Aster usage » Help with first problem » 2021-10-27 17:56:22

clancy70 wrote:

Hi,
I have tried to get a very simple problem solved in aster, I am not familiar with this software very much and followed the first tutorial for the portal frame, and now tried my own problem and want to see what I am doing wrong. The problem is a beam supported at two ends with a traction applied to one surface.

The problem I think is I am applying a boundary condition to a line, when this is a 3d problem, I may need to define a group or something I believe for this group of nodes, as aster is warning that there are 'edge elements' defined. So I think I need to say that this group of elements in Gmsh actually corresponds to nodes of the 3d elements, or something.

I have attached the problem anyway in case anyone has time to give me guidance.

Thanks

Hi!
You tried to impose force on beam-like element which is absent in your mesh - pointed group is another type i.e. faces of 3d elements. Probably you need FORCE_FACE keyword in AFFE_CHAR_MECA.
Regards
Filjan

#6 Re: Code_Aster usage » Unexpected influence of boundary conditions on buckling modes » 2021-10-25 15:55:49

jeanpierreaubry wrote:

please post her a med 4.0 file so i can run the problem on 15.2 version of code_aster

Here you are. Attached mesh was converted into MED 4.0.0 from 4.1.0 in salome_meca, because I did in gmsh and used C_A 15.4 then.

Best regards
Filjan

#7 Re: Code_Aster usage » Unexpected influence of boundary conditions on buckling modes » 2021-10-24 17:22:49

jeanpierreaubry wrote:

hello

in the vicinity of group "force" the boundary conditions do not represent a symmetry in any one of the two conditions

jean pierre aubry


Of course - symmetry boundaries wasn't purpose here - I mean discrepancy in results in symmetrical areas mesh (see picture). 
Boundary conditions shouldn't introduce any eccentricity in buckling modes, but mode occured uneven.

#8 Code_Aster usage » Unexpected influence of boundary conditions on buckling modes » 2021-10-24 13:41:37

filjan
Replies: 6

Hi the Code_Aster Community!

I obtained unexpected results from simple linear buckling analysis - I've noticed 2 points for discussion:

1. Depending on imposing rotation DOF on boundary edges I got a lot of artificial, unexpected buckling first multipliers (and modes). At last 8th buckling modes with restricted rotations corresponds to the first with free rotations (see attached pictures and snippets from .mess file below)! How to explain this first 7 unreal buckling modes?

2. Whole model is symmetrical to the XY plane, and the first real buckling mode should also be symmetric, but on picture you can find the bigger positive DZ displacement than in negative direction. What can be source of this discrepancy?

In the attachment you can find pictures, .comm file and  .rmed mesh and .mess file

A)

First minimum buckling multipliers with free rotations (with COQUE_NCOU=5)
------------------------------------------------------------------------
Calcul modal : Méthode d'itération simultanée
                    Méthode de Sorensen

numéro    charge critique    norme d'erreur

1       6.07851E+00        3.42566E-10

2       7.54621E+00        2.42043E-10

3       7.65019E+00        1.62089E-10

4       1.00785E+01        1.03446E-10

5       1.04750E+01        1.15403E-10

6       1.13024E+01        6.11925E-11

7       1.25364E+01        8.58257E-11

8       1.36543E+01        5.32246E-11

9       1.42141E+01        4.96179E-11

10       1.47606E+01        3.89146E-11

Norme d'erreur moyenne   :  1.25432E-10

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

B)
First minimum buckling multipliers with imposed zero rotations on boundary edges (with COQUE_NCOU=5)

------------------------------------------------------------------------
Calcul modal : Méthode d'itération simultanée
                    Méthode de Sorensen

numéro    charge critique    norme d'erreur

1      -6.09552E+00        2.48475E-13

2      -5.81936E+00        3.22682E-14

3      -4.53943E+00        2.11344E-14

4      -3.49609E+00        2.73799E-14

5       3.48710E+00        2.97868E-14

6       4.53262E+00        2.53528E-14

7       5.81460E+00        4.86050E-14

8       6.03323E+00        1.60771E-11

9       6.07375E+00        4.76493E-13

10       6.82361E+00        1.92509E-13

Norme d'erreur moyenne   :  1.71791E-12

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

Best regards
filjan

#9 Re: Salome-Meca installation » salome meca 2021 installation problems » 2021-10-10 16:26:55

Hi massimobrivio,

I have same problem in WSL2 on Ubuntu 20.04, on Win10

./salome_meca-lgpl-2021.0.0-1-20210811-scibian-9 --soft
not exist: /etc/krb5.conf
not exist: ${XDG_RUNTIME_DIR}
*****************************************************
INFO : Running salome_meca in software rendering mode
*****************************************************
runSalome running on DESKTOP-3H9G6D5
ERROR:salomeContext:Unexpected error:
Traceback (most recent call last):
  File "/opt/salome_meca/Salome-V2021-s9/modules/KERNEL_V9_7_0/bin/salome/salomeContext.py", line 278, in _startSalome
    res = getattr(self, command)(options) # run appropriate method
  File "/opt/salome_meca/Salome-V2021-s9/modules/KERNEL_V9_7_0/bin/salome/salomeContext.py", line 357, in _runAppli
    runSalome.runSalome()
  File "/opt/salome_meca/appli_V2021/bin/salome/runSalome.py", line 925, in runSalome
    clt,args = main()
  File "/opt/salome_meca/appli_V2021/bin/salome/runSalome.py", line 851, in main
    searchFreePort(args, save_config, args.get('useport'))
  File "/opt/salome_meca/appli_V2021/bin/salome/searchFreePort.py", line 116, in searchFreePort
    queue = Queue()
  File "/opt/python/3.6.5/lib/python3.6/multiprocessing/context.py", line 102, in Queue
    return Queue(maxsize, ctx=self.get_context())
  File "/opt/python/3.6.5/lib/python3.6/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/opt/python/3.6.5/lib/python3.6/multiprocessing/context.py", line 67, in Lock
    return Lock(ctx=self.get_context())
  File "/opt/python/3.6.5/lib/python3.6/multiprocessing/synchronize.py", line 163, in __init__
    SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
  File "/opt/python/3.6.5/lib/python3.6/multiprocessing/synchronize.py", line 60, in __init__
    unlink_now)
FileNotFoundError: [Errno 2] No such file or directory
singularity exit code: 1

If you solve the problem, don't miss to share solution please.
regards
Filjan

#10 Re: Salome-Meca installation » Installation on Ubuntu 20.04 » 2021-10-10 11:39:47

Hi community!

I encountered failures during installation singularity-container on my Ubuntu 20.04. Singularity is vital for the newest S_M 2021. For me helped belowed snippet (unfortunately i'm not allowed to paste direct link), which one I'd like to share:

Source: github ' How can I get singularity container on Ubantu 20.04 #5390 ' issue

qhaas wrote:

Luckily for those not wanting to compile from source, most of the binaries in the (well maintained) EPEL EL8 singularity 3.8.x rpm are static linked, so it is one of the cleaner conversions using alien:

$ grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Ubuntu 20.04.2 LTS"
$ alien --version
alien version 8.95
# WARNING:  singularity version numbers subject to change, browse the yum repo to get up-to-date URL
wget https:/ /dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/s/singularity-3.8.0-1.el8.x86_64.rpm
$ sudo alien -d singularity-3.8.0-1.el8.x86_64.rpm
...
$ sudo apt-get install ./singularity_3.8.0-2_amd64.deb
...
$ singularity --version
singularity version 3.8.0-1.el8

Hope this answer will help someone else.
Regards
Filjan

#11 Re: Salome-Meca usage » [SOLVED] ParaVis not working in Salome-Meca » 2020-04-22 19:01:26

I found the solution in another thread i.e.: "[SOLVED] Open paravis from terminal like code aster or salome"

regards
Filjan

#12 Re: Salome-Meca usage » [SOLVED] ParaVis not working in Salome-Meca » 2020-04-11 13:48:31

Hi!

Do you know how can I run Paravis standalone to SalomeMeca 2019? The abovementioned way doesn't work in the current SM version.

Best regards

filjan

#13 Re: Code_Aster usage » [SOLVED] Unexpected results with FACE_IMPO -> DNOR=0.0 boundaries » 2018-11-24 20:32:03

konyaro wrote:

Hello Filjan,
according to doc U4.44.01  §2.9.1:
"Si DNOR est spécifié, la normale sur un nœud est la moyenne des
normales des mailles sur lesquelles sont affectées les conditions limites et qui ont ce
nœud en commun."

That means that the direction of the normal of the nodes on the edges is at ~45°.

If you split your symmetry conditions into 3 parts it works:

FACE_IMPO=(
    _F(DNOR=0.0,
        GROUP_MA=('F_Side', )),
    _F(DNOR=0.0,
        GROUP_MA=('F_Up', )),
    _F(DNOR=0.0,
        GROUP_MA=('F_Down', ))),

Konyaro


Hi!

Thank your for explanation. Now I see my mistake in defining boundaries smile

regards
Filjan

#14 Code_Aster usage » [SOLVED] Unexpected results with FACE_IMPO -> DNOR=0.0 boundaries » 2018-11-09 14:15:47

filjan
Replies: 2

Hi Code_Aster community!

I've noticed unexpected results after imposing symmetry conditions by FACE_IMPO condition.

Look on the attachment (BoundaryDescription.jpg). You can see two similar models of cylinder with differently imposed symmetry conditions. In my opinion these models should produce identical results, but in the picture (Results.jpg) you see differences. Can someone explain me source of the differences on four faces edges? Is it bug?

I tried to check the influence of mesh density and small deformation assumption on this occurence, but results are same.

[I attach also mesh and .mess file]

regards
Filjan

#15 Re: Salome-Meca usage » Non linear material » 2018-09-22 11:31:37

thomas.helfer wrote:

Hi Raphaël,

to my knowledge, you can't describe such a behaviour using build-in Aster behaviours.

In plasticity, one way to do it would have been to use two yield surfaces  able to describe yield differential effects (such as Cazacu 2004), one for the behaviour and tension and one for the behaviour in compression, and appropriatly choose the two isotropic hardening laws. This is already hard work.


If you manage to do this, contact me as your best options would probably to implement it with MFront.

Best regards,

Thomas

Hi Thomas,

i'm struggling now with similar to rbravo's problem. Can you explain what means "appropriate two isotropic laws"? Can you extend your idea about two different isotropic hardening laws?

Best regards,

FilJan

#16 Re: Code_Aster usage » XXXX_ELGA to table » 2018-08-23 20:30:28

konyaro wrote:

Hello filjan,
you can print all the ELGA values with IMPR_RESU:

IMPR_RESU(FORMAT='RESULTAT',
            RESU=_F(RESULTAT=resu01,
                    NOM_CHAM=('SIEQ_ELGA'),),
                            UNITE=10,)

but it seems that you cannot post-process them with POST_RELEVE_T.

Any other ideas welcome!

Konyaro

Hello Konyaro,

thank you for reply, it's something I've been looking for. How can I change values from RESULTAT-like results to python ? I mean something like  EXTR_TABLE() with ordinary tables.

regards
Filjan

#17 Code_Aster usage » XXXX_ELGA to table » 2018-08-20 19:07:37

filjan
Replies: 2

Hi!

How can I extract _ELGA values like SIEQ_ELGA to table? I tried simple POST_RELEVE_T but then encounter exception:

   !----------------------------------------------------------------------------------!
   ! <EXCEPTION> <POSTRELE_47>                                            !
   !                                                                                                       !
   !  occurrence 1 du mot clé facteur ACTION                              !
   !  le ou les champs élémentaires mis en jeu est ou sont donnés aux points de gauss !
   !  ce ou ces champs ne sont pas traités.                                   !
   !----------------------------------------------------------------------------------!
   
Does exist any direct way to get values from Gauss points in C_A?

Best regards
Filjan

#18 Re: Code_Aster usage » bi-linear gasket stiffness » 2018-08-04 09:28:41

Hi,

have you found any workaround to solve this problem? I'm struggling now with similar issue.

Thread is rather old, but I hope someone can help.

regard
Filjan

#19 Re: Code_Aster usage » COQUE 3D central nodes DEPL =0 » 2018-05-23 17:09:37

Hi!

It's disadvantage of code_aster postprocessing with shells. To correctly display displacements you must first project results onto QUAD8 or similiar elements type without center node.

regards
Filjan

#20 Re: Code_Aster usage » [RESOLU] Crack propagation in 3D solid stops after a few steps » 2018-04-08 11:28:24

Hi!

I suggest use more uniform size of mesh in the whole cross-section of pin (see picture). Refine mesh in the core, or derefine in the surface. Homard then will better handle refinement. You can try decrease the maximum crack advance, advance of few refined sizes of element should be appropriate. In the matter of CALC_G and LISSAGE function it's hard to give a universal tip.

I'm not sure, about one thing. If C_A renumerates nodes from initial mesh during refinement,  it can provide unexpected results when you define boundary to nodes by their numbers.

regards
Filjan

#21 Re: Code_Aster usage » [RESOLU] Crack propagation in 3D solid stops after a few steps » 2018-04-05 20:12:50

Hi,

your problem is very interesting. I'll try help you. At first I recommend change a crack growth solution algorithm to geometrical (this change can demand changes in whole calculation loop). Are you sure about stiffness values of discrete elements? Also I recommend group similar nodes (in terms of boundary values) - then it'll be easier to check boundary conditions. You can also try higher values of LEGENDRE polynomial.

regards
Filjan

#22 Re: Code_Aster usage » [RESOLU] Crack propagation in 3D solid stops after a few steps » 2018-03-24 10:34:09

Hi!

Without .mess file, and mesh file, it's almost impossible to find the problem. When you will attach these files, i'll try help.
regards
Filjan

#23 Code_Aster usage » <Exception> <CALCUL_37> due to xfem+contact » 2018-02-24 16:45:13

filjan
Replies: 0

Hi!

Last time I've noticed probably bug:
   !--------------------------------------------------------------------------------------------------------------------------------------------------!
   ! <EXCEPTION> <CALCUL_37>                                                                                                                                    !
   !                                                                                                                                                                                       !
   ! Erreur utilisateur :                                                                                                                                                       !
   !   -> Le TYPE_ELEMENT MEDPTR3_XHC  ne sait pas encore calculer l'option:  VARI_ELNO.                              !
   !                                                                                                                                                                                      !
   !   -> Risques & Conseils :                                                                                                                                           !
   !    * Si vous utilisez une commande de "calcul" (THER_LINEAIRE, STAT_NON_LINE, ...), il n'y a pas                 !
   !      moyen de contourner ce problème. Il faut changer de modélisation ou émettre une demande d'évolution. !
   !                                                                                                                                                                                     !
   !    * Si c'est un calcul de post-traitement, vous pouvez sans doute "éviter" le problème                                  !
   !      en ne faisant le post-traitement que sur les mailles qui savent le faire.                                                        !
   !      Pour cela, il faut sans doute utiliser un mot clé de type "GROUP_MA".                                                        !
   !      S'il n'y en a pas, il faut faire une demande d'évolution.                                                                                   !
   !--------------------------------------------------------------------------------------------------------------------------------------------------!

Exception appears during CALC_G operation, and only with contact (between lips of the xfem crack) into STAT_NON_LINE.
How can I solve this problem?

regards
Filjan

#24 Re: Code_Aster usage » MACR_ADAP_MAIL and projection stress field into refined mesh(MAJ_CHAM) » 2018-02-10 15:50:40

Anirudh wrote:

Hello,
Does that imply that hex mesh refining is not possible?

Thanks
Anirudh


No. You can refine hex mesh smile just it's impossible to simultaneously project stress filed into new refined mesh.

#25 Re: Code_Aster usage » MACR_ADAP_MAIL and projection stress field into refined mesh(MAJ_CHAM) » 2018-02-01 16:47:05

Thank you for reply Nicholas. I recommend add this restriction to official MACR_ADAP_MAIL documentation - it will save a lot of troubles in the future : )
regards
Filjan