2. Data structures

An SD goes through several phases:

• Creation of the SD;

• Reading user information and storing it in the SD;

• SD initializations;

• Destruction of the SD.

SDs don’t necessarily go through all of these phases.

2.1. The types of SD

Three levels of SD are introduced:

1. Concepts from other orders or produced by the order itself;

2. « Medium-level » SDs are Fortran variables (simple arrays) with access routines. In this category, we will find the vector of activated functionalities list_func_acti and the hat variables, which are arrays of character strings containing more complex objects (matrices, vectors, etc.);

3. The « high level » SDs are

   • Or JEVEUX objects specific to the operator (with access routines)

   • Or standard SDs (mesh, model,…) from Code_Aster that will remain internal to the operator

   • Or SDs described using Fortran derived types;

2.1.1. SD concept

The concepts come from another operator or are built by the operator for use in other commands. They are built exclusively on standard SDs in*Code_Aster* (fields, numbers, etc.). Their content is described in the D4 documentation. Here is the complete list of these SDs in OP0070.f90:

Description	Type	Generally used name
Mesh	sd_mailla	MAILLA
Model	sd_model	MODELE
Result	sd_resultat	RESULT
Basic characteristics	sd_cara_elem	CARELE
Loads	sd_l_charges	LISCHA
Material field and control variables	sd_cham_mater	MATE
Define contacts	sd_contact	DEFICO
Definition of one-sided relationships	sd_contact	DEFICU

2.1.2. Mid-level SD

Mid-level SDs are intermediate between « low-level » SDs and « high-level » SDs. Indeed, these variables are simple Fortran objects but have access routines. They are therefore « low-level » from a storage point of view, but they are accessed through specific routines, just like « high-level » SDs.

Description	Type	Name
Features enabled	INTEGER (100)	list_func_acti
Hat variable — Elementary matrices	CHAR *19 (ZMEELM)	MEELEM
Variable-hat — Assembled matrices	CHAR *19 (ZMEASS)	MEASSE
Hat variable — Elementary Vectors	CHAR *19 (ZVEELM)	VEELEM
Hat variable — Assembled vectors	CHAR *19 (ZVEASS)	VEASSE
Variable-hat — Solution fields	CHAR *19 (ZSOLAL)	SOLALG
Hat variable — Incremental solution fields	CHAR *19 (ZVALIN)	VALINC

2.1.3. High-level SD

All these SDs are built on JEVEUX objects or derived types and are accessed through dedicated routines (data encapsulation) when the SDs are specific. We do not go over all of them, because they are concepts contained in the operator’s keywords or produced by the operator (§ 2.1.1).

Description	Type	Name
Behavior map	sd_map	COMPOR
Solver	sd_solver	SOLVEU
Preconditioning matrix	sd_matr_asse	MAPREC
Assembled resolution matrix	sd_matr_asse	MATASS
Convergence criteria map for behavior	sd_map	CARCRI
Map of reference control variables	sd_map	COMREF
Return code map behavior error	sd_card	CODERE
Numbering	sd_nume_ddl	NUMDDL
Fixed numbering (used for continuous contact method)	sd_nume_ddl	NUMFIX
Print Management	specific to op0070	ds_print
Management of time measurements and statistics	specific to op0070	ds_measure
Algorithm error handling	specific to op0070	SDERRO
Archiving and initial state management (IN and OUT)	specific to op0070	ds_inout
Convergence Management	specific to op0070	ds_conv
Management of SUIVI_DDL	specific to op0070	SDSUIV
Quality criteria management	specific to op0070	SDCRIQ
Management of control	specific to op0070	SDPILO
Numbering management	specific to op0070	SDNUME
Dynamic Management	specific to op0070	SDDYNA
Temporal discretization management	specific to op0070	SDDISC
Management of convergence criteria	specific to op0070	SDCRIT
Management of OBSERVATION	specific to op0070	SDOBSE
Post-processing management (MODE_VIBR and CRIT_STAB)	specific to op0070	SDPOST
Energy Management	specific to op0070	SDENER
Algorithm parameters	specific to op0070	ds_algopara

The rest of the document will essentially describe the content, use, and access to SDs specific to op0070.

Some SDs are built using Fortran derivative types. They obey common rules:

• The module describing these types is Nonlin_Datastructure_Type.f90;

• Types are prefixed with the string « NL_DS_ ». For example type (NL_DS_Print) for print management;

• In general, there is only one variable of this type in the operator, this variable is passed as an argument in the subroutines that need it (they are not global variables);

• The management of these SDs is standardized:

• The creation of these SDs is done in the Nmini0.f90 routine by routines of the form Create**Type**DS.F90 with**Type** the name of the derived type;

• Reading user data from the command file is done in NMData.f90, usually in routines of the form Read**Type**.F90 with**Type** the name of the derived type;

• Data initialization is done in NMinit.f90 in general, except for some types that need more specific initialization (at each time step for example). The routines performing these initializations are generally of the form Init**Type**.F90 with**Type** the name of the derived type.

Ultimately, all of the operator’s data structures will be of this form.

2.2. Creating SDs

The following table summarizes the origin of the creation of SDs.

Description	Type	Creation
Maillage	sd_mailla	comes from .com
Model	sd_model	comes from .com
Result	sd_resultat	nmnoli
Elementary characteristics	sd_cara_elem	comes from .comm
Behavior map	sd_map	nmdocc
Loads	sd_l_charges	nmdoch
Coded material	sd_cham_mater	comes from .com
Definition of contacts	sd_contact	comes from .com
Definition of unilateral relationships	sd_contact	comes from .com
Features enabled	INTEGER (100)	op0070
Hat variable — Elementary matrices	CHAR *19 (ZMEELM)	op0070
Variable-hat — Assembled matrices	CHAR *19 (ZMEASS)	op0070
Hat variable — Elementary vectors	CHAR *19 (ZVEELM)	op0070
Variable-hat — Assembled vectors	CHAR *19 (ZVEASS)	op0070
Variable-hat — Solution fields	CHAR *19 (ZSOLAL)	op0070
Variable-hat — Incremental solution fields	CHAR *19 (ZVALIN)	op0070
Solver	sd_solver	nmlect
Preconditioning matrix	sd_matr_asse	during the algo
Assembled resolution matrix	sd_matr_asse	during the algo
Convergence criteria map for behavior	sd_map	nmdocr
Map of reference control variables	sd_map	nmvcre
Return code map behavior error	sd_card	during the algorithm
Numbering	sd_nume_ddl	nmprof
Fixed numbering (used for continuous contact method)	sd_nume_ddl	nmpro2
Print Management	Derived Type	CreatePrintDS
Time measurement management	Derived type	nmcrti
Algorithm error management	specific	nmcrga
Archive and initial state management (IN and OUT)	Derived type	nmetcr NT and CR
Statistics Management	Derived Type	nmcrst
Convergence Management	Derived Type	CreateConvds
Management of SUIVI_DDL	specific	nmcrdd
Management of quality criteria	specific	nmcrer
Management of control	specific	nmdopi
Numbering management	specific	name
Dynamic Management	Specific	ndcrdy
Temporal discretization management	specific	nmcrli
Management of OBSERVATION	specific	nmcrob
Post-processing management (MODE_VIBR and CRIT_STAB)	specific	nmdopo
Energy Management	Derived Type	Eninit
CONTACT resolution	Derived type	cfmxsd
LIAISON_UNIL resolution	Derived type	cfmxsd
Algorithm Settings	Derived Type	CreateAlgoParads

2.3. Reading user data

The reading of user data is mostly done under the nmdata routine, this routine reads the user data and possibly creates the necessary SDs. The nmdome routine reads the characteristics given by the keywords MODELE, CHAM_MATER,,, CARA_ELEM and EXCIT while also dealing with the case of recomputation (reuse) which uses the information stored in the result SD. The table below brings together all the SDs that will read information directly from the command file (and therefore use the getxxx routines for communication between Fortran and the Python supervisor).

Description	Keywords	Reading routine
Template	MODELE	nmdome
Result	concept created	mnoli
Basic characteristics	CARA_ELEM	nmdome
Behavior map	COMPORTEMENT	nmdocc
Loads	EXCIT	nmdome
Coded material	CHAM_MATER	nmdome
Define contacts	CONTACT	cfmxsd
Definition of one-sided links	CONTACT	cfmxsd
Convergence Management	CONVERGENCE	ReadConv
Solver	SOLVEUR	cresol
Convergence criteria map for behavior	COMPORTEMENT	nmdocr
Print Management	IMPRESSION	ReadPrint
Archiving and initial state management (IN and OUT)	ARCHIVAGE ETAT_INIT	metcr NMCRAR Nmdoet
Managing SUIVI_DDL	SUIVI_DDL	nmcrdd
Quality criteria management	CRIT_QUALITE	nmcrer
Pilot Management	PILOTAGE	nmdopi
Dynamic Management	SCHEMA_TEMPS MASS_DIAG PROJ_MODAL MODE_STAT AMOR_MODAL	ndlect
Temporal discretization management	DISCRETISATION	nmcrsu
Managing OBSERVATION	OBSERVATION	nmcrob
Post-processing management (MODE_VIBR and CRIT_STAB)	CRIT_STAB MODE_VIBR	Nmdopo
Energy Management	ENERGIE	eninit
Resolution of CONTACT	CONTACT	cfmxsd
Resolution of LIAISON_UNIL	CONTACT	cfmxsd
Algorithm Settings	METHODE RECH_LINEAIRE	Nmdomt mndomt_ls

