Atom topic feed | site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban
You are not logged in.
Hi.
I've attached a simple model to this post. It consists of an aluminium mast section constrained by a bulkhead (built-in at a central node) at the top and a 1000N vertical load applied to each node at the base.
When the plate offset is zero, the nodal forces on the base nodes and the reaction forces on the bulkhead nodes match my expectations. Also I have calculated a force resultant about the central node at the top, which looks ok. Although the FX force should be zero.
However, when the plate offset is 5mm, the nodal forces, reaction forces and resultant force make no sense whatsoever.
Is this a major bug? Can anyone please explain this????
I have attached the output table results as well, although it only takes a couple of seconds to run the model. I have run this with STA10.2.0 and STA10.2.29
Thanks,
Todd.
Last edited by todd_alan_martin (2010-12-13 03:05:16)
Offline
Hello.
Has anyone looked at this problem. Surely someone thought to check the nodal force and reaction sums when implementing plate element offsets???
Offline
Hi Todd,
Thanks a lot for your feedback. We'll look into it as soon as possible (which could mean early next year ;-)).
TdS
Offline
Hi Thomas.
Thank you for your response. It relieves me to know that someone is at least looking at this.
Todd.
Last edited by todd_alan_martin (2010-12-15 22:44:44)
Offline
Hi
When you finish the correction of datareovery for Incorrect nodal forces with plate offset.
i will show you the error of offset implementation in Aster for all procedures.
Merry christmas and a happy new year
thanks
pdupuis75
Offline
I agree Pierre.
The theory is nicely presented in the documentation.
Perhaps pdupuis75 has discovered a flaw in the implementation. Can you enlighten us please?
Offline
the error is not in the implementation but it's in the concept itself
with positif offset, offsetted model have the gaps between elements
negatif offset have the overlaps between elements.
stiffness and mass of whole model are incorrectly computed, all linear procedures
linear,mode,direct,modal of time and frequencies response are not correct
Aster's plats w/wo offset don't have geomertique stiffeness, buckling is not not correct and Stat_NONLIN
or DYNA_NON_LINE are difficul to get convergence
two manpowers(Massin,Deroches) are nedded at leat 10 years for compleness of Aster's plats and solve this problem
it's small in comparision with power plant's life
Pdupuis75
Offline
Hi Todd,
I have submitted the problem to our bugtracker. I'm not expert on this subject so it's hard for me to tell what's wrong apart from the fact that the nodal forces seem quite higher when adding offset.
Note : the release this week fixed something related to plate offsets but did not affect the nodal forces in your case.
TdS
Offline
Hi pdupuis75
Are you talking about COQUE_3D models or DKT / DST models?
The documentation states that plate offset is not supported for COQUE_3D.
Offline
Hi Todd,
1) I have talked all Aster's plats, DKT/DQT and DST.
i have showed in prevvious posts, DKT is a simple case of DQT
it's sufficient a parameter to distigush thin or thick plat to simplify
the redundant coding for each separated DKT/DKQ(3,4 nods) elements.
Aster's plats is not at industrial level, able to handle any 2D discretized geometry
they don't carry out well force,moment between elements,etc...
they're needed to be completness(see previous post).
2) Aster's plat and COQUE_3D by examination of R3's involved notes, i guess that
Aster people have abandonned R/D about the plats. completeness and finding out a way
to go non linear domain. they have created a new original shell element COQUE_3D(6,9 nods)
in geometry non linear with some tricks indenpendant german(Stutgard,Karlsruhe,Bochum)
and netherland schools. note that shell element is not popular accepted in industrial codes
due to perfomance computation lack features for procedures, hard to elaborate finite elemnt model
loading must be consistant etc...
but the developpement is not yet achieved, because straight beam modeled in COQUE_3D elements
can not bend into a circle however it takes a advantage over Plats element for buckling,
because COQUE_3D has now unsymetrique(left rotation) gemetric stifnness.
but it seems that bucling procedure with symtrized geometric stiffness is abandonned
by many developpers at the end of 90 due to some problems.
Thanks
Pdupuis75
Offline
Hi Pdupuis75
Aster's plats is not at industrial level, able to handle any 2D discretized geometry
they don't carry out well force,moment between elements,etc...
Have you produced a model which demonstrates this to the code-aster developers???
but the developpement is not yet achieved, because straight beam modeled in COQUE_3D elements
can not bend into a circle however it takes a advantage over Plats element for buckling,
because COQUE_3D has now unsymetrique(left rotation) gemetric stifnness.
but it seems that bucling procedure with symtrized geometric stiffness is abandonned
by many developpers at the end of 90 due to some problems.
Are you talking about the code-aster developers or FEA software developers in general? Is that the end of 1990 or version 9.0 you're referring to??? Please be precise. I am not a mind reader!
Offline
Since there has been no response from the EDF team regarding this problem, I am raising it again.
Is anyone looking into this????
Without a bug-tracker, how is anyone supposed to know what bugs have been logged, assigned, or fixed? All we get is stone cold silence.
Is the plan to sneak the fix into a future release without highlighting it, so that no one questions the ISO certification?
Todd.
Offline
Dear Todd,
I would like to thank you for your precious feedback. Be sure that the Code_Aster's team considers the bug detection of the forum's members as an high value information.
We are opening a bug thread in our bug tracker and we will inform you of the advance of its analysis and fix as soon as possible.
Thanks,
The Code_Aster Team
Offline
Hi,
About nodal forces with plate offset, it is known that the DST modelisation in Aster is wrong, wheras DKT is correct.
For thick plates, I recommend to use the Q4G modelisation instead.
There is a bug in DST and, as this model is tricky, we plan to suppress it and replace it with Q4G (and T3G which will be developped).
XDesroches
Offline
Hi Todd,
in responses to your quetions
1a) "Have you produced a model which demonstrates this to the code-aster developers???"
test written is autosdescritif.
1b) i have mistaken due to my auwful english. it must read that end of nineties.(1999,2000,2001)
2) i don't know any code's aster developpers, except some SAMCEF's developpers throught out their publications.
Hi Descroches,
my opinion that you have to continue to do completeness for DKT,DKQ, with Q4G
you will be falling into Bath's formuulation QUAD4 MITC.
It's a chanlenge for you to pass all Macneal's tests and finding the way into large displacement results.
in expectant accuracy of QUAD4 model,
Todd is right to say that 'VERY long long time' to reach the commercial results code's
pdupuis75
PS: note that linear stiffness of Triangular element is always 'stiff' due to complete form fucntions.
it's up to you to discover this chalange!!!
Offline
Hi,
We have fixed the remaining problems (in 10.3.22 version dated last Tuesday) with plate elements regarding :
- computing of the stress tensor among all layers (SIEF_ELGA field) with or without offset
- for the ELAS / ELAS_COQUE / DEFI_COQU_MULT material
- for the DKT/DST elements
However there are things you need to know :
- Shear stress in Code_Aster cannot account for the change introduced by offset. Basically this means that the SIXZ and SIYZ components of the stress tensor computed by SIEF_ELGA/SIGM_ELNO option are not correct when offset is added (e.g. they do not verify the free border condition and are not zero).
- the Q4G element still has some problems with the computed stresses (a bug has been filed).
Since the FORC_NODA field is computed by mean of the SIEF_ELGA field this explains the problem with nodal forces and offset. Note however that nodal forces do not have any physical meaning (except of course when they are summed) and one usually prefers using the stress tensor or the generalized stresses for structural elements.
TdS
Offline
Hi Thomas
However there are things you need to know :
- Shear stress in Code_Aster cannot account for the change introduced by offset. Basically this means that the SIXZ and SIYZ components of the stress tensor computed by SIEF_ELGA/SIGM_ELNO option are not correct when offset is added (e.g. they do not verify the free border condition and are not zero).
- the Q4G element still has some problems with the computed stresses (a bug has been filed).
Since the shear stresses are parallel to the offset direction, ie. normal to the surface, why is the free surface condition unsatisfied?
Since the FORC_NODA field is computed by mean of the SIEF_ELGA field this explains the problem with nodal forces and offset. Note however that nodal forces do not have any physical meaning (except of course when they are summed) and one usually prefers using the stress tensor or the generalized stresses for structural elements.
Summed over what? If I weld a cylindrical shell to a solid hemi-sphere and then press that solid against a rigid surface, can I not reliably extract the nodal force distribution transferred from the solid to the base of the cylindrical shell?
Offline
A late answer :
Since the shear stresses are parallel to the offset direction, ie. normal to the surface, why is the free surface condition unsatisfied?
Indeed the generalized stress (e.g. the QX and QY components of the EFGE_ELNO field for a plate/shell) are not impacted by the offset. But the SIEF_ELGA field is, and as of now the distribution of the SIXZ, SIYZ (which are perpendicular to the offset) is not correct when offset is added. Note that the shear stress (I mean from a Cauchy Tensor point of view) is computed after the solving so this does not impact results.
Summed over what? If I weld a cylindrical shell to a solid hemi-sphere and then press that solid against a rigid surface, can I not reliably extract the nodal force distribution transferred from the solid to the base of the cylindrical shell?
Yes you can do so safely. I'm just used to warning FEM software users of the "danger" represented by nodal forces. They have no real meaning pointwise since they are mesh-dependent (but an experienced user like you knows that).
Ideally you would want to sum nodal forces on whole part of the structure (they're usually null everywhere except on the border and where density forces are applied).
TdS
Offline