Conversation
|
Actually made a reasonably large change here to allow me to do the kind of at-scale processing we need to be able to do for type-5 verification. The main change is that now we actually read the SRF entirely in C code. For my testing this improves the performance of the SRF reader by something like 10x. I'm hoping this will cut down on the time to process the SRF analysis from 10 hours to 1 hour. Accordingly, the slip values are now recorded in sparse matrices that are also built in C, and so are no longer part of the points DataFrame. This is disappointing because it makes code handling slip a little more complicated, but is necessary to parse 100Mb+ SRF files efficiently. As for why we can't use |
claudio525
left a comment
There was a problem hiding this comment.
Nice work! Only comment I have is that the C-code needs a lot more comments imo. Adding both docstrings and block comments would make it significantly easier to read & work with this code.
|
Yeah I forgot to add comments to the srf C code |
|
Needs to a be a draft temporarily while I figure out the SRF writing glitches. |
AndrewRidden-Harper
left a comment
There was a problem hiding this comment.
nice visual explanation in the comments

This PR adds a few SRF module enhancements:
sliptproperty that is the total slip at each timestep for each patch. The SRF spec stores slip in three componentsslipt1,slipt2,slipt3, but most often we care about the total slip in all three directions.slipproperty that is the total slip for each patch. Theslipparameter is related tosliptas the integral ofsliptover time.These changes are used for the plots I'm generating, and also by Cesar, who is also using the srf module for his work.