Plates sliding over each other

[Dyeoue]

Maybe there's just something I'm not getting, but to me, it seems like currently when two plates collide, they don't crash into each other making a mountain, they just pass over each other without interacting. I'm not sure if this is the current intended behaviour or what could be done about it.

The seed in this example is /tectonics.js/index.html?seed=ChgW3

You can see that the plates are the same plates from before they collided.

[davidson16807]

Known bug. The models either needs some representation of subduction zone congestion, or better representation of crust as it subducts and drags the rest of the crust with it, or both.

[davidson16807]

This is going to be my next focus now that I've made some progress on #8. Could be a simple fix. It might only require us to recalculate velocity with each timestep.

[astrographer]

I wonder if part of the problem with elevations blowing up doesn’t come back to crust segments stacking up like this.

On Mar 13, 2018, at 2:12 PM, Carl Davidson notifications@github.com wrote:

This is going to be my next focus now that I've made some progress on #8. Could be a simple fix. It might only require us to recalculate velocity with each timestep.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[davidson16807]

The thing with elevations blowing up has everything to do with integrating conserved mass deltas over multiple plates. If conserved mass was less likely to stack up around plate boundaries, then yeah, it would probably mask the problem, but it wouldn't fix it.

If that doesn't make sense: continental crust is a conserved quantity in the model. It's never created or destroyed, but it is transported and transformed. Continental crust can be transported/transformed by a number of processes: erosion, weathering, accretion, asteroid impact, etc. The model represents each process using a "delta". For each grid cell, the delta indicates how much crust will be gained or lost within a single timestep. Because continental crust is conserved, if you sum up the gains/losses for each grid cell, the sum will always equal zero. We check against this assumption every timestep and we can guarantee the deltas are calculated properly, but the problem is with how we add the deltas onto the plates.

For performance reasons, we calculate the deltas only once for the entire globe, but for accuracy reasons, we store the state of the crust across several plates (the alternative to this is storing a single world map of crust and running an advection model). So in other words, for each grid cell in the delta we have to allocate it to a grid cell on one of the plates. This is where conservation errors crop up. Imagine what happens when a grid cell on a plate map corresponds to multiple grid cells on the world map. Imagine what happens on the borders of plates.

My solution so far has been to tinker around with different approaches and pick the one that seems to work the best. Not the ideal solution, but it's gotten better. Actually, as of 19114235afe1493802cb55ec016bf1efdc8e3871 the model is slowly losing mass, not gaining it.

Either way, fixing issue #18 may help to mask #17, an otherwise intractable problem.

[davidson16807]

As of commit abf1ae6dc1a1eda597959300cb27438b89adc002, plate velocity is calculated deterministically for each timestep based on crust density. This will almost certainly resolve this issue.

Here's a brief rundown how it works: Imagine a cloth with lead weights strapped to one side. It's sitting in a vat of honey. The lead weights slowly drag the cloth into honey at a constant rate of speed. It's kind of like that.

Here's a less than brief rundown:

Start with density

use that to calculate the buoyancy force: B = g Δρ where g is force of gravity and Δρ is difference in density compared to the mantle. The velocity of subducting crust is essentially the terminal velocity of the crust as it descends into the viscous mantle due to the buoyancy force, so we calculate that from buoyancy.

OK, now we already have a plate field as part of the simulator. Each plate has a mask indicating regions it occupies. Take the gradient of that mask and that gives you a boundary normal - in other words, a set of vectors that are normal to the plate boundary.

Multiply boundary normal by the velocity of subducting crust and you get an estimate for lateral velocity at that point. The average across all estimates is an estimate for the velocity of the entire plate.

It's important to note this is not the proper way to calculate velocity. It's only a fast approximation. If we wanted to do it the right way, we'd calculate the net drag force given the current plate velocity, then use that with the buoyancy force to update velocity. We'd do this for several iterations each timestep to get a good estimate. The reason we don't do it this way is 1.) it's slow, 2.) it's complicated, and 3.) it's not super important.

This is a huge improvement to the model, at least in principle. Velocity is actually calculated from something! I can't think of any other non-academic simulator that does that. We're not just randomly generating it anymore! The model even outputs velocity in the correct units of measure. We're not even fudging on the units any more, people!

Also: can I get someone to confirm this resolves the issue? Some general feedback on model behavior as of this commit would be helpful, as well.

Elevation appears to be much more realistic over large timescales. We no longer get lots of super small, super tall continents that are mostly composed of mountains. This is because continents will eventually stop when their surrounding oceanic crust is subducted and destroyed.

However, I do think the model is less likely to form supercontinents, now. I suspect that continental crust is still slowly being destroyed over time, but as mentioned previously this is for reasons beyond my control. I also suspect continents take on much less impressive, realistic looking shapes, but this is an aesthetic complaint and sometimes the model still pleasantly surprises me:

nemales-1.62Gy (1).txt

[davidson16807]

Going to close this out if no objection