[WIP] use old strain-rate instead of current strain-rate to add as a reaction to strain fields of strain-dependent. #6141
Conversation
…on to strain fields of strain-dependent.
There was a problem hiding this comment.
@MFraters - Thanks for testing this change! I agree the current approach is more physically realistic, but at this stage this would just be one of many approximations we (and the broader community) make to achieve numerical stability. If I was specifically looking at the fine details of fracture development my inclination would be to use the current approach, but for most studies I think the proposed approach would be fine.
If this approach does help, my vote would be to make using the old strain rate as an input parameter option.
| @@ -633,7 +633,32 @@ namespace aspect | |||
| ExcMessage("Invalid strain_rate in the MaterialModelInputs. This is likely because it was " | |||
| "not filled by the caller.")); | |||
|
|
|||
| const double edot_ii = std::max(std::sqrt(std::max(-second_invariant(deviator(in.strain_rate[i])), 0.)), | |||
|
|
|||
| // Get old (previous time step) velocity gradients to compute the ol strain-rate | |||
There was a problem hiding this comment.
| // Get old (previous time step) velocity gradients to compute the ol strain-rate | |
| // Get old (previous time step) velocity gradients to compute the old strain rate |
| const SymmetricTensor<2,dim> strain_rate = symmetrize (evaluator->get_gradient(i)); | ||
|
|
||
|
|
||
| const double edot_ii = std::max(std::sqrt(std::max(-second_invariant(deviator(strain_rate)), 0.)), |
There was a problem hiding this comment.
I think to avoid future confusion we should calculate both edot_ii and old_edot_ii, and then allow the user to select via an input parameter which approach to take.
When updating the strain compositional fields in the strain_depended rheology module, it uses the current strain. I don't think this is conceptually the best idea, since I think it should but the accumulated strain up to this point, but it is also numerically very difficult to solve since the whole system can become extremely nonlinear.
This pull request changes that instead of the current strain-rate to the old strain-rate (previous time-step) is added to the strain fields.
This is a work in progress, and I still need to do some testing how this would work out, but I would like to get some early feedback on whether this makes sense to other people or not.