bug in method from_srf_file in the class of finitefault

[wangyf]

I found that two orthogonal slip velocity components (sv1 and sv2) share the same rake angle which is not consistent with the definition of the rake in SRF format. Rake is the sv1 direction while sv2 follows rake + 90 as its rake angle as seen in Figure-1 of http://hypocenter.usc.edu/research/SRF/srf4.pdf. I suggest modifying the line 1207 in source.py from rake to rake + 90

[martinvandriel]

Thanks for reporting, I think you are right. I am just trying to figure out how this slipped through and whether your suggested fix this breaks any tests. It seems we never really tested/benchmarked slip along u2 as we also never got a source file with such input.

Maybe you have means to verify this? How did you find the bug?

[wangyf]

Actually I am a dynamic rupture modeler. Our colleague tries to use instaseis to compute waveforms from a dynamic rupture model in which rake angle may vary during the rupture. Therefore we cannot use a single rake direction to describe our source (namely only u1 direction). I modified some parts: 1) allow M0 to be negative (means slip direction is anti-rake) and 2) +90 on u2 rake. In this scenario, we may have a means to verify this. @xiansch

[martinvandriel]

allow M0 to be negative (means slip direction is anti-rake)

May I ask what the purpose of this is? Wouldn't it be better to just use rake + 180?

[wangyf]

Because in our simulation, we do not assume the rake angle (because it can vary during the rupture). In other words, in our model, we do have negative slips thus allowing negative moments. But when I import srf into instaseis, I rotate the rake as you mention rake+180 while keeping moment is still positive.

[krischer]

Should we implement this?