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/13 11:59] – papeleux
@@ Line 1: / Line 1: @@
 ===== Future commit LPX =====
-===== Commit - LPx - 29 Juin 2018 =====
+===== Commit - LPx - 13 Juin 2019 =====
-YieldGpState :
+bug fix & modification StopCriterion::StopAtFac
-===== YieldGpState  =====
+deplacement de l'appel à criterion->checkCriterion(&metafor)
+===== bug fix : 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 pourrait (devrait) ê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 coût 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
+===== stopAtNextFac- checkAtFac: =====
+  * Pour donner plus de souplesse au Stop Criterion, j'ai modifié les options des StopCriterion
+    * stopAtNextFac (def : false) : teste le critère à chaque pas de temps mais n'arrete le calcul que au prochain archivage (particulièrement adapté aux calculs d'IRS pour lesquels les postpros sont écrits sur base de "tours entiers. La valeur mesurée pourrait redescendre en dessous de la valeur critique au moment du fac)
+Remplace évidemment l'option "StopAtFac".
+    * checkAtFac (def : false) : ne teste les critères que au moment des archivages (et stoppe donc aussi à ces moments)
 ===== Fichiers ajoutés/supprimés : =====
 <code>
-Added :
+Added : oo_meta/mtFEM/ValueManagerStopCriterion.h/cpp
 Deleted :
 Moved :
@@ Line 25: / Line 33: @@
 ===== Tests ajoutés/supprimés =====
 <code>
-Adding:
+Adding: oo_meta/apps/imp/nineStopCriterion3.py
 Deleted :
 Moved :
 </code>
- --- //[[L.Papeleux@ulg.ac.be|Luc Papeleux]] 2018/06/28 //
+ --- //[[L.Papeleux@ulg.ac.be|Luc Papeleux]] 2019/06/11 //