CSDMS Basic Modeling Interface (version 1.0)

  • In order to simplify conversion of an existing model to a reusable, plug-and-play model component, CSDMS has developed a simple interface called the Basic Model Interface or BMI that model developers are asked to implement. Recall that in this context an interface is a named set of functions with prescribed function names, argument types and return types.
  • By design, the BMI functions are straightforward to implement in any of the languages supported by CSDMS, which include C, C++, Fortran (all years), Java and Python. Even though some of these languages are object-oriented and support user-defined types, the BMI functions use only simple (universal) data types.
  • Also by design, the BMI functions are noninvasive. A BMI-compliant model does not make any calls to CSDMS components or tools and is not modified to use CSDMS data structures. BMI therefore introduces no dependencies into a model and the model can still be used in a "stand-alone" manner.
  • Any model that provides the BMI functions can be easily be converted to a CSDMS plug-and-play component that has a CSDMS Component Model Interface or CMI. This conversion/wrapping process is done by CSDMS staff. The BMI functions are called by the CMI, by the framework and by service components. It is not necessary for a developer to learn anything about the CMI unless they're just curious.
  • Any model that provides the BMI functions should also be straightforward to ingest as a component into other component-based modeling frameworks. For example, all model coupling frameworks use Model Control Functions very similar to those described below, so providing them helps get a model ready for plug-and-play.
  • Once a BMI-compliant model has been wrapped by CSDMS staff to become a CSDMS component, it automatically gains many new capabilities. This includes the ability to be coupled to other models even if their (1) programming language, (2) variable names, (3) variable units, (4) time-stepping scheme or (5) computational grid is different. It also gains (1) the ability to write output variables to standardized NetCDF files, (2) a "tabbed-dialog" graphical user interface (GUI) (this requires a corresponding XML file) (3) a standardized HTML help page and (4) the ability to run within the CSDMS Modeling Tool (CMT). Examples of (1) a GUI XML file, (2) a standardized HTML help page and (3) a Model Metadata File will be provided soon.
  • The CMI wrapping does not have a significant impact on performance. This is due to the use of Babel for language interoperability and the fact that CSDMS components pass values by reference instead of by copy whenever possible.

Model Control Functions

