[WIP] Revert one change of PR #5580 to improve Newton solver convergence #6160
+45
−36
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a result of #6159. I would like to discuss reverting this change that happened originally in #5580. The difference between the
strain_rate
andeffective_strain_rate
is for most models (that dont use elasticity) thateffective_strain_rate
is simply the deviatoric part of the strain rate. I do not understand why we use the deviatoric strain rate here (it will be used to assemble the Newton matrix, i.e. the Jacobian). Maybe I just didnt follow the discussion in #5580 closely enough. From my understanding this should be the full strain rate, and at least the benchmark in #6159 massively benefits from my change here:These are the relevant results from the benchmark in #6159 pre #5580:
These are the relevant results post #5580. You can see you the stabilized version / dots converge faster, but the unstabilized version / lines are much worse:
Now these are the relevant results post #5580 but with the change I propose in this PR. The unstabilized models are reverted to their original (better) convergence, and even the stabilized models gain another small boost:
I think this change may be responsible for some of the changes in #6159 that I couldnt explain. I will have to rerun more benchmarks, but in the meantime @YiminJin and @MFraters could you remind me why we did this change originally?