Basic Model Interface (BMI) specification for the
Julia programming language. This package contains all 41 functions
that are part of the BMI 2.0 specification. These functions are declared without any
methods, like so:
function initialize end. They do have documentation that shows how they
should be used.
It is up to model specific implementations to extend the functions defined here, adding methods for their own model type, such as:
const BMI = BasicModelInterface
# any type you created to represent your model
struct MyModel end
# write MyModel update implementation here
This package is not yet registered, and is currently being developed independently of Community Surface Dynamics Modeling System(CSDMS). After it has been proven successful with several Julia BMI implementations, we should consider proposing CSDMS adoption as well, to join the existing C, C++, Fortran and Python specifications.
Table below taken from https://bmi.readthedocs.io/en/latest/#the-basic-model-interface.
|Perform startup tasks for the model.
|Advance model state by one time step.
|Advance model state until the given time.
|Perform tear-down tasks for the model.
|Name of the model.
|Count of a model's input variables.
|Count of a model's output variables.
|List of a model's input variables.
|List of a model's output variables.
|Get the grid identifier for a variable.
|Get the data type of a variable.
|Get the units of a variable.
|Get the size (in bytes) of one element of a variable.
|Get the total size (in bytes) of a variable.
|Get the grid element type of a variable.
|Current time of the model.
|Start time of the model.
|End time of the model.
|Time units used in the model.
|Time step used in the model.
|Get a copy of values of a given variable.
|Get a reference to the values of a given variable.
|Get variable values at specific locations.
|Set the values of a given variable.
|Set the values of a variable at specific locations.
|Get the number of dimensions of a computational grid.
|Get the total number of elements of a computational grid.
|Get the grid type as a string.
|Get the dimensions of a computational grid.
|Get the spacing between grid nodes.
|Get the origin of a grid.
|Get the locations of a grid's nodes in dimension 1.
|Get the locations of a grid's nodes in dimension 2.
|Get the locations of a grid's nodes in dimension 3.
|Get the number of nodes in the grid.
|Get the number of edges in the grid.
|Get the number of faces in the grid.
|Get the edge-node connectivity.
|Get the face-edge connectivity.
|Get the face-node connectivity.
|Get the number of nodes for each face.
This specification is adopted from the BMI 2.0 Python specification.
Instead of Python's class methods, the Julia specification expects a
as the first argument. Julia will dispatch to the right implementation based on the type
We do not apply the Julia convention to put a ! after mutating function names, to keep the function names consistent with the other languages.
- Time must be a float.
- Grid is an integer grid identifier.
- Units should be string.
See if we can instead use richer types that keep more information,
yet still convert to the right
get_grid_shape: Instead of passing in a
Vector to fill, do not require a shape argument,
and return a
Tuple, like the
Constructs and features that are natural for the language should be used when implementing a BMI. BMI strives to be developer-friendly.
BMI functions always use flattened, one-dimensional arrays. This avoids any issues stemming from row/column-major indexing when coupling models written in different languages. It’s the developer's responsibility to ensure that array information is flattened/redimensionalized in the correct order.
From the above and the get_grid_shape docs it is not quite clear yet what the correct order is. Flattening a row-array and a column-major array will result in the same size but different order array.
“ij” indexing (as opposed to “xy”)
i here stand for the first dimension, regardless of row/column-major indexing?
the length of the z-dimension, nz, would be listed first.
If the z-dimension needs to go first, that means different z at the same xy location will be close in memory for column-major, and far in memory for row-major.