3. Source code instrumentation#

Source and test case units should have a standardized comment line that should appear once and only once in each source unit.

This line is called line INFO.

There are two types of INFO lines:

  • line AJOUT which is intended to inform the management modules that the source unit is new.

  • line MODIF which is intended to inform the management modules that the source unit is modifying an already existing source unit.

Lines of the latter type should not be modified under any case by the developer.

Their form differs for code FORTRAN, CAL, C, CATALOGUE, or CASTEST.

3.1. Type code FORTRAN#

Lines INFO are of the form:

SUBROUTINE sub name

—— information from the SUBROUTINE subname not taken into account by the modules

management ——

C MODIF nombib_1 DATE dd/mm/aa AUTEUR user_ CRAY author_name

—— information from the SUBROUTINE subname not taken into account by the modules

management ——

END

INTEGER FUNCTION fun name

—— information from the FUNCTION namfun not taken into account by the modules

management ——

C AJOUT nombib_2

—— information from the FUNCTION name not taken into account by the modules

management ——

END

Syntax for a INFO line (the various fields are separated by at least 1 blank):

  • « C » in the first column,

  • « MODIF » or « AJOUT »,

  • nombib_i: name of the library,

if « MODIF »:

  • « DATE »,

  • dd/mm/yy: date managed at the time the reference version was updated,

  • « AUTEUR »,

  • user_ CRAY: user on CRAY of the last person who modified the routine,

  • author_name: linked to the previous identifier. These two identifiers are also managed when the reference version is updated.

These are the fields that should not be changed by the developer.

3.2. Type code CAL#

Lines INFO are of the form:

When you want to add a routine you have to put the following line INFO in the module (this line delimits the start of the module):

  • AJOUT module_name library_name

** in the first column,

  • AJOUT (in uppercase letters required!) ,

  • the name of the module,

the name of a library CAL*Aster*where the module should be added (this library must already exist -cf organization Source*Aster -).

Note:

A module you want to add must not already exist in Aster (either en FORTRANsoit en C or en CAL) .

Once the module is added to the*Code_Aster*, line INFO is managed and updated by AGLA. It then has the following form:

  • MODIF module_name NOM_BIB DATE dd/mm/aa AUTEUR J2 BHHMB C. MASSERET

It then contains:

  • the name of the module,

  • the name of library CAL where the module is located,

  • the date it was last modified,

  • the user Cray and the name of the author of the last modification.

3.3. Type C code#

Lines INFO are of the form:

/AJOUT function_name library_name/

/ in the first column,

  • AJOUT (in uppercase letters required!) ,

  • the name of the function,

the name of a C*Aster*library where the function should be added (this library must already exist -cf organization Source*Aster -).

Once the function is added to the Code Aster, line INFO is managed and updated by AGLA. It then has the following form:

/MODIF fun_name NOM_BIB DATE dd/mm/aa AUTEUR J2 BHHMB C. MASSERET/

It then contains:

  • the name of the function,

  • the name of the C library where the function is located,

  • the date it was last modified,

  • the user Cray and the name of the author of the last modification.

Note:

For a function C to be called in FORTRANil must have its name in uppercase letters.

3.4. Type code CATALOGU#

Lines INFO are of the form:

%& MODIF catalog_name_1 DATE dd/mm/aa AUTEUR user_ CRAY author_name ————- catalog item information catalog_name_1

not taken into account by the management modules ——

%& AJOUT catalog_name_2 ————- catalog item information catalog_name_2

not taken into account by the management modules ——

Syntax for a INFO line (the various fields are separated by at least 1 blank):

  • « % » in the first column,

  • « MODIF » or « AJOUT »,

  • & in the second column,

  • catalog_name: name of the catalog,

if « MODIF »:

  • « DATE »,

  • dd/mm/yy: date managed at the time the reference version was updated,

  • « AUTEUR »,

  • user_ CRAY: user on CRAY of the last person who modified the routine,

  • author_name: linked to the previous identifier. These two identifiers are also managed when the reference version is updated.

In this example, we can see that line INFO acts as a delimiter contrary in the case of FORTRAN.

3.5. File type CASTEST#

For test cases two INFO lines are mandatory AJOUT or MODIF and TITRE.

Lines INFO are of the form:

  • for the modification of a test case:

% MODIF DATE dd/mm/aa AUTEUR user_ CRAY author_name % TITRE explanation, in plain text, of the role of this test case ————- information not taken into account by the management modules —- DEBUT (CODE :( NOM :”testcase_name”,

  • to add a test case:

% AJOUT % TITRE explanation, in plain text, of the role of this test case ————- information not taken into account by the management modules —- DEBUT (CODE :( NOM :”testcase_name”,

It should be noted that:

  • the name of the file must match that of the test case,

  • there is only one test case per file,

  • line INFO “TITRE” must be filled in by the developer.

3.6. File type UNIGEST#

A file of type UNIGEST does not expressly contain source code, but instructions concerning source units for the rendering modules.

In this file we indicate the source or test case units that we want to move from one library to another or delete. This type of file contains lines of the following type:

  • FORSUPPR routine_name bibli_name

for the routines you want to delete, indicating their name and the library they belong to,

  • CATSUPPR subcatalog name catalog_name

for the catalog items that you want to delete, by indicating their name and the catalog to which they belong,

  • TESSUPPR test_case_name

for the test cases that you want to delete, by indicating their name,

  • FORDEPLA routine_name bibli1 bibli2

for routines that you want to move from a bibli1 library to a bibli2 library.

It should be noted that for this type of file:

  • there is no concept of comment,

  • so that there is no inconsistency there cannot be more than one UNIGEST order concerning the same unit,

  • equivalent orders are currently not planned for source C and CAL.

3.7. File types#

We will call file type:

  • FORTRANun file containing FORTRAN source,

  • CALun file containing Cray assembler-type source,

  • C a file containing C language-type source,

  • CATALOGUun file containing CATALOGU source,

  • CASTEST a file containing a CASTEST source,

  • UNIGESTun file containing UNIGEST source.

Remarks:

You cannot mix different types in the same file (FORTRAN, CAL, , , , , , , UNIGEST), CATALOGU CASTEST

For additions, the date and the name of the author are obviously not required in the line INFO .