1. Généralités#

Cet objet de type EIGENOLVER a pour fonction de stocker et de véhiculer entre les différentes routines du code (pour l’instant qu’en interne de la commande CALC_MODES [1] ), les informations décrivant un problème modal au sens Code_Aster (GEP ou QEP) ainsi que les paramètres attenants au solveur modal choisi (SORENSEN, TRI_DIAG, JACOBI ou QZ). Cet objet est créé sur la base volatile.

Il ne doit être créé et remplit que via VPINIS . La cohérence de ses paramètres et celles de certains objets sous-jacents (par ex. les matrices définissant le problème) sont contrôlées via VPVERS. Cette routine fait aussi intervenir, optionnellement, la définition au sens Python de cet objet (sd_eigensolver.py) via un appel à la routine cheksd. Dans CALC_MODES cette option est toujours activée.

D’autres routines dédiées (type «méthode» au sens C++) permettent en outre de manipuler cet objet:

  • Le relire entièrement et mettre à jour certaines variables auxiliaires: VPLECS.

  • Lire un coefficient donné de cet objet: VPLECI.

  • Ecrire un coefficient donné de cet objet: VPECRI.

Normalement, tous les champs de cet objet, une fois qu’ils ont été remplis et vérifiés, ne doit plus être modifiés . Les seules exceptions concernent, pour l’instant, dans CALC_MODES:

  • ESVK(2) et ESVK(3): afin d’intervertir les matrices de travail si OPTION=”PLUS_GRANDE”,

  • ESVI(1) et ESVI(2): recalcul/correction du nombre de modes et de la taille de l’espace de projection.

Lors d’une modification de cette structure de données il faut donc veiller à:

  • mettre en cohérence, si nécessaire, les sources mentionnées ci-dessus,

  • mettre à jour, si nécessaire, le catalogue sd_eigensolver.py,

  • mettre à jour les documentations (cette doc. D et si nécessaire les doc. U concernant le calcul modal),

  • enrichir ou modifier, si nécessaire, quelques cas-tests.