# Rate and state friction model

**URL:** <https://community.geodynamics.org/t/rate-and-state-friction-model/2046>\
**Category:** PyLith\
**Created:** [October 20, 2021, 10:28am UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046 "2021-10-20T10:28:52Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![LauraBM](https://avatars.discourse-cdn.com/v4/letter/l/3bc359/32.png) [@LauraBM](https://community.geodynamics.org/u/LauraBM)\
**Post date:** [October 20, 2021, 10:28am UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046/1 "2021-10-20T10:28:52Z")

</div>

Hello,

I have a few questions regarding the rate and state friction model implemented in Pylith:

1. Does Pylith allow negative friction coefficients, in particular given the term b_ln(v0_theta/L) ? (It could be that v0 is very small, and v0\*theta/L such that the log is negative)
2. The resolution (eqs. 6.72 and 6.73) of the ageing law works if 1-v\*theta/L is positive (so theta is an increasing function of time, upper limit L/v), but for instance, in step14 of the hex8 example in the manual, theta decreases at some point of the simulation. In that case, is it correct to use eqs 6.72 and 6.73 ?
3. I took the rate and state files as a basis and created a new fault model with some prints. I noticed the reference slip rate is modified from the value provided in the input file (for step14.cfg, the reference value is 2e-11 m/s but the code prints 6.31152e-07). The same happens with the characteristic slip distance, modified from 5e-2 m to 5e-5 internally. Could you explain why?

Thanks,

Laura

---

<div class="post-metadata">

**Author:** ![baagaard](https://yyz2.discourse-cdn.com/flex036/user_avatar/community.geodynamics.org/baagaard/32/615_2.png) [@baagaard](https://community.geodynamics.org/u/baagaard)\
**Post date:** [October 20, 2021, 2:12pm UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046/2 "2021-10-20T14:12:58Z")

</div>

We expect the user will provide a reasonable set of parameters, a, b, v0, L, etc so that the coefficient of friction stays positive.

It has been a while since I looked at the derivation for eqn 6.72, but I believe it is independent of the sign of 1-v\*theta/L.

Internally, PyLith uses nondimensional values, so all dimensioned parameters, including friction model parameters, are nondimensionalized during the initialization process. See the PyLith manual for more information about the scales used for nondimensionalization.

---

<div class="post-metadata">

**Author:** ![LauraBM](https://avatars.discourse-cdn.com/v4/letter/l/3bc359/32.png) [@LauraBM](https://community.geodynamics.org/u/LauraBM)\
**Post date:** [October 21, 2021, 9:37pm UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046/3 "2021-10-21T21:37:06Z")

</div>

Thanks for your answers.  
Regarding the sign of the friction coefficient, if I take step14 in tutorial 3d/hex8, for instance output at t140, when I compute the friction coefficient for the sixth node in the file, I get a negative value (-0.031). I added the lines  
vertex\_info\_fields = [normal\_dir,strike\_dir,dip\_dir,reference\_friction\_coefficient,reference\_slip\_rate,characteristic\_slip\_distance,constitutive\_parameter\_a,constitutive\_parameter\_b,cohesion]

vertex\_data\_fields = [slip,traction,slip\_rate,state\_variable]

to the input file to get the target output in the vtk files. Does Pylith use this value or is there a check for inconsistent values in the code?

Thanks,

Laura

---

<div class="post-metadata">

**Author:** ![baagaard](https://yyz2.discourse-cdn.com/flex036/user_avatar/community.geodynamics.org/baagaard/32/615_2.png) [@baagaard](https://community.geodynamics.org/u/baagaard)\
**Post date:** [October 27, 2021, 3:59pm UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046/4 "2021-10-27T15:59:50Z")

</div>

There is a check for using values of theta \> 0 (see [pylith/RateStateAgeing.cc at releases/v2.2 · geodynamics/pylith · GitHub](https://github.com/geodynamics/pylith/blob/releases/v2.2/libsrc/pylith/friction/RateStateAgeing.cc#L321)), but I did not find a check ensuring the coefficient of friction is positive.

---

<div class="post-metadata">

**Author:** ![LauraBM](https://avatars.discourse-cdn.com/v4/letter/l/3bc359/32.png) [@LauraBM](https://community.geodynamics.org/u/LauraBM)\
**Post date:** [October 29, 2021, 12:17pm UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046/5 "2021-10-29T12:17:33Z")

</div>

Thanks for your answer. Do you think this is something that could be done?

---

<div class="post-metadata">

**Author:** ![baagaard](https://yyz2.discourse-cdn.com/flex036/user_avatar/community.geodynamics.org/baagaard/32/615_2.png) [@baagaard](https://community.geodynamics.org/u/baagaard)\
**Post date:** [October 29, 2021, 1:59pm UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046/6 "2021-10-29T13:59:46Z")

</div>

This issue seems to be confined to the rate-state friction model, so it is best handled within the friction model implementation. We are focusing on the v3 code base and no longer working on the v2 code base. We will definitely keep this issue in mind as we re-implement friction in the v3 code base.

---

<div class="post-metadata">

**Author:** ![LauraBM](https://avatars.discourse-cdn.com/v4/letter/l/3bc359/32.png) [@LauraBM](https://community.geodynamics.org/u/LauraBM)\
**Post date:** [October 29, 2021, 2:22pm UTC](https://community.geodynamics.org/t/rate-and-state-friction-model/2046/7 "2021-10-29T14:22:08Z")

</div>

Great, thanks
