Generalities ==== Principles ---- There are three main categories of operands: * Operands applying kinematic conditions or Dirichlet loads, i.e. relationships between degrees of freedom. In AFFE_CHAR_MECA, these conditions are applied by dualization (Lagrange double method, see [:external:ref:`R3.03.01 `]); * Operands applying loads such as "forces" or Neumann loads, applied in weak form, which involves the use of a numerical integration scheme. Some loads involve the presence of edge elements in the model; * Operands applying special loads, including the mixed type of Dirichlet/Neumann. Most operands are built on the same principle: * Specification of the place of application of the boundary conditions by standard keywords GROUP_NO, GROUP_MA, and sometimes SANS_GROUP_NO and SANS_GROUP_MA. * Specification of the affected components, which fall into three groups: * Standard components of the quantity considered. It's the DEPL_R size (or DEPL_C or DEPL_F), representing the degrees of freedom of the mechanics problem * Combined components DNOR and DTAN, which build a combination between components of the quantity DEPL_R on considerations relating to tangents and to the normal; * Components in forces, moments or pressure using either the quantity FORC_R (or FORC_C or FORC_F), the size PRES_R (or PRES_C or PRES_F); * The affected components must be of the right type depending on the operator used: * Of the real type for operator AFFE_CHAR_MECA; * Of the complex type for operator AFFE_CHAR_MECA_C; * Of the function type (created in particular by one of the DEFI_FONCTION operators), DEFI_NAPPE or DEFI_CONSTANTE) for the AFFE_CHAR_MECA_F operator. This is true for a exception: the argument of COEF_MULT for the keyword factor LIAISON_DDL in AFFE_CHAR_MECA_F must be of a real type. For loads LIAISON_DDL, LIAISON_MAIL, LIAISON_GROUP, and LIAISON_UNIF, the list of applicable components is restricted to certain degrees of freedom. note The use of the GROUP_MA keyword does not presuppose that the uploads will be applied to The elements are also to make life easier for users. For example, for Dirichlet loads, GROUP_MA is used but we get the nodes that belong to to the elements thus designated Assumptions and limitations ---- In addition to defining the assumptions and limitations specific to each load, there are general hypotheses that we will recall here. Linearity of kinematic relationships ~~~~ A kinematic relationship makes it possible to write an equation of the type: .. math:: {\sum }_{i=1}^{r}{\alpha }_{i}{U}_{i} = \beta With :math:`{U}_{i}` the list of :math:`r` degrees of freedom, :math:`{\alpha }_{i}` the coefficients and :math:`\beta` the second member. The kinematic relationships of*code_aster* are **linear** relationships, i.e.: * They cannot depend*a priori* on the deformation or movement of the structure: they remain valid only in the event of small disturbances, unless otherwise specified opposite (see LIAISON_SOLIDE); * The coefficients :math:`{\alpha }_{i}` of the linear relationship cannot be functions of time, since the matrix :math:`B` of Dirichlet conditions is constant for all the transitory. On the other hand, these coefficients can be functions of geometry **initial**; * The second member :math:`\beta` can be a function of time or**initial** geometry; Neumann loadings ~~~~ It is entirely possible that some Neumann loadings are non-linear, and, in in particular, depend on the deformation of the structure. Such loads are commonly called **follower loads**. However, in this case, as the problem becomes non-linear, it is necessary to use an appropriate calculation operator such as STAT_NON_LINE or DYNA_NON_LINE and specify that these loads are in fact considered as followers (see [:external:ref:`U4.51.03 `]). Most Neumann loads (except FORCE_NODALE) are applied in weak form, that is to say, we use a formula of numerical quadrature. In addition, one cannot apply simultaneously a Neumann load and a Dirichlet load on the same node and in the same direction. As a result, it can exist a difference between the theoretical solution and the finite element solution. For example, on an insufficiently meshed structure, it is possible to notice a discrepancy between the sum of the nodal forces corresponding to the gravity load and the value of the real weight, the difference corresponding *roughly* to the number of clamped nodes within the structure. A mesh refinement makes it possible to minimize this difference. We can also make sure that the finite elements, on which kinematic conditions are imposed, are of a size small enough for their weight to be negligible against that of the total structure. Another solution is to split the nodes on which the kinematic condition is imposed and for example, to make a LIAISON_DDL between the two nodes or to use discrete elements. Availability of loads by type ---- The available loads are not necessarily applicable in all three operators AFFE_CHAR_MECA. Here is the list of availability according to the type of operator: .. csv-table:: "**Keyword**", "**AFFE_CHAR_MECA**", "**AFFE_CHAR_MECA_C**", "**AFFE_CHAR_MECA_F**" "**ARETE_IMPO**", "OUI "," NON "," NON" "**CHAMNO_IMPO**", "OUI "," NON "," NON" "**DDL_IMPO**", "OUI "," OUI "," OUI" "**EFFE_FOND**", "OUI "," NON "," OUI" "**EVOL_CHAR**", "OUI "," NON "," NON" "**FACE_IMPO**", "OUI "," NON "," OUI" "**FLUX_THM_REP**", "OUI "," NON "," OUI" "**FORCE_ARETE**", "OUI "," NON "," OUI" "**FORCE_CONTOUR**", "OUI "," NON "," OUI" "**FORCE_COQUE**", "OUI "," NON "," OUI" "**FORCE_COQUE_FO**", "OUI "," NON "," NON" "**FORCE_ELEC**", "OUI "," NON "," NON" "**FORCE_FACE**", "OUI "," NON "," OUI" "**FORCE_INTERNE**", "OUI "," NON "," OUI" "**FORCE_NODALE**", "OUI "," NON "," OUI" "**FORCE_POUTRE**", "OUI "," OUI "," OUI" "**FORCE_SOL**", "OUI "," NON "," NON" "**FORCE_TUYAU**", "OUI "," NON "," OUI" "**LIAISON_CHAMNO**", "OUI "," NON "," NON" "**LIAISON_ CYCL**", "OUI "," NON "," NON" "**LIAISON_DDL**", "OUI "," OUI "," OUI" "**LIAISON_ ELEM**", "OUI "," NON "," NON" "**LIAISON_GROUP**", "OUI "," NON "," OUI" "**LIAISON_INTERF**", "OUI "," NON "," NON" "**LIAISON_MAIL**", "OUI "," NON "," NON" "**LIAISON_OBLIQUE**", "OUI "," NON "," OUI" "**LIAISON_RBE3**", "OUI "," NON "," NON" "**LIAISON_SOLIDE**", "OUI "," NON "," NON" "**LIAISON_UNIF**", "OUI "," NON "," OUI" "**ONDE_FLUI**", "OUI "," NON "," NON" "**ONDE_PLANE**", "NON "," NON "," OUI" "**PESANTEUR**", "OUI "," NON "," NON" "**PRE_EPSI**", "OUI "," NON "," OUI" "**PRE_SIGM**", "OUI "," NON "," NON" "**PRES_REP**", "OUI "," NON "," OUI" "**RELA_CINE_BP**", "OUI "," NON "," NON" "**ROTATION**", "OUI "," NON "," NON" "**VECT_ASSE**", "OUI "," NON "," NON" "**VITE_FACE**", "OUI "," NON "," OUI" Possible error messages ---- Sometimes a mechanical calculation command stops due to a fatal error during the calculation second elementary members due to the loads defined in the order. When the code stops during these basic calculations, an important piece of information in the message Error is the name of the calculation option requested by the code. The name of this option is generally unknown to the user and it is therefore difficult for him to understand the message. In the table below, a correspondence is established between keywords factors and the names of the calculation options they activate: .. csv-table:: "**Keyword**", "**Option name**" "**EVOL_CHAR**", "CHAR_MECA_PRES_R CHAR_MECA_FR3D3D CHAR_MECA_FR2D2D CHAR_MECA_FR2D3D CHAR_MECA_FR1D2D" "**PESANTEUR**", "CHAR_MECA_PESA_R" "**ROTATION**", "CHAR_MECA_ROTA_R" "**PRE_SIGM**", "FORC_NODA" "**FORCE_NODALE**", "CHAR_MECA_FORC_R CHAR_MECA_FORC_F" "**FORCE_ARETE**", "CHAR_MECA_FR1D3D CHAR_MECA_FF1D3D" "**FORCE_CONTOUR**", "CHAR_MECA_FR1D2D CHAR_MECA_FF1D2D" "**FORCE_FACE**", "CHAR_MECA_FR2D3D CHAR_MECA_FF2D3D" "**FORCE_INTERNE**", "CHAR_MECA_FR2D2D CHAR_MECA_FR3D3D CHAR_MECA_FF2D2D CHAR_MECA_FF3D3D" "**PRES_REP**", "CHAR_MECA_PRES_R CHAR_MECA_PRES_F" "**EFFE_FOND**", "CHAR_MECA_EFON_R CHAR_MECA_EFON_F" "**PRE_EPSI**", "CHAR_MECA_EPSI_R CHAR_MECA_EPSI_F" "**FORCE_ELEC**", "CHAR_MECA_FRELEC" "**FORCE_POUTRE**", "CHAR_MECA_FR1D1D CHAR_MECA_FC1D1D CHAR_MECA_FF1D1D" "**FORCE_TUYAU**", "CHAR_MECA_PRES_R CHAR_MECA_PRES_F" "**FORCE_COQUE**", "CHAR_MECA_FRCO2D CHAR_MECA_FRCO3D CHAR_MECA_FFCO2D CHAR_MECA_FFCO3D" "**FLUX_THM_REP**", "CHAR_MECA_FLUX_R CHAR_MECA_FLUX_F" Choice of units ---- For Neumann loads, the forces must be provided: * per mesh unit for linear forces, * per mesh unit squared for surface forces, * and per cubed mesh unit for the volume forces, in line with the definition of material properties (Young's modulus for example). In the axisymmetric case, the required forces are reduced to a sector of :math:`1` radian (to divide the real loading by :math:`2\pi`). The case of large transformations ---- Problem ~~~~ When applying Dirichlet loading to a structure undergoing large transformations (large movements, large rotations), care must be taken to ensure that this load is applicable when the hypothesis of small disturbances is no longer verified. This is naturally the case for the following shipments: * DDL_IMPO but if you use AFFE_CHAR_MECA_F, you have to do it with functions that represent the **real** imposed displacement (curvilinear in general). If we don't do it, interpolation in time makes us go through "false" intermediate states; * LIAISON_MAIL + TYPE_RACCORD =' MASSIF '; * LIAISON_UNIF; * LIAISON_OBLIQUE; * LIAISON_DDL; * LIAISON_CHAM_NO; * CHAMNO_IMPO; * LIAISON_SOLIDE provided you apply the hypothesis of a follower load. On the other hand, for the following loads, the hypothesis of large transformations is not applicable and will cause false results: * FACE_IMPO with DNOR =f (t): the "normal" changes in large rotations; * LIAISON_MAIL + TYPE_RACCORD =' COQUE_MASSIF 'and LIAISON_MAIL + 'MASSIF_COQUE'; * LIAISON_ELEM; * LIAISON_RBE3. Follower loads ~~~~ For non-linear operators (STAT_NON_LINE and DYNA_NON_LINE), some loads may be "followers", that is to say that their application depends on the movement and therefore changes with each Newton's iteration. It is then necessary for the user to specify it with the operand TYPE_CHARGE in the EXCIT factor keyword of these commands (see [:external:ref:`U4.51.03 `]). Specifying that the load is a follow-on sometimes adds a contribution to the stiffness matrix (see for example [:external:ref:`R3.03.04 `]) and can make it non-symmetric. For load EVOL_CHAR, it is not necessary to specify that the loads are followers, they are automatically followed by default. Specifying it will simply activate the additional matrix contribution and therefore to affect the speed of convergence (and not on the accuracy of the result). Loading EFFE_FOND in follower mode is an approximation to reality. It is activated because it simultaneously depends on a load of type PRES_REP. On the other hand, if, in the area where it is applied Loading EFFE_FOND, the movements are not negligible (variation of the section such What non-negligible ovalization or rotation that changes the normal), we are making a mistake. Designation of topological load assignment entities ---- In general, when the entities on which values should be assigned are defined: * On a single node: we use the GROUP_NO operand which must obviously only contain one node; * On a list of nodes: you can use the GROUP_NO operand but also the GROUP_MA operand or TOUT =' OUI 'to affect the whole mesh; * On a single mesh: we use the GROUP_MA operand which must obviously only contain one mesh; * On a list of meshes: you can use the GROUP_MA or TOUT operand =' OUI 'to affect the whole mesh; Some keywords need to define several topological entities (groups of nodes in opposite for example), in this case, the names may vary slightly (GROUP_NO_2, GROUP_MA_ESCL, etc.). In most keywords, it is possible to exclude knots or stitches using keywords such as SANS_ *. This feature prevents redefine groups in your mesh or in the DEFI_GROUP command. Overload and remanence rules ---- To define the domain of assignment as simply as possible, we use the rule of overload defined in the document [:ref:`U1.03.00 `] of which the principles are pointed out: * Assignments are made by superimposing the effects of different loads; * In case of conflict, the last load takes precedence over the previous ones; For example, if the user does: .. code-block:: text FORCE_FACE =_F (GROUP_MA ='G1', FX=12), PRES_REP =_F (GROUP_MA ='G1', PRES = 13) And if the normal for :math:`{G1}` is oriented according to :math:`X`, then everything will happen as if we had done: .. code-block:: text FORCE_FACE =_F (GROUP_MA ='G1', FX= 25) The previous overload rule must be supplemented by another rule to specify what is pass when you can assign several quantities for each occurrence of a load. Either by example: .. code-block:: text FORCE_INTERNE =( _F (TOUT = 'OUI', FX = 1.), _F (GROUP_MA = 'GM1', FY = 2.), ) The overload rule tells us that the second occurrence of FORCE_INTERNE overrides the first. But what is FX worth on a mesh belonging to GM1? Was it erased by the second occurrence? If the only overload rule is applied, FX is not set to GM1. We therefore use a second rule called remanence which specifies that when applying the Overload rule on occurrences, we keep the components that are not overloaded. By applying the remanence rule on the example, FX maintains the value assigned beforehand. So all the elements of the model have a value for FX and the elements of GM1 have a value at both for FX and FY Defining landmarks ---- Most loads are defined in the **global** coordinate system of the mesh, except: * For structural elements; * For the keywords DNOR, DTAN and loads of pressure type. In this case it is necessary to define normals and tangents, or even possibly to use the MODI_MAILLAGE command; * When the ANGL_NAUT keyword is usable; In other cases, it is generally possible to define functions of space. Normals and tangents to meshes ~~~~ One gives here the standard definition of normals and tangents according to the type of edge mesh: * For 2D segment elements, the tangent is that defined by the segment oriented by its first two knots, normal :math:`\underline{n}` is then such that :math:`(\underline{n},\underline{t})` form a direct reference frame .. figure:: images/100002E80000089400000457B8CE41B364143DAC.svg :width: 200 :height: 150 Definition of normal in the two-dimensional case .. figure:: images/10000386000008AF000007A62A00C6CBF19E3838.svg :width: 200 :height: 150 Definition of the tangent in the two-dimensional case * For triangular or quadrangle elements in 3D, the orientation of the normal :math:`\underline{n}` is the one corresponding to the anticlockwise direction of the mesh description. .. figure:: images/1000076C000019D700000707B9DB2381FC2441CD.svg :width: 300 :height: 200 Definition of normal in the three-dimensional case If DNOR (or DTAN) is specified, the normal (or tangent) on a node is the average of normal or tangents of the cells on which the boundary conditions are affected and which have this node in common (except for curved quadratic elements where the normal is correctly) calculated at all points). .. figure:: images/100004A2000010BE000006ED6AE0FD3CA03A9B57.svg :width: 200 :height: 100 Normals smoothing The operator MODI_MAILLAGE makes it possible to ensure the continuity of the orientation of the normal to edges of massive elements in a continuous medium. Case of structural elements ~~~~ The structural elements (beams, plates and shells) have their own **local** coordinate system including the definition is given in the documentation for command AFFE_CARA_ELEM [:ref:`U4.42.01 `]. Definition of a coordinate system by nautical angles ~~~~ Some uploads offer the possibility of giving their application direction using nautical angles whose definition is recalled here. The nautical angles :math:`\alpha`, :math:`\beta`, :math:`\gamma`, provided in degrees, are the angles allowing to pass from the global coordinate system for defining the coordinates of the nodes :math:`(P,X,Y,Z)` to the local :math:`(P,{X}_{3},{Y}_{3},{Z}_{3})` coordinate system. This is obtained by three rotations: * A rotation of angle :math:`\alpha` around :math:`Z`, turning :math:`(XYZ)` into :math:`({X}_{1}{Y}_{1}{Z}_{1})` with :math:`{Z}_{1}\equiv Z`; ` .. figure:: images/10000000000001150000010F926B712830D3F866.png :width: 200 :height: 150 Definition of angle :math:`\alpha` * A rotation of angle :math:`\beta` around :math:`{Y}_{1}`, transforming :math:`({X}_{1}{Y}_{1}{Z}_{1})` in :math:`({X}_{2}{Y}_{2}{Z}_{2})` with :math:`{Y}_{2}\equiv {Y}_{1}`; .. figure:: images/100000000000012500000107BF6F9ECA7DAA2232.png :width: 200 :height: 150 Definition of angle :math:`\beta` (rotation angle :math:`\beta` is negative) * A rotation of angle :math:`\gamma` around :math:`{X}_{2}`, transforming :math:`({X}_{2}{Y}_{2}{Z}_{2})` in :math:`({X}_{3}{Y}_{3}{Z}_{3})` with :math:`{X}_{3}\equiv {X}_{2}`; .. figure:: images/10000000000000E4000000D535841AC46D6286CE.png :width: 200 :height: 150 Definition of angle :math:`\gamma` The local coordinate system is: :math:`({X}_{3}{Y}_{3}{Z}_{3})`. .. figure:: images/10000000000001C5000001A617B17BAA9B5DCDBE.png :width: 440 :height: 409 Representation of global and local landmarks