-
Notifications
You must be signed in to change notification settings - Fork 0
Q&A
Bert Jagers is a Senior Researcher at Deltares and a member of the CSDMS steering committee. Christophe provided an introduction, and I asked Bert a number of the questions that had been on my "ask Deltares" list since the mid-August meeting in Wellington.
Tom: Some of the existing models we’re working with produce a steady-state result, rather than a dynamic one. We will still need to iterate solutions across linked models, because the results of one model can be boundary conditions for another, but in these cases the goal is to come to a state of equilibrium among the models, rather than to produce a dynamic system where the outputs of one model are the inputs to another model for this time step or the next one. The APIs for both Delta Shell and BMI seem to be oriented toward the dynamic case. Can we use them (or one of them) for steady-state applications?
Bert: Many of the model coupling standards have time stepping implicitly included. We’ve faced similar issue with the European OpenMI standard which initially required all components to perform time stepping, but after some initial applications using databases the time progress became optional in the OpenMI 2.0 standard. We are using BMI or at least BMI-like interfaces for iterations between our 1D and 2D flow solvers; these may be used as inspiration.
Tom: Does BMI provide data-passing tools for the cases where we have a conceptual or lumped-process model computing over features like reaches, catchments, or farms that will produce single-variable time series for quantities like discharge or nutrient concentrations? The notion of the functional coverage used in Delta Shell would seem to support this through feature coverages or network coverages, but the methods definitions given in the BMI spec are described in terms of surfaces, like grids and meshes. Is there a way to pass one catchment’s runoff to a simple routing model through BMI as a time series? Can a layer of farms produce a separate output for each farm and pass it as an identifiable entity to another model through BMI?
Bert: I don’t see an immediate problem here; the “grid types” included in the BMI descriptions are indeed limited, but they have been intended as extendable as needed. We exchange point data from our flow model to a real-time control component, and pass set point back to the hydraulic control structures – geospatial location is unavailable or irrelevant here. Many data quantities may be passed between components without fully defining the geospatial location; obviously this requires that the person coupling the components has some inside knowledge. However, if you need the geospatial location description (e.g. for interpolation or mapping) then it may be possible to extend the “grid types” … it’s an ongoing discussion and I’m not sure that the CSDMS BMI information fully up to date.
Tom: Can models share look-up tables through the Delta Shell or BMI interfaces?
Bert: Not completely sure that I understand you question correctly. Do you mean whether a look-up table (more concrete e.g. a stage-discharge relation) can be exchanged via BMI interfaces? I know this question has popped before, but I haven’t seen a concrete solution in BMI. Since BMI intends to be language neutral, it is difficult to standardize composite data objects. I know that a colleague has passed derived types across an extension of the BMI interface, so maybe that could be explored further in this context. This is not a fundamental problem for Delta Shell since everything is implemented in C#.
Tom: Where a model has been developed to write its outputs to a file of some sort – anything from CSV to netCDF – will the model contributors have to put features into their BMI or Delta Shell wrappers to pass the data live in memory, or can they point to the files they’ve written to?
Bert: Output data can be made accessible to user or to the user interface via files, but if the data is to be exchanged between components at runtime (e.g. as part of the iteration or time progress) then they have to be made available via the BMI in memory interface. Hardwired exceptions are possible but they limit flexibility and should thus be avoided.
Tom: Do BMI and Delta Shell provide ways of handling errors or exceptions across the linked models? If my model throws an C++ exception, can that be translated to something that will interrupt the controlling program in a graceful or controllable way?
Bert: The BMI standard doesn’t include any exception handling, but coupling frameworks built using the BMI standard may do so. Both Delta Shell and the C++ DIMR program do include exception handling (partially still under development).