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

Does Pylith allow negative friction coefficients, in particular given the term bln(v0theta/L) ? (It could be that v0 is very small, and v0*theta/L such that the log is negative)

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 ?

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?

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.

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]

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.