Authors: Simon Williams1
1 EarthByte Research Group, School of Geosciences, University of Sydney, Australia
This tutorial is designed to describe the process of creating a plate model in GPlates. The model of Rodinia assembly and breakup presented by Li et al (2008) is used an example - you will learn how to build a rotation file from scratch, both from published poles of rotation values and by generating additional poles of rotation using the tools in GPlates. You'll also create a new set of plate polygons. The tutorial builds on skills described in many of the earlier tutorials, including those for 'Changing Rotations' and 'Creating Features'.
To download the files required for this tutorial, click here. In this bundle you should have:
Previous tutorials have described the rotation file. Here is a brief recap of how the rotation file is organized;
Column 1: “Moving” Plate ID e.g. 611
Column 2: Time e.g. 0.0 (Ma)
Columns 3, 4, 5: Rotation poles. The first two are the coordinates of the pole of rotation (latitude, longitude), the third is the angle of rotation.
Column 6: Conjugate or “fixed” Plate ID (Rotations relative to this plate)
Column 7: Abbreviation of Plate and Conjugate Plate and name
There are usually multiple entries for the same Plate ID, but with different times and rotation poles and, sometimes, different conjugate plates, to capture the rotation history of a give plate relative to neighboring, or conjugate plates.
For this exercise, we are going to build a completely new rotation file describing Rodinia assembly and dispersal, based on the poles of rotation given by Li et al (2008). Appendix 3 of this paper contains the poles of rotation for each cratonic block at a series of times between 1100Ma and 530Ma. Below is a screenshot of the first page in this document.
This table contains all the information we need to make reconstructions at each of the times given (and GPlates will interpolate the positions of each block for all the times in between). However, we need to modify and rearrange the data into a format that GPlates can understand. In rotation files, each plate has it's own unique integer ID number, and all the finite rotations for each plate are grouped together in chronological order (rather than grouping by age, as in the table shown above).
First, you can open the word document 'RodiniaRotationTable.doc' then cut and paste the contents of the table into a spreadsheet application (Excel, Numbers, Google Docs). Alternatively, you can load the file 'Rodinia_Tutorial_Rotation_Tables.xls' and look at the first sheet. Either way, you are now ready to carry out the steps listed below.
We need to perform the following operations:
1. Add a new column for the 'Time' of each rotation. Set this value to 1100 for the rows of finite rotations at 1100Ma, 1050 for the rows corresponding to 1050Ma, etc down to 530Ma at the bottom of the table.
2. Look at the part of the table that contains the rotations for 600Ma. You'll see that their are two sets of rotations for this time, reflecting two alternative reconstruction scenarios (the 'Low-Latitude Option' and 'High-Latitude Option', referring to different possible latitudes for Laurentia at this time). To compare these two models, we can make two rotation files containing the two alternative sets of 600Ma poles of rotation. For the moment, keep the 'High-Latitude Option' poles and delete the rows containing the 'Low-Latitude Option'.
3. Also Delete all the spare rows in the table without any rotations.
4. Sort the table based on the 'Name' column into alphabetical order, so that all the rotations for Amazonia are grouped together, followed by all the rotations for Australia, etc. (be sure to sort all columns, not just the column containing the names)
Illustration of steps 1-4: Load table into spreadsheet, remove unnecessary rows, sort all columns on the column containing the plate names.
5. Create a new column for the moving plate code for each rotation. You need to decide on an integer value to use as a unique ID for each plate. Any integer should work, but it is suggested that the numbers chosen follow some general conventions that have become established within the plate modelling community - plates that form part of present day North America begin with a 1, South America 2, Europe 3, Eastern Eurasia 4, India-Central Asia 5, East Asia 6, Africa 7, Australia-Antarctica 8, and Pacific 9. So in this case, we could give Amazonia the code 2201, the Sao Francisco craton 2202, and so on until each plate has its own unique ID number.
6. Once you've decided on the plate codes, make sure that each line in the 'Moving Plate' column contains the appropriate integer ID value.
7. You also need to add a column for the 'Fixed Plate'. For this particular model, all the rotations are given relative to the present-day location of the plate (rather than relative to another plate). In this case, we assign 0 to be the value in the Fixed Plate column.
8. For each plate, we need to add an entry that defines the pole of rotation for the present day (t=0). In each case, this row is just a series of zeros for the pole latitude, longitude and angle.
Illustration of steps 5-8: Insert unique integer plate codes for each plate, add a column for the 'fixed' plate containing all zeros, add in rotations for time=0.
The second sheet in the spreadsheet provided shows the results of the process outlined above
One final wrinkle with the Rodinia example is when plates have finite rotation poles greater than 180 degrees. If you simply use the rotations given in the Li et al table directly into GPlates, the reconstructions at the time prescribed in the table will look fine - however, the interpolated poles defining the positions of the plates between these times may give strange results. This is a problem that is more likely to occur in models going a long way back in time (e.g. this Rodinia model), since there is greater potential for blocks to have rotated large amounts relative to their original position. To avoid this problem, we can add 360 degrees to the rotation angle for each time where the rotation pole results in an unnecessarily circuitous path from one finite rotation pole time to the next. To see the effect of this process, look at the third sheet in the provided spreadsheet and compare it to the second one.
The table now contains all the information necessary for it to work in GPlates. The final step is to export the data into an ascii '*.rot' file, the standard format for rotation tables used in GPlates.
To export to .rot format, follow these steps:
1. Rearrange the columns so that they appear in the standard order; Moving Plate,Time,Pole Lat, Pole Lon, Pole Angle, Fixed Plate, Comment. The comment needs to be preceded by a exclamation mark (!), so we can insert a column of !'s before the plate name column to use these as the comments.
2. export to a tab delimited text file, give it the file extension *.rot so that GPlates will recognise it as a rotation table
(IMPORTANT NOTE: mac users may experience an issue where a rotation file that appears perfectly fine will not load properly into GPlates (no error message is returned, bit the rotation table is empty). A possible cause is that the rotation file has 'Mac OS style' line endings. Try opening the file in a text editor (e.g. textmate), go to 'Save As...' then specify Windows format line endings. The new file should load ok.
Illustration of the rotation table with the columns in the correct order to be exported to an ascii rotation table.
Now that we have a rotation model, we need to create some vector data sets that allow us to visualize the plate motions.
The file 'RodiniaBlocks.shp' is a shapefile containing the block outlines used to create the Geodynamic Map of Rodinia project (the shapefile is derived from a larger set of GIS data available online here: http://www.tsrc.uwa.edu.au/440project/rodiniamaps)
To get started with the Rodinia model, do the following;
1. Open GPlates
2. Load the rotation file you have created - go to 'File --> Open Feature Collection...' , then select the .rot file. Alternatively, if you don't want to go to the trouble of creating the rotation file yourself, you can use the already rotation file 'Rodinia_Tutorial_ExportFromExcelSheet3.rot'
3. Using the same file load dialogue, also load the shape file 'RodiniaBlocks.shp'.
In the 'rectangular' projection, the data should look like this;
The Rodinia model contains rotation poles for time between 1100 Ma and 530 Ma. Change the reconstruction time to one of these times by typing it into the 'Time' panel in the top left of the GPlates window.
Notice that nothing appears to have happened.
This is because the polygon do not have plate codes assigned. (Note that by default, the plates are displayed with colours matched to Plate ID. At the moments all the plates have an ID of zero, hence they are all yellow. If you look at the table of reconstruction poles ('Reconstruction --> View Total Reconstruction Poles...') you will see that the rotation table os populated with values for each plate as defined by the .rot file. Since the polygons in the shapefile don't have the corresponding Plate IDs defined, GPlates doesn't know where to move each one.
So we need to define the Plate ID for each polygon:
1. Select the ‘Choose Feature’ icon from the Tool Palette
2. Click on one of the plates.
3. Click on the ‘Edit Feature’ icon in the Current Feature Panel to the right of the main view.
4. Select the gpml:reconstructionPlateId property, then in the dialogue box at the bottom of the panel, enter the value of the Plate ID for the plate that you selected. For example, below the 'West Africa' plate is selected. We assigned this plate to have an ID of 7703, so we assign the same value to the polygon.
5. Close the Feature Properties dialogue box. You'll see that the polygon for which you just assigned a plate ID has now moved to its reconstructed position at the current reconstruction time.
6. Repeat this process for some of the other plates, assigning the appropriate plate ID for each one.
At this point, it is worth noting a few things:
i. the polygons you have edited have moved (based on the values in the rotation table) and changed colour (becuase by default the polygons are coloured by Plate ID - in the beginning all the Plate IDs were zero, hence all the polygons were yellow).
ii. a red disk icon had appeared in the bottom right of the main GPlates window. This indicates that changes have been made to features in GPlates, but that these changes have not been saved. To save changes at any point, go the 'Manage Feature Collections' dialogue (File --> Manage Feature Collections...'). Features with unsaved modifications are highlighted in red.
Illustration of Rodinia model after three of the polygons (West Africa, Australia and Laurentia) have been assigned Plate IDs. The modified plate polygons have changed colour and moved to the correct location at 530 Ma. The red icon in the lower left corner indicates that features have unsaved changes.
Now, continue assigning Plate IDs until all the plates for which there are rotations in the rotation table created earlier. Once this process is completed, the reconstruction for 530 Ma should look like this:
At this point, we have defined the Rodinia reconstruction model to the full extent allowed by the data provided by Li et al (2008).
You'll notice that, following the process above, there are two blocks that haven't moved - the Hoggar and Sahara Blocks. These weren't listed in the table of rotations of Li et al (2008). So, we need to come up with an alternative method to derive poles of rotation for these blocks. To help in this process, we can look at figures and animations that show the location of these blocks within reconstruction for certain times. For example, in the figure below from Li et al (2008) we can see the approximate location of Sahara, as well as Arabia and Nubia (for which you haven't been provided block outlines).
Rodinia reconstruction at 780 Ma, from Li et al (2008).
GPlates tutorial #6 includes in introduction to the concept of the reverse engineering plate reconstructions from images in papers. You can use this approach to extend the Rodinia model by defining rotations for the Hoggar and Sahara Blocks. You can also define extra blocks by digitizing new geometries, and define rotations for these blocks as well.
The directory "Tutorial13_CompletedRodiniaModel" in the data bundle contains a completed version of the Rodinia model following the steps outlined above. So if you want to skip carrying out all the steps described above, simply unload all the existing data from GPlates, then load in the shapefiles and rotation file in the directory.
The file 'Rodinia_Tutorial_CompleteRotationFile.rot' contains a completed rotation table (with rotations included for Sahara and Hoggar).
The file 'RodiniaBlocks_WithPlateIDColumnAndIDs.shp' contains the cratonic block polygons with all plate codes assigned to match the rotation table.
The Rodinia reconstruction model give us an opportunity to reconstruct data back to 1100 Ma, much further back in time than many other global plate models. A few sample data sets have been provided - these are:
Load each of these datasets into GPlates and try reconstructing them using the Rodinia model, as illustrated below.
Z.X. Li, S.V. Bogdanova, A.S. Collins, A. Davidson, B. De Waele, R.E. Ernst, I.C.W. Fitzsimons, R.A. Fuck, D.P. Gladkochub, J. Jacobs, K.E. Karlstrom, S. Lu, L.M. Natapov, V. Pease, S.A. Pisarevsky, K. Thrane, V. Vernikovsky, Assembly, configuration, and break-up history of Rodinia: A synthesis, Precambrian Research, Volume 160, Issues 1-2, Testing the Rodinia Hypothesis: Records in its Building Blocks, 5 January 2008, Pages 179-210, ISSN 0301-9268, DOI: 10.1016/j.precamres.2007.04.021.