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
Pages: 1