2. General mechanism of operation of the supervisor#

2.1. General architecture#

The basic elements involved when running an Aster calculation are:

  • the command file, provided by the user,

  • the order catalog: it is a Python module called cata placed in the Cata package,

  • the high level object SUPERVISEUR,

  • the JDC object created by the latter and which is finally executed.

The SUPERVISEUR object is a Python object that analyzes the options passed on the command line, imports the command catalog, creates the JDC object from the command file, and executes this one.

The JDC object (name for Command Set) is a Python object created by the SUPERVISEUR object from the text in the command file and the command catalog module. It contains items ETAPE. The object JDC is representative of the user command file.

Objects ETAPE are representative of each of the calls to Aster commands in the command file. Each ETAPE object has the name of the order it references, the list of active keywords and their values, the type and the name of the product concept.

Building and then running object JDC triggers the following actions:

  • syntactic analysis of the user command file: this is where the Python syntax is checked (brackets, commas between keywords, indentation…). Detecting an error (Python SyntaxError) causes Aster to stop running. The first error is fatal: we are not looking for the following errors,

  • construction of the steps: this consists of creating a ETAPE object for each call to an Aster command in the command file. This object is registered with JDC, which manages the list of steps and related concepts,

  • checking each ETAPE: if the call to a command in the user file is inconsistent with the order catalog, a report is displayed and execution is stopped at this level. It’s semantic checking,

  • actual execution of the commands: for each step taken in order, call to the corresponding high level routine FORTRAN (op0nnn.f).

2.2. Global execution or step by step#

A command set can be built and executed in two modes:

the global mode for which**all* the steps of the command set are first built and then executed in the order in which they appear. This mode is chosen by the keyword PAR_LOT =” OUI “in the start command DEBUT

  • the step-by-step mode for which each step is executed immediately after construction. This mode is chosen by the keyword PAR_LOT =” NON “in the DEBUT command.

If the user does not specify anything in the start command, the global mode (PAR_LOT =” OUI “) is retained. These two modes each have their advantages and disadvantages.

The global execution mode assures the user that their entire file is semantically correct before starting calculations that may fail or may not converge. It would indeed be a shame to end up in a fatal error after a long resolution because of a forgotten keyword in a post-processing order.

It also means that all steps in the command set are built and stored in memory. If you reach several thousand steps, this can become very memory intensive and this mode is then no longer recommended.

Step-by-Step mode only builds a step after completing the previous one. It therefore only detects the semantic errors of the current command and has the disadvantage described above. However, it makes it possible to use a calculated result (in a concept) in the command file to, for example, place conditional instructions there.

In this mode, the step executed is immediately freed from memory. The memory used is then independent of the number of steps to be executed.

Here is an example of a loop with a stop criterion on the value of a calculated quantity, stored in the table-type concept: RELV [k]. For example, if a mandatory keyword is missing in the call to POST_RELEVE_T, this will only be detected after the first MECA_STATIQUE has been fully executed. On the other hand, the step-by-step mode here makes it possible to assign the variable SYY since the concept RELV [k] was completely calculated when the supervisor executes this line.

DEBUT (PAR_LOT =” NON “)

RESU = [None] *10

RELV = [None] *10

for k in range (1.10):

RESU [k] = MECA_STATIQUE (…)

RELV [k] = POST_RELEVE_T (…)

SYY = RELV [k] [“VMIS “,4]

if SYY < criteria:

Break

FIN ()

It should be noted that the choice of an execution mode determines the order in which the semantic analysis will take place (ETAPE by ETAPE or globally for all of JDC). But, in both cases, Python syntactic analysis is always done beforehand for the entire command file.

Note:

EFICAS can only generate and reread command sets containing ASTER commands exclusively, without other python instructions; this is independent of the mode PAR_LOTchoisi.

2.3. The construction of the stages#

During the construction of each ETAPE object, we check its semantic consistency with the catalog of the command to which it refers. Any error detected is recorded in a report which, in global execution mode, is delivered after the entire command file has been analyzed.

Examples of semantic checks:

  • respect for the number of arguments of the keywords,

  • respect for the type of argument,

  • belonging of an argument to a list of possible values,

  • accuracy of the spelling of a keyword or a key word factor,

  • compliance with the rules of exclusion or involvement between keywords,

  • presence of mandatory keywords.

At this stage, if the order is an operator and produces a concept, this one is typed. The supervisor verifies that a concept with the same name has not already been defined, or if it is reused, that the command allows it.

2.4. The processing of macro-orders#

A macro command, seen by the user, is an ordinary command. In fact, it does not call a high-level Fortran routine directly but generates other commands.

Two types of macro commands exist:

  • macros in Python,

  • supervisor macros: these are special commands (DEBUT, FORMULE,,, INCLUDE, INCLUDE_MATERIAU, POURSUITE) that require processing at the level of their construction.

Just like JDC itself, calling a macro command produces a parent object (type MACRO - ETAPE) that contains child objects: the steps that the macro generates, or even other macros.

A macro command from JDC is first treated like the other commands (syntactic check, construction of the macro step). Then it is « built » by applying the Python Build method to object JDC. After its construction, the steps of the commands produced by the macro are replaced by the step of the macro itself, for later execution.

It is important to note that the macro-commands construction phase takes place just before they are executed, and not during the global pass on the command file in mode PAR_LOT =” OUI “. This has two consequences:

  • EFICAS analyzes the syntax of the macro command itself, but not the syntax of its sub-commands.

  • On the other hand, when programming macros, you can use data previously calculated and retrieved into the python namespace, without having to impose the PAR_LOT =” NON “mode on the macro user.

2.5. Start-up procedures#

The available startup procedures are:

DEBUT (cf. [U4.11.01] and POURSUITE [U4.11.03])

At least one of these two procedures must be present in the command file. No other Aster commands should precede them. If this is the case or none is present, the execution will be stopped as soon as JDC is created. These procedures contain information on the execution mode (PAR_LOT =” OUI “or” NON “) that determines the mode of execution of the commands that follow.

These are supervisor macrocommands that, when they are constructed, call Fortran routines to initialize the calculation by the following tasks:

  • « connection » of the logical units of the standard files,

  • opening of databases,

  • reading the element catalog.

The first task is to map logical unit numbers from standard input/output files (message, error, result).

The second task is to define and open the databases (direct access files used by the memory manager) in accordance with the instructions of the user, who can redefine the parameters of these files (see documents [U4.11.01] and [U4.11.03] on startup procedures). To do this, we call the initialization routines JEVEUX (see document [D6.02.01] the Memory Manager, JEVEUX).

The sequence of commands to be executed must end with command FIN. The text that follows FIN should be commentarized (i.e. start with #). For an included file, the RETOUR command marks the end of the instructions that ASTER must take into account.

Note:

In interactive mode, entering orders by hand, do not put an command FINet pass the argument —interact on the job submission command line.