16. Versions d’ADAO et compatibilités externes

16.1. Passer d’une version d’ADAO à une nouvelle

Le module ADAO et ses fichiers de cas « .comm » sont identifiés par des versions, avec des caractéristiques « Major », « Minor », « Revision » et optionnellement « Installation ». Une version particulière est numérotée « Major.Minor.Revision », avec un lien fort avec la numérotation de la plateforme SALOME. L’indication optionnelle d’un quatrième numéro désigne une différence dans le mode d’installation, pas dans le contenu de la version.

Chaque version « Major.Minor.Revision » du module ADAO peut lire les fichiers de cas ADAO de la précédente version mineure « Major.Minor-1.* ». En général, elle peut aussi lire les fichiers de cas de toutes les versions mineures « Major.*.* » d’une branche majeure, mais ce n’est pas obligatoirement vrai pour toutes les commandes ou tous les mots-clés. En général aussi, un fichier de cas ADAO d’une version ne peut pas être lu par une précédente version mineure ou majeure du module ADAO.

16.1.1. Passer de la version 9.x à la 9.y avec y > x

Il n’y a pas d’incompatibilité connue pour les fichiers de cas ADAO. La procédure de montée en version consiste à lire l’ancien fichier de cas ADAO avec le nouveau module SALOME/ADAO, et à l’enregistrer avec un nouveau nom.

Cependant, il peut se présenter des incompatibilités provenant de cas utilisateurs écrits directement en interface TUI. Il est conseillé de revoir la syntaxe et les arguments dans les scripts TUI à chaque changement de version. En particulier, il convient de vérifier que les paramètres d’algorithme sont toujours adéquats et actifs, sachant qu’il a été explicitement choisi qu’il n’y ait pas de message lorsqu’un paramètre devient inactif (pour l’exemple, on cite le paramètre « MaximumNumberOfSteps » comme ayant changé de nom pour devenir « MaximumNumberOfIterations », par homogénéité avec les variables pouvant être affichées).

16.1.2. Passer de la version 8.5 à la 9.2

Il n’y a pas d’incompatibilité connue pour les fichiers de cas ADAO. La procédure de montée en version consiste à lire l’ancien fichier de cas ADAO avec le nouveau module SALOME/ADAO, et à l’enregistrer avec un nouveau nom.

Cependant, il peut se présenter des incompatibilités provenant de fichiers scripts utilisateurs qui n’auraient pas une syntaxe compatible avec Python 3. L’erreur la plus immédiate est l’usage de l’impression « print » avec la syntaxe « commande » au lieu de la syntaxe fonctionnelle « print(…) ». Dans ce cas, il est suggéré de corriger la syntaxe des fichiers utilisateurs dans l’environnement 8 avant de passer en environnement 9.

16.1.3. Passer de la version 8.x à la 8.y avec y > x

Il n’y a pas d’incompatibilité connue pour les fichiers de cas ADAO. La procédure de montée en version consiste à lire l’ancien fichier de cas ADAO avec le nouveau module SALOME/ADAO, et à l’enregistrer avec un nouveau nom.

Pour faciliter les futures évolutions, il est fortement recommandé de veiller à ce que vos fichiers scripts utilisateurs utilisent une syntaxe compatible avec Python 2 et avec Python 3. En particulier, on recommande d’utiliser la syntaxe fonctionnelle pour les « print » et non pas la syntaxe « commande », comme par exemple :

# Python 2 & 3
x, unit = 1., "cm"
print( "x = %s %s"%(str(x),str(unit)) )

ou :

# Python 2 & 3
x, unit = 1., "cm"
print( "x = {0} {1}".format(str(x),str(unit)) )

plutôt que :

# Python 2 uniquement
x, unit = 1., "cm"
print "x =", x, unit

16.1.4. Passer de la version 7.8 à la 8.1

Il n’y a pas d’incompatibilité connue pour les fichiers de cas ADAO. La procédure de montée en version consiste à lire l’ancien fichier de cas ADAO avec le nouveau module SALOME/ADAO, et à l’enregistrer avec un nouveau nom.

16.1.5. Passer de la version 7.x à la 7.y avec y > x

Il n’y a pas d’incompatibilité connue pour les fichiers de cas ADAO. La procédure de montée en version consiste à lire l’ancien fichier de cas ADAO avec le nouveau module SALOME/ADAO, et à l’enregistrer avec un nouveau nom.

16.1.6. Passer de la version 6.6 à la 7.2

Il n’y a pas d’incompatibilité connue pour les fichiers de cas ADAO. La procédure de montée en version consiste à lire l’ancien fichier de cas ADAO avec le nouveau module SALOME/ADAO, et à l’enregistrer avec un nouveau nom.

Il y a une incompatibilité introduite dans les fichiers de script de post-processing ou d’observers. L’ancienne syntaxe pour interroger un objet résultat, comme celui d’analyse « Analysis » (fourni dans un script à travers le mot-clé « UserPostAnalysis »), était par exemple :

Analysis = ADD.get("Analysis").valueserie(-1)
Analysis = ADD.get("Analysis").valueserie()

La nouvelle syntaxe est entièrement compatible avec celle (classique) pour les objets de type liste ou tuple :

Analysis = ADD.get("Analysis")[-1]
Analysis = ADD.get("Analysis")[:]

Les scripts de post-processing doivent être modifiés.

16.1.7. Passer de la version 6.x à la 6.y avec y > x

Il n’y a pas d’incompatibilité connue pour les fichiers de cas ADAO. La procédure de montée en version consiste à lire l’ancien fichier de cas ADAO avec le nouveau module SALOME/ADAO, et à l’enregistrer avec un nouveau nom.

Il y a une incompatibilité introduite dans les fichiers de script d’opérateur, lors de la dénomination des opérateurs élémentaires utilisés pour l’opérateur d’observation par script. Les nouveaux noms requis sont « DirectOperator », « TangentOperator » et « AdjointOperator », comme décrit dans la quatrième partie du chapitre [DocR] Description de référence des commandes et mots-clés ADAO. Les fichiers de script d’opérateur doivent être modifiés.

16.2. Versions de compatibilité d’ADAO avec les outils support

Le module ADAO bénéficie largement de l”environnement Python [Python] et des nombreuses possibilités de ce langage, des outils de calcul scientifique inclus dans NumPy [NumPy20], SciPy [SciPy20], NLopt [Johnson08] ou dans les outils atteignables grâce à eux, et des nombreuses capacités de SALOME [Salome] lorsqu’il est utilisé en association.

Chaque version du module ADAO est validée dans le cadre de SALOME, et elle est donc compatible avec l’environnement implicitement défini par la version correspondante 9.12.0 de SALOME identique à celle d’ADAO pour le présent document. Les versions de validation sont indiquées ici pour information uniquement sachant que, en cas de doute, c’est la fiche de version de SALOME [Salome] qui indique les versions officielles de validation.

Tableau 16.1 Versions de validation des outils support pour ADAO

Outil

Version

ADAO

9.12.0

EFICAS

9.12.0

SALOME

9.12.0

Python

3.9.2

Numpy

1.19.5

Scipy

1.6.0

MatplotLib

3.3.4

Gnuplot

1.8

NLopt

2.4.2

La compatibilité du module est de plus vérifiée par rapport à diverses versions de Python et des modules support comme Numpy et Scipy. L’étendue des versions atteintes lors des tests dépend de leur disponibilité, et les tests ne sont pas systématiques sur toutes les versions intermédiaires. Pour toutes les versions testées, le module ADAO se comporte de manière identique (dans la mesure de modifications dépendant des outils support). Il est fortement déconseillé (ou impossible) d’utiliser ADAO avec une version inférieure à la version minimale, et il n’y a pas de limitation explicite à l’utilisation du module ADAO au-delà au-delà de la version atteinte mais cela reste sans garantie. Si une erreur inhabituelle est rencontrée pour des calculs fonctionnant précédemment, il est fortement conseillé de revenir à des versions d’outils supports comprises dans l’étendue décrite ci-dessous.

Tableau 16.2 Intervalles de vérification des outils support pour ADAO

Outil

Version minimale

Version atteinte

Python

3.6.5

3.11.7

Numpy

1.14.3

1.26.2

Scipy

0.19.1

1.11.4

MatplotLib

2.2.2

3.8.2

GnuplotPy

1.8

1.8

NLopt

2.4.2

2.7.1