13. Performances#

  • Performances GDEF_LOG (#33694 - 17.1)

    Beaucoup de temps était passé dans « intégration de la loi de comportement » dans le cas GDEF_LOG, même avec un comportement linéaire, notamment dans le calcul des déformations logarithmiques. La factorisation du code permet un gain de :

    • ~20% dans « intégration de la loi de comportement » (ex perf02a)

    • 7% en moyenne sur l’ensemble des tests GDEF_LOG

  • Réduire l’empreinte disque des sorties de DEFI_SOL_EQUI (#33639 - 17.1)

    Réduction de l’empreinte sur disque des fichiers de sortie de la macro-commande DEFI_SOL_EQUI en proposant à l’utilisateur d’enregistrer dans la table enregistrée dans l’unité UNITE_RESU_TRAN uniquement :

    • accélération au champ-libre

    • accélération au rocher affleurant

    • accélération au borehole

    • accélération sur les noeuds inférieurs des couches de la colonne de sol (définis soit via la colonne “M” de la table de sol, soit via le mot-clé COUCHE)

    Pour ce dernier point, l’utilisateur pourra fournir une liste avec les noms des couches où il souhaite obtenir les accélérations (cela peut être utile pour des comparaisons avec le mouvement sismique « within »). On ajoute les mot-clés TOUT_ACCE et LIST_COUCHE_ACCE.

  • Optimisation des performances de REST_GENE_PHYS (#33336 - 17.1)

    Dans les études, les coûts en temps de cet op REST_GENE_PHYS (et de DEFI_BASE_MODALE) étaient disproportionnés par rapport à ceux de CALC_MODES (qui lui bénéficie de 3 niveaux de parallèlisme et des optimisations de longues dates dans le calcul modal et dans MUMPS). Maintenant que ces derniers sont optimisés. On observe des accélérations pouvant aller jusqu’à un facteur 30.

  • Simplification de l’appariement nodal pour LIAISON_GROUP (#33763 - 17.1)

    L’appariement nodal effectué dans LIAISON_GROUP n’était pas optimal. Il y a beaucoup trop de vérifications sans utilité et l’ordre des boucles a été inversé pour gagner en efficacité.

  • Temps de lecture du maillage (#34447 - 17.3)

    On supprime le nommage des noeuds et des mailles dans aster. On réécrit la lecture de maillage LIRE_MAILLAGE au format MED en C++ avec l’interface med dont on dispose déjà. On peut donc valoriser au mieux les améliorations des collections en C++ avec des accès directs en mémoire. Dans l’exemple traité, on passe de 5h à 7min.