GPlates
Age/spreading grids parameterised by topologies/isochrons and reference frame
In yesterday's meeting Dietmar mentioned ultimately having different sets of age grids (in PlateModelManager) based on:
-
Whether generated from topologies and/or isochrons. So there would be 3 combinations:
- topologies-only (eg, 410-0 Ma),
- isochrons-only (eg, 250-0 Ma) and
- a topologies-isochrons mixture (eg, topologies 410-250 and isochrons 250-0).
With, I think, the default being isochrons only - but I'm not sure - it might have been topologies-isochrons mixture.
-
Reference frame used to generate: with choices being PMAG and mantle (optimised absolute plate motion) where, since PMAG will be the default reference frame (000) for all models going foward, PMAG would be the default here too.
Currently you have PlateModel.get_raster(raster_name, time). One option is to add the above two categories as two extra parameters. But, then again, they only really apply to "age grid" rasters, not other types of rasters. In which case you could have another method, such as PlateModel.get_age_grid_raster(time, generated_from=<isochrons-only>, reference_frame=<PMAG>), that has the two parameters (the first being an enumeration, and maybe the second also an enum) with the appropriate defaults.
Anyway, that's just an idea. You may prefer to just encode all this in the raster_name argument of the existing PlateModel.get_raster. Ie, in addition to your existing "AgeGrids" parameter (which could now be the default age grid raster) you could have something like "AgeGrids-IsochronsOnly-PMAG", etc. Or can have that in addition to PlateModel.get_age_grid_raster(time, generated_from=<isochrons-only>, reference_frame=<PMAG>) - which would require a code level change to PlateModelManager - but I think it'd be worth it.
Including this email from today (for reference)...
From recent discussions, I guess Zahirovic2022 will become the default plate model - in the GPlates Web Service and GPlately/PlateModelManager (and in pyBacktrack).
We also talked about making PMAG the default reference frame going forward. However, for Z22, the default is mantle (with PMAG being 701701). Just mentioning because whatever default we use for a particular model might not always be plate 000. So GPlately/PlateModelManager may need to hardcode the default reference frame for each plate model. Going forward, I think we decided all future plate models will default to PMAG. But I guess, for existing models, some will default to mantle and others to PMAG.
That brings up the issue of naming the plate models. Michael recently pointed out that there are multiple versions of the Matthews2016 plate model. Looking here I see “Matthews2016” and “Matthews2016_pmag_ref”, which I assume are mantle and pmag respectively.
Another option is to just have one model name, which is “Matthews2016”, but be able to specify the reference frame as a parameter when retrieving it. For this model, the default reference frame would presumably be mantle. For example, instead of specifying…
gplately.DataServer("Matthews2016"), and gplately.DataServer("Matthews2016_pmag_ref")…you could specify…
gplately.DataServer("Matthews2016", gplately.MantleReferenceFrame), and gplately.DataServer("Matthews2016", gplately.PmagReferenceFrame)…and if you only specify
gplately.DataServer("Matthews2016")then you’ll get mantle by default. Also this way we can later tack on extra default parameters - such as the default age/spreading grids for the model.As you mentioned Michael, you may prefer to keep the existing naming scheme for PlateModelManager. However the above approach can be useful for configuring multiple orthogonal defaults (ie, user can choose which, of several, defaults to override).
Which brings up the question of whether we plan to ultimately deprecate gplately.DataServer (in favour of PlateModelManager). They essentially do the same thing (as far as I see) but have slightly different APIs. Just wondering, because under Common Use Cases for gplately.DataServer it does encourage users to use the newer PlateModelManager.
Finally, I’ll just mention that there can be backward compatibility issues when we change the defaults. In other words, users relying on the default behaviour can get unexpected results when upgrading our software (if the defaults have changed). Just something to be mindful of, I guess.
Which brings up the question of whether we plan to ultimately deprecate gplately.DataServer (in favour of PlateModelManager).
Recently, I realised that the DataServer may be quite useful. I think we should keep gplately.DataServer so that some high level optimisation can be done in the DataServer class.
