Version 9.2.0 (06/07/2026)

ㅤ

Aspects numériques :

• Mise à jour concernant la face de référence de pression : auparavant stockée dans le tableau isostd, elle est désormais stockée dans cs_glob_fluid_properties sous deux nouveaux attributs : p0_face_id contient l'identifiant de la face, tandis que p0_rank_id contient l'identifiant du rang. Elle est donc désormais accessible par l'utilisateur ou depuis n'importe quel autre endroit du code. Le tableau isostd a désormais une taille de n_b_faces (auparavant n_b_faces+1).
• La mise à jour des conditions aux limites de pression s’effectue désormais entre la prédiction et la correction afin d’éviter de prendre la condition aux limites p^(n+1) et le champ p^(n) dans la prédiction, ce qui créerait un gradient de pression parasite dans le cas d’une condition aux limites de pression dépendante du temps.
  • L’ancien comportement peut être rétabli en définissant cs_glob_velocity_pressure_param->update_pbc_after_prediction sur 0.
• Gestion des versions des schémas : ajout de la fonction cs_convection_diffusion_set_scheme_version, afin de permettre de revenir à des schémas aussi proches que possible de ceux utilisés dans les anciennes versions. Cela permettra d’effectuer des mises à jour plus importantes dans la combinaison des schémas de diffusion et de convection tout en conservant un filet de sécurité jusqu’à ce que suffisamment de retours d’expérience soient disponibles.
• Gradients : ajout d’un mode de calcul pour l’écrêtage des gradients au niveau des cellules, afin de garantir que la reconstruction aux valeurs I’/J’ ne rompt pas la monotonie pour les scalaires, et reste dans les limites de la variation maximale entre les valeurs d’une cellule et celles de ses voisines pour les vecteurs et les tenseurs. Le type de cette nouvelle implémentation CS_GRADIENT_LIMIT_RC est comparable à celui de CS_GRADIENT_LIMIT_FACE, mais devrait offrir un meilleur contrôle des limites avec moins de découpage (et donc une plus grande précision).
• CDO : modification de l’algorithme par défaut pour le calcul des grandeurs géométriques dans les schémas CDO. Le nouveau choix devrait être plus robuste sur des maillages de très mauvaise qualité.
• CDO : plusieurs corrections apportées à l’ordre de construction du système de cellules dans les schémas monolithiques CDOFb. Une attention particulière doit être portée à l’augmentation du système, à la condensation statique et à la manière d’appliquer les conditions aux limites de Dirichlet.
• CDO : Ajout d’une option d’entrée mappée pour les conditions aux limites de Dirichlet.
• CDO : Ajout d’une option « pseudo-stationnaire » lors de la résolution des équations de Navier-Stokes avec un modèle instationnaire, afin de trouver une solution stationnaire. Le calcul est arrêté lorsque la solution stationnaire est trouvée, en fonction des paramètres de convergence.
• Un nouvel algorithme de projection du champ nodal utilisant CFEMDEC de ParaMEDMEM a été implémenté. Il est entièrement distribué en mémoire et sur le processeur. Cette nouvelle projection est désormais utilisée pour le couplage avec code_aster afin de recevoir le déplacement du maillage et, en option, d’envoyer les contraintes aux limites.

ㅤ

Modifications pour l'utilisateur :

• Introduction d'un type d'accumulateur à moyenne pondérée exponentiellement (EWA) avec une échelle de temps T définie par l'utilisateur. L'EWA est sélectionné en passant CS_TIME_MOMENT_EWA à n'importe quelle fonction existante de la famille cs_time_moment_define_by_*, l'échelle de temps T étant fournie via un argument facultatif « final » ewa_time_scale. La valeur par défaut est -1 (non définie) ; ainsi, tous les emplacements d’appel existants restent inchangés et seuls les moments EWA doivent passer T.
• Module thermique mural 1D :
  • Les utilisateurs peuvent désormais utiliser cs_user_1d_wall_thermal_setup pour définir une condition thermique murale 1D à l’aide d’une API de haut niveau basée sur des zones limites.
    • Permet le post-traitement du champ thermique. Actuellement, la sortie est liée à l’enregistreur par défaut, mais des travaux futurs permettront d’accéder à ces paramètres via l’interface graphique.
    • Cela s’inscrit dans le cadre d’un travail de modernisation en cours du module. Cette mise à jour marque désormais cs_user_1d_wall_thermal comme obsolète. La fonction n’est pas encore supprimée afin de permettre aux utilisateurs de la mettre à jour.
• Étendre l’utilisation de la variable d’environnement facultative CATALYST_IMPLEMENTATION_NAME de « stub », « paraview » et « legacy » à « ensight », « med » et « cgns ». Cela s’avère utile lors de l’exécution ou du débogage d’un cas existant sur une version où Catalyst n’est pas disponible, ou lorsque le chargement de Catalyst sous un débogueur est très lent.
• Ajout d’une API de haut niveau compatible avec le GPU pour les utilisateurs. Cela évite d’avoir à spécifier directement un contexte. Cette modification définit également désormais un contexte par défaut accessible dans toutes les routines. À titre d’exemple, les utilisateurs peuvent désormais écrire simplement : cs::parallel_for(n_values, CS_LAMBDA (cs_lnum_t e_id) {...});
• Redémarrage : le choix du comportement de prétraitement du maillage et/ou le redémarrage à partir d’un autre maillage est désormais plus explicite et cohérent. En cas de redémarrage à partir d’un autre maillage, celui-ci doit désormais toujours se trouver dans restart/mesh_input.csm.
• Histogrammes : remplacement de l’option de sortie au format PNG par le format SVG. Cela permet de supprimer la dépendance à Catalyst pour cette option.
• Séparation des fonctions d’extraction du niveau de raffinement et de la génération des éléments de maillage. Cela permet de visualiser à la fois le niveau de raffinement et la génération pour les faces intérieures.

ㅤ

Modifications architecturales :

• Ajout de la possibilité de masquer les avertissements du compilateur générés par l'inclusion de fichiers d'en-tête de bibliothèques externes (lorsque l'avertissement provient de la bibliothèque elle-même). Ce masquage peut être désactivé à l'aide du drapeau de compilation -DCS_DONT_SUPPRESS_EXTERNAL_WARNINGS lors de l'étape de configuration.
• Ajout d’options de débogage supplémentaires pour les classes cs_mdspan et cs_array. Ces options peuvent être activées à l’aide de drapeaux de compilation fournis lors de la phase de configuration ou pendant la compilation.
  • -DCS_ARRAY_DBG_BOUNDS : ajoute une vérification des limites chaque fois qu’on tente d’utiliser un opérateur d’accès, () ou [], ce qui génère une erreur si les indices fournis sont hors limites. Cette option est compatible avec les environnements d’exécution sur CPU et GPU.
  • Pour cs_array uniquement, l’option -DCS_ARRAY_DBG_INIT force une initialisation en signalant une valeur NaN chaque fois qu’un nouveau tableau est créé avec une allocation de données. Ainsi, une erreur est générée si le tableau est utilisé sans avoir été initialisé dans une opération mathématique.
• Suppression de la compatibilité avec le langage C pour les fonctions définies par l’utilisateur.
• Ajout d’un backend HIP pour les GPU AMD à code_saturne.
• Le compilateur Fortran devient un prérequis facultatif
• La dépendance Fortran n'est désormais requise que pour le module Atmo, et plus précisément pour les fonctions chimiques de Polyphemus.
  • La désactivation de Fortran lors de l'étape de configuration s'effectue à l'aide de l'option --disable-fortran de configure.
  • Si Fortran est désactivé lors de la phase de configuration, le code correspondant n’est pas compilé ; si des fonctions Fortran du module des écoulements atmosphériques s’avèrent nécessaires, en fonction des paramètres définis par l’utilisateur, le code s’arrête alors avec un message d’erreur spécifique.
• Ajout de tableaux multidimensionnels pour les champs « liés ».
  • Il est désormais possible de définir, pour un objet cs_field_t, qu’il fait partie d’une série. Ce faisant, l’un des champs liés est défini comme le propriétaire de la série et gère l’allocation des données. Les autres champs n’utilisent alors qu’une vue des données (non-propriétaires).
  • Ce nouveau mécanisme utilise des objets cs_array_3d qui sont détenus et gérés par le propriétaire de la série. Les objets _vals (cs_array_2d) des autres champs pointent vers des sous-tableaux du propriétaire cs_array_3d.
• Raffinement du maillage : restructuration de la gestion du raffinement des cellules polyédriques, partant de l’hypothèse que, dans la plupart des cas, seul un petit sous-ensemble de toutes les cellules nécessite un raffinement à l’aide d’un modèle polyédrique, mais que ce raffinement est plus complexe et plus coûteux que celui des autres types de cellules.

  • Ajouter une classe cs_cell_refine_helper capable de gérer le raffinement local d'un seul polyèdre, ce qui permettra d'améliorer à l'avenir les modèles de raffinement indépendamment de l'étape de calcul de la taille des tableaux.

    • Préallouer des tableaux spécifiques aux polyèdres devant être raffinés.
    • Lors de l’étape de comptage, le raffinement des polyèdres est effectivement calculé (à l’aide d’un objet cs_cell_refine_helper par thread), puis stocké dans des tampons.
    • Lors de l’étape de raffinement proprement dite, les données sont copiées.

    ㅤ

SMGR :

• Mode batch SLURM : lecture de l’exemple de batch à partir de la configuration d’installation sur le cluster
• L’étape de post-traitement copie désormais les données utilisées pour afficher les résultats dans le dossier POST de destination, selon la structure suivante : POST/CURRENT/<case>/<run_id>

ㅤ