Differences

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

--- commit:2019:04_05 [2019/04/05 13:32] – laruelle
+++ commit:2019:04_05 [2019/04/05 13:55] (current) – laruelle
@@ Line 1: / Line 1: @@
 ====== Commit 2019-05-04 ======
 ===== Stabilization of the “Souza” method in ContinuousDamageEvpIsoHHypoMaterial=====
-Some test cases using the "Souza" method for stress computation in the ContinuousDamageEvpIsoHHypoMaterial were not working only on my computer (apps.monosMaterials2.EvpIsoDamageLemaitreSouza). After looking into it I noticed that even on the other machines some of the test cases were a bit unstable or had an abnormally high number of steps/iterations. The problem occurred in the tests where a force was first applied, increasing the damage in the material, and then the force stopped, which should result in no modification of the damage in the rest of the simulation. An example is EvpIsoDamageLemaitreSouza.TracRot3DNumEas were we have first a traction and then a simple rotation of the Element. Those tests had convergence issues in the part of the simulation where the damage evolution should be 0.
+Some test cases using the "Souza" method for stress computation in the ContinuousDamageEvpIsoHHypoMaterial were not working only on my computer (apps.monosMaterials2.EvpIsoDamageLemaitreSouza). After looking into it I noticed that even on the other machines some of the test cases were a bit unstable or had an abnormally high number of steps/iterations. The problem occurred in the tests where a force was first applied, increasing the damage in the material, and then the force stopped, which should result in no modification of the damage in the rest of the simulation. An example is EvpIsoDamageLemaitreSouza.TracRot3DNumEas where we have first a traction and then a simple rotation of the Element. Those tests had convergence issues in the part of the simulation where the damage evolution should be 0.
 To solve this problem I first checked the implementation of all the equations and found no mistakes.
@@ Line 7: / Line 7: @@
 I concluded that the problem might be purely numerical so I tried to improve the code and made the following changes:
-) I changed the computation of the derivative of the residue with respect to deltaR (effective plastic strain increment) to compute seperately the term relative to the damage (dResD) and to the damage evolution function (dResDD). Those two terms having different order of magnitude in the case where no damage is applied, this should result in less numerical errors.
+) I changed the computation of the derivative of the residue with respect to deltaR (effective plastic strain increment) to compute seperately the term relative to the damage (dResD) and to the damage evolution function (dResDD). Those two terms having different order of magnitude in the case where the damage should not change, this should result in less numerical errors.
 ) I changed the minimum allowed deltaR (effective plastic strain increment) from 1.0e-16 to 0.0.