void initialize (in string config_file) 
void update (in double dt) //  Advance model variables by time interval, dt (dt=-1 means use model time step)
void finalize () 
void run_model (in string config_file) //  Do a complete model run. Not needed for CMI.
  • These BMI functions are critical to plug-and-play modeling because they allow a calling component to bypass a model's own time loop. They also provide the caller with fine-grained control over the model, similar to a TV remote control.
  • The initialize() function accepts a string argument that gives the name (and path) of its "main input file", called a configuration file. This function should perform all tasks that are to take place before entering the model's time loop.
  • The update() function accepts a time step argument, "dt". If (dt == -1), then the model should use its own (internal) timestep; otherwise it should use the value provided. This function should perform all tasks that take place during one pass through the model's time loop. It does not contain the time loop. This typically includes incrementing all of the model's state variables.
  • The finalize() function should perform all tasks that take place after exiting the model's time loop. This typically includes deallocating memory, closing files and printing reports.
  • The run_model() function is not needed by CSDMS but provides a simple method to run the model in "stand-alone mode". (It is often used by the developer; basically the model's "main".) It would simply call "initialize()", start a time loop that only calls "update()" and then calls "finalize()".

Model Information Functions

array<string> get_input_var_names()
array<string> get_output_var_names()
string get_attribute( in string att_name ) // (for model_name, mesh_type, time_step_type, etc.)
  • These BMI functions are called by the CSDMS framework in order to determine what input variables each model component needs and what output variables it can provide to other components.
  • Note that "long variable name" and "long_var_name" refer to standardized variable names from the CSDMS Standard Names. The use of these names makes it possible for the framework to automatically connect "user components" to "provider components" without user intervention. The framework can also use metadata associated with the "long variable name" (stored in a Model Metadata File) to determine the degree to which the variable from the provider matches the needs of the user.
  • The get_input_var_names() function returns a string array of the model's input variable names as "long variable names".
  • The get_output_var_names() function returns a string array of the models output variable names.
  • The get_attribute() function returns static attributes of the model when passed an attribute name from the following list:
numerical_method   (explicit or implicit)
For the "mesh_type" attribute, the allowed return values are:
uniform, rectilinear, s_mesh and u_mesh
as described in the section called Grid Information Functions below. For the "time_step_type" attribute, the allowed return values are:
fixed       (Timestep size is fixed for all time and is used by all grid cells.)
adaptive    (Timestep varies in time, but is used by all grid cells.)
des         (Timestep size varies in both space and time.  See below.)
Note that DES (Discrete Event Simulation) models allow each grid cell to have its own, adaptive time step.

Variable Information Functions

string get_var_type( in string long_var_name ) // ( returns type_string, e.g. ‘double’)
string get_var_units( in string long_var_name ) // ( returns unit_string, e.g. ‘meters’ )
int get_var_rank( in string long_var_name ) // ( returns array rank or 0 for scalar)
string get_var_name( in string long_var_name ) // ( returns model’s internal, short name )
double get_time_step() // (returns the model’s current timestep;  adaptive or fixed.)
string get_time_units() // (returns unit string for model time, e.g. ‘seconds’, ‘years’)
double get_start_time()
double get_current_time()
double get_end_time()
  • These BMI functions are called by the CSDMS framework to obtain information about a particular input or output variable. Based on this information, the framework can apply type or unit conversion when necessary.
  • Note that "long variable name" and "long_var_name" refer to standardized variable names from the CSDMS Standard Names.
  • For the get_var_units() and get_time_units() functions, standard unit names (in lower case) should be provided, such as "meters" or "feet". Standard abbreviations, like "m" for "meters" and "mi" for "miles" are also supported. For variables with "compound units", each primitive unit name or abbreviation is separated by a single space character and exponents other than 1 are placed immediately after the name, as in "m s-1" for velocity, or "W m-2" for an energy flux. CSDMS uses the UDUNITS standard from Unidata.
  • The get_var_name() function is not used by CSDMS but often makes it easier to implement the other BMI functions.
  • For the get_var_type() function, the returned data type should be a string from the first column of the following table.
  BMI datatype C datatype NumPy datatype
  BMI_CHAR char int8
  BMI_UNSIGNED_CHAR unsigned char uint8
  BMI_INT signed int int16
  BMI_LONG signed long int int32
  BMI_UNSIGNED_INT unsigned int uint16
  BMI_UNSIGNED_LONG unsigned long int uint32
  BMI_FLOAT float float32
  BMI_DOUBLE double float64

Variable Getter and Setter Functions

double get_0d_double( in string long_var_name )
array<double> get_1d_double( in string long_var_name  )
array<double,2> get_2d_double( in string long_var_name )
array<double> get_2d_double_at_indices( in string long_var_name, array<int> indices )

void set_0d_double( in string long_var_name, in double scalar )
void set_1d_double( in string long_var_name, in array<double> array)
void set_2d_double( in string long_var_name, in array<double,2> array)
void set_2d_double_at_indices( in string long_var_name, in array<int> indices, in array<double,2> array)
  • There are different getter and setter functions for scalars (0d), 1D arrays (1d), 2D arrays (2d) and 3D arrays (3d). This simplifies implementation, since most of the programming languages supported by CSDMS require static vs. dynamic data types. (However, other approaches are possible and may also be supported later.)
  • Although not listed above, BMI functions to get and set integer data are also supported. They have names like: "get_2d_int()" instead of "get_2d_double()".
  • There is no problem if a model uses arrays with a dimension greater than 3. In that case, BMI functions with names like "get_4d_double()" would simply be provided, following the same naming pattern.
  • The BMI functions get_2d_double_at_indices() and set_2d_double_at_indices() allow a (possibly much smaller) subset of values to be obtained from an array. This can dramatically reduce the amount of data that is passed, which can be important when components are coupled across a network.
  • Note that "long variable name" and "long_var_name" refer to standardized variable names from the CSDMS Standard Names.

Grid Information Functions

  • The BMI function call get_attribute( "mesh_type" ) should return one of the following strings:
uniform       (for uniform rectilinear)
rectilinear   (for rectilinear)
s_mesh        (for structured mesh)
u_mesh        (for unstructured mesh)
  • Each of these strings corresponds to a particular type of model grid or mesh. In order to provide a complete and standardized description of a model's grid, there is a different set of BMI functions that are required for each model "mesh_type" as described in this section.
  • The BMI functions below return grid descriptions that are compatible with ESMP, the new Python interface for the ESMF regridding tool. CSDMS uses this tool for spatial regridding, when needed.
  • The BMI functions below are also closely aligned with the mesh types supported by VTK, as described in the VTK File Formats document.
  • The Ugrid Interoperability Group is working on a standard method for describing and storing unstructured grids. It is expected to be compatible with NetCDF files.
  • An orthogonal curvilinear coordinate system is a special case of a "structured mesh".
  • Note that "uniform rectilinear", "rectilinear" and "structured mesh" all have the topology of a two-dimensional array.

  Uniform Rectilinear


array<double, 1> get_grid_spacing (in string long_var_name)
array<double, 1> get_grid_lower_left_corner (in string long_var_name)
array<int, 1> get_grid_shape (in string long_var_name)



array<double, 1> get_grid_x (in string long_var_name)
array<double, 1> get_grid_y (in string long_var_name)
array<double, 1> get_grid_z (in string long_var_name)
array<int, 1> get_grid_shape (in string long_var_name)

  Structured Mesh


array<double, 1> get_grid_x (in string long_var_name)
array<double, 1> get_grid_y (in string long_var_name)
array<int, 1> get_grid_shape (in string long_var_name)

  Unstructured Mesh


array<double, 1> get_grid_x (in string long_var_name)
array<double, 1> get_grid_y (in string long_var_name)
array<int, 1> get_grid_connectivity (in string long_var_name)
array<int, 1> get_grid_offset (in string long_var_name)