2. Object management#

2.1. The attributes#

2.1.1. Generalities#

The attributes to which the user has access are, with two exceptions, not directly modifiable.

They are assigned when the descriptor is created (for example the type) and then frozen until this descriptor is destroyed. The system also manages attributes that change during the application (for example the memory address of the value segment).

There are three categories of attributes for JEVEUX objects:

  • generic attributes: class, genre, type,…

  • collection attributes.

  • attributes of collectibles.

All attributes can be viewed at any time by the user. In the rest of the document, for each attribute, we indicate:

  • the symbolic name by which it can be consulted,

  • the Fortran type of each attribute with the following conventions:

Code

Type

Fortran Declaration

I

integer

INTEGER

S

integer

INTEGER *4

R

real

REAL *8

C

complex

COMPLEX *16

L

logic

LOGICAL

Ki

character

CHARACTER *i

K*

string

CHARACTER* (*)

2.1.2. Generic attributes#

Attributes assigned by the user (cannot be modified after creating the descriptor):

CLAS

K1

class for attaching the object to a database

GENR

K1

object type: - Simple variable - Vvector, - N directory of K8, K16, or K24 type names.

TYPE

K1

Fortran object type: I, R, C, Lou K

LTYP

I

type length: automatically managed for types I, R, C and L, - standardized for characters with values 8, 16, 24, 32, and 80

length of the object: LONMAX NOMMAX

I I

number of components of the genre object V maximum number of names of the genre object N

Attributes that can be modified at any time by the user:

These attributes are not essential for the operation of the software package. They allow the user to complete the description of the JEVEUX objects that they are manipulating.

LONUTI

I

number of components of the V genre object used

DOCU

K4

four free characters left to the user

Attributes assigned and managed by the system and viewable by the user:

These attributes are described for information purposes, they can be consulted during the development of an application (error search,…).

NOMUTI

I

number of names of the genre object N actually used

DATE

I

integer containing the month, day, year, year, year, hour, and minutes of execution of the work that last modified the value segment (last unloaded to the database)

IADM

I

memory address: relative position in memory JEVEUX of the value segment and address of the pointer to the dynamically allocated memory area (stored in 2 integers for each object)

IADD

I

disk address: contains the number of the value segment record in the database and the relative position in the record (stored in 2 integers for each object)

LONO

I

length in object addressing units (space occupied by the value segment measured in length of the type)

USAGE

K16

use of an object JEVEUX: contains both information on the use in writing or reading, the status (downloadable, removable,…) of the value segment when it is present in memory and the trademarks registered during the first read and write request

These are only used internally in JEVEUX.

2.1.3. Collection attributes#

Common attributes assigned by the user or managed by the system:

Attributes that are common (CLAS, GENR, TYPE, LTYP, DOCU, etc.) to collectibles are accessible in the same way as attributes of a simple object and meet the same rules.

Attribute assigned and managed by the system and viewable by the user:

NUTIOC

I

number of objects actually created in the collection

Note:

This attribute is updated only when the collection object creation routine JECROC is called .

Attributes that are assigned by the user and cannot be changed:

ACCES

K*

access type: NOMMEou NUMEROTE (see the assignment of this attribute by JECREC)

STOCKAGE

K*

Value storage mode: - CONTIG: all objects are contiguous in the value segment - DISPERSE: objects are archived as and when needed

MODELONG

K*

How to define the length of collectibles: - CONSTANT: all objects are of the same length (length attribute of the reference object) - VARIABLE: each object can have a different length

LONT

I

total length of a contiguous collection

NMAXOC

I

maximum number of objects in the collection

2.1.4. Attributes of collectibles#

The attribute name rules for collection objects are the same as for simple objects.

2.2. The associated databases#

To each class it is possible to associate a database on disk. This possibility is by no means mandatory: you can work without writing and reading on disk (which can lead to saturating the available memory and stopping the application).

The number of classes you can work on simultaneously is limited to 5. A class can be opened or closed at any time during the application.

Opening a pre-existing database makes it possible to retrieve all the information stored on it. At the end of the work, it is possible to destroy an entire class.

A database is a direct access file; it is defined by:

  • a class name (K1),

  • a local file name (K8),

  • a block length,

  • a number of blocks.

Note:

In Code_Aster, all classes are associated with databases cf. § 3.3 The Code_Aster environment.

2.3. Access to values#

The user accesses the values of an JEVEUX object by a relative address in an array defined by one of the appropriate Fortran reference variables. These reference variables (ZI, ZR,…) are placed in standardized commons confer [D2.06.01]: Usage I want « Liberation of value segments and brand concept ».

Note:

The returned address remains valid as long as the user has not declared that they are no longer using the object.

_images/10000000000003D300000204BBA30CFC594EBDDD.png
  • ZR (LR) 1st component of the values of the real type object

  • ZK16 (LK16 - 1 + I) th component of the values of the K16 object

2.4. Memory management concepts#

Access to JEVEUX objects is by name. These names are stored in a simple object such as a name directory accessible only by the software package and managed by an associative addressing method.

To order an application, the user must group JEVEUX objects into one or more classes opened beforehand. Each class is associated with a catalog: it is the set made up of the directory of names and attributes of the JEVEUX objects of the class. The class is one of the attributes defined when the descriptor of an JEVEUX object is created. The search for the name is carried out among all the classes open at this time.

Note:

A name cannot therefore appear more than once among all open classes.

To each class, it is possible to associate a direct access file (or database), which will contain, at the end of the application, the descriptors and the value segments of all the JEVEUX objects of the class. This type of file allows quick access to the various records, an index describing the position of each of them.

Exchanges between the central memory and the databases associated with the classes are entirely taken care of by the software package. When the central memory is full (when it is no longer possible to allocate a zone dynamically), this one unloads or destroys the value segments declared unused. At the end of the application, all the JEVEUX objects present in memory are unloaded into the associated database, as well as the catalogs (simple « system » objects), which allows subsequent reuse.

The direct access file will only be valid if the index was updated during the closure, so it is essential to properly stop the application using routine JEFINI. Any value segment in memory is surrounded by eight integers (four in front, four in the back) making it possible to manage the value segment, to indicate its use (free, used for reading, downloadable,…), to store the associated identifier, and to provide partial protection against overflows (the software package checks the integrity of the values contained by these integers during any request).

2.5. Object usage queries#

Package JEVEUX provides various subroutines and functions to manage all objects. A distinction is made between the following different requests:

  • the creation of the descriptor of an object JEVEUXou of a collection object,

the allocation of the object: search for space in memory for the associated value segment, initialization of the values or rereading on the database, finally providing the calling program unit with a relative address of the segment of values in relation to a reference variable Z. This allocation can be formulated in read-only mode or read/write mode;

  • the consultation of the descriptor which allows the value of an attribute to be retrieved dynamically;

  • the impressions of the descriptor, the value segment, the catalog, or the state of the memory managed by JEVEUX;

  • the release that ends the allocation of the object and makes the value segment (s) unused;

  • the destruction of the descriptor and the value segment of an object JEVEUXou of a collection object.

2.6. The particularities of the collections#

The size of a collection depends on its type. For each type, the method of defining the associated value segment (s) is described below.

2.6.1. Contiguous collection of variable length#

We define:

  • be the total length of the value segment by the LONT attribute (total length) of the collection. In this case, you can create the collection and define (in no particular order) later the length of each object before using it;

  • or the length of all or part of the objects in the collection by giving the length vector managed by the user, or by updating the length attribute for each object, the total length of the value segment will be calculated by the software package.

_images/10000000000003D400000173C636DD8F6F564657.png

Notes:

It is recommended to define the length of all objects in a contiguous collection before the first allocation request in memory,

The length of the value segment LONT is fixed during the first memory allocation request,

A contiguous collection of variable length cannot therefore be expanded after the first access,

all objects created in a contiguous collection are managed together,

The associated value segment can be used as a value vector by ignoring division into collectibles.

2.6.2. Contiguous collection of constant length#

The length common to all collection objects is defined; the length of the value segment will be equal to the product of the constant length by the maximum number of objects in the collection.

Attention: when doing the JEECRA of the LONMAX of the collection, you must indicate the length of a single element of the collection and not the total length.

2.6.3. Scattered collection of varying length#

We define:

  • the majority of the number of objects,

  • the length of each object, as and when required and in no particular order, before the object is allocated.

Note:

The effective size of this type of collection is limited to the cumulative length of the objects actually created.

_images/100000000000042A000001B4A07F97955EBABD92.png

Note:

For a scattered collection, you can use an object (whose length has been defined) before you have finished defining all the objects.

2.6.4. Dispersed collection of constant length#

We define:

  • the majority of the number of objects,

  • the length common to all objects.

2.6.5. The basic concepts#

Item JEVEUX:

The JEVEUX software package makes it possible to manage two types of data structures accessible by name within the application. It was customary to call these data structures JEVEUX objects. By definition, a JEVEUX object is:

  • be a simple object,

  • or a collection of objects.

A JEVEUX object is the set consisting of a descriptor and one or more value segments.

Descriptor:

A descriptor is a set of information consisting of a name and various attributes. The descriptor allows access, from the name, to the value segment (s) of the object JEVEUX. Attributes describe the structure of the JEVEUX object.

Name:

A name consists of a sequence of alphanumeric characters limited to 24 characters (the name is associated, by a table and an encoding function, with an integer allowing access to the object by associative addressing).

Attribute:

Attributes are the parameters (in a fixed number for simple objects) used to define and describe the data structure (variable, table). For example, the type of values and the length of the array are part of the set of attributes.

Value segment:

A value segment is a continuous sequence of words or bytes (depending on the addressing unit of the machine) used to store values in central memory or in auxiliary memory (file).

Note:

With some exceptions (name directories), a value segment is a sequence of values of the same type.

2.7. The release of value segments#

A request for read or write access to a value segment associated with an object JEVEUX causes a loading into memory of the content of the associated value segment. When managing a finite memory space, there comes a point where it is no longer possible to find space to load a new object. It is then necessary to cause unloads to disk or to eliminate value segments that have become useless. This mechanism cannot be fully supported by JEVEUX: the programmer must have indicated the objects concerned beforehand. But certain precautions must be observed: several program units can simultaneously use the same memory address associated with an object. Storing a value segment is accompanied by the assignment of an entire mark that measures the level of depth in subroutine calls for each new request. The release can only be carried out if the call level at this moment is identical to the brand associated with the value segment. The current call level is called current brand. The implementation of this mechanism imposes a very strict rule of use of JEVEUX: any routine that calls JEVEUO or WKVECT must make a call to JEMARQ as the first executable instruction and a call to JEDEMA as the last executable instruction. The JEMARQ routine allows you to update the current brand value, by incrementing it by 1, assigned to all value segments loaded later. The JEDEMA routine releases all value segments associated with the current brand and then decrements the current brand.

Some configurations allow exceptions to this rule: for example, loops on matrix blocks. It is then necessary to release the objects gradually; routine JELIBE is used in this case.

It is sometimes necessary to have certain objects available at all times or throughout a Code_Aster command (for the Execution Supervisor, the coded material), specific queries are used, which affect a special brand.

The current brand value can be viewed at any time using the JEVEMA routine.