2.4. SD description

2.4.1. Mid-level SD

2.4.1.1. Features enabled — list_func_acti

This SD allows you to know which functionalities are active in the algorithm at any given time. The main idea of this SD is a very rustic talk to answer a simple question about active features in op0070. For example:

• There is contact: isfonc (list_func_acti, “CONTACT”) is true;

• Linear search is enabled: isfonc (list_func_acti, “RECH_LINEAIRE”) is true;

We will not list the functionalities that can be searched by this mechanism in this document because this vector is often modified, you just need to read the isfonc routine. Even if this object is low-level (simple INTEGER arrays), it must be accessed through only three routines:

Operation on the vector of activated features — list_func_acti	Routine
Preparing activated features	nmfonc
Querying an activated feature	isfonc
Rules for the exclusion of certain functionalities	exfonc

It is imperative to modify the list_func_acti vector only in the nmfonc routine (called in nminit) and to always provide the question corresponding to this feature in isfonc. Likewise, it is this vector that will be used primarily to test the compatibility between certain functionalities (exfonc routine, called by nmfonc).

2.4.1.2. Hat variable — Elementary matrices MEELEM

This hat variable contains the names of all the elementary matrices that can be used in op0070. It is therefore a list of SDs of the type sd_matr_elem (sd_resu_elem). The tracking code in the variables hats MEELEM/MEASSE is the same if they are the same objects.

Hat variable — Elementary matrix MEELEM	Locating code
Elementary stiffness matrices	MERIGI
Elementary matrices of dualized Dirichlet boundary conditions	MEDIRI
Elementary mass matrices	MEMASS
Elementary damping matrices	MEAMOR
Elementary matrices of follower loadings	MESUIV
Elementary matrices of substructures (macroelements)	MESSTR
Elementary matrices of geometric rigidity	MEGEOM
Elementary contact matrices (method CONTINUEet XFEM)	MEELTC
Elementary friction matrices (method CONTINUEet XFEM)	MEELTF

2.4.1.3. Variable-hat — Assembled matrices MEASSE

This hat variable contains the names of all the assembled matrices that can be used in op0070. It is therefore a list of SDs of the type sd_matr_asse. The tracking code in the variables hats MEELEM/MEASSE is the same if they are the same objects.

Variable-hat — Assembled matrix MEASSE	Identification code
Assembled stiffness matrix	MERIGI
Mass Assembled Matrix	MEMASS
Assembled damping matrix	MEAMOR
Assembled matrix of substructures (macroelements)	MESSTR

2.4.1.4. Hat variable — Elementary Vectors VEELEM

This hat variable contains the names of all the elementary vectors that can be used in op0070. It is therefore a list of SDs of type sd_vect_elem (sd_resu_elem). The tracking code in the variables hats VEELEM/VEASSE is the same if they are the same objects.

Hat variable — Elementary vectors VEELEM	Locating code
Elementary vector of internal forces	CNFINT
Elementary vector of support reactions for dualized Dirichlet boundary conditions	CNDIRI
Elementary vector of dualized Dirichlet boundary conditions	CNBUDI
Elementary vector of nodal forces	CNFNOD
Elementary vector of the given Dirichlet boundary conditions	CNDIDO
Elementary vector of controlled Dirichlet boundary conditions	CNDIPI
Elementary vector of the given Neumann boundary conditions	CNFEDO
Elementary vector of controlled Neumann limit conditions	CNFEPI
Elementary vector of Laplace-type boundary conditions	CNLAPL
Elementary vector of plane wave boundary conditions	CNONDP
Elementary vector of the following Neumann boundary conditions and data	CNFSDO
Elementary vector of impedance-type boundary conditions (in prediction)	CNIMPP
Elementary vector of differential Dirichlet boundary conditions	CNDIDI
Elementary vector of forces on substructures	CNSSTF
Elementary vector of contact forces (method CONTINUEet XFEM)	CNELTC
Elementary vector of frictional forces (method CONTINUEet XFEM)	CNELTF
Elementary vector of reference forces (RESI_REFE_RELA)	CNREFE
Elementary vector of control variables for the initial state	CNVCF1
Elementary vector of control variables for convergence	CNVCF0
Elementary vector of impedance-type boundary conditions (in correction)	CNIMPC

2.4.1.5. Variable-hat — Assembled Vectors VEASSE

This hat variable contains the names of all the assembled vectors that can be used in op0070. So it is a list of SDs of the type sd_cham_no. These vectors are essentially used in the construction of the second members and in the evaluation of convergence. The tracking code in the variables hats VEELEM/VEASSE is the same if they are the same objects.

Hat variable — Assembled Vectors VEASSE	Locating code
Assembled Internal Forces Vector	CNFINT
Assembled vector of support reactions for dualized Dirichlet boundary conditions	CNDIRI
Assembled vector of dualized Dirichlet boundary conditions	CNBUDI
Assembled vector of nodal forces	CNFNOD
Assembled vector of the given Dirichlet boundary conditions	CNDIDO
Assembled vector of controlled Dirichlet boundary conditions	CNDIPI
Assembled vector of the given Neumann boundary conditions	CNFEDO
Assembled vector of controlled Neumann boundary conditions	CNFEPI
Assembled vector of Laplace-type boundary conditions	CNLAPL
Assembled vector of plane wave boundary conditions	CNONDP
Assembled vector of the following Neumann boundary conditions and data	CNFSDO
Assembled vector of impedance-type boundary conditions (in prediction)	CNIMPP
Assembled vector of differential Dirichlet boundary conditions	CNDIDI
Assembled vector of forces on substructures	CNSSTF
Assembled vector of contact forces (method CONTINUEet XFEM)	CNELTC
Assembled vector of frictional forces (method CONTINUEet XFEM)	CNELTF
Assembled reference force vector (RESI_REFE_RELA)	CNREFE
Assembled vector of command variables for initial state	CNVCF1
Assembled vector of control variables for convergence	CNVCF0
Assembled vector of impedance-type boundary conditions (in correction)	CNIMPC
Assembled vector of eliminated Dirichlet boundary conditions	CNCINE
Assembled vector of substructures	CNSSTR
Assembled vector of frictional forces (method DISCRETE)	CNCTDF
Assembled vector of control variables for calculation	CNVCPR
Assembled vector of dynamic forces	CNDYNA
Assembled vector of modal damping (in prediction)	CNMODP
Assembled vector of modal damping (in correction)	CNMODC
Assembled vector of contact forces (method DISCRETE)	CNCTDC
Assembled vector of unilateral forces (method LIAISON_UNIL)	CNUNIL
Assembled vector of external forces	CNFEXT
Assembled vector of boundary conditions of type VECT_ISS	CNVISS

2.4.1.6. Variable hat — Solution vectors SOLALG

This hat variable contains the names of the fields at the nodes that are used in the algorithm to calculate the solution.

Variable-hat — Vectors for solutions SOLALG	Locating code
Displacement solution of the current Newton iteration	DDEPLA
Accumulated displacement since the start of the time step	DEPDEL
Previous time step displacement increment	DEPOLD
Solution on the move of prediction	DEPPR1
On-the-go prediction solution (controlled part)	DEPPR2
Velocity solution of the current Newton iteration	DVITLA
Cumulative speed since the start of the time step	VITDEL
Previous time step speed increment	VITOLD
Solution in speed of prediction	VITPR1
Prediction speed solution (controlled part)	VITPR2
Solution in acceleration of the current Newton iteration	DACCLA
Accumulated acceleration since the start of the time step	ACCDEL
Acceleration increment of the previous time step	ACCOLD
Solution to accelerate prediction	ACCPR1
Solution for accelerating prediction (controlled part)	ACCPR2
System Solution	DEPSO1
System solution (controlled part)	DEPSO2

2.4.1.7. Variable-hat — Incremental solutions VALINC

This hat variable contains the names of the fields at the nodes or fields of type ELGA that will be the solutions to the non-linear problem.

Hat variable — Incremental solutions VALINC	Locating code
Travel at the start of the time step	DEPMOI
Constraints at the start of the time step	SIGMOI
Internal variables at the start of the time step	VARMOI
Speeds at the start of the time step	VITMOI
Accelerations at the start of the time step	ACCMOI
Command variables at the start of the time step	COMMOI
Variables for multi-fiber elements at the start of the time step	STRMOI
External forces at the start of the time step (for calculating energies)	FEXMOI
Damping forces at the start of the time step (for calculating energies)	FAMMOI
Bonding forces at the start of the time step (for calculating energies)	FLIMOI
Nodal forces at the start of the time step (for calculating energies)	FNOMOI
Travel at the end of the time step	DEPPLU
Constraints at the end of the time step	SIGPLU
Internal variables at the end of the time step	VARPLU
Speeds at the end of the time step	VITPLU
Accelerations at the end of the time step	ACCPLU
Command variables at the end of the time step	COMPLU
Variables for multi-fiber elements at the end of the time step	STRPLU
External forces at the end of the time step (for calculating energies)	FEXPLU
Damping forces at the end of the time step (for calculating energies)	FAMPLU
Bonding forces at the end of the time step (for calculating energies)	FLIPLU
Nodal forces at the end of the time step (for calculating energies)	FNOPLU
Extrapolated constraints (method IMPLEX)	SIGEXT
Displacements at the current Newton iteration (management of large rotations)	DEPKM1
Velocities at current Newton iteration (large rotation management)	VITKM1
Accelerations at the current Newton iteration (large rotation management)	ACCKM1
Rotations to the previous Newton iteration (managing large rotations)	ROMK
Rotations at the current Newton iteration (large rotation management)	ROMKM1

2.4.1.8. Access to hat variables

Access to the top variables is done through five routines.

Operation on the hat variable	Routine
Creating a hat variable	nmcha0
Retrieving the index where the name of the variable is stored in the hat variable	nmchai
Copy of a hat variable	nmchcp
Retrieving the name of the variable in the hat variable	nmchex
Copy a hat variable by possibly changing a variable name	nmchso
Creating CHAM_NOpour VALINC, SOLAGet VEASSE	nmcrch

The size of these SDs is shown in the same way as the low-level SDs. However, a change in size should be reflected in the main nmchai routine. If you want to modify the content of a hat variable (add, delete or modify the content of a hat variable), you must:

• Optionally impact the length in op0070, nmini0 (ASSERT for protection) and nmchai;

• Edit in nmchai;

• Create the hat variable (see § 2.2);

• Optionally initialize the content of the hat variable;

These routines simply manage the hat variables as a list of names, the actual content of these hat variables does not depend on them. For example, the hat variable VEASSE contains assembled vectors. None of the routines in the previous table take care of managing the SD CHAM_NO of the objects contained in the hat variable, just their name. For the three hat variables that define CHAM_NO, the fields are created in the nmcrch routine, using information about active list_func_acti features.

2.4.2. High-level SD

2.4.2.1. Print Management — NL_DS_Print

Printing involves three types of objects:

• « standard » prints based on utmess;

• Printing the convergence table (in the .mess file and possibly exported in a csv-type file);

• The separator lines in the message file.

The main difficulty in managing this data structure comes from the fact that the convergence table is dynamic because the display of columns depends both on the activated functionalities (linear search, type of residue, contact, etc.) defined via the list_func_acti object (see § 2.4.1.1), but also on options defined by the user (see §), but also on options defined by the user (INFO_RESIDU and INFO_TEMPS in the keyword factor AFFICHAGE monitoring, etc.) but also on options defined by the user (see §), but also on options defined by the user (and in the keyword factor) but also on options defined by the user (and in the keyword factor) but also on options defined by the user (see §). freedom in the keyword factor SUIVI_DDL).

A single ds_print variable of type NL_DS_Print manages all prints (except standard utmess). It contains various pieces of information:

• the information retrieved in the AFFICHAGE keyword;

• a flag indicating whether to display in the message file (evaluated using parameter PAS);

• a convergence table;

• a character string (the width of the convergence table) containing the separator line (with « -« );

Currently, op0070 only has a convergence table, but the definition of what a table is in generic form (see § 2.4.2.2) will eventually allow other tables to be added (such as energy for example).

Type NL_DS_Printa has the following structure:

Type	Name	Description
aster_logical	l_print	flag to know if you are displaying or not
type (NL_DS_Table)	table_cvg	convergence table
aster_logical	l_info_resi	parameter INFO_RESIDU in AFFICHAGE
aster_logical	l_info_time	parameter INFO_TEMPS in AFFICHAGE
aster_logical	l_tcvg_csv	flag to know if we output the convergence table in a file CSV
integer	tcvg_unit	parameter UNITEdans AFFICHAGE	parameter (convergence table in a file CSV)
integer	reac_print	parameter PASdans AFFICHAGE
character (len=255)	sep_line	dividing line (—), of the width of the convergence table

SD management is done in three stages:

1. Creating the SD in the CreatePrintDS routine in nmini0. In particular, this creation includes the creation of all possible columns in the convergence table. Their actual display will depend on the status of the flag when they are activated.

2. Reading the information given by the user (keyword AFFICHAGE). ReadPrint routine in nmdata. The information is stored in ds_print.

3. SD initialization. It is done in two stages:

   • Added columns for SUIVI_DDL in the InitPrint routine in nminit. Indeed, these columns (including their title) will depend on what the user asked for in the keyword factor SUIVI_DDL;

   • Activation of columns according to functionalities at each time step in nmimin (nmnpas routine).

Then, in terms of use in the algorithm, it is done in two stages. The developer assigns column values at the right time using the SetCol routine. The general algorithm concatenates the information, creates the convergence table, and displays it regularly at each Newton’s iteration. These utility routines for manipulating SD generally have an identifier starting with NMimpx. The list is not exhaustive.

2.4.2.2. Management of tables — NL_DS_Table

Data structure NL_DS_Table is an object that has a double function:

• it manages a table (in the Code_Aster sense) that is attached to the result data structure as is the observation table (see § 2.4.2.13) or statistics (see § 2.4.2.3);

• it manages a table that can be displayed in the mess file or exportable in CSV format (convergence or energy table for example)

This table is defined by:

• its columns: number, identifier and type (integer, real, string or complex);

• its lines: for each line, the value assigned and an assignment indicator;

• its header: title (three lines maximum);

• its graphic elements: dividing line (for example when passing loops of fixed points in contact);

• its dimensions: its total width (which is a function of the number of columns and the width of each column).

One of the difficulties in managing this table is to dynamically define the columns (depending on the functionalities for example.) To do this, we manage a double list:

• the exhaustive list of possible columns;

• an indicator of the activation of a column.

The generic array type is defined by NL_DS_Table which has the following structure:

Type	Name	Description
integer	nb_cols	Number of columns
integer	nb_cols_maxi	Maximum number of columns in a table
type (NL_DS_Column)	cols (max)	List of columns
aster_logical	l_cols_acti (max)	Flag indicating that the column is active or not
integer	width	Total width of the table
integer	title_height	Title height (3 by the convergence table)
character (len=255)	sep_line	Dividing line in the table
aster_logical	l_csv	Flag to say that this table is also printed in an external CSV file
integer	unit_csv	Logical unit for exporting to csv format
type (NL_DS_TableIO)	table_io	table_container data structure
integer	indx_vale (max)	Indirection table between columns and the associated object

The table_name, nb_para, list_para, and type_para objects allow table management utilities to be used directly. For example:

• call tbajpa (tble%table_name, tble%nb_para, tble%list_para, tble%type_para)

• call tbajli (tble%table_name, tble%nb_para, tble%list_para,…)

Without the need to rebuild parameter lists every time.

For reasons of efficiency, the maximum number of columns is not evaluated dynamically but given by the variable nb_cols_maxi. It is used for the variables cols (*) and l_cols_acti (*).

The utilities available for SD are as follows:

• createTable.f90: create a table in the result SD

• CreateVoidTable.f90: create an empty table (initialize all objects)

• ComputeTableHead.f90: creates strings that allow you to write the table title

• ComputeTableWidth.f90: calculates the total width of the table (according to the active columns)

• PrepareTableLine.f90: creates the string corresponding to an (empty) row in the table

• PrintTableLine.f90: creates the string (with values and marks) and prints it in a logical unit

• setTableColumn.f90: assigns a column in a table

• SettablePara.f90: prepare the list_para and type_para objects

A column is defined by:

• an identifier in the form of a string;

• three strings defining the title of the column (you can use 1, 2 or 3 depending on the definition of the table);

• a flag to say if a value is assigned or not (allows you to display nothing if the value is not defined);

• four flags to indicate the type of value contained in the column: integer, string, complex or real;

• four variables (integer, string, complex, real) containing the value to be displayed;

• the possibility of displaying a « brand » next to a value in a column. This mark is used, for example, to say on which residue we are converging (an « X ») or if we have reached a limit in the case of piloting. Note: Branding is only allowed with integer or real columns, not with strings.

A column is defined by the NL_DS_Column type which has the following structure:

Type	Name	Description
aster_logical	l_vale_affe	flag to say that we assigned a value in the column
aster_logical	l_vale_inte	flag to say that the column contains an integer
aster_logical	l_vale_real	flag to say that the column contains a real one
aster_logical	l_vale_cplx	flag to say that the column contains a complex
aster_logical	l_vale_strg	flag to say that the column contains a string
integer	vale_inte	value of the column if it is an integer
real (kind=8)	vale_real	column value if it’s a real
complex (kind=8)	vale_cplx	column value if it is a complex
character (len=24)	vale_strg	column value if it is a string
character (len=9)	name	column name (unique identifier)
character (len=16)	title (3)	column title (up to three title lines)
character (len=1)	mark	possible mark next to the value in the column (X, B, etc.)

2.4.2.3. Managing time measurements and statistics— NL_DS_Measure

The data structure makes it possible to manage the various measurements made during a calculation. It stores the times but also various information such as the number of iterations of Newton or the number of nodes in contact.

This is based on three data structures:

• SD NL_DS_Measure is represented by a single variable called ds_measure. It is an aggregator of the various measures;

• SD NL_DS_Timer manages the various timers;

• SD NL_DS_Device is the object that carries out the measurements.

Data structure NL_DS_Timer is a fairly simple object that allows you to manage calls to utilities such as UttCPU.f90. It has the following structure:

Type	Name	Description
character (len=9)	type	timer name (unique identifier)
character (len=24)	cpu_name	name for uttCPU utilities
real (kind=8)	time_init	initial time saved

The NMTime.f90 routine manages these timers (start, stop, measure and reset).

To start a timer:

call namtime (ds_measure, “Launch”, “Time_Step”)

To stop it (and measure):

call nmtime (ds_measure, “Stop”, “Time_Step”)

Then, data structure NL_DS_Device manages the measurements. Each device allows you to measure an operation during the calculation. The SD has the following structure:

Type	Name	Description
character (len=9)	type	Device name (unique identifier)
character (len=9)	timer_name	Name of the timer attached to the device
real (kind=8)	time_iter	Measured time for a Newton’s iteration
real (kind=8)	time_step	Time measured for a calculation step
real (kind=8)	time_comp	Measured time for the whole calculation
integer	time_indi_step	Index in the measure.py message catalog to show the time for this device at each time step (managed in Nmimpr_mess.f90)
integer	time_indi_comp	Index in the measure.py message catalog to show the time for this device at the end of the calculation (managed in Nmimpr_mess.f90)
aster_logical	l_count_add	Flag for accumulating the number of occurrences at each stage
integer	count_iter	Occurrence count for a newton iteration
integer	count_step	Occurrence count for a calculation step
integer	count_comp	Occurrence count for the whole calculation
integer	count_indi_step	Index in the measure.py message catalog to show the counter for this device at each time step (managed in Nmimpr_mess.f90)
integer	count_indi_comp	Index in the measure.py message catalog to show the counter for this device at the end of the calculation (managed in Nmimpr_mess.f90)

The Nmrvai.f90 routine allows you to manage counters.

To increment a counter (number of time steps for example):

call nmrinc (ds_measure, “Time_Step”)

To give the value of a counter:

call nmrvai (ds_measure, “contact_numbcount”, input_count = nbliac)

In fact Nmrinc.f90 is Nmrvai.f90 with input_count = 1.

Finally, the data structure NL_DS_Measure manages all the SDs allowing measurements (time and various statistics). It has the following structure:

Type	Name	Description
aster_logical	l_table	.true. when the user wrote TABLE =” OUI “in the MESURE keyword
type (NL_DS_Table)	table	Output table for statistics
integer	nb_device	Number of devices used
integer	nb_device_maxi	Number of devicemaxima
type (NL_DS_Device)	device (maxdevice)	Device list
aster_logical	l_device_acti (maxdevice)	List of active devices
integer	indx_cols (2*maxdevice)	Table column reference to device
integer	nb_timer	Number of timers used
integer	nb_timer_max	Maximum timer count
type (NL_DS_Timer)	timer (2*maxtimer)	Timer list
real (kind=8)	store_mean_time	Average archiving time
real (kind=8)	iter_mean_time	Average time per newton’s iteration
real (kind=8)	step_mean_time	Average time per time step
real (kind=8)	iter_resi_time	Time left for iteration
real (kind=8)	step_rememb_time	Time left for the time step

All of the data in this structure is created in the main routine Nmcrti.f90. This routine uses the ActivateDevice.F90 routine which allows you to activate a device depending on the availability of certain functionalities.

2.4.2.4. Energy calculation management— NL_DS_Energy

To measure energies, a NL_DS_Energy data structure is used, which has the following structure:

Type	Name	Description
aster_logical	l_comp	.true. when you want to measure energies
type (NL_DS_Table)	table	output table for energies (see § 16)
character (len=16)	command	Calling command

2.4.2.5. Algorithm error handling— SDERRO

This SD takes care of managing the errors of the algorithm. It contains seven objects of the same size, the number of events (variable ZEVEN) that can be processed by the algorithm (modifiable in nmcrga, see § 3.4.1)

SDERRO — Objects
Name	Description
SDERRO (1:19) //”. ENOM “	Name of the event
SDERRO (1:19) //”. ECOV “	Value of the return code linked to the event
SDERRO (1:19) //”. ECON “	Name of the return code linked to the event
SDERRO (1:19) //”. ENIV “	Type and level of triggering of the event
SDERRO (1:19) //”. EFCT “	Functionality that activates a convergence or divergence event
SDERRO (1:19) //”. EACT “	Event status (activated or not)
SDERRO (1:19) //”. EMSG “	Message code to be displayed when the event is triggered

The other two objects allow you to manage the state of the loop and to store the last triggered event (will be used for displays).

SDERRO — Objects
Name	Description
SDERRO (1:19) //”. CONV “	Loop status
SDERRO (1:19) //”. EEVT “	Information on the last triggered event

SDERRO is used using some of the information in SDDISC (§ 2.4.2.18), from the event definitions in the DEFI_LIST_INST command.

Operation on algorithm error management — SDERRO	Routine
Creating the SDERRO	nmcrga
Event registration	nmcrel
Registering an event from a return code	nmcret
Changing the state of a loop	nmeceb
Reading the state of a loop	nmleeb
Resetting events	nmeraz
Returns the status of an event (active or not) according to its name	nmerge
Issuance of the event information message	nmevim
Assessment of the convergence state of a loop	nmevcv
Returns the status of an event (active or not) according to its type	nmltev

The use of these routines for event management is detailed in § 3.4.

2.4.2.6. Input/Output Management — NL_DS_InOut

All the operations related to the following functionalities are called inputs/outputs of non-linear operators:

• Reading an initial state (keyword factor ETAT_INIT);

• Extraction of results into a table during the calculation (keyword factor OBSERVATION) and real-time monitoring in the convergence table (keyword factor SUIVI_DDL);

• Archiving the results in the result SD (keyword factor ARCHIVAGE).

There are two derived types for this feature: NL_DS_Inout and NL_DS_Field.

A single ds_inout variable of type NL_DS_Inout manages all the inputs/outputs. The main ds_inout object contains parameters from the user (keywords ETAT_INIT and ARCHIVAGE) as well as a list of fields and their input/output behavior.

This SD does not yet manage the case of _parameters_ of the result SDs (except the list of loads), but only the list of fields. It also does not manage the utilities related to the timing of the archiving (for the moment in SDDISC see § 2.4.2.18) nor the information related to how to perform a OBSERVATION (for the moment in the SDOBSE see § 2.4.2.13). Type NL_DS_Inout has the following structure:

Type	Name	Description
character (len=8)	result	name of the SD result to archive
integer	nb_field	number of fields managed
integer	nb_field_max	maximum number of manageable fields
type (NL_DS_Field)	field (nb_field_maxi)	List of fields
character (len=8)	stin_evol	SD name result in ETAT_INIT
aster_logical	l_stin_evol	flag for the presence of an SD result in ETAT_INIT
aster_logical	l_field_acti (nb_field_maxi)	flags of active fields (depends on features)
aster_logical	l_field_read (nb_field_maxi)	flags to indicate that a field is to be considered in the initial state
aster_logical	l_state_init	flag to indicate the presence of an initial state
aster_logical	l_reuse	flag to indicate that we are in reuse mode
integer	didi_nume	order number for loads DIDI (NUME_DIDI in ETAT_INIT)
character (len=8)	criterion	value of CRITEREdans ETAT_INIT (for selection by an instant)
real (kind=8)	precision	value of PRECISIONdans ETAT_INIT (for instant selection)
real (kind=8)	user_time	value of the initial state given by a moment in ETAT_INIT
aster_logical	l_user_time	flag to say that the value of the initial state is given by an instant in ETAT_INIT
integer	user_nume	value of the initial state given by an order number in ETAT_INIT
aster_logical	l_user_nume	flag to say that the value of the initial state is given by an order number in ETAT_INIT
real (kind=8)	stin_time	initial state value set by INST_ETAT_INIT in ETAT_INIT
aster_logical	l_stin_time	flag to say that the initial state value is set by INST_ETAT_INIT in ETAT_INIT
real (kind=8)	init_time	value of the initial moment
integer	init_nume	value of of the initial order number
character (len=19)	list_load_resu	name of the JEVEUX object storing the load list in the result SD
aster_logical	l_init_stat	flag to say that the initial state is stationary (for thermal)
aster_logical	l_init_vale	flag to say that the initial state is a value (for thermal)
real (kind=8)	temp_init	temperature given by the initial state when it is a value (for thermal)
type (NL_DS_TableIO)	table_io	Data structure for table_container PARA_CALC

This object therefore brings together both information from the user, but also the definition of input-output fields and their behavior, defined by the developer. A field has several states:

• It can define an initial state;

• It can be observed;

• It can be archived.

These three states are not necessarily independent. For example, a field that can be read in the initial state is necessarily archivable but the opposite is not true (there are fields that need to be archived but not in the initial state such as COMPORTEMENT, CONT_NOEU, CRIT_STAB, etc.).

A field is usable (initial state, observation and archiving) only if certain functionalities are active (for example, the dynamic speed field or the contact statuses for the contact)

If a field is defined in the initial state, it could be read in ETAT_INIT (either individually, per field, or in the SD result given in ETAT_INIT), or created (equal to zero) by the command (in this case, it will be necessary to define the name of this null field and create it).

So we have a list of fields (variable field) defined by the derived type NL_DS_Field. This object has the following structure:

SD management is done in three stages:

• Creation of the SD in the CreateInOutDS routine. In particular, this creation includes the creation of all possible fields. It is in this routine that the developer can add and define the behavior (initial state, archivable, observable, etc.) of a new field;

• Reading information given by the user (keyword ETAT_INIT). ReadInOut routine in nmdata;

• SD initialization: routine nmetcr for mechanics and nt etcr for thermal. These routines will activate the fields according to the functionalities present.

The utility routines for accessing the SD are as follows:

• Get IOField => retrieve information from a given field

• Set IOField => give information for a given field

These routines use the type of the input field (SD type variable NL_DS_Field).

Context of use: the developer wants to add a field, make it usable in OBSERVATION, ARCHIVAGE, SUIVI_DDL, or ETAT_INIT.

1. He starts by editing the CreateInOut DS_Mou CreateInOut DS_Mselon routine whether you are in mechanics or in thermal engineering. All you have to do is complete the information comprehensively at the beginning of this routine. If a new field is added, the total number must be modified (parameter nb_field_max);

2. If he must add a field in the result SD, it is also necessary to modify rscrsd;

3. The field is now _possibly_ activatable. But you have to activate it (for example under the condition of an active feature) in the nmetac routine;

4. Finally, if it is necessary to have a blank initial state, you should modify the nmetc0 routine to create this field.

2.4.2.7. Contact management — NL_DS_Contact

The contact is managed by two types of data structures:

• For the*definition* of contact and unilateral relationships [1]

(operator DEFI_CONTACT), refer to the documentation [D4.06.14] of sd_contact. This SD is not covered in this document;

• For the*resolution* of contact and unilateral relationships, a derived type called NL_DS_Contact is introduced.

The main ds_contact object (type NL_DS_Contact) contains the parameters useful for solving the touch/friction problem. A single ds_contact object of type NL_DS_Contactgère the entire touch/friction. It has the following structure:

Type	Name	Description
aster_logical	l_contact	flag to say that contact or ooze is activated in the operator
aster_logical	l_meca_cont	flag to say that mechanical contact is activated in the operator
aster_logical	l_meca_unil	flag to say that ooze is activated in the operator
character (len=8)	sdcont	concept name DEFI_CONTACT entered in STAT_NON_LINE/CONTACT
character (len=24)	sdcont_defi	object name JEVEUX for contact definition
character (len=24)	sdcont_solv	object prefix JEVEUX for contact resolution
character (len=24)	sdunil_defi	object name JEVEUX for the definition of LIAISON_UNIL
character (len=24)	sdunil_solv	object prefix JEVEUX for LIAISON_UNIL resolution
aster_logical	l_form_cont	flag to say we are in FORMULATION =” CONTINUE “
aster_logical	l_form_disc	flag to say we are in FORMULATION =” DISCRET “
aster_logical	l_form_xfem	flag to say we are in FORMULATION =” XFEM “
aster_logical	l_form_lac	flag to say we are in FORMULATION =” LAC “
aster_logical	l_elem_slav	flag to indicate the presence of contact slave elements (CONTINUE/LAC/XFEM)
character (len=8)	ligrel_elem_slav	name of <DNT_dnadkpoalflmkiebogncnhcbdnejnhgh >for slave elements (created in DEFI_CONTACT)
aster_logical	l_elem_cont	flag to indicate the presence of contact elements (CONTINUE/LAC/XFEM)
character (len=19)	ligrel_elem_cont	name of <DNT_mpnhjbfgeacnkbipomcokbihcchbcfia >for contact items (created in STAT_NON_LINE)
aster_logical	l_iden_rela	flag to indicate the presence of identity relationships to be processed by modifying the matrix (XFEMavec ELIM_ARETE or method LAC)
character (len=24)	iden_rela	name of the SD defining identity relationships
aster_logical	l_dof_rela	flag to indicate the presence of linear relationships between DDL (QUAD8pour discrete methods or XFEM, created in DEFI_CONTACT)
character (len=8)	ligrel_dof_rela	name of the SD defining linear relationships between DDL
character (len=19)	field_input	name of CHAM_ELEM as input to TEpour methods XFEM/CONTINUE/LAC
character (len=14)	nume_dof_frot	name of the NUME_DDLpour discrete friction matrix
character (len=19)	field_cont_node	name of field at nodes CONT_NOEU for post-processing
character (len=19)	fields_cont_node	simple node field name CONT_NOEU for post-processing
character (len=19)	field_cont_perc	name of the field at the percussion/impact nodes for post-processing
integer	nb_loop	effective number of contact processing loops to manage
integer	nb_loop_maxi	maximum number of contact processing loops to manage
NL_DS_Loop	loop (nb_loop_maxi)	pointers to the contact processing loops to be managed
aster_logical	l_renumber	flag for renumbering the matrix
real (kind=8)	geom_maxi	value to control the geometry loop
aster_logical	l_getoff	Flag for the detachment indicator (theta-schema)
aster_logical	l_first_geom	Flag to say this is the first iteration of a geometry loop
aster_logical	l_pair	Flag to say to match
aster_logical	l_wait_conv	Flag to say that you should wait for the fixed point of discrete contact (friction) sub-iterations

To manage the fixed contact point loops (geometry, friction and contact statuses), we created the derivative type NL_DS_Loop whose structure is as follows:

Type	Name	Description
character (len=4)	type	String identifying the type of the loop (Geom, Fricet Cont)
integer	counter	iterator for the loop counter
aster_logical	conv	flag to say that this loop is converged
aster_logical	error	flag to say that there was an error evaluating the loop
real (kind=8)	vale_calc	loop convergence value
character (len=16)	locus_calc	where the loop converges

SD management is done in three stages:

• Creation of the SD in the CreateContactDS routine;

• Reading information given by the user (keyword CONTACT). ReadContact routine in nmdata;

• SD initializations:

  • InitContact routine in nminit. This phase includes in particular reading the type of contact to manage LIGRELà (see routine nmdoct);

  • cfmxsd routine in nminit. Creation of the objects necessary for the resolution of the contact (essentially discreet). They are dynamic objects (depending on the number of nodes in contact) and it is therefore necessary to make them JEVEUX objects;

  • Cucrsd routine in nminit. Creation of the objects necessary for the resolution of unilateral links. They are dynamic objects (depending on the number of nodes) and it is therefore necessary to make them objects JEVEUX;

  • NMdoct routine: managing late LIGREL

The use of the SD is direct by calling its sub-objects (using%) or by already existing utility routines (such as the cfdis*and mminf* routines), already used to access the sdcont from DEFI_CONTACT.

2.4.2.8. Convergence Management — NL_DS_Conv

The aim here is to manage the information and the algorithm concerning convergence management, which includes:

• the management and calculation of equilibrium residues;

• the management of options coming from the keyword factor CONVERGENCE.

We create the derived types NL_DS_Resi, NL_DS_ResiRefeet NL_DS_Conv. A single ds_conv object of type NL_DS_Convgère the whole convergence. It contains various pieces of information:

• the information retrieved in the CONVERGENCE keyword;

• a location to store the value that triggered the RESI_GLOB_RELA to RESI_GLOB_MAXI switch;

• two variables to manage linear search.

It has the following structure:

Type	Name	Description
integer	nb_resi	residue count
integer	nb_resi_maxi	maximum number of residuals
type (NL_DS_Resi)	list_resi (max)	residue list
aster_logical	l_resi_test (max)	flag to say if we should use this residue for convergence
integer	nb_refe	number of components of type RESI_REFE_RELA
integer	nb_refe_maxi	maximum number of components of type RESI_REFE_RELA
type (NL_DS_RefeResi)	list_refe (max2)	list of components
aster_logical	l_refe_test (max2)	flag to say if the component is active or not
integer	iter_glob_maxi	parameter ITER_GLOB_MAXI
integer	iter_glob_elas	parameter ITER_GLOB_ELAS
aster_logical	l_stop	parameter ARRET =” NON “
aster_logical	l_iter_elas	flag to say that the user has explicitly entered ITER_GLOB_ELAS
real (kind=8)	swap_trig	value that triggered the RESI_GLOB_RELA to RESI_GLOB_MAXI switch
real (kind=8)	line_sear_coef	linear search coefficient
integer	line_sear_iter	number of iterations of linear search

This object contains the list of possible residues (currently, there are six residues included in the convergence assessment). Each residue is itself defined by the derivative type NL_DS_Resi which has the following structure:

Type	Name	Description
character (len=16)	type	residue type identifier
character (len=16)	col_name	identifier of the column in the convergence table storing the residual value
character (len=16)	col_name_locus	identifier of the column in the convergence table storing the location of the maximum residue norm (when INFO_RESIDU =” OUI “)
character (len=16)	event_type	identifier of the residual divergence event
real (kind=8)	vale_calc	value of the maximum residue norm
character (len=16)	locus_calc	location of the maximum residue norm
real (kind=8)	user_para	value of the criterion given by the user
aster_logical	l_conv	flag to indicate that vale_calc < user_para

Finally, the ds_conv object also contains the list of objects that define the RESI_REFE_RELA residue. Currently, eleven types of components exist. An object of type NL_DS_ResiRefea has the following structure:

Type	Name	Description
character (len=16)	type	component type
real (kind=8)	user_para	value of the component given by the user
character (len=8)	cmp_name	name of the component in the quantity for the TE

This SD is mainly used for residue evaluation. The routine that assesses their convergence is nmcore. Now, it is autonomous in the sense that the addition of a new type of residue does not require a specific step for this part (on the other hand, it will be necessary to perform the effective calculation of this residue, which is currently mainly carried out in nmresi).

To facilitate maintenance and readability, the part that deals with « flip-flops » has also been extracted:

• Passage of RESI_GLOB_RELAà RESI_GLOB_MAXI when the external load is zero;

• Transition from RESI_COMP_RELAà to RESI_GLOB_RELA at first moment

Note:

It is possible to do a double toggle RESI_COMP_RELA => RESI_GLOB_RELA => RESI_GLOB_MAXI.

SD management is done in three stages:

1. Creating the SD in the CreateConv DSdans nmini0 routine. In particular, this creation includes the creation of all available residues. Their effective use in the evaluation of convergence will depend on the status of the flag of their activation;

2. Reading the information given by the user (keyword AFFICHAGE). nmdoc routine in nmdata. The information is stored in ds_conv;

3. SD initialization in InitConv. In particular, this routine manages alarms (ARRET =” NON “or residue that is too loose) and activates residues specific to the contact (because they are read in nmdoc and not in nmdocn).

To handle the SD, we have the routine pairs SetResi/GetResiand SetResiRefe.

2.4.2.9. Algorithm Parameter Management — NL_DS_AlgoPara

This object stores two types of information:

• data from the options for the keyword factor NEWTON (REAC_ITER, matrix types, options for linear search, etc.);

• the intermediate results of the algorithm: results of the linear search and values of the calculated convergence residuals.

We create the derived types NL_DS_LineSearchet NL_DS_AlgoPara. An object of type NL_DS_AlgoParagère the parameters of the algorithm, it has the following structure:

Type	Name	Description
character (len=16)	method	keyword METHODE (Newton, Newton-Krylov, IMPLEX)
character (len=16)	matrix_pred	type of matrix in prediction
character (len=16)	matrix_corr	type of matrix being corrected
integer	reac_incr	value of REAC_INCR
integer	reac_iter	value of REAC_ITER
real (kind=8)	not_mini_elas	value of PAS_MINI_ELAS
integer	reac_iter_elas	value of REAC_ITER_ELAS
aster_logical	l_line_search	flag to say that linear search is enabled
type (NL_DS_LineSearch)	line_search	object to describe linear search parameters
character (len=8)	result_prev_disp	SD result for DEPL_CALCULE/EXTRAPOLE
aster_logical	l_matr_rigi_syme	Flag to symmetrize the stiffness matrix (MATR_RIGI_SYME)

The line_search object is a type derived from type NL_DS_LineSearchdont here is the structure:

Type	Name	Description
character (len=16)	method	linear search type
real (kind=8)	resi_rela	tolerance for linear search
integer	iter_max	maximum number of linear search iterations
real (kind=8)	rho_mini	minimum value of the linear search code
real (kind=8)	rho_maxi	maximum value of the linear search code
real (kind=8)	rho_excl	value to exclude for linear search code

We define a single ds_algoparade variable type NL_DS_AlgoParaqui will be passed as an argument in the routines that need it. SD management is done in three stages:

1. Creating the SD in the CreateAlgoPara routine DSdans nmini0;

2. Reading the information given by the user (keyword NEWTON). Nmdomt routine;

3. Reading the information given by the user (keyword RECH_LINEAIRE). nmdomt_ls routine;

4. Initialization of the SD by the InitParaAlgo routine.

2.4.2.10. Field extraction management — SDEXTR

SUIVI_DDL shares with OBSERVATION (see § 2.4.2.13) a common SD called SDEXTR, a routine for extracting field values. We will therefore start by describing this last SD. The first three objects are general and their length is proportional to the number of occurrences of the SUIVI_DDL or OBSERVATION keyword.

SDEXTR — Objects
Name (beware of white people!)	Description
SDEXTR (1:14) //”. INFO “	Various information on extraction data
SDEXTR (1:14) //”. EXTR “	Extraction type - On the field (NOEU and ELGA) On the mesh (if ELGA) On the components or formula between the components
SDEXTR (1:14) //”. ACTI “	Active extraction or not

We cannot have more than 99 occurrences of keywords because we build the names of certain objects from this occurrence number OCC. These objects are as follows:

SDEXTR — Objects
Name (beware of white people!)	Description
SDEXTR (1:14)//OCC//”. NOEU “	Nodes affected by extraction
SDEXTR (1:14)//OCC//”. MAIL “	Meshes affected by extraction
SDEXTR (1:14)//OCC//”. POIN “	Integration points affected by extraction
SDEXTR (1:14)//OCC//”. SSPI “	Integration sub-points affected by extraction
SDEXTR (1:14)//OCC//”. CMP “	Components involved in extraction

2.4.2.11. Management of SUIVI_DDL — SDSUIV

This SD is used to manage the SUIVI_DDL feature. In addition to the references to extracting fields (SDEXTR, § 2.4.2.11), we have a specific object for the SUIVI_DDL.

SDSUIV — Objects
Name (beware of white people!)	Description
SD SUIV (1:14) //”. TITR “	Column titles

2.4.2.12. Management of the OBSERVATION — SDOBSE

This SD is used to manage the OBSERVATION feature. OBSERVATION shares with SUIVI_DDL (see § 2.4.2.12) a common SD called SDEXTR, already described in (§ 2.4.2.11).

Then we have specific objects for OBSERVATION. One that will give the name of the table and one that stores the information relating to the observation frequency (utility object SDSELI, see § 2.4.2.19), indexed by the occurrence number OCCdu keyword OBSERVATION.

SDOBSE — Objects
Name (beware of white people!)	Description
SDOBSE (1:14) //”. TABL “	Table name
SDOBSE (1:14)//OCC//”.LI”	Access to SDSELI, list of moments to observe

2.4.2.13. Management of quality criteria — SDCRIQ

This SD is used to assess quality criteria (keyword CRIT_QUALITE). It is very simple and has only one object.

SDCRIQ — Objects
Name	Description
SDSUIV (1:1 9) //”. ERRT “	Value of errors THM space and time, coefficient THETA

2.4.2.14. Piloting Management— SDPILO

This SD is used for piloting (continuation method). Most of these objects are grouped together in type logic (real with real, strings with strings), rather than in functional logic.

SDPILO — Objects
Name	Description
SDPILO (1:19) //”. PLTK “	Contains the control parameters (string type) or the names of objects required for control
SDPILO (1:19) //”. PLIR “	Contains control parameters (real type)
SDPILO (1:14) //”. PLCR “	List of coefficients for piloting
SDPILO (1:14) //”. PLSL “	List of DDL types \(\mathit{DX}\), \(\mathit{DY}\) and \(\mathit{DZ}\) for piloting
SDPILO (1:14) //”. PLCI “	List of coefficients for piloting - Case XFEM

There are no top-level access routines, the SD is created in the nmdopi routine. You have to attack the SD directly.

2.4.2.15. Numbering Management— SDNUME

This SD complements the two SDs NUMDDL and NUMFIX to manage the numbering of equations. NUMDDL is the numbering of the equations, which can be variable during the transition, when using functionalities like contact CONTINUE or contact XFEM. NUMFIX is the fixed numbering, it is useful in the case of macroelements, in order to be able to combine matrices. SDNUME contains three other items:

SDNUME — Objects
Name	Description
SDNUME (1:19) //”. NDRO “	Finding DDL for big rotations
SDNUME (1:19) //”. NUCO “	Finding the DDL for contact and friction Lagrangians
SDNUME (1:19) //”. ENDO “	Finding DDL for node damage

These three objects have the same logic: they are sized to the total number of degrees of freedom of the structure, with the same numbering as the matrices and CHAM_NO used in op0070. A particular value (generally 1) is used to identify specific DDL in principle: those corresponding to large rotations, those corresponding to touch/friction lagrangians and those corresponding to damage. They are then used in some cases (for example, to update specific fields in the case of large rotations or to filter the components in the evaluation of residues). There are no specific access routines.

2.4.2.16. Dynamic Management— SDDYNA

This SD contains all the information necessary for the dynamic calculation.

SDDYNA — Objects
Name	Description
SDDYNA (1:15) //”. PARA_SCH “	Schema settings in time
SDDYNA (1:15) //”. INFO_SD “	Dynamic parameters
SDDYNA (1:15) //”. NOM_SD “	SD names for dynamics (static modes, vectors,…)
SDDYNA (1:15) //”. TYPE_FOR “	Type of formulation (displacement, speed, or acceleration)
SDDYNA (1:15) //”. COEF_SCH “	CoEFFICIENTS TO BE USED IN THE CALCULATION
SDDYNA (1:15) //”. TYPE_CHA “	ONDE_PLANE Charging Information
SDDYNA (1:15) //”. NBRE_CHA “	Information on some dynamics-specific loads
SDDYNA (1:15) //”. VEEL_OLD “	Elementary vectors of the previous step for multi-step schemes
SDDYNA (1:15) //”. VEAS_OLD “	Assembled vectors from the previous step for multi-step diagrams
SDDYNA (1:15) //”. VECENT “	Quantities in training (movements, speeds and acceleration)
SDDYNA (1:15) //”. VECABS “	Absolute quantities (displacements, velocities and acceleration)

Access to this information is done via four routines, each dedicated to a type, with a string asking the question (on the model of the Dismoi routine):

Operation on dynamic management — SDDYNA	Routine
Reading type information <booléen>	Ndynlo
Reading type information <réel>	Ndynd
Reading type information <entier>	Ndynin
Reading type information <chaîne>	ndynkk

Note that these questions will lead to a fatal error if we are not in dynamics, except in the case of question NDYNLO (SDDYNA, “DYNAMIQUE”) which will answer.false. if we are in static (i.e. who knows how to detect the case where SDDYNA does not exist). Apart from these four routines, access to SDDYNA is done directly in two routines:

Operation on dynamic management — SDDYNA	Routine
Reading information from the command file	ndlect
Record value of the various coefficients	ndnpas

We come back to the coefficients necessary for the calculation in dynamics because they are very numerous. These coefficients are constructed from three pieces of information:

• The type of diagram;

• The parameters of the diagram (coefficients ALPHA, BETA, KAPPA, etc.);

• The time increment;

The fact of depending on the time step implies that the coefficients are re-evaluated at each step (in the ndnpas routine).

Coefficient	Description
COEF_MATR_RIGI	Coefficient in front of the stiffness matrix
COEF_MATR_AMOR	Coefficient in front of the damping matrix
COEF_MATR_MASS	Coefficient in front of the mass matrix
COEF_DEPL_DEPL	Predictor on the move: coefficient in front of the displacement of the previous step
COEF_DEPL_VITE	Predictor on the move: coefficient in front of the speed of the previous step
COEF_DEPL_ACCE	Predictor on the move: coefficient in front of the acceleration of the previous step
COEF_VITE_DEPL	Speed predictor: coefficient in front of the displacement of the previous step
COEF_VITE_VITE	Speed predictor: coefficient in front of the speed of the previous step
COEF_VITE_ACCE	Speed predictor: coefficient in front of the acceleration of the previous step
COEF_VITE_DEPL	Accelerator predictor: coefficient in front of the displacement of the previous step
COEF_VITE_VITE	Accelerator predictor: coefficient in front of the speed of the previous step
COEF_VITE_ACCE	Accelerator predictor: coefficient in front of the acceleration of the previous step
COEF_DEPL	Coefficient in front of the displacement increment
COEF_VITE	Coefficient in front of the speed increment
COEF_ACCE	Coefficient in front of the acceleration increment
COEF_MPAS_FEXT_PREC	Coefficient in front of the external forces of the previous step (multistep diagram)
COEF_MPAS_FINT_PREC	Coefficient in front of the internal forces of the previous step (multistep diagram)
COEF_MPAS_FEXT_COUR	Coefficient in front of the external forces of the current step (multistep diagram)
COEF_MPAS_EQUI_COUR	Coefficient in front of the other terms of the second member (inertia, damping)
COEF_FDYN_MASSE	Coefficient in front of dynamic restoring forces (inertia)
COEF_FDYN_AMORT	Coefficient in front of dynamic restoring forces (damping)
COEF_FDYN_RIGID	Coefficient in front of the restoring forces?????? (used by Krenk???)
COEF_FORC_INER	Coefficient in front of inertial forces to be put in the denominator in the equilibrium residue
INST_PREC	No previous time (only useful for the pursuit with, at the same time, the full HHT schema and the laws of behavior that need this parameter)

2.4.2.17. Managing time discretization— SDDISC

Data structure SDDISC contains all the information from the DEFI_LIST_INST operator (creation of the concept SDLIST) and information relating to the management of temporal discretization in op0070. First, the information from the DEFI_LIST_INST operator (see [D4.06.17]) is copied locally into the SDDISC.

SDDISC — Objects
Name	Description
SDDISC (1:19) //”. LINF “	Information on the list of moments (see content in []) Copy of the object SDLIST (1:8) //”. LIST. INFOR “
SDDISC (1:19) //”. DITR “	List of moments — This list is dynamic (in case of cutting or accelerating the time step)
SDDISC (1:19) //”. DINI “	Indicator of the level of sub-division for each time step. Initially, the cutting level is 1. There cannot be more than one cutting level between two successive steps (check in the nmdcin routine) —This list is dynamic (in case of cutting or accelerating the time step)
SDDISC (1:19) //”. ITER “	Nombre d'itérations de Newton qu'il a fallu pour chaque pas de temps – Cette liste est dynamique (en cas de découpe ou d'accélération du pas de temps)
SDDISC (1:19) //”. EPIL “	Indicator for the choice of the management solution (action AUTRE_PILOTAGE)
SDDISC (1:19) //”. LIPO “	List of mandatory calculation times. This object is used in the case of the automatic adaptation of the time step, it indicates the moments that will be calculated no matter what (even in case of enlargement of the time step). We also talk about « milestone » moments. Its length is that of the initial list of times given by the user in DEFI_LIST_INST. So it’s a non-dynamic list.
SDDISC (1:19) //”. REPC “	Preconditioning update management indicator (action REAC_PRECOND)
SDDISC (1:19) //”. EEVR “	Copy object SDLIST (1:8) //”. ECHE. EVENR “See contained in []
SDDISC (1:19) //”. EEVK “	Copy object SDLIST (1:8) //”. ECHE. EVENK “See contained in []
SDDISC (1:19) //”. ESUR “	Copy object SDLIST (1:8) //”. ECHE. SUBDR “See contained in []
SDDISC (1:19) //”. AEVR “	Copy object SDLIST (1:8) //”. ADAP. EVENR “See contained in []
SDDISC (1:19) //”. AEVK “	Copy object SDLIST (1:8) //”. ADAP. EVENK “See contained in []
SDDISC (1:19) //”. ATPR “	Copy object SDLIST (1:8) //”. ADAP. TPLUR “See contained in []
SDDISC (1:19) //”. ATPK “	Copy object SDLIST (1:8) //”. ADAP. TPLUK “See contained in []
SDDISC (1:19) //”. AEXT “	Object for the extension of the cut (treatment of the case of COLLISION)
SDDISC (1:19) //”. IFCV “	Object storing the state of convergence for adaptation V (1) —Value of MAX (ITER_GLOB_MAXI, ITER_GLOB_ELAS) V (2) —Value of MIN (ITER_GLOB_MAXI, ITER_GLOB_ELAS) V (3) —Maximum number of possible iterations (including additional iterations possible by ITER_SUPPL) V (4) —Value of “PAS_MINI_ELAS” V (5) —Value of “ RESI_GLOB_RELA “V (6) —Value of” RESI_GLOB_MAXI “V (7) —Type of residue requested by the user: =1 for RESI_GLOB_RELA =2 for RESI_GLOB_MAXI =3 for RESI_GLOB_RELA and RESI_GLOB_MAXI V (8) —Value of” INIT_NEWTON_KRYLOV “V (9) —Value of” “V (9) —Value of” ITER_NEWTON_KRYLOV “V (9) —Value of” “V (10) —Indicates that additional iterations are allowed
SDDISC (1:19) //”. IFRE “	Object storing the value of the residuals at each Newton iteration V (3*(ITER -1) +0) —Value of RESI_GLOB_RELA V (3* (ITER -1) +1) —Value of RESI_GLOB_MAXI V (3* (ITER -1) +2) —Value of load

To handle SDDISC, a series of utilities are used.

Operation on the management of temporal discretization— SDDISC	Routine
A general utility routine that allows access to the contents of objects. LINF,. EEVR,. EEVK,. ESUR,. AEVR,. AEVK,. ATPR,. ATPK,. REPCet. EPIL. Access can be done by reading or writing.	used
Go back. RUE .if we leave the list of moments (end of the transitory)	didern
Value of the moment according to number of the moment	diinst

2.4.2.18. Managing the selection of a moment— SDSELI

The data structure SDSELI makes it possible to select an instant according to a frequency, a list of values, taking into account a tolerance and a type of criterion (absolute or relative).

SDSELI — Objects
Name	Description
SDSELI (1:19) //”. INFL “	General selection information (selection parameters)
SDSELI (1:19) //”. LIST “	List of moments given by the user

To operate on this SD, two routines are mainly used:

• one that reads user settings (nmcrpx);

• search if the given moment is selected (nmcrpo);

Operation on managing the selection of a moment — SDSELI	Routine
Reading the list of moments to select	nmcrpa
Reading the precision and the type of criterion (relative or absolute)	nmcrpp
Reading all information (call to nmcrpa and nmcrpp)	nmcrpx
Search for a real in a list (with precision and criteria)	utacli
Main search routine of the moment	nmcrpo
Search for the index in the SD result just before a given moment	nmttch

This SD is used for the management of temporal discretization, initial state, archiving and observation.

2.4.2.19. Managing convergence criteria— SDCRIT

This SD manages information relating to convergence criteria, it is used in particular to store residues in SD RESULTAT.

SDCRIT — Objects
Name	Description
SDCRIT (1:19) //”. CRTR “	Information values (residuals, number of iterations, etc.)
SDCRIT (1:19) //”. CRDE “	Name of information for storage in SD RESULTAT (residuals, number of iterations, etc.)

This SD is also used for the THER_NON_LINE command (be careful, the objects are not of the same size!). The information for this SD is saved in the nmcore routine that evaluates convergence at each Newton iteration.

Operation on the management of convergence criteria — SDCRIT	Routine
Creation of the SD	nmcrcv ntcrcv
Saving information in SDCRIT	nmcore OP0186
Save information to SD RESULTAT	nmarc0 Ntarc0

2.4.2.20. Managing the selection list— NL_DS_SelectList

This data structure allows you to select a moment from a list or a frequency.

Type	Name	Description
integer	nb_value	Number of values in the list of given times
real (kind=8)	incr_mini	Minimum time increment between two times in the list
real (kind=8), pointer	list_value	List of moments
real (kind=8)	precision	Precision value to select an instant
aster_logical	l_abso	Sets.true. If the value is selected in absolute
real (kind=8)	tolerance	Tolerance calculated if selected in relative
integer	freq_step	Instant selection frequency
aster_logical	l_by_freq	Sets.true. If we select by frequency

The SelectListRead routine allows you to read the user’s keywords and fills the data structure.

The SelectListGet routine returns.true. Whether the current moment must be selected in relation to the parameters (frequency, list of moments with precision, etc.). Finally, the SelectListClean routine deallocates the memory (necessary because a pointer is used for the list of moments).

2.4.2.21. Management of modal calculation during non-linear calculation — NL_DS_PostTimeStep, NL_DS_Spectral, NL_DS_Stability and NL_DS_SpectralResults

These data structures are used to manage the keywords MODE_VIBR and CRIT_STAB.

Data structure for saving modal analysis parameters: NL_DS_Spectral.

Type	Name	Description
character (len=16)	option	Calculation option
character (len=16)	type_matr_rigi	Stiffness matrix type
aster_logical	l_small	Value.true if we calculate the smallest eigenvalues
aster_logical	l_strip	Value.true if you calculate the eigenvalues in a band
real (kind=8)	strip_bounds (2)	Frequency band if l_strip
integer	nb_eigen	Number of eigenvalues if l_small
integer	coef_dim_espace	Parameter for the modal solver	Parameter for the modal solver
type (NL_DS_SelectList)	selector	Selector of calculation times
character (len=16)	level	Calculation level: per band, smallest values or calibration mode (only number of eigenvalues)

Data structure for saving stability analysis parameters (CRIT_STAB): NL_DS_Stability.

Type	Name	Description
aster_logical	l_geom_matr	Value.true.to take into account geometric rigidity	l_geom_matr	Value.true
aster_logical	l_modi_rigi	Value.true.to take into account the stiffness modification
integer	nb_dof_excl	Count of DDL excluded
character (len=8), pointer	list_dof_excl	List of DDL excluded
integer	nb_dof_stab	DDL stabilization count
character (len=8), pointer	list_dof_stab	List of DDL stabilization
character (len=16)	instab_sign	Instability sign value
real (kind=8)	instab_prec	Absolute value of instability

Data structure to save modal analysis parameters (MODE_VIBR and CRIT_STAB): NL_DS_PostTimeStep.

Type	Name	Description
aster_logical	l_crit_stab	If CRIT_STAB is specified
aster_logical	l_mode_vibr	If MODE_VIBR is specified
type (NL_DS_Spectral)	crit_stab	CRIT_STAB general settings
type (NL_DS_Spectral)	mode_vibr	MODE_VIBR general settings
type (NL_DS_Stability)	stab_para	Parameters specific to CRIT_STAB
type (NL_DS_TableIO)	table_io	table_container data structure ANALYSE_MODALE
aster_logical	l_hpp	Value.true if HPP

2.4.2.22. Managing container tables— NL_DS_TableIO

This data structure makes it possible to manage the table_containers attached to STAT_NON_LINE and DYNA_NON_LINE.

Type	Name	Description
character (len=8)	result	Result data structure name
character (len=19)	table_name	Table_container name JEVEUX
character (len=24)	table_type	Table_container type
integer	nb_para	Total number of parameters in the table_container (number of columns)
integer	nb_para_inte	Number of integer parameters
integer	nb_para_real	Number of real parameters
integer	nb_para_cplx	Number of complex parameters
integer	nb_para_strg	Number of string parameters
character (len=24), pointer	list_para	List of parameter names
character (len=8), pointer	type_para	List of parameter types

The nonlin DSTableIOCreate routine allows you to create the data structure and the table_container in the evol_noli data structure.

The nonlin DSTableIOSetPara routine allows you to give the list of parameters in the table. They can be given in two ways:

• or from data structure NL_DS_Table (see § 2.4.2.2);

• or from an exhaustive list of these parameters.

The nonlin DSTableIOClean routine deallocates objects (required because of the use of pointers).

2.4.2.23. CARCRI and COMPOR behavior management

Data structure CARCRI is an sd_map that contains real numbers. It currently stores 22 parameters, which are listed below.

Hint	Content
1	Keyword COMPORTEMENT/ITER_INTE_MAXI
2	Keyword COMPORTEMENT/TYPE_MATR_TANG
3	Keyword COMPORTEMENT/RESI_INTE_RELA
4	Keyword COMPORTEMENT/PARM_THETA
5	Keyword COMPORTEMENT/ITER_INTE_PAS
6	Keyword COMPORTEMENT/ALGO_INTE
7	Keyword COMPORTEMENT/VALE_PERT_RELA
8	Keyword COMPORTEMENT/RESI_CPLAN_MAXI
9	Keyword COMPORTEMENT/ITER_CPLAN_MAXI
10	Keyword COMPORTEMENT/RESI_RADI_RELA
11	Integer coded for the presence of externalStateVariable command variables
12	Keyword SCHEMA_THM/PARM_THETA
13	Keyword COMPORTEMENT/POST_ITER
14	Pointer to the number of internal variables stateVariablefor MFront
15	Pointer to the names of the internal variables stateVariablefor MFront
16	Pointer to the law of behavior MFront
17	Tangent Behavior Matrix Symmetry Indicator
18	Keyword SCHEMA_THM/PARM_ALPHA
19	Pointer to material parameter names for MFront
20	Pointer to material parameter names for MFront
21	Keyword COMPORTEMENT/POST_INCR
22	Kinematic model type for MFront

Data structure COMPOR is an sd_map that contains strings. It currently stores 20 parameters, which are listed below.

The clue is given in the behaviour_type.h file.

Indication name**	Content
RELA_NAME	Keyword COMPORTEMENT/RELATION
NVAR	Number of internal variables
DEFO	Keyword COMPORTEMENT/DEFORMATION
INCRELAS	Incremental or total model indicator
PLANESTRESS	Plane constraint model (Deborst or analytical)
NUME	Behavioral Law Call Index (lcxxxx)
MULTCOMP	Data structure name from DEFI_COMPOR
POSTITER	COMPORTEMENT/POST_ITER keyword content
KIT1_NAME THMC_NAME CREEP_NAME CABLE_NAME	Name of the first relationship for a kit
KIT2_NAME THER_NAME PLAS_NAME SHEATH_NAME	Name of the second relationship for a kit
KIT3_NAME COUPL_NAME HYDR_NAME	Name of the third relationship for a kit
KIT4_NAME CPLA_NAME MECA_NAME	Name of the fourth relationship for a kit
KIT1_NUME THMC_NUME PLAS_NUME	First relationship call clue for a kit
KIT2_NUME THER_NUME CREEP_NUME	Second relationship call clue for a kit
KIT3_NUME HYDR_NUME	Third relationship call clue for a kit
KIT4_NUME MECA_NUME	Fourth relationship call clue for a kit
KIT1_NVAR THMC_NVAR CREEP_NVAR	Number of internal variables in the first relationship for a kit
KIT2_NVAR THER_NVAR PLAS_NVAR	Number of internal variables in the second relationship for a kit
KIT3_NVAR HYDR_NVAR	Number of internal variables in the third relationship for a kit
KIT4_NVAR MECA_NVAR	Number of internal variables in the fourth relationship for a kit

[1]

Unilateral conditions (LIAISON_UNILATER) manage suction and ooze conditions for issues in THM