-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consider feature type pygplates.FeatureType.gpml_transform when getting the transforms from topologies #227
Comments
I just realised that So I wonder if it's better/easier to have a user option in the plotting function(s) to include @nickywright I'm guessing you wanted the option to plot PS: I'll be away tomorrow (Weds). |
Sorry @jcannon-gplates - emails from GitHub get buried in a folder! Currently But intuitively, I would've thought plot/get transforms would have meant from actual gpml:Transforms, and the result of the ridges and transforms splitting would be called something completely different (or personally, not be used at all because clearly at 430 Ma - random time I picked - it doesn't work). See two examples here (made with pygmt @michaelchin in case you need an example?). It gets more noticeable as you go into the deep past with the more recent models (here I've used Müller et al. 2022) because I've noticed that the gpml: Transforms feature types are used more in the deeper past. The 430 Ma plot also illustrates how the ridges and transform code isn't working very well right now at all (see plot on the left). I would imagine this would have major implications for if you were trying to calculate ridge vs transform plate boundary lengths, or perhaps crustal production at this time and it used these ridge segments/got rid of the transform segments from the gpml:MidOceanRidge, because now you're actually missing most of your actual ridge segments at this time period. I'm not sure what the codes do but I've mentioned this to Dietmar. The code to reproduce this all (including Cartopy figures) is in this gist |
Thanks @nickywright, I agree that the ridge/transform separation doesn't appear to be working too well. In fact Dietmar just said:
Aside from the Which leads to Dietmar's next point...
So we could, for now, just ignore the That might mean a bunch of function renaming is needed. For example, Regarding Dietmar's proposed way forward for crustal production along MORs:
So that would be more of a GPlately thing that pyGPlates (since age grids are involved). Ultimately I can imagine functionality in pyGPlates that could seed points along MORs and move them over a time interval (similar to the first phase of the new age gridding workflow), Then join those moved points into a new line and calculate the intervening area (between original and moved lines). Or something along those lines (no pun intended). I'll have a think about that when I do the plate boundary divergence/convergence in pyGPlates - but that's for the longer term.
So the computation of crustal production rates by itself probably wouldn't help here. In which case, in reference to the above-mentioned pyGPlates crustal production rate functionality, I should investigate whether that can also separate ridge/transform segments somehow (without running into the same stage rotation issues that's currently causing all our problems). If that works, it could ultimately replace the functionality of So, for now, I guess it's the crustal production age-gridding approach (in GPlately), and just hide the ridge/transform separation functionality (without removing it completely). And the renaming of |
The solution proposed by the client might also close #228 |
Thanks @jcannon-gplates @nickywright I summarise the things which need to be done below. Let me know if I missed anything or misunderstood anything.
|
@michaelchin , that sounds correct to me. Thank you! Perhaps you can also please clarify what |
I don't have the answer right now. I will ask around. I am not the original author of the code. I was told to look after GPlately a few months ago. Some parts of GPlately are still unknown to me. @GPlates/gplately-dev Does anyone know the answer to @nickywright 's question above? |
It's the I would suggest we remove I also wonder if we should rename |
According to client DM's latest email, it seemed that he has changed his mind. He said and I quote
I think we should hold further actions until DM has made up his mind. |
I see two issues here:
I suggest we should continue to do point 1. And point 2 should be done in new functions. I think Nicky agrees...
...and then the issue of the ridge/transform splitting not working very well can hopefully be improved in the future (I'll look into it when I do plate boundary convergence/divergence in pyGPlates). So I think we can do point 1 without waiting, but we wait before doing point 2 until we're certain we still want to split MORs into ridge/transform segments. Maybe we can that discuss in the next meeting. |
From the recent meeting, we decided we probably won't explicitly separate into ridge and transform segments. Instead each segment will get a value in the range [0,1] for how ridge-like it is. This'll be used to calculate things like ridge lengths, crustal production, ridge spreading rates. So the idea of separating into ridge and transform segments no longer really applies. So, when the time comes (once the necessary functionality is in pyGPlates) we can take another look at restructuring the current ridge-transform separation code (and ridge spreading code). So I think we can now just assume that we only need to plot/get
|
OK, I will
|
Currently PTT only consider pygplates.FeatureType.gpml_mid_ocean_ridge when getting ridges and transforms from topologies. see the code below.
gplately/gplately/ptt/resolve_topologies.py
Lines 224 to 227 in a29e3ae
One of the clients mentioned that features with type pygplates.FeatureType.gpml_transform should also be considered.
I am not sure if other feature types should also be considered, such as pygplates.FeatureType.gpml_aseismic_ridge
The text was updated successfully, but these errors were encountered: