3. Contents of the catalog#

The catalog chosen as an example is the following (flux_elga.py):

from Cataelem.Tools.Base_Objects import InputParameter, OutputParameter, Option, CondCalculus

import Cataelem.Commons.Physical_Quantities as PHY

import Cataelem.Commons.Parameters as SP

import Cataelem.Commons.Attributes as SAT


PNBSP_I = InputParameter (phys= PHY. NBSP_I, container=' CARA!. CANBSP ',

comment=" "" PNBSP_I: NOMBRE FROM COUCHE """)


PVARCPR = InputParameter (phys= PHY. VARI_R, container=' VOLA! & CCPARA. VARI_INT_N ',

comment=" "" PVARCPR: VARIABLES FROM COMMANDE """)


PFLUXPG = OutputParameter (phys= PHY. FLUX_R, type=' ELGA ',

comment=" "" PFLUXPG: FLUX AUX POINTS FROM GAUSS """)


FLUX_ELGA = Optional (

by a_in =(

SP. PCACOQU,

SP. PCAMASS,

SP. PGEOMER,

SP. PHARMON,

SP. PMATERC,

PNBSP_I,

SP. PTEMPER,

SP. PTEMPSR,

PVARCPR,

),

para_out =(

PFLUXPG,

),

condition =(

ConCalculation ('+', ((AT. PHENO, 'TH'), (AT. BORD, '0'),)),

),

comment=" "" FLUX_ELGA: CALCUL FROM FLUX AUX POINTS FROM GAUSS """,

)

Let’s comment on this file:

3.1. Parameters#

We start by describing the option parameters that are specific to the option (that is, those that are not « shared » parameters found in cataelem.commons.parameters).

There are input parameters (InputParameter) and output parameters (OutputParameter)

For each parameter, you must specify:

  • his name (what is to the left of the “=” sign)

  • the quantity associated with this parameter

  • a comment

If it is an input parameter, you can also indicate a « location » of the field associated with this parameter. This location is a character string with a particular format: several « fields » separated by the « ! » sign. This location allows you to tell the program where to find (by default) the parameter field: in which data structure, with what order number if this data structure is an sd_result.

Example of location: container=” CARA!. CANBSP “

This means: the field name is obtained by concatenating the string “. CANBSP “on behalf of sd_cara_elem.

If it is an output parameter, you must add information on the « type » of the field associated with this parameter (type=”xxx”). The possible types are:

  • “ELEM”: for a constant field per element,

  • “ELGA”: for a field at the Gauss points of the element,

  • “ELNO”: for a field with nodes per element.

  • “RESL”: for a resuelem field (matrix or vector).

3.2. Option#

The option itself is then described (FLUX_ELGA = Option (…)).

To the left of the “=” sign, we find the name of the option (in uppercase letters).

The description of the option is very simple: we specify the list of input parameters (para_in= (…)) and the list of output parameters (para_out= (…)).

The settings that appear in these two lists are either shared settings (for example: SP. PMATERC) or parameters defined earlier in the option catalog (for example: PFLUXPG)

3.3. Condition block/CondCalculation#

This block is very important. It allows you to define all the elements that are concerned by the option (those who should calculate it).

Let’s take the example of the block corresponding to option RIGI_MECA_GE:

condition =(

ConCalculation (“+”, ((AT. PHENO, “ME”), (AT. BORD, “0”),)),

CondCalculation (“-”, ((AT. PHENO, “ME”), (AT. DISCRET, “OUI”),)),

),

It is a question of designating the set of all the finite elements for which this option makes sense (and who should therefore know how to calculate it). By designating them all, we express, on the contrary, that all the other elements are not affected by this option (and therefore that they should not calculate this option).

We refer to « packages » of finite elements using the attributes defined in the element catalogs or in the phenomenons_modelisations.py catalog.

In the previous example, we define two « packages » of elements:

  1. those who have the PHENO =”ME” and attribute BORD =”0”

  2. those who have the attribute PHENO =”ME” and the attribute DISCRET =” OUI “

All the elements that must calculate the option are obtained by « adding » or « removing » the packages defined according to the « sign » of CondCalcul (“+” or “-“).

In the previous example, the set of elements that should calculate option RIGI_MECA_GE is obtained by taking all the elements of the phenomenon MECANIQUE, which are « main » (BORD =”0”) and by removing the discrete elements.

The number of CondCalcul « rows » is not limited. The order of these lines is important: the list of items concerned by the option is created by adding and deleting packages in the order of the list.

3.4. Commentary#

We end the description of an option with a comment field (argument comment= “…”).

This comment can be used, for example, to clarify an error message.

It should explicitly describe the purpose of the calculation option.

For example, for option FLUX_ELGA, you can write:

Comment=' FLUX_ELGA: CALCUL FROM FLUX THERMIQUE AUX POINTS FROM GAUSS '

3.5. notes#

Each parameter field of the option corresponds to a couple (name of the parameter, quantity). The size is often sufficient to characterize the field. For example, when we talk about the GEOM_R field (node geometry), everyone understands what it’s all about.

But sometimes an option requires several fields of the same size. For example, think of an option that would have 2 displacement fields as input fields (quantity DEPL_R): one corresponding to the displacement at the beginning of the time step and the other corresponding to a displacement increment.

The parameters are used to distinguish between these different fields. A « little name » is associated with each field: this is the name of the parameter.

For our example, we would write:

PDEPLMR = InputParameter (phys= PHY. DEPL_R,

comment= » «  » DEPLACEMENT INSTANT PRECEDENT « «  »)

PDEPLPR = InputParameter (phys= PHY. DEPL_R,

comment= » «  » INCREMENT FROM DEPLACEMENT. « «  »)

When there is no ambiguity (only one field for a given quantity), it is customary to name the parameter associated with this quantity by adding a “P” in front of the name of the quantity. For example:

PCACOQU = InputParameter (phys= PHY. CACOQU,…)

The catalog for an option is used by all finite elements that calculate that option. The list of parameter fields must therefore be an « envelope » list of the fields used by the elements.

For example, shell elements generally need geometric information (thickness,…) that is not found in the geometry field (coordinates of mesh nodes). This missing geometric data is in a field in data structure CARA_ELEM (of the cacoqu quantity). We will therefore often find the block in the catalog of an option:

PCACOQU = InputParameter (phys= PHY. CACOQU,…)

Since the catalog of an option is an « envelope » of the needs of the elements, the list of parameter fields for an option can be long. That’s why it’s important to comment out all parameter fields.

It is mandatory that the person responsible for an option choose a « type » for each output field (ELGA, ELNO,…) for each output field. The aim of this constraint is to force a certain homogeneity for the various finite elements that calculate this option. This also makes it possible to « type » the produced cham_elemglobal. A fiel_element will therefore always be either ELGA or ELNOsoit ELEM.