[GPlates-discuss] Crustal stretching factor values

[John Cannon]

Hi Thomas,

Regarding point (1), it is possible for strain to accumulate quickly in certain locations within the deforming regions. For example, some triangles in a network triangulation can have excessively high strain rates (depending on the specific deforming network). This can be mitigated somewhat by enabling strain rate clamping. It looks like the dataset referenced by the paper has clamping enabled for the project without crustal thinning grids (“Muller_etal_2019.gproj”) but disabled for crustal thinning grids (“Muller_etal_2019_7_Point_Density_Project_File.gproj”). If I enable clamping in the latter project, in all the brown (topological network) layers, then the maximum stretching factor reduces from about 300 to 160.  And as it turns out, this also helps a lot with the negative stretching factors in point (2).

https://protect-au.mimecast.com/s/Xa4HCD1jy9tkOKGGFWxAfd?domain=earthbyte.org


Regarding point (2)…

Yes theoretically it should not be possible to get negative stretching factors. However it seems in practice that numerical solutions using finite time steps can cause this. The differential equation for crustal thickness is “DH/Dt = -H * SR” where H is thickness and SR is strain (dilatation) rate. So when the dilatation rate is positive (ie, extension) the thickness decreases exponentially – which means it should decay towards zero but never cross zero (to become negative). However with a finite time interval the simplest integration is “(H1 - H0) / delta_T = – H0 * SR” or “H1 = H0 * (1 - SR * delta_T)”. So H1 can be negative if “SR * delta_T” is greater than 1.0. GPlates integrates using Runge-Kutta order 2 (with a time interval of 1My), but updating that to order 4 didn’t make it that much better (just tried that now). I think the time interval (1My) is a little too large for the strain rates we can encounter – need to reduce “SR * delta_T” – I’ll look into that (maybe an adaptive time interval).  Alternatively there’s strain rate clamping - another way to reduce “SR * delta_T” which is why it seemed to work so well as mentioned above.

As you noted it doesn’t happen much at all (which is probably why we didn’t notice it). Just looking into it now I noticed it happens when a deforming network ends and is replaced by an ‘inactive’ version (in the “Inactive_Deforming_Meshes” layer). The term ‘inactive’ I think just means that although there’s still an ‘active’ topological network there is no deformation taking place within it (because it’s been built to remain rigid). Although it seems deformation is taking place in some cases (eg, ‘LHR_Topo’ becomes ‘inactive’ at 58Ma but has high deformation for some times during 58-41Ma) and high enough to trigger this problem (“SR * delta_T” is greater than 1.0). Disabling that layer (as opposed to just making the layer invisible) does help noticeably. But it happens in other layers too. However what really helps a lot is enabling strain rate clamping (mentioned above).  But I’ll look further into the integration.

Regards,
John


From: GPlates-discuss <gplates-discuss-bounces at mailman.sydney.edu.au> On Behalf Of Linden, T.J.M. van der (Thomas)
Sent: Wednesday, 9 October 2019 6:21 PM
To: gplates-discuss at mailman.sydney.edu.au
Subject: [GPlates-discuss] Crustal stretching factor values

Hi all,

From the data provided with the Müller Tectonics June 2019 article I exported the CrustalStretchingFactors to further process.

The data contains values that go beyond my expectations. For instance at 10Ma the minimum is -99 and the maximum 235.
From the article I understand for β values greater than 1 represent extensional regions and values between 0 and 1 represent compressional regions.

There are 12 values below 0 and 16 above 10, which I realise is only a very small fraction of the 64001 points.

But two questions that remain:

  1.  Would it be safe to say the (very) high values are artefacts? For instance of the drawing of the topologies
  2.  How can values below 0 be explained? These seem fundamentally impossible.

Best from Berlin,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.sydney.edu.au/pipermail/gplates-discuss/attachments/20191009/6499a551/attachment-0001.html>