J'ai éliminé la variable stepIsRecomputed.

Pour information, un pas de temps est recalculé si il y a une erreur (Jacobien Négatif ou non convergence d'une loi matérielle (retour radial, etc …) durant le calcul des forces (C'est le flag “ErrorDuringStep” situé dans Metafor) ou il est refusé (C'est le flag “StepIsRefused” situé dans TimeStepManager) sur base d'un critère d'évaluation de la qualité de l'intégration temporelle entre les deux instants discrets to et t1.

J'ai éliminé la variable oldTimeStepNo.

Après investigations, cette variable était utilisée pour indiquer le step courant avec un pas de temps limité par la présence d'un archivage. Pour éviter de perturber l'intégration temporelle, on recalcule le pas de temps sur base du fait qu'il a été tronqué précédemment !

A la place de cette variable, j'ai utilisé le flag suivant “timeStepIsLimitedByFac”, plus explicite !

J'ai corrigé un bug lors d'un restart d'un cas test. En fait, lors d'un restart, nous devons calculer le pas de temps du nouveau step. Il s'avère que si le pas de temps fut limité par la présence d'un archivage, le pas de temps était mal recalculé ! Ainsi, nous pouvons observer sur le cas test apps.complex.cont5_1 que le nombre de pas de temps pour l'intégration complète est de 76. Si nous recommençons l'intégration temporelle à la moitié, nous avons toujours 76 pas de temps au lieu de 62 pas de temps comme auparavant !

Il y a toujours un problème pour la méthode de calcul du pas de temps basée sur l'erreur d'intégration.

Pour tous les cas tests qui utilisent la méthode d'erreur d'intégration pour mettre à jour le pas de temps, j'ai indiqué explicitement dans le jeux de données la commande suivante :

tsm.setTimeStepComputationMethod(TSM_INTEGRATIONERRORMETHOD)

[r]:
[a]:

[r]:
[a]: 

— Gaëtan WAUTELET 2015/10/29