natgrein
commented
6 days ago Concernant la question de savoir si abortTimeStep() doit aller jusqu'à oublier le pas de temps qu'il avait calculé avec le précédent appel à computeTimeStep() : on pourrait répondre oui, et dire qu'en cas d'échec du solveTimeStep(), il faut rappeler computeTimeStep() avant abortTimeStep() pour obtenir un dt différent de celui qui avait été utilisé et qui avait conduit à un échec de la résolution.
L'idée de renforcer abortTimeStep() semble partagée. abortTimeStep() ne permettrait plus seulement de faire un nouveau calcul, mais annulerait complètement le dernier calcul effectué.
Il est envisagé qu'abortTimeStep() fasse revenir à l'état précédant le dernier initTimeStep().
L'état des variables de sortie d'un code juste après un abortTimeStep() (donc avant initTimeStep()) fait débat : elles pourraient revenir à l'état précédent (ce qui semble logique d'un point de vue utilisateur). Il est également évoqué la possibilité de laisser ces variables dans un état "non défini" pour faciliter l'implémentation de la norme.
La décision doit se faire au regard de l'utilité d'accéder à des variables à ce moment-là, et à l'éventuel coût de supporter cette mise à jour des variables de sortie. Avez-vous des éléments à partager ?