Differences

This shows you the differences between two versions of the page.

--- commit:futur:lpx [2018/06/28 15:01] – papeleux
+++ commit:futur:lpx [2019/06/12 15:02] – [Commit - LPx - 13 Juin 2019] papeleux
@@ Line 1: / Line 1: @@
 ===== Future commit LPX =====
-===== Commit - LPx - 29 Juin 2018 =====
+===== Commit - LPx - 13 Juin 2019 =====
-YieldGpState :
+bug fix StopCriterion::StopAtFac
-===== YieldGpState  =====
+deplacement de l'appel à criterion->checkCriterion(&metafor)
+===== StopCriterion::StopAtFac: =====
+  * de manière peu identifiée, la demande au TimeStepManager si on est au temps de l'archivage ( bool TimeStepManager::writeToFac()) incrémentait un compteur interne à TimeStepManager''currentFacNo'' si on est au temps du fac
-===== Divers : =====
+  * l'appel à la fonction writeToFac dans les stop criterion bloquait l'écriture du fac sur disque (bien que tout le reste du process se passe de manière identique
-  * tests Fluotournage :
+  * en "workaround", j'ai sorti l'incrémentation du compteur ''currentFacNo'' hors de la fonction ''TimeStepManager::writeToFac()'' pour créer une fonction ''TimeStepManager::facWritten()'' dont le rôle est l'incrémentation du dit compteur (appelé pour les archivages aux temps prévus, pas pour les remaillages, ...).
-  * ContinuousDamageEvpIsoHHypoMaterial : bug MCCE
+  * Une gestion unifiée des temps d'archivage pourtait être mise en place (d'autres mécanismes doivent co-exister pour voir si on est aux temps des facs, des stages, ...)
-    * le paramètre MCCE (introduit par Christian) est un paramètre qui modifie l'effet de l'endommagement sur les paramètres matériaux selon que l'on soit en traction ou compression. En effet, un matériau a beau être endommagé, sa résistance à la compression est moins impactée par cet endommagement que en traction.
-    * le paramètre est calculé sur le pas de temps précédent ''mcce = computeMCCE(GP0)''
+===== déplacement checkCriterion : =====
-    * les termes de modification des paramètres élastique s'écrivent : ''(1-d*mcce)''
+  * A la demande de Yannick, l'appel à checkCriterion a été déplacé de avant le calcul des extracteur à juste après (dans la fonction Final Balancing).
-    * Mais il n'était pas passé à ''computePlasticCorrection''
+  * L'intérêt est de pouvoir utiliser un extracteur déjà calculé dans le ValuesManager (dont le cout peut être non négligeable)
+  * Enfin, ce déplacement amène l'appel à "checkCriterion" après l'appel à la fonction "finalConfigurationBalancing" (qui calcules les forces sur les Dofs fixés) => si le critère est basé sur la mesure d'une réaction, il sera (cette fois) calculé sur les bonnes réactions
 ===== Fichiers ajoutés/supprimés : =====
 <code>
@@ Line 30: / Line 32: @@
 </code>
- --- //[[L.Papeleux@ulg.ac.be|Luc Papeleux]] 2018/06/28 //
+ --- //[[L.Papeleux@ulg.ac.be|Luc Papeleux]] 2019/06/11 //