1. Introduction#

Numerical study

To perform a numerical study with*Code_Aster*, the end user triggers the code functionalities and provides the information required to perform these functionalities.

A feature is selected through a command. A command is first of all a name, i.e. a character string or even an external identifier (known to the user) of the feature. It also aggregates attributes and first of all the internal identifier of the feature (usable by the Fortran code).

The information required to launch and execute the order, in other words the parameters of digital processing, are data entered using keywords identifying them. For a given command, a certain number of parameters must be defined.

The description of commands and keywords is done by the developers of*Code_Aster*. in a file called « order catalog ».

The end user uses the code through a file called a « command file. » It provides orders whose composition must be compatible with their description in the order catalog. The commands are numerous but the number of associated data is much greater with very numerous possible combinations themselves.

Finally, the calculation code stores information (commands and keywords) in an internal data structure called a « command set ».

The role of the supervisor

The supervisor is the part of*Code_Aster* that manages the command set. In particular:

  1. it imports the command catalog into Python memory,

  2. it loads commands and their keywords into Python memory,

  3. it executes the processing on a command-by-command basis,

  4. it provides - at the request of Fortran - the value of the parameters to the functionalities of Code_Aster. stored in Python memory. To do this, the supervisor offers a API C.

The Eficas graphical interface

It is possible to define your command file « manually », for example using a text editor. However, the user who is not familiar with the syntax of the commands he manipulates but also with the Python language will be able to use Eficas.

The Eficas graphical interface is intended for the end user of*Code_Aster*. It allows it to build valid commands with associated keywords that are also statically validated, then to generate a command file for the code. The user is assured that the file produced by Eficas has correct syntax.

The core

The sources common to the Eficas graphical interface and the Code_Aster supervisor are organized (identified and grouped) in a specific development space called the « Core ». Understanding these sources is obviously a necessary condition for undertaking the maintenance of the two tools that use them.

The main actors

The main types of actors working in the Eficas and supervisor environment are listed below.

  1. The end user: rather, he knows the physical part of the problem to be solved and his task is to enter valid data into the code, launch calculations and analyze the results; he can use the Eficas graphical interface to do this.

  2. The developer of functionalities in Code_Aster: he essentially practices Fortran programming numerical algorithms and, in the case of a macro-command, writing the corresponding Python script; he enriches and/or modifies the command catalog and he uses the supervisor’s API C to retrieve the values provided by the end user in his Fortran code.

  3. The supervisor developer in Code_Aster: he writes the scripts for reading and interpreting the command catalog and the command set; he also takes care of the python aster module written in C (astermodule.c) which serves as API for the supervisor.

  4. The person responsible for maintaining the code, the user environment and the configuration management: he centralizes the sources. In addition to Fortran code, these sources include those in the catalog (Python) of commands, the scripts (Python) of the supervisor, and those of the aster module.

  5. The developer of the graphical interface Eficas is developing a human-machine interface. Its role is to design and program dialog boxes as well as event sequences allowing the consideration of end user requests and the verification - at any moment - of the validity of the set of commands under construction.

Instead, this document focuses on the principles of kernel design on the details of scripts that cannot be spared from examining.

Topics covered

The first chapter provides a summary definition of the terms used extensively throughout the rest of the document.

Chapter 2 introduces the few conventions and the organization of source files into directories: packages. It also describes the environment necessary for the development and operation of the Code_Aster supervisor and the Eficas graphical interface.

In chapter 3, a few reminders are given about the Python scripting language. They must guide the future maintenance manager towards certain techniques that he will need to master in order to perform his task.

The important subject of the control factory is discussed in chapter 4. It is a necessary basis for understanding the entire structure of the command set.

Finally, an answer is given in chapter 5, to some questions that any future maintenance manager may ask themselves.

1.1. Definitions#

Batch Mode

The process of processing user orders by the*Code_Aster* can be carried out in two modes.

In the first mode, the command file is loaded into memory to create the command set. This creation of the jdc makes it possible to validate the Python syntax (brackets, commas), the Aster syntax (coherence with the catalog) and to validate the concepts passed as arguments. Finally, after this verification, the command set is scanned to perform the corresponding numerical treatments.

This first mode is called « batch mode ». The end user selects this mode by specifying the value “OUI” for the PAR_LOT keyword under the DEBUT command.

In the second mode, the command file is loaded into memory to create the command set. Then the steps (equivalent to the commands) are constructed and executed sequentially.

The end user selects this mode by specifying the value “NON” for the PAR_LOT keyword under the DEBUT command.

By default, the mode used is PAR_LOT =” OUI “.

Operator Code_Aster

An operator is a unit of*Code_Aster* that takes care of a code feature. Concretely, it’s a Fortran subroutine whose name is numbered, for example the OP0001 subroutine that loads a mesh into the application’s memory. The numbering of operators facilitates the association between their internal representation (Fortran subroutine) and their external representation for the end user (command).

Order

A command is a character string identifying a numerical operator. It therefore allows the end user to trigger the execution of this operator from a data file called a « command file ».

There are 4 types of commands: OPER, PROC,, MACRO, and FORMULE.

The developer of the digital operator defines - in the order catalog - the characteristics of the order and those of the keywords corresponding to the parameters of the digital operator:

  1. its name (the character string that can be used by the end user),

  2. its rules of composition in keywords,

  3. an explanatory commentary in English and/or French,

  4. the key defining the manual and the chapter devoted to this keyword in the Code_Aster documentation.

Order OPER

In addition to the attributes listed above, a OPER command has the following attribute:

  1. The type of the Aster data structure produced by the operator and returned by the command;

Order PROC

A PROC command has the characteristic of not having to return a value. Apart from this particularity, it has the same attributes as a OPER command.

Order MACRO

A macro is a function written in Python — by the developer Aster — that calls commands — that is, operators — of*Code_Aster*. It stores results that can be retrieved via the supervisor.

The macro text can be public; in this case it is stored in a specific file in the Macro subdirectory. If it is private, it is placed or imported into the command file.

A command like MACRO allows the end user to use the macro. For example, the ASSEMBLAGE command allows you to launch the public assemblage_ops macro.

Order catalog

The catalog of an order is the set of Python instructions describing the definition of the command, that is, the values assigned to the attributes of the command.

The catalog for an order is written by the developer of the digital operator associated with the order.

General catalog

The general catalog is a Python file containing the description of all the commands, in other words containing the catalogs of all the commands.

Command game

The command set is the data structure - organized in a Python object - containing all the information provided by the end user, in the command file.

Order file

The command file allows the end user to trigger numerical operators carrying the functionalities of Code_Aster via commands.

Aster data structure

An Aster data structure is an organization of data produced by a numerical operator of*Code_Aster*. It is identified by a type that is itself declared at the beginning of the catalog (cata.py); this allows it to be used — symbolically — in the command file even though it is produced by Fortran.

Simple keyword

A simple keyword is a character string identifying data used as input by an operator (a numerical feature of*Code_Aster*). A simple keyword is therefore defined inside a Code_Aster command.

The end user will be able to provide a value to the command parameter via the name of the corresponding simple keyword in the command file.

The Code_Aster feature developer will define the characteristics of the simple keyword in the catalog of the command containing the simple keyword:

  1. its name (the character string usable by the end user and by the numerical operator),

  2. the type of the parameter (integer, real, text, concept,…),

  3. the status of the simple keyword (optional or mandatory),

  4. the default value to assign to the parameter,

  5. the minimum number of data that the end user must provide behind the simple keyword,

  6. the maximum number of data that the end user must provide behind the simple keyword,

  7. an explanatory commentary in English and/or French.

The Code_Aster supervisor loads the characteristics of the simple keyword into the application’s memory from the command catalog. Then it loads (and verifies) possibly the value of the command parameter from the command file provided to the application by the end user.

The numeric operator of*Code_Aster* queries the supervisor via the API getvxx command to retrieve the parameter value from the keyword name. The supervisor returns the value provided by the user or the default value of the parameter.

Key factor

A keyword factor is a character string identifying a group of simple semantically associated keywords. A factor keyword is defined inside a command. An order can contain several keyword factors, possibly optional factors., each factor keyword itself contains simple keywords with the same name.

In his command file, the end user will be able to define a factor keyword by specifying its name and then its value, i.e. the value of the numerical parameters defined behind the simple keywords of the factor keyword.

The developer of the Code_Aster feature defines the characteristics of the factor keyword in the catalog of the command containing the factor keyword:

  1. its name (the character string usable by the end user and by the numerical operator),

  2. its rules of composition in simple keywords,

  3. the status of the factor keyword (optional or mandatory),

  4. the minimum number of times the factor keyword is repeated,

  5. the maximum number of times the factor keyword is repeated,

  6. an explanatory commentary in English and/or French,

  7. the key defining the manual and the chapter devoted to this keyword in the Code_Aster documentation.

Conditional block

A conditional block (a block), associated with:

  1. simple keywords,

  2. key factors,

  3. and conditional blocks.

The occurrence of the block in its command depends on a condition expressed during the definition of the command by the developer of the digital functionality.

The developer of the operator corresponding to the command containing the block specifies the characteristics of the block:

  1. his name,

  2. its condition,

  3. its rules of composition in simple keywords,

  4. an explanatory commentary in English and/or French.

The end user will be able to give a value to the processing parameters using the factor keywords and the simple keywords associated in the conditional block but without specifying the name of the block.

Composition rule

The composite entities of the command catalog, such as « command set », command, command, keyword, factor, and conditional block, structure other entities by possibly following one or more composition rules among the following:

AU_MOINS_UN

Rule AU_MOINS_UN states that at least one of the entities whose names are passed as arguments must be present in the composite entity in which the rule is located.

UN_PARMI

Rule UN_PARMI expresses that one and only one of the entities of the entities whose names are passed as arguments must be present in the composite entity in which the rule is located.

EXCLUS

Rule EXCLUS expresses that if one of the entities whose name is passed as an argument is present, the entities corresponding to the other arguments must be absent in the composite entity in which the rule is located. In other words, if several entities in the group are present, the rule is violated.

ENSEMBLE

Rule ENSEMBLE states that if one of the entities whose name is passed as an argument is present in the compound entity, then all those corresponding to the other names must be present as well. The order of the occurrences does not matter. And if none of the entities represented in the rule are present in the composite entity, the composite entity is valid.

PRESENT_PRESENT

Rule PRESENT_PRESENT expresses that if the entity corresponding to the first name is present, then all those corresponding to the other names must also be present in the current composite entity. The order of occurrence of the other entities does not matter. If none of the entities represented in the rule are present, the composite entity is valid.

PRESENT_ABSENT

Rule PRESENT_ABSENT expresses that if the entity corresponding to the first name is present, then all those corresponding to the other names must be absent in the current composite entity. The order of occurrence of the other entities does not matter. If none of the entities represented in the rule are present, the composite entity is valid.

Each composition rule (also called simply « rule ») is a class (see the regle.py module).

1.2. Maintenance support#

The following approach is proposed to the candidate for the maintenance of the Eficas graphical interface and/or the Code_Aster supervisor.

  1. Study « Accas », i.e. what is common to the Eficas graphical interface and to the Code_Aster supervisor;

  2. Study the structure of the general order catalog: in the catalog file and in the application memory. For this:

  • become familiar with Python programming techniques, used in Accas;

  • develop a small factory model (cf. [§ 4.1]) to properly integrate the basic mechanism for loading keywords.

  1. Study the structure of the command set (in its file) and in the memory; in particular the question of loading the command set (mechanism and code areas concerned) must be considered;

  2. Examine Python scripts or C sources used when requesting changes or handling errors detected by users.