Skip to content

Conversation

MFraters
Copy link
Member

@MFraters MFraters commented Nov 7, 2024

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.

Copy link
Contributor

@naliboff naliboff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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.)),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants