[newton] Update shift after actual update
Alternative for !3865 (closed). Fixes #1394 (closed).
Reassembly is now calculated based on the actual update. I think this makes more sense because if we haven't moved much due to a small step size we are more likely to can afford keeping the Jacobian entry.
Merge request reports
Activity
assigned to @timok
@bernd Here I flip the order of actual update and shift calculation. All tests seem to pass except 1p adaptive which I think uses partial reassembly. So I'll have to check if that does still the same, or at least was improved and not made worse. In particular check if updateShiftFromLastIteration still does the same upon which we base the reassembly threshold.
One aspect that didn't appear before is that the actual step size can be very small (line search or chop) and that the shift is then really small. Only using shift criterion in this case is probably bad but if someone is doing this it might lead to Newton saying converged now at some point where we are not converged.
added 7 commits
-
64d37796...a837a288 - 6 commits from branch
master
- ffefed59 - [newton] Update shift after actual update
-
64d37796...a837a288 - 6 commits from branch
added 40 commits
-
ffefed59...f9b4606d - 39 commits from branch
master
- 06567661 - [newton] Update shift after actual update
-
ffefed59...f9b4606d - 39 commits from branch
changed milestone to %3.10
added Common/IO/(Non-)Linear/Parallel label
enabled an automatic merge when all merge checks for 06567661 pass
mentioned in merge request !3865 (closed)
added Fix label
mentioned in commit 659d849f