Currently Fastscapelib only provides two kinds of 2-d cartesian grids but those are not ideal for global (Earth or planetary) simulations. We could provide two additional grid (sub)classes for dealing with spherical coordinates: global_raster_gridglobal_trimesh, which would inherit directly from raster_grid and trimesh respectively. I think all it would need is each a specialized implementation for neighbors_distances_impl and nodes_areas_impl. Distances can be computed using the Haversine formula. Areas might be a little more complex to compute but maybe we could use an approximation (flat facets).
While it could be convenient, I'm not sure that a global_raster_grid with uniform spacing in latitude / longitude would be very useful for landscape evolution modeling, though. It would also need some additional validation checks or logic for boundary conditions (looped by default on the longitude) and for dealing with high-latitudes (poles), e.g., allow abs(latitude) < 90 degrees and add two pole nodes connected to all max(abs(latitude)) grid nodes.
Alternatively to subclasses, we could reuse the same classes with specialized factories (e.g., trimesh::from_latlon()).
Pros:
Keep the number of classes small (for the Python bindings, we need to register each grid type for the flow graph constructor, which is not ideal regarding compilation time, binary size, etc.)
Cons:
Messy internals, especially for raster grid (which probably require different container types for storing distances and/or areas with cartesian vs. spherical coordinates)
Less explicit (only the constructor vs. factory is explicit)
Currently Fastscapelib only provides two kinds of 2-d cartesian grids but those are not ideal for global (Earth or planetary) simulations. We could provide two additional grid (sub)classes for dealing with spherical coordinates:
global_raster_grid
global_trimesh
, which would inherit directly fromraster_grid
andtrimesh
respectively. I think all it would need is each a specialized implementation forneighbors_distances_impl
andnodes_areas_impl
. Distances can be computed using the Haversine formula. Areas might be a little more complex to compute but maybe we could use an approximation (flat facets).While it could be convenient, I'm not sure that a
global_raster_grid
with uniform spacing in latitude / longitude would be very useful for landscape evolution modeling, though. It would also need some additional validation checks or logic for boundary conditions (looped by default on the longitude) and for dealing with high-latitudes (poles), e.g., allow abs(latitude) < 90 degrees and add two pole nodes connected to all max(abs(latitude)) grid nodes.cc @hannahsophiadavies