Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harmonize MODFLOW 6 and CSDMS BMI implementation approaches #66

Open
mdpiper opened this issue Mar 26, 2020 · 2 comments
Open

Harmonize MODFLOW 6 and CSDMS BMI implementation approaches #66

mdpiper opened this issue Mar 26, 2020 · 2 comments
Milestone

Comments

@mdpiper
Copy link
Member

mdpiper commented Mar 26, 2020

I'm opening this issue to facilitate discussion of how we can harmonize the BMI implementation techniques used by the MODFLOW development team and CSDMS.

The MODFLOW development team of @jdhughes-usgs and @langevin-usgs at USGS, working with @mjr-deltares at Deltares, has developed a BMI implementation for MODFLOW 6 that includes extensions (the AMI) that allow internal MODFLOW components to be tightly coupled within a time step as they iterate to a solution. The goal of this interstitial coupling is to eventually allow other models, such as PRMS or MetaSWAP, to be coupled with MODFLOW. Further, this team has developed a Python package, amipy, that wraps both BMI and AMI and allows MODFLOW 6 to be called from and run within Python (example).

The CSDMS development team of @mcflugen and @mdpiper has a slightly different approach that yields similar results. A model developer implements the Fortran BMI specification for their model. At CSDMS, we then wrap the BMI with an interoperability layer (similar to what's integrated into the BMI/AMI above), then compile and link the Fortran code into a C library through Cython, creating a Python package that can be called standalone or from pymt. This process has been templated and automated, so that once a model with a BMI is provided to CSDMS, it can be quickly processed into a Python package. The PRMS Surface component provides an example of this process. Here are the key points:

  • Here is @rmcd-mscb's BMI implementation (see the src directory). Once Rich wrote his BMI, he was able to hand it over to CSDMS.
  • The tool we call the cookiecutter provides Cython templates for BMIs written in C, C++, and Fortran. It also provides the Fortran interoperability layer. All Fortran BMIs get this same interoperability layer. All of these are in this directory of the repo.
  • Here is the resulting PRMS Surface Python package output from the cookiecutter. See especially the Cython class at its core and the setup.py file which compiles and links the Cython extension.
  • In this repo I've included simple examples of using PRMS Surface as a standalone Python package and as a pymt component. Rich has also created a Jupyter Notebook example.
@jdhughes-usgs
Copy link

Maybe there could be an Basin Model Interface for Fortran (iso_c_binding) bmi-fortran-isoc version like there is for standard Fortran bmi-fortran?

@mdpiper
Copy link
Member Author

mdpiper commented Jun 22, 2022

Yeah, having a separate BMI for Fortran would solve this. The more I think about it, though, I think you guys did it right. The iso_c_binding module has been standard since Fortran 2003, and because we have an eye toward coupling (and cross-language compiling) whenever we implement a BMI, we should just use it. I was maybe being too dogmatic in wanting to use object-oriented Fortran (Fortran 2003), but not wanting to use this module. Perhaps it's stuck in my mind as an extension.

Updating the Fortran BMI language spec would be a great task for BMI v3.0!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants