The pygplates documentation has a guide for creating isochrons from ridges, which looks really useful. What happens if a new boundary (ridge, subduction, or transform) forms that bisects one or both of the plates after the isochrons have been created?
Example 1: Plates A and B are diverging at 200 Ma, and then at 150 Ma plate B splits into B1 and B2. The rift between B1 and B2 would extend to a triple junction with A, and any existing isochrons associated with B would also need to be split. In the simplest case, I guess the initial rift between A and B could be represented as two features, one between A and B1 and one between A and B2.
Example 2: Plates D and E are diverging for a few hundred Ma, and then a subduction zone appears along the margin of E which eventually pulls a microcontinent away from D after subducting the original ridge. Two plates become at least four: the original D and E, the oceanic crust that formed as part of E but subducts under E, and the microcontinent D1. I can draw the boundary features (and continental crust fragments) manually, but I don’t know how to create the isochrons so they’re attached to the correct plate.
Example 3: Plates F and G are diverging, and then the original ridge becomes inactive and a new ridge between them forms somewhere else. The new ridge bisects through oceanic crust that was part of both plates, so some crust that was originally part of F is now part of G, and vice-versa.
All of these (plus other, more complex examples) can be observed in Merdith et al (2020).
I’ve been doing this manually, but this is somewhat time-consuming and error-prone, so suggestions of a better way of creating complex isochrons would be greatly appreciated.
If you are wanting to automate this sort of thing with pyGPlates that could get quite tricky. The isochron generating example you linked just creates the isochrons but doesn’t later subduct them, or split them when a plate splits into two, that sort of thing. I mean you could potentially do all that using pyGPlates but it would be complicated. For example, splitting isochrons lines using static (or even dynamic) plate polygons and deciding whether the pieces are on separate plates or one piece is subducting and therefore should disappear, etc.
The closest thing that does this is reconstructing points using dynamic polygons and deforming networks in GPlates (soon to be in pyGPlates), but that’s only points (not lines). It can follow a point across plate splits and merges and eventually subduct the point - but getting that working with lines is really tricky (which is why it hasn’t been done yet) - well it sort of works with lines but it just tessellates them into points (and so effectively loses the original line).
The end result I’m after is some way of indicating the ocean crust age for a global reconstruction as I build it. I’ll edit the original post to more clearly indicate this so that others don’t get caught in the same X-Y problem trap.
Isochrons seemed like a good place to start, but generating them manually has very quickly become a huge task in and of itself, especially when the plate reconstruction gets complicated. In my current model, I’m using them in conjunction with flowlines to make sure that the plate motions look reasonable and to indicate when I should start subducting ocean crust. They’re useful, but not necessary.
Can you suggest other ways of achieving the same goal? I don’t have real sources of data to work off as I’m modelling an exoplanet. The algorithm that Karlsen et al described looks promising, and there’s probably other research on the topic that will point me in the right direction.
You could do essentially what that paper (that you linked) is doing. Their process of adding tracers (points) at/near mid-ocean ridges and following them through plate splits and merges (ie, changes in plate ID) until they subduct (or hit continents) uses essentially the same idea that GPlates currently uses (in the process I mentioned in a post above) to reconstruct arbitrary points using dynamic polygons.
The main difference is they are continually generating points along ridges through time and keeping track of the ages of these points as they are reconstructed, and then using those points and their ages to create age grids. With GPlates you decide which points to give it and when, and then it reconstructs/subducts them. In both these cases working with points is easier than lines (eg, isochrons).
The next release of pyGPlates will also be able to do this (what GPlates currently does), in which case you could then … deep breath… generate isochron lines (like the first pygplates sample code you listed), with the mid-ocean ridges coming from your own ridges (instead of topological plate boundaries like usual but the general idea is similar), and tessellate those lines into points (using pyGPlates), and move them slightly off the mid-ocean ridge (ie, make two copies so one moves on one flank of MOR and the other copy moves on other flank - you don’t want them right on the MOR making their reconstruction ambiguous) then use the yet-to-be-release pyGPlates to reconstruct them through plate splits/merges (and eventually subduct them). And you also keep generating new MOR points each time step, with any point’s age at any particular time being the point’s begin time (when created at MOR) minus the current time. Then at each time step gather all points created by MORs so far, and their ages, and create a single feature with a scalar coverage (like Simon shows in this post but it’ll be age instead of crustal thickness) - a scalar coverage is basically a feature containing a bunch of points where each point has its own scalar value(s), in this case age. And make it so that feature only exists for that particular time (ie, has [begin, end] time range of [t+0.5, t-0.5]) - it’s basically a snapshot of that time since you don’t want it to appear for any other time except t. You’ll then have one such feature for each time, together representing snapshots of the ages of all the tracked points at all times. Put all those snapshot features into a single feature collection (file) and load that into GPlates. Then you can change the time slider and see the different ages of all the points (coloured by a colour palette) through time. That should give you a pretty good visual representation of the ocean crust age through time.
That’s all contingent on the new pyGPlates release though, but I could probably send you a premature version in February. The actual public release would definitely be later than Feb though, since there’s a couple other deformation features still need to be implemented.
Thanks for all that information. Karlsen et al made their implementation public and open-source, so I should be able to use that in the meantime if I port it to python3. I haven’t been able to get pyGPlates to compile on my computer due to this compilation error, and the installation procedure puts the library in a non-standard location.
Is there a gplates-dev branch for testers or early adopters? I’m using GPlates for my own personal project rather than a research or work project, so I don’t have to worry about deadlines or grant applications or anything like that. I’m also keeping my work in a Git repo so if an experimental application feature eats my work I can always roll back to a previous version if necessary.
Today I’ll try to port the GPlates 2.3 code fixes across to the last public pyGPlates (revision 28). I don’t do it very often because the merge is quite messy (mainly due to the internal model revisioning changes being only on the pyGPlates branch as mentioned here).
If not today then I’ll do it after the holidays in late January.
Also, before the next GPlates release, I’ll set up a public git repo that will contain public releases. It’ll have no dev branches, but I will put early releases in there (tags for early beta releases and release candidates that early adopters/testers can try out before the official public release).
Further to John’s replies, it is worth mentioning that there are three (that I know of) open source repositories that contain code relevant to your original question. One is related to the Karlsen et al study you mentioned, another can be found here:
and finally this one (which I wrote together with John, and where the process for reconstructing points through time and figuring out where they should be subducted or switch from one plateid to another mirrors to a large extent what GPlates desktop does when using the ‘reconstruct by topologies’ option).
Hard for me to say which is best for your specific needs (and anyway I’m biased), but it would be worth noting that the last of the three:
has been updated to work with python3.
includes a function called ‘get_isochrons_from_topologies’ which would more specifically address your original question about creating isochrons (although related to John’s previous explanation, this does not produce isochron ‘lines’ specifically, rather a series of points lying along where these lines would go. Having said that, if you are only interested as isochrons as a means to an end (ie to map the seafloor ages continuously over the oceanic regions) then it may not be necessary to focus specifically on that function, rather make use of the overall workflow that outputs reconstructed grids.
The main branch of that repo is compatible with pygplates v2.8. There is a different branch that is compatible with the not-yet-but-soon-to-be public version of pygplates where the inner workings will change slightly but the results would fundamentally be the same (the new version would also allow for use with reconstructions that contain deforming regions, though for exoplanets I doubt that is an issue).
Here’s pyGPlates revision 33, you’ll want pygplates_rev33_src.tar.bz2. This is the latest internal release (ie, not revision 28 which is the most recent public release). It was easier to merge into 33 than 28, and that also means you can use that different branch that Simon mentioned in his age gridding workflow (thanks Simon for mentioning those repositories, btw).
When you compile the code there’ll be some warnings about multi-line comments, but you can ignore those for now.
Have a nice holiday break! I’ll be back late January
I’ll be back late January 