Add tranforms faults to ridges

[MFraters]

Up to now you could only specify one ridge per oceanic plate. That means that if you wanted to use tranform faults, you needed to make several oceanic plates. This is very inconvenient and leads to world builder input files which are a lot longer and more complex than needed. A simple solution is to allow multiple ridges per oceanic plate, in an array of ridges instead of a single ridge. This does mean it is a breaking change.

A second advantage is that the mass conservative slab temperature model can now be perfectly fitted to the temperature/age of the connecting oceanic plate. See image below, which shows the model from below:

There are two main way of approaching this. One is to infer that the transform fault is defined by the offset between the last coordinate of the current ridge and the first coordinate of the next ridge. This is the approach I have taken since it seems to me like the correct choice physically. An other option would be to let the users define the location of the transform fault themselves, by interpreting every odd numbered ridge as a transform fault. This would create a lot more flexibility, but also a lot more complexity in the code and the writing the input file. I can't think of a good use case for that so I don't see the value of taking that approach.

I will leave this pull request open for a few days to allow others to think about this as well and provide input on this or other choices.

I am planning to also implement this for the plate model in this pull request, to make sure ridge coordinates are consistent throughout the world builder. Since this is a breaking change it is going to break a few tests, but the fix should be simple.

@alarshi, @lhy11009,@rfildes, @mibillen and @danieldouglas92 if/when this pull request is merged, it will break any model which uses a ridge, but the fix is simple: change [[1,2],[3,4],[5,6]] to [[[1,2],[3,4],[5,6]]] and you will get the same results as before.

[github-actions]

Benchmark	Main	Feature	Difference (99.9% CI)
Slab interpolation simple none	1.206 ± 0.003 (s=377)	1.207 ± 0.004 (s=371)	+0.1% .. +0.2%
Slab interpolation curved simple none	1.230 ± 0.005 (s=365)	1.230 ± 0.005 (s=369)	-0.2% .. +0.0%
Spherical slab interpolation simple none	1.561 ± 0.047 (s=299)	1.557 ± 0.043 (s=281)	-1.1% .. +0.5%
Slab interpolation simple curved CMS	1.869 ± 0.095 (s=248)	1.848 ± 0.096 (s=239)	-2.6% .. +0.4%
Spherical slab interpolation simple CMS	2.988 ± 0.026 (s=139)	2.979 ± 0.023 (s=165)	-0.6% .. +0.0%
Spherical fault interpolation simple none	1.635 ± 0.164 (s=270)	1.629 ± 0.163 (s=284)	-3.2% .. +2.5%

[mibillen]

@MFraters, one question about the shape of the transform boundary that is assumed between the two offset points. On a sphere, I think the transform boundary should be small circle paths between the two end ridge points, whereas in cartesian coordinates the transform is just a straight line. Is this already taken into account in spherical coordinates?

[MFraters]

@mibillen Thanks for the question. This part of the computation is all done in natural coordinates (i.e. cartesian for a box and spherical for a sphere, chunk, etc.) In cartesian coordinates this is just a line. In spherical coordinates, the straight line is also straight in spherical coordinates. This creates the small circle path between the two end points of the ridges.

[codecov]

Codecov Report

Merging #362 (b216c89) into main (053cde8) will decrease coverage by 1.08%.
The diff coverage is 49.49%.

❗ Current head b216c89 differs from pull request most recent head ca684e8. Consider uploading reports for the commit ca684e8 to get more accurate results

@@            Coverage Diff             @@
##             main     #362      +/-   ##
==========================================
- Coverage   98.86%   97.77%   -1.09%     
==========================================
  Files          77       77              
  Lines        4476     4548      +72     
==========================================
+ Hits         4425     4447      +22     
- Misses         51      101      +50     

Impacted Files	Coverage Δ
...ucting_plate_models/temperature/mass_conserving.cc	87.65% <38.46%> (-9.63%)	⬇️
...eanic_plate_models/temperature/half_space_model.cc	75.32% <40.74%> (-19.51%)	⬇️
...es/oceanic_plate_models/temperature/plate_model.cc	80.68% <40.74%> (-17.87%)	⬇️
source/parameters.cc	99.17% <89.47%> (-0.40%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 053cde8...ca684e8. Read the comment docs.

[MFraters]

The pull request is now almost done. I just need to improve the coverage for multiple ridges. If not further comments are made about this pull request it will probably be merged on Friday.

[MFraters]

The coverage is fixed now, even though the codcov post doesn't show it. All new lines are covered and there are now new misses. All tests have passed and the benchmarks show no significant difference (some benchmarks seem to be, if anything, consistently on the faster side even though more works needs to be done). This is ready to merge now.

[lhy11009]

Hi Menno Thanks for letting us know about this new feature. Just to be clear, we need to put our ridge coordinates into a list, right? If we have no transform faults, that would be just one component in that list, correct?

…

On Fri, Nov 5, 2021 at 6:21 PM Menno Fraters ***@***.***> wrote: Merged #362 <#362> into main. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG2WMFPB32NCKJWI3ZIIBO3UKR7IJANCNFSM5HDKULHQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Ph.D student of Geophysics Earth & Planetary Sciences Dept., UC Davis Davis, CA 95616

[MFraters]

Yes, that is correct. For example, [[10,20],[30,40]] becomes [[[10,20],[30,40]]]