EQ magnitudes > 10

[kwschultz]

We have a bug appearing on Mac and Linux compiled versions of VQ, with earthquake magnitude running away (8 -> 10 -> 12...) after somewhere between 4500 years (linux) and 8000 years (mac).

This may be due to overlapping fault segments causing Green's functions to get absurdly large.

We're still testing the effect aftershocks have on this.

I think one possible solution is to use the VQ input parameter sim.greens.kill_distance (which is used in vq/src/simulation/GreensKillInteraction.cpp::killInteraction) to set a threshold/max for Greens Function. Setting sim.greens.kill_distance to be proportional to the element_size might prevent this by detecting element overlap then capping the Greens function values

[kwschultz]

Mark raises a good point about needing an Omori style smooth solution, not a sharp step-function for the GF, we're now turning our attention to sim.greens.sample_distance

[ericheien]

sample_distance (if it's even used anymore) refers to doing multiple Greens calculations for an element. For example, rather than calculating stress at 1 point in the center, it could calculate 2x2 points evenly spaced over the block and average these.

[markyoder]

these monster events likely result from bogus greens_values, consequence of overlapping and intersecting fault segments (see some of the 3km or 2.5 km fault model kml files). i've added... or i'm adding some codes to PyVQ to analyze greens_function data; note that the 3km model produces a few values that are >> 10 times the "next" values. SO, i've added code to set max/min values for greens shear values (there are notes attached to another ticket), but basically the notation is like: sim.greens.shear_max, sim.greens.shear_min, sim.greens.normal_max, sim.greens.normal_min in the vq parameters file. this appears to mitigate the giant events. note also that this problem is separate from heisen_hang (mysterious hanging/freezing of the simulation on mac systems).

the real fix for this problem most likely requires an improved "mesher" logic. this might include 1) a generalized implementation of a triangular lattice along a 2D surface embedded in 3D (a fault surface, "ribbon"), 2) tweaking the existing mesher to reduce the size of or remove intersecting elements; this can be accomplished posthumously, after the initial mesher run, either in C++ or externally in Python, 3) ???

so this problem is mitigated and presumably manageable at this point. further "fixes" will be pretty involved, so we can nominally close this ticket... or leave it open. kasey?

[kwschultz]

I'm not 100% convinced it's only due to overlapping faults. I think the rupture model is involved. Like we've discussed, in a few recent allcal sims (5km), we see elements that induce many back to back to back events that occur in long sequences. These sequences tend to slowly decrease in magnitude for ~10-30 events, then slowly increase in magnitude for many events ~20-500, then the last event in the series has a big increase in magnitude (in the example below it's 4.93 -> 7.37). In this whole series of consecutive events, for each event there's a net increase in shear stress though very small < 1%. This amount of stress build up is almost equally released in the small time between consecutive events. Upon visual inspection, it looks like every event in this simulation has event_shear_final > event_shear_init.

I've seen this phenomenon in full CA model runs, but the example below is from a northern CA subset of faults.

Example allcal (NORTHERN CA SUBSET, not full CA model) model, 5km, 5000 years, 4 processors on my iMac (with dip/strike convention updates that will soon be pushed to geodynamics/vq)

Element 185 has this sequence of triggered events: event_year event_magnitude 3906.4 6.68 ...other events... 4060.1 7.12 ...other events... 4137.9 7.01 ...one other event... 4178.3 7.20 ...other events... 4271.4 7.19 4302.5 7.17 4308.1 6.51 ...other events... 4676.7 6.97 4686.2 6.81 4691.6 6.66 ...element 185 has 28 consecutive events that slowly decrease in magnitude, each separated by 0.1yr to 2yr... 4705.1 4.91 ...element 185 has 530 consecutive events that slowly increase the magnitude from 4.91 to 4.93... 4711.87 4.93 4711.88 7.37
The very next event is triggered by element 114 and it's a magnitude 8.05 (one of the largest 4 EQs in this short simulation)

[kwschultz]

Also, 2 other elements in that same simulation had similar sequences of consecutive earthquakes

[kwschultz]

This seems to have been fixed by removing absolute values from the CFF calculation. It was: CFF = abs(shear_stress) - coeff_friction_abs(normal_stress) Corrected to be: CFF = shear_stress - coeff_friction_normal_stress