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
Hi everyone, I am starting this thread to report error in documentation files. May be this post should be made sticky so that everyone can see and post it. I also hope the developers will update the documents.
Offline
Location:
U3.11.01 Page 7
Error:
.........Non-linear statics SSLS111B...
Rectification:
SSLS111B should be SSNL111
Offline
POSSIBLE ERROR in U4.81.01, Documentation for CALC_ELEM, page 15/27
EPSP is "Déformations anélastiques aux points de Gauss" as is written on the documentation, or is it the PLASTIQUE STRAIN?
Regarding the symbol I would say that it is the plastique strain and not anelastique strain!
In Documentation for CALC_CHAMP, page 14/31 there is the same situation!
In addition, in u4.83.02, Documentation for CALC_FATIGUE, in page 13/27 EPSP_ELGA is considered as plastique strain!
Can someone clarify my doubt?
Thank you!
Last edited by argi (2019-07-11 16:16:51)
Offline
Hello,
There seems to be a typographic error in AFFE_CARA_ELEM documentation(u4.42.01) Page 31.
The error is under Opérande CARA = ’ANGL_VRIL’.
The text is , "...transformant ( P , x3, x 2, x2 ) en ( P , x3, y3, z3)"...
whereas it should be "...transformant ( P , x3, y2, z2 ) en ( P , x3, y3, z3)..."
Regards
Anirudh
Offline
Document U4.43.01 DEFI_MATERIAU
Section 7.21 Keyword BETON_RAG
The syntax given below do not match with the code aster/salome meca input. Instead it is something as shown in attached snapshot.
/ BETON_RAG = _F(
Characteristics for the mechanical behavior damage
♦ ENDO_MC = meca_mc [R]
♦ ENDO_MT = meca_mt [R]
♦ ENDO_SIGUC = meca_siguc [R]
♦ ENDO_SIGUT = meca_sigut [R]
♦ ENDO_DRUPRA = will meca_drupra [R]
Characteristics of creep
♦ FLUA_SPH_KR = flua_sph_kr [R]
♦ FLUA_SPH_KI = flua_sph_ki [R]
♦ FLUA_SPH_NR = flua_sph_nr [R]
♦ FLUA_SPH_NI = flua_sph_ni [R]
♦ FLUA_DEV_KR = flua_dev_kr [R]
♦ FLUA_DEV_KI = flua_dev_ki [R]
♦ FLUA_DEV_NR = flua_dev_nr [R]
♦ FLUA_DEV_NI = flua_dev_ni [R]
Characteristics of L has formation of the gels and of the RAG
♦ GEL_ALPHA0 = gel_alpha0 [R]
♦ GEL_TREF = gel_tref [R]
♦ GEL_EAR = gel_ear [R]
♦ GEL_SR0 = gel_sr0 [R]
♦ GEL_VG = gel_vg [R]
♦ GEL_MG = gel_mg [R]
♦ GEL_BG = gel_bg [R]
♦ GEL_A0 = gel_a0 [R]
♦ RAG_EPSI0 = rag_epsi0 [R]
♦ PW_A = pw_a [R]
♦ PW_B = pw_b [R]
)
Offline
V7.31.121
1. Dimension of mesh file provided is smaller by factor of 10.
2. rectify section 1.2 :: sigma_y=6E6 Pa; ET=−6E5 Pa
3. rectify section 3.2 :: number of nodes=128
Last edited by nirmaljoshi (2020-05-18 06:19:31)
Offline
Hi all,
Just because it's too good not to share it, I suggest looking at p.18 of CALC_CHAMP documentation
but only if you do like cocktails
Offline
Very funny !
Automatic translation....
It is a document written especially for James Bond. In a shaker, not with a spoon
Code_Asterの開発者
Offline
Hi All,
Out of many errors scattered over various documents, one has costed me few hours. It is about U4.72.04 CREA_CHAMP - English version. At Section 3.4, the key word 'ASSE' is translated as 'ADZE'. I took it seriously, thinking that 'ASSE' has been replaced by 'ADZE' in the current stable version.
Finally I could know the truth only by looking into the French version, but only after few frustrating hours!!
It was heard from TdS (W W W.code-aster.org/forum2/viewtopic.php?id=23420) that works were on for improvement of machine-translations. But sadly the same is not reflected yet in the documentation, at least up to a satisfactory level.
IMHO, ANY of the following would improve the current situation:
i) Crowd funding of Human translation
ii) something like supervised machine translation
iii) Opening wiki based documentation, accepting Community input. Seems to be a feasible idea. It is supposed to supplement the current documentations and NOT TO supplant those.
If none of the above are feasible, then at least, a message file completely in English, would go a long way to rescue many non French speaking users like me (as was hinted in the post W W W.code-aster.org/forum2/viewtopic.php?id=23420).
Best regards.
Sukumar
Last edited by sb1966 (2020-08-31 21:26:10)
Offline
Hi,
I think I may have found either a mistake or a potential shortcoming of CA.
Document U4.81.04 CALC_CHAMP, version 26/05/2020 revision c281cb952c14, section 2.6.5 criteria (Operand CRITERIA).
In the section EP**_**** it says:
Fields EPEQ_* are calculated starting from the fields EPSI_* (deformations in small
displacement), fields EPGQ_* are calculated starting from the fields EPSG_* (deformations
of Green-Lagrange) and fields EPMQ_* are calculated starting from the fields EPME_*
(mechanical deformations).
Is there no equivalent for deformations of type EPMG_**** (section 2.6.2, DEFORMATION)? Or is it that the EPMQ_* criteria is for EPMG_*? It would make sense to me. If the documentation is correct, then there is no VMIS criteria for "mechanical" deformations with large displacements criteria. Maybe I am missing something. This paragraph is the same in the french version.
I also agree with Sukumar, the ADZE translation error caught me by surprise. And does not seem to have been fixed in over a year.
Is the internal translation system that you are using consuming the European IATE database? It is wonderful for technical terms and it is open https:// iate.europa.eu/
Regards,
Fer
Offline
Sorry, I forgot another bug. This one is either in the documentation or in Code Aster itself.
In the Non-linear-behaviours (Comportements non linearies), under the entry 4.4.2.4 VMIS_ISOT_NL it indicates the existence of ECRO_NL_FO. However, that function does not exist in DEFI_MATERIAU, only ECRO_NL is indicated to exist.
ECRO_NL exists in Salome Mecha AsterStudy module, but not ECRO_NL_FO. So the question becomes, does ECRO_NL_FO exist or not? I would expect it to exist, since most behaviour can take function (mainly to model temperature dependence), so I suppose this is a documentation and AsterStudy issue. But maybe CA never implemented the function variant.
Regards,
Fer
Offline
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
Offline
Hi,
My question is about the transformation matrixes that permit to pass from stress at gauss point to nodes that are exposed in R3.06.03.
It's written :
"
- des matrices M1P carrées, qui sont à utiliser lorsque le nombre de points de GAUSS utilisé pour le calcul des contraintes aux points de GAUSS k est identique au nombre de nœuds sommets,
- Puis les matrices M1P (données après) sont utilisées pour calculer les contraintes aux nœuds. Il s'agit des éléments :
• en 2D : QUAD4, TRIA6, QUAD8 sous-intégré, "
TRIA3 elements should be included in this group ? Since they have 3 gauss points and 3 sommets.
Thanks !
Offline
Dear colleagues,
In the document U3.11.07 (POU_D_EM) commands like AFFE_SECT and AFFE_FIBRE are mentioned, but I nowhere found explanations or examples about them. An older way to set multifibre beams, maybe?
Best regards,
================
Helio
---------------------------------------------------
Helio Carlos Bortolon,
Mech Engr, M.Eng. and Maggoo
---------------------------------------------------
Offline
Dear colleagues,
In the document U3.11.07 (POU_D_EM) commands like AFFE_SECT and AFFE_FIBRE are mentioned, but I nowhere found explanations or examples about them. An older way to set multifibre beams, maybe?
Best regards,
================
Helio
Hello,
this is quite strange. There is one fortran routine in source files for processing this two commands but nothing else. Maybe somebody have not finished this yet, but why is it in documentation (from 2015).
mecour
Offline
Pages: 1