3. Item SD_L_CHARGES — New version#

3.1. Principles#

3.1.1. What is a load?#

A load is generally defined in two stages:

Description of the load in operators AFFE_CHAR_;

  • Application of the load in the order (under the keyword EXCIT/CHARGE)

However, there is a second way to define a loading: *

  • Definition of a CHAM_NO (VECT_ASSE) or a VECT_ASSE_GENEà using vector manipulation operators (CALC_VECT_ELEM, ASSE_VECTEUR, etc.) or following a previous calculation;

  • Application of the load in the order (under the keyword EXCIT/VECT_ASSE);

This second way of doing things is very used in dynamics.

In the EXCIT keyword, you can also define:

  • a real or complex time multiplier function;

  • A type of loading application (keyword TYPE_CHARGE) used mainly in non-linear operators;

3.1.2. Multiplier function#

Internally, orders always use a multiplier function (FONC_MULT or FONC_MULT_C). If the user has not specified, it is a constant unit function defined internally, or also a non-unit function with a coefficient given by the user by COEF_MULT or COEF_MULT_C. In the complex case, it is possible to give the phase (PHAS_DEG) and the power of the pulsation (PUIS_PULS) of the complex load, written in the form of a complex exponential.

3.1.3. Defining the type of load#

When the user defines a loading in AFFE_CHAR_ , he is using a particular keyword. AFFE_CHAR_ then proceed in several different ways:

1. Creation of a CARTEcontenant the necessary information on the entire model. For example, if the load is a distributed pressure, it means that the pressure will be defined as non-zero only on the cells affected by the load. On the rest of MODELE, the pressure will be zero [1] _ ;

  1. Creating a CARTEsur part of the model (GROUP_MAdéfini);

  2. Creating specific objects that are not maps.

Case 1 is the most common. Case 2 is much rarer: in mechanics, it only concerns the Dirichlet and FORCE_NODALE loads.

Case 3 concerns some loads (in mechanics: EVOL_CHAR, FORCE_ELEC and AFFE_CHAR_CINE for example).

Information on the type of load is retrievable by the name of the object (CARTEou other object) created by AFFE_CHAR_MECA. But there are some ambiguous cases (information lost). In any case, the place of application of the load is lost because, in general, CARTEsur is defined all MODELE (case 2).

3.1.4. The concept of load type#

A kind of load includes loads that have the following points in common:

  • Phenomenological unit: Neumann/Dirichlet on a PHENOMENEdonné;

Unit of description: the load is described in the same operator (AFFE_CHAR_ for example) and is constructed in the same way: same object (map) and an associated parameter, a LIGREL, an option;

  • Programming unit: the load calculation is done in a single routine

There are (currently) fifteen types of load:

  • DIRI_DUAL: AFFE_CHAR_MECA with Dirichlet dualized;

  • DIRI_ELIM: AFFE_CHAR_CINE;

  • NEUM_MECA: Neumann loading in mechanics;

  • PRE_SIGM: as the name suggests;

  • VITE_FACE: as the name suggests;

  • IMPE_FACE: as the name suggests;

  • EVOL_CHAR: as the name suggests;

  • SIGM_CABLE: as the name suggests;

  • FORCE_ELEC: as the name suggests;

  • INTE_ELEC: as the name suggests;

  • ONDE_FLUI: as the name suggests;

  • ONDE_PLANE: as the name suggests;

  • VECT_ASSE_CHAR: VECT_ASSE defined by AFFE_CHAR_MECA;

  • VECT_ASSE: CHAMNO directly at the input of EXCIT;

  • VECT_ASSE_GENE: VECT_ASSE_GENE directly at the input of EXCIT;

A genre includes several types of loading. For example NEUM_MECA groups together Neumann-type loads in mechanics, defined in AFFE_CHAR_MECA * and with keywords as diverse as FORCE_NODALE or FORCE_COQUE.

3.1.5. The concept of a charge keyword#

Identifiable by the name of the card or object (except in ambiguous cases). Only used in a few cases (debug prints, identifying specific loads such as gravity or command CALC_G).

3.1.6. Multiplicity of genres/keywords#

In a single AFFE_CHAR_ , you can define several very different loads (several genres and keywords). However, the name of the load (concept of AFFE_CHAR_ or name of VECT_ASSE/VECT_ASSE_GENE) is used as iterators in the sd_l_charges.

There are as many charges as there are occurrences of the keyword factor EXCIT. But there are multiple loads per occurrence.

To identify the gender, a coded integer is therefore used and therefore 30 different types of charges are possible. By decoding this integer, we can say whether or not this gender is present in the occurrence of the load.

To identify the load keyword, two coded integers are therefore used and therefore 60 different load keywords are possible.

3.1.7. Notion of object and prefix#

A load is defined by one or more objects.

The object name is always prefixed in the same way in the case of AFFE_CHAR_ . The**prefix* PREFOB is built on the following basis:

PREFOB (1:8): name of the concept from AFFE_CHAR_;

  • PREFOB (9:13): string identifying the phenomenon either. CHAC,. CHMEou. CHTH (respectively, acoustic: AFFE_CHAR_ACOU, mechanical: AFFE_CHAR_MECA, or thermal: AFFE_CHAR_THER);

With this prefix:

  • The object is identified: a card or another object. By identifying the object, it is possible to identify the genre and, possibly, the keyword;

  • For uploads to LIGRELréduit, you can build the name of LIGRELà from the prefix;

3.2. SD content and access to information#

3.2.1. Arborescence#

sd_l_charges (K19): :=record

(o) “. NCHA “: OJB S V K8 LONUTI =nchar (o) “. CODC “: OJB S V I LONUTI =nchar (o) “. TYPC “: OJB S V K8 LONUTI =nchar (o) “. TYPA “: OJB SV K16 LONUTI =nchar (o) “. PREO “: OJB SV K24 LONUTI =nchar (o) “. NFON “: OJB S V K8 LONUTI =nchar (o) “. TFON “: OJB SV K16 LONUTI =nchar (o) “. VFON “: OJB S V R LONUTI =nchar

All these objects are indexed by the load number ichar, knowing that nchar corresponds to the number of occurrences of the keyword factor EXCIT.

“. NCHA “contains the name of the loads (concept from AFFE_CHAR_ or VECT_ASSE) —Read access by lislch.f;

*”. CODC “contains the genre of the loads (coded integer) — Read access by lislco.f;

*”. TYPC “contains the type of the load (complex, real, function): REEL, COMP, FONC_F0 (function [2] _ any) and FONC_FT (time function) — Read access by lisltc.f;

*”. TYPA “contains the type of load application (fixed load, controlled, follower, differential Dirichlet): FIXE_CSTE, FIXE_PILO, SUIVet DIDI — Read access by lislta.f;

*”. PREO “contains the prefix of the load objects — Read access by lisllc.f;

*”. NFON “contains the name of the multiplier function — Read access by lislnf.f;

*”. TFON “contains the type of the multiplier function: real or complex function or constant (FONCT_REEL, FONCT_COMP, CONST_REEL and CONST_COMP) — Read access by lisltf.f;

*”. VFON “contains the parameters of the complex exponential in the case of a complex multiplier function — Read access by lispcp.f;

Important: it is forbidden to directly access SD objects by name, access routines must be used.

3.2.2. Utility routines#

We create the SD (empty objects) in the liscrs.f routine.

You print its content (mode INFO =2) using lisimp.f.

You read the EXCIT keyword and fill in the SD in lislec.f.

3.2.3. Expense list checks#

Some checks are offered as standard in the SD. The routine doing these checks is lischk.f, it is called systematically after creating and filling the SD. These checks are:

  • Coherence of the models: all the loads are based on the same model and are consistent with the calculation model (this limitation is temporary, pending consideration of the case of transients) — routine liscom.f;

  • Coherence between the loads and the phenomenon: all the loads are based on the same phenomenon and are consistent with the operator phenomenon — lisccp.f routine;

  • Consistency between the loads and the command: the type of load can be calculated on the command —routine lisccm.f;

  • Prohibition of duplicates: it is forbidden for the same load to be present twice —routine lisdbl.f;

  • Load type checks. For the moment, not automatic enough, some various checks (piloting, follower loadings). Eventually, these incompatibilities will probably be more automated —routine lisver.f;

3.3. Calculation of loads#

3.3.1. General principle#

To effectively calculate a loading (and therefore create the second member to integrate it into a resolution), there are two cases:

  1. Standard loads: they are built from the assembly in a CHAM_NOde elementary vectors. There is therefore a phase of calculating these VECT_ELEM (call to CALCUL) and a phase of assembling);

  2. Non-standard loads: the CHAM_NOest copied from the object already built elsewhere (VECT_ASSE for example) or it is a particular load (contact for example);

3.3.2. Routines for calculating loads#

The most important routine is vechme.f. Calculate like NEUM_MECA, EVOL_CHAR, and stuff while glutin” sometimes. In the new version, vechme.f is replaced by vechms.f, and only calculates gender NEUM_MECA, it is separated into two pieces:

  • Preparation of input fields (standard with a parameter map) —Routine vechmp.f;

  • Effective calculation of VECT_ELEM — vechmx.f routine;

For sensitivity: we go from vechde.f to vechd2.f (temporary before sensitivity resorption)

For the dualized Dirichlets: we go from vedime.f to vedimd.f

For EVOL_CHAR, we go from vechme.f to veevoc.f. In practice, a EVOL_CHAR contains NEUM_MECA loadings. So for the calculation veevoc.f will call vechmp.f/vechmx.f by constructing a temporary sd_l_charges.

The processing of VECT_ASSE/VECT_ASSE_GENE is planned in cnvesl.f.

The treatment of VECT_ASSE coming from AFFE_CHAR_MECA (like VECT_ASSE_CHAR) is planned in veassc.f.

3.3.3. Pre-assembly routines#

As all the loads are constructed using a multiplier function, the assembly is done in two sequences:

  • Pre-assembly: the VECT_ELEM are assembled into a list of CHAM_NO, in the asvepr.f routine that builds a list;

  • Linear combination of CHAM_NO: we combine the CHAM_NOpré -assemblies with the multiplier functions in the ascomb.f routine;

3.4. Add a new load#

To add a new load, you need to:

Make the necessary impacts in AFFE_CHAR_;

  • Identify the type of load in comparison with what already exists;

  • Identify the operators allowing the use of this load;

  • Write the routines that will calculate this load (§ 3.3.2 and any elementary calculations);

  • Impact the main lisdef.f routine (complete DATA);

  • Add usage protections in lischk.f (identify operators allowing the use of this load for example, make it incompatible with control, etc…)