Mark Piper

This might also be a good time to move x -> x1 y -> x2 z -> x3 which might allow easier generalization to other coordinate systems (natural, spherical, etc.).

As part of adding geospatial capabilities to BMI, it's suggested in #11 and #80 that BMI have a function (or functions) to do this. While this is needed for a...

Suggested function prototypes, in SIDL, are here: https://github.com/csdms/bmi/issues/80#issuecomment-801471477.

For Option 2, requiring the _dim_ argument could simplify the call by making the _units_ argument a string instead of a string array: ```java int get_grid_units(in int grid, in int...

Further, we could introduce another new function to get the names of the grid dimensions: ```java int get_grid_dimension_names(in int grid, out array names); ``` It could return ["x", "y", "z"]...

> If we go with option 2, we may want to think about adding a _get_grid_node_coordinates_ (to replace _get_grid_[xyz]_) function. > > ```java > int get_grid_node_coordinates(in int grid, in int...

Hey @kettner -- time is handled separately in the BMI through a set of time functions. We do need to represent grids of rank > 3, though; I'm making a...

Talking with @mcflugen, this is really an implementation detail. We can handle this with the existing *get_var_units* function.

The C, C++, Fortran, and Python examples are now built for tests of the [babelizer](https://github.com/csdms/babelizer).

Link to #11, which has a similar request.