Only resolve rigid plates when getting ridges and transforms

[michaelchin]

only resolve rigid plates by adding the parameter “resolve_topology_types=pygplates.ResolveTopologyType.boundary” to the pygplates.resolve_topologies() function

The COBs should not be there

[michaelchin]

After adding the parameter “resolve_topology_types=pygplates.ResolveTopologyType.boundary”, I am able to get rid of most of the COBs. But some of them are still there. See the screenshot below.

[michaelchin]

@jcannon-gplates

I found some side effects to plot_all_topologies() function after d7919a7

Before, the plot_all_topologies() plot boundaries + networks. After the change, the plot_all_topologies() plot boundaries only.

In GPlately, the resolve topologies code is here

gplately/gplately/plot.py

Lines 445 to 459 in a29e3ae

	(
	self.topologies,
	self.ridge_transforms,
	self.ridges,
	self.transforms,
	self.trenches,
	self.trench_left,
	self.trench_right,
	self.other,
	) = ptt.resolve_topologies.resolve_topologies_into_features(
	self.plate_reconstruction.rotation_model,
	self.plate_reconstruction.topology_features,
	self.time,
	anchor_plate_id=self.anchor_plate_id,
	)

Shall I make another call to pygplates.resolve_topologies() without the new parameter for self.topologies? Any other better ideas?

[michaelchin]

Those points seem to live in

Australia_Antarctica_Mesh_Topologies.gpml

As a test, I would just open that GPML and turn the MORs into gpml:UnclassifiedFeature

[jcannon-gplates]

Yeah it sounds like Sabin's comment (in email) about changing lines from MOR to something else is the way to go.

And his comment...

I remember having to fix this since 2019 in the trunk model. The only thing to watch out for is that there is a MOR made from points too, and those points need to remain MOR from about 90 to 83 Ma. Might be easier to change everything unclassified, and then manually change the handful of points needed for the MOR

...hopefully doesn't affect us, but I think it depends on the model (ie, how the topological plates/networks were created).

It might be that those points (he mentions) belong to topological lines (which would, in turn, have been added to topological plates/networks). If so, then as long as the topological lines are not labelled MOR then hopefully it should be OK - I think the points (that the topo lines reference, ie, join together into a line) don't need to be re-labelled. But if the points were directly added to the topological plates/networks (without an intermediate topological line) then it could still be an issue.

[michaelchin]

todo: plot velocities

[michaelchin]

@jcannon-gplates Do you still need me to plot the velocities on the ridges and transforms maps? DM told me that you are going to take care the ridges and transforms thing and asked me to switch to other tasks.

By the way, the code for plotting maps and creating videos is here.

[jcannon-gplates]

Do you still need me to plot the velocities on the ridges and transforms maps?

No thanks. I had thought there might be a bug in the current ridge-transform separation algorithm, but DM said that it's an "inconsistency between the way plate boundaries are drawn and labelled and their correspondence to associated plate velocities. These inconsistences are minimal for post 200 ma times, but increase back in time".

DM told me that you are going to take care the ridges and transforms thing and asked me to switch to other tasks.

Yes I'll start with that in pyGPlates (adding divergence/convergence along all plate boundaries) and then I'll return to use it in the ridge-transform separation in PTT.

The new approach will be better suited to deal with those model inconsistencies in deep time.