[GPlates-discuss] Linking two or more rotation files

Fri Jun 9 21:31:05 AEST 2017

Thanks for your feedback on this. Yeah it's a bit tricky with the overlaps and what to do there. I'll chat with some users at my end about this potential way forward, which is:

1) give user the option to prioritize rotation files (in a rotation layer) where only the highest priority rotation sequence per plate pair is used, and
2) users need to make sure that there are no internal rotation file conflicts (otherwise behaviour is undefined).

Regards,
John

________________________________________
From: gplates-discuss-bounces at mailman.sydney.edu.au [gplates-discuss-bounces at mailman.sydney.edu.au] on behalf of Christian.Heine at shell.com [Christian.Heine at shell.com]
Sent: Friday, 9 June 2017 9:06 PM
To: gplates-discuss at mailman.sydney.edu.au
Subject: Re: [GPlates-discuss] Linking two or more rotation files

> > Only the first rotation encountered is used - the second, third, etc,
> are simply rejected. This applies regardless of whether the stage
> rotations are different or not.
>
> ...I should clarify the current behaviour as the first rotation
> encountered *at the reconstruction time*. For example, if the first
> 926/901 rotation (sequence) covers the time period 60-190Ma and the second
> covers 50-200Ma, then the first rotation is used for times in the range
> 60-190Ma and the second is used for times in the ranges 50-60Ma and 190-
> 200Ma (ie, periods exclusive to the second rotation).

Ok, this helps a lot.

> This may not be what we want if we implement a priority system.  In other
> words, perhaps the priority system should discard an entire rotation
> sequence. For example, if the first 926/901 rotation (covering 60-190Ma)
> is the highest priority then the second 926/901 rotation (covering 50-
> 200Ma) is completely discarded. The result would be no 926/901 rotation
> outside 60-190Ma.

This could easily get out of control if you have even more rotations for the same plate pair across files so I think one needs to draw a line along what you suggest - ie limiting the merge to rotation sequences (for now). It might then also be easier to fix gaps/overlaps in the rotation sequences.

Cheers,
Christian

> ________________________________________
> From: gplates-discuss-bounces at mailman.sydney.edu.au [gplates-discuss-
> bounces at mailman.sydney.edu.au] on behalf of John Cannon
> [john.cannon at sydney.edu.au]
> Sent: Friday, 9 June 2017 7:51 PM
> To: GPlates general discussion mailing list
> Subject: Re: [GPlates-discuss] Linking two or more rotation files
>
> > tool or option in GPlates to "prioritize" rotation (files/input) based
> > on some notion
>
> If it's useful there could be a dialog in the rotation layer enabling
> users to sort/prioritise rotation *files*. This would prioritise
> conflicting rotations (eg, two rotations for the 926/901 plate pair) where
> the first rotation is in one file and the second in another file - then
> only the rotation in the highest priority file would get used (the other
> rotation would be discarded).
>
> This would not resolve a conflict *within* a single file though (eg, if
> both 926/901 rotations were in the same file) but this scenario is
> probably much less common.
>
>
> > Could you clarify what happens when rotation feature layers are merged
> that contain duplicate rotations pairs and what happens when there's a
> duplicate plate pair but different stage rotations?
>
> Only the first rotation encountered is used - the second, third, etc, are
> simply rejected. This applies regardless of whether the stage rotations
> are different or not.
>
> Currently the order in which rotations are applied is essentially
> undefined. However, as mentioned above, we could define an order *across*
> files (but not *within* files).
>
> Regards,
> John
>
> ________________________________________
> From: gplates-discuss-bounces at mailman.sydney.edu.au [gplates-discuss-
> bounces at mailman.sydney.edu.au] on behalf of Christian.Heine at shell.com
> [Christian.Heine at shell.com]
> Sent: Friday, 9 June 2017 5:30 PM
> To: gplates-discuss at mailman.sydney.edu.au
> Subject: Re: [GPlates-discuss] Linking two or more rotation files
>
> John, Sabin
>
> thanks for the response & clarification.
>
> > The intent is that there is no priority applied when multiple
> > rotations with the same moving/fixed plate pair are found (at a
> > particular reconstruction time). This is because GPlates relies on the
> > user to ensure their rotation data contains no conflicts.
>
> Never overestimate your users ;-) ;-)
>
> Jokes aside, I think it would be a useful feature, maybe not by default
> but rather as tool or option in GPlates to "prioritize" rotation
> (files/input) based on some notion. One argument would be that there's the
> possibility to use more than a single rotation file and some users might
> have the need to branch off some dangling nodes of rotation trees and
> replace existing rotations in a global file with custom ones.
>
> > Having said that, you might notice an ordering (or priority), such as
> > the first of two rotation files having precedence (or the first of two
> > moving/fixed pairs within a single rotation file), but it is not
> > intentional and therefore cannot be relied upon to remain this way in
> > future versions of the software.
>
> Ok, that's what I saw in some tests here. I haven't tried more than two
> stage rotations for a single plate pair.
>
> Could you clarify what happens when rotation feature layers are merged
> that contain duplicate rotations pairs and what happens when there's a
> duplicate plate pair but different stage rotations?
>
> Cheers,
> Christian
>
>
>
> > ________________________________________
> > From: gplates-discuss-bounces at mailman.sydney.edu.au [gplates-discuss-
> > bounces at mailman.sydney.edu.au] on behalf of Sabin Zahirovic
> > [sabin.zahirovic at sydney.edu.au]
> > Sent: Friday, 9 June 2017 9:15 AM
> > To: GPlates general discussion mailing list
> > Subject: Re: [GPlates-discuss] Linking two or more rotation files
> >
> > Hi Christian,
> >
> > Hmm good question! I was under the impression that there was no
> > priority applied, that it was as if you were concatenating the
> > rotation files into one. That means it can be easy to have conflicts
> > if you have multiple entries for the same plate id and time. Perhaps
> > John can clarify, as my description is solely based on my experiences
> with it.
> >
> > Cheers,
> > Sabin
> >
> >
> > On 9/6/17, 1:23 am, "gplates-discuss-bounces at mailman.sydney.edu.au on
> > behalf of Christian.Heine at shell.com" <gplates-discuss-
> > bounces at mailman.sydney.edu.au on behalf of Christian.Heine at shell.com>
> > wrote:
> >
> >     Hi list,
> >
> >     I have a quick question regarding the connecting/linking/merging
> > of two or more rotation files. Am I right to assume that the
> > hierarchy/priority used when multiple rotation sequences for the same
> > plate id exist are the order the rotation layers are connected (ie
> > default rotation feature layer, then 2nd connection, then 3rd...)?
> >
> >     Cheers,
> >     Christian
> >
> >
> >
> >
> >     _______________________________________________
> >     GPlates-discuss mailing list
> >     GPlates-discuss at mailman.sydney.edu.au
> >
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.
> > sydney.edu.au%2Fmailman%2Flistinfo%2Fgplates-
> > discuss&data=01%7C01%7Cchristian.heine%40shell.com%7C7c7ca9a10fc84e2f6
> > 9730
> > 8d4aef0e852%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0&sdata=nP12IWNHNn7Pa
> > %2Bt
> > n1LdYl0dqvpmnrIozh151T%2BycbcI%3D&reserved=0
> >
> >
> >
> > _______________________________________________
> > GPlates-discuss mailing list
> > GPlates-discuss at mailman.sydney.edu.au
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.
> > sydney.edu.au%2Fmailman%2Flistinfo%2Fgplates-
> > discuss&data=01%7C01%7Cchristian.heine%40shell.com%7C7c7ca9a10fc84e2f6
> > 9730
> > 8d4aef0e852%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0&sdata=nP12IWNHNn7Pa
> > %2Bt
> > n1LdYl0dqvpmnrIozh151T%2BycbcI%3D&reserved=0
> >
> >
> >
> > _______________________________________________
> > GPlates-discuss mailing list
> > GPlates-discuss at mailman.sydney.edu.au
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.
> > sydney.edu.au%2Fmailman%2Flistinfo%2Fgplates-
> > discuss&data=01%7C01%7Cchristian.heine%40shell.com%7C7c7ca9a10fc84e2f6
> > 9730
> > 8d4aef0e852%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0&sdata=nP12IWNHNn7Pa
> > %2Bt
> > n1LdYl0dqvpmnrIozh151T%2BycbcI%3D&reserved=0
>
> _______________________________________________
> GPlates-discuss mailing list
> GPlates-discuss at mailman.sydney.edu.au
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.
> sydney.edu.au%2Fmailman%2Flistinfo%2Fgplates-
> discuss&data=01%7C01%7Cchristian.heine%40shell.com%7C87b0720170224793bf410
> 8d4af265c9c%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0&sdata=4n9TRwcrjPl327VfK
> l%2BY8Hp1jngQAhoqt43YS3FDgPg%3D&reserved=0
>
>
>
> _______________________________________________
> GPlates-discuss mailing list
> GPlates-discuss at mailman.sydney.edu.au
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.
> sydney.edu.au%2Fmailman%2Flistinfo%2Fgplates-
> discuss&data=01%7C01%7Cchristian.heine%40shell.com%7C87b0720170224793bf410
> 8d4af265c9c%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0&sdata=4n9TRwcrjPl327VfK
> l%2BY8Hp1jngQAhoqt43YS3FDgPg%3D&reserved=0
>
>
>
> _______________________________________________
> GPlates-discuss mailing list
> GPlates-discuss at mailman.sydney.edu.au
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailman.
> sydney.edu.au%2Fmailman%2Flistinfo%2Fgplates-
> discuss&data=01%7C01%7Cchristian.heine%40shell.com%7C87b0720170224793bf410
> 8d4af265c9c%7Cdb1e96a8a3da442a930b235cac24cd5c%7C0&sdata=4n9TRwcrjPl327VfK
> l%2BY8Hp1jngQAhoqt43YS3FDgPg%3D&reserved=0

_______________________________________________
GPlates-discuss mailing list
GPlates-discuss at mailman.sydney.edu.au
http://mailman.sydney.edu.au/mailman/listinfo/gplates-discuss