Atom topic feed | site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban
You are not logged in.
Pages: 1
Hello CA users,
We tried to make modal analysis on a simple straight beam, encastred at one of its end, as test, before a bigger 'project'.
The geometry was created and meshed in the Salome, and exported into MED.
The problem .comm file was established by hand, and the running was done through the ASTK.
Every thing was good, if the beam axis was positioned in the direction in the X global direction.
But if we changed it into global Z or Y, or whatever else, the ASTER drop an exception right after the reading the MED (I guess).
The strange thing is, that if we create the mesh through the .mail file, it runs fine, even if the beam axis is in the global Z direction.
Without the use of the Orientation keyword in the AFFE_CARA_ELEM!
So we guess, that the problem comes from the MED representation of the mesh, and not from the command file.
We tried a lot of things: change the group names, rectangle section - circle section, quadratic and linear mesh, Salome 6.3, 6.4, 6.5, ASTER 10 and 11 version form the CaeLinux, etc.
What can be the problem? Do we need the orientation keyword? If the answer is yes, why the problem can be run, if we use the .mail file. Is there any difference in the MED and .mail from this point of view?
I've attached both of the problems (with MED, and with aster mesh file)
Thank you for any feedback!
(An other question: we use the ASTK in interactive follow-up mode. Is there any way, that the small text window with the messages does not disappear quickly, right after the calculation finishing?)
Best regards,
DT
Last edited by dezsit (2012-06-28 14:53:35)
Offline
hello
there are so many filee in your post than it is difficult to find it's way out
anyhow i made my on run with beamModal2_z.comm and beamModal2_z.med
and it runs fine in 10.6 and 11.1.15
so????????????
ido not know how to keep the terminal open
but its output is written in the .mess file
jean pierre aubry
consider reading my book
freely available here https://framabook.org/beginning-with-code_aster/
Offline
I don't know what exception you get, but remember that Code_Aster considers a structure formed by a beam as along X-axis wherever it is defined in med file, while considers a plane structure as in x-y plane, even if it is defined in x-z, y-z or any other plane.
Corrado
Offline
Hi,
thank you for your answers,
Dear Jean Pierre Aubry
yes I'm attached a lot of files, sorry that without any explanation... ,
the comm and mess files without Mail in thier filenames mean the problematic "versions", used the MED mesh.
If you take a look on the mess file beamModal2_z.mess in my attached zip, than you can see the exception, what we got anytime, except, if the beam axis oriented in the global X axis.
Yes, it really very strange to me, after so many tests, that you did not get any exception with the med version. Maybe the problem is somewere in our system (which is an "original CaeLinux2011 installation in a virtual machine...)?
Some other point: I dowloaded a problem, with beams and shells in one mesh, which used a MED file for the mesh, an it runs fine on our system (and there was not any orientation keyword in it). The beams are oriented various way in it...
Yes I figured it out, that the terminal shows similar messages, what I can find in the mess file, it could be only a nice to have feature of the ASTK
Dear Corrado
I know the orientation rules, the strange thing is that some other problems run fine without the usage of the orientation, (for example the same study in the zip, with the .mail mesh)
so I supposed, that the CA has a default projection rule (as in case of some other fea codes),
according to what the local systems derived from the global system, that is the reason why the orientation keyword can be omitted.
Thank you for your answers again,
Best regards
DT.
Offline
hello
i have made beams analysis for years now with Code_Aster and never met the type of problem you mention
if you do not use the ORIENTATION keyword the default behavior is as such
local x axis is along the beam oriented from lower to higher node number
local y axis is always lying in the XY global plane
in addition if the beam is STRICTLY lying in the global Z direction
then the local y axis is the parallel to the global Y axis
this is explained in here http://www.caelinux.org/wiki/index.php/ … ierreaubry
as there is a default behavior ommitting the ORIENTATION keyword cannot lead to an error msg, only unexpected results
what in can see in beamModal2_z.mess is that error code is 134, i had this once
http://www.code-aster.org/forum2/viewtopic.php?id=15020
maybe it is a Line Feed or a CR coming from a window$ edited file
one other thing, before performing a modal analysis i advise you to run a static analysis with a simple load case, for example ownweight, it is easier to find out if something goes wrong
jean pierre aubry
consider reading my book
freely available here https://framabook.org/beginning-with-code_aster/
Offline
Hello,
thank you for the reply,
I expected same rules for the orientation, what you described before (from my experiences with other codes),
but we did not find it in the manual up to know, or maybe we was just careless, so thank you for the explanation...
We got a lot of exception code with this problem, 139 for example, but I try to figure it out, according to your link, how we can solve this issue.
The really annoying thing is, that we solved a lot of case (not only from the CA cases, but tutorials, and cases from our old projects), static, and modal,
contact, etc., 3D solid, shell, beam, and this problem was the first, what we was not able to solve at all.
So any other idea would be highly appreciated.
Thank you, and best regards
DT.
Offline
Hi,
Your problem might be related to this one : http://www.code-aster.org/forum2/viewtopic.php?id=16783
You should a newer version (11.0.10 is one year old).
TdS
Offline
Hello,
thank you for your response, we tried it both of the installed Aster version (10.5, and 11.0 ) in CaeLinux, with the same results.
The installation of the newest version of the Aster is on the way, so I will report, if we have any progress,
BR.
DT.
Offline
Pages: 1