Alternative workflow for _isochron-based_ age gridding.

[jcannon-gplates]

Dietmar has requested that:

the isochron age gridding workflow should be made publicly available and integrated into GPlately as an alternative for age gridding

Some more details:

This involves also making the input data for this workflow available. I think the current situation with having only one of the workflows, namely topology-based agegridding publicly available and integrated in GPlately, is not particularly conducive for enabling a kind of synchronization between the workflows , if we want to call it that_

I believe that we only need to make one set of age grid input files for isochron-based gridding available at this point, because the recently published models for which users may want to use isochrons-based age gridding use the same isochrons and age gridding input files, ie Muller2019, Cao2022, Zahirovic2022.

The files can be found here:

https://github.sydney.edu.au/EarthByte/EarthBytePlateMotionModel-ARCHIVE/tree/master/Zahirovic_etal_2022_GDJ/StaticGeometries/AgeGridInput

They should be integrated into a GPlately workflow for isochron-based age gridding, with the proviso that they should only be used with the three models above, because older models would require different isochron files and likely some different associated orations, and some other recently published models like Clennett2020 and Alfonso2024 are not suitable for isochrons-based age gridding because they include back-arc basins along western North America for which no isochrons have been constructed.

Nicky added:

there is also a batching script associated with it (so we can run it on multiple processors).

FYI, here is the publicly available version with Maria’s present-day age grid paper: https://github.com/EarthByte/presentday-agegridding/blob/master/compute_agegrid.sh (and this repository). Very brief look is that Sabin has made edits since.

[michaelchin]

Some notes for myself lest I forget.

• https://github.com/EarthByte/presentday-agegridding/blob/master/compute_agegrid.sh 5-year-old. although this one is older, it is cleaner.
• https://github.sydney.edu.au/EarthByte/EarthByteWorkflows/blob/master/PaleoAgeGrids/compute_agegrid.sh 4-year-old. but use Stripy instead of gmt sphinterpolate. we don't want to reintroduce Stripy back into GPlately if possible.
• https://github.sydney.edu.au/EarthByte/EByteDeformingModels-SVN-archive/blob/master/02_Workflows/02_PaleoAgeGrids/compute_agegrid.sh 5-year-old

It seems almost everything is in isopolate.py. The shell script is only used to prepare input files and calls GMT to interpolate and create NetCDF file. So, it shouldn't be too hard to integrate the workflow into GPlately.

[jcannon-gplates]

I’m currently making a lot of changes to the regular topology-based seafloor gridding on a few different branches. But I don’t think that’ll interfere with your isochron-based workflow. By the way, one of my branches can't be merged until there's a bug-fix release for pyGPlates (so it might be a little while before I can merge all this work into the main branch).

The topology-based workflow is using the SeafloorGrid class. I guess the isochron-based workflow could be a separate class. So we could have something like a TopologySeafloorGrid class (ultimately renamed from the existing SeafloorGrid class) and a IsochronSeafloorGrid class. It’s probably best not to merge them into the same class, at least initially (or ever). Maybe down the road there could be a workflow that combines topology and isochron-based grids - but I'm guessing it'd be fairly simple, like isochron-based for 0-250 Ma and topology-based prior to 250 Ma as mentioned in #360 - in which case having separate classes still works fine there.

And both classes could have a single generate function (so the existing SeafloorGrid.reconstruct_by_topologies would ultimately be renamed to TopologySeafloorGrid.generate). That way the user can construct either workflow from a class and then just call generate on it. There would also be lat_lon_z_to_netCDF to write out the age grid and spreading rate grids. All other functions would be private (in my branches I've made them private because generate and lat_lon_z_to_netCDF are really the only two methods the user should call).

[michaelchin]

I’m currently making a lot of changes to the regular topology-based seafloor gridding on a few different branches. But I don’t think that’ll interfere with your isochron-based workflow. By the way, one of my branches can't be merged until there's a bug-fix release for pyGPlates (so it might be a little while before I can merge all this work into the main branch).

The topology-based workflow is using the SeafloorGrid class. I guess the isochron-based workflow could be a separate class. So we could have something like a TopologySeafloorGrid class (ultimately renamed from the existing SeafloorGrid class) and a IsochronSeafloorGrid class. It’s probably best not to merge them into the same class, at least initially (or ever). Maybe down the road there could be a workflow that combines topology and isochron-based grids - but I'm guessing it'd be fairly simple, like isochron-based for 0-250 Ma and topology-based prior to 250 Ma as mentioned in #360 - in which case having separate classes still works fine there.

And both classes could have a single generate function (so the existing SeafloorGrid.reconstruct_by_topologies would ultimately be renamed to TopologySeafloorGrid.generate). That way the user can construct either workflow from a class and then just call generate on it. There would also be lat_lon_z_to_netCDF to write out the age grid and spreading rate grids. All other functions would be private (in my branches I've made them private because generate and lat_lon_z_to_netCDF are really the only two methods the user should call).

Noted with thanks. No problem. All good.