csdms / bmi-fortran Goto Github PK

It's used, for example, here. It's a part of BMI++.

In #14, generic getters and setters are created to handle integer, float, and double types (using the SIDL conventions from Babel) for the Fortran BMI. Here, implement remaining types:

• bool
• long
• fcomplex
• dcomplex

This repository has some simple tests, but they're currently bundled into the GitHub Actions Build and Test workflow. The tests should be extracted from the workflow file and placed in a tests/ (or test/ for fpm?) directory, then run through ctest and in the Actions workflow.

There should be a conda recipe that builds and installs the bmif library from bmi.f90.

There's a relatively new package manager on the block for Fortran, aptly called the Fortran Package Manager, or fpm for short. It aims to make building Fortran projects with dependencies easier than the standard methods commonly used (like manually installing or simply copying over source files).

I think it would be very neat if the BMI Fortran module could be installed using fpm. In short, this would mean that a Fortran programmer using fpm to build their code and who wanted to implement the BMI could simply add a one-liner to their fpm.toml file (the fpm config file that controls the build of each package):

[dependencies]
bmi = { git = "https://github.com/csdms/bmi-fortran" }

If you guys are interested in this, I would be more than happy to rustle up a PR to show how it could work in action. In theory it should just be a case of adding an fpm.toml file to the repo with some build instructions.

This method is found here, for example, and is a part of the BMI++. Its signature is

int (* get_var_location)(void *, const char *, char *);

In Fortran, the type and rank of an argument must be known at compile time. This implies that we need BMI getters and setters for each intrinsic type that a model may use (i.e., get_value_int, get_value_float, get_value_double, etc.). However, we can simplify calls to the getters and setters by defining generic procedure interfaces with implementations for all the types that we expect to be passed at runtime. The user would only have to call get_value, and not be concerned with type. The model developer writing a BMI would still have to write get_value_int, get_value_float, etc.

For this issue, I'll implement the following methods:

• get_value_int
• get_value_float
• get_value_double
• get_value_ref_int
• get_value_ref_float
• get_value_ref_double
• get_value_at_indices_int
• get_value_at_indices_float
• get_value_at_indices_double
• set_value_int
• set_value_float
• set_value_double
• set_value_at_indices_int
• set_value_at_indices_float
• set_value_at_indices_double

I'll leave long and complex types for a separate, deferred, issue.

cc @sc0tts, @mcflugen

There are a bunch of obsolete parameters at the top of bmi.f90 that should be removed. Leave only:

• BMI_SUCCESS
• BMI_FAILURE
• BMI_MAXVARNAMESTR
• BMI_MAXCOMPNAMESTR
• BMI_MAXUNITSSTR

They're used here, for example. They're a part of BMI++. Their signatures are:

int (* get_grid_face_count)(void *, int, int *);
int (* get_grid_point_count)(void *, int, int *);
int (* get_grid_vertex_count)(void *, int, int *);

Update: Well, actually, there are several methods to implement. Here's the list:

• get_grid_node_count
• get_grid_edge_count
• get_grid_face_count
• get_grid_edge_nodes
• get_grid_face_nodes
• get_grid_face_edges
• get_grid_nodes_per_face

Following an internal discussion about Fortran real kinds, I noticed that the BMI 2.0 API uses the Fortran "double precision" as the real kind as the work horse for data exchange. It's these days considered bad practise to use real kind "double precision" since it depends on various compiler flags. One should instead define the precision kind that one really is expecting there. Now, there are two aspects to the BMI API. First, strictly it's a Fortran API and hence one could opt for any real kind definition that is commonly used in Fortran programs and libaries. However, there is also the second aspect of interoperability. I'm not sure how the internals of the Babelizer work, but I expect that at some level it assumes that the values in Fortran can be transferred to C, Java or Python without conversion. This would suggest across language interoperability. For this purpose the iso_c_bindings were introduced including the definition of a real kind c_double. I had a recent discussion about this topic on the Fortran-lang discourse grop. Maybe we should consider changing the Fortran real kinds being used in the API from real and double precision to c_float and c_double although on most platforms these definitions probably align.

Currently, conda does not find a package for the osx-arm64 architecture:

✖  conda install bmi-fortran -c conda-forge
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.

PackagesNotFoundError: The following packages are not available from current channels:

  - bmi-fortran

Current channels:

  - https://conda.anaconda.org/conda-forge/osx-arm64
  - https://conda.anaconda.org/conda-forge/noarch
  - https://repo.anaconda.com/pkgs/main/osx-arm64
  - https://repo.anaconda.com/pkgs/main/noarch
  - https://repo.anaconda.com/pkgs/r/osx-arm64
  - https://repo.anaconda.com/pkgs/r/noarch

To search for alternate channels that may provide the conda package you're
looking for, navigate to

    https://anaconda.org

and use the search bar at the top of the page.

The documentation on the time methods is here.

These are existing methods that I forgot to implement.

It's found here, for example. It's a part of BMI++.

The GitHub Actions CI is currently run on Linux and macOS. It should also be run on Windows.

I currently have only one input item and one output item defined in bmi_heat.f90, and they're both defined with data statements at the module level. For a more realistic example, I should add more exchange items and list them elsewhere.

The current set of tests in the testing directory are really examples, and should be renamed as such. The project should have actual unit tests for the BMI methods.

I need to explain to model developers how to implement this BMI for their Fortran code.

The BMI functions

• get_grid_shape
• get_grid_spacing
• get_grid_origin
• get_grid_x
• get_grid_y
• get_grid_z
• get_grid_edge_nodes
• get_grid_face_edges
• get_grid_face_nodes
• get_grid_nodes_per_face

are declared with a 1d array parameter of intent in in the SIDL file. This is done so that in a language like C, a pointer can be passed that will hold the shape, spacing, etc. output.

In Fortran, intent in is interpreted differently, in that declaring intent(in) on a parameter means the values of the parameter can't be changed in the subprogram. Setting intent(in) in the Fortran BMI wouldn't work. I've set the array parameter for these functions as intent(out), which means that they can only output information; information can't be communicated into the subprogram. For example, I can't change anything about the grid, I can only get back information (shape, spacing, etc.) about the grid from these functions.

I think this is the correct interpretation of the BMI, although I could also make a case for intent(inout).

The standard location for installing Fortran .mod files is the include directory, not the lib directory, as I'm currently doing.

It may not really be the conda compiler, but CMake is reporting it failing with the following:

Run cmake .. -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX="$env:CONDA_PREFIX" -DCMAKE_BUILD_TYPE=Release
-- The Fortran compiler identification is Flang 99.99.1
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Check for working Fortran compiler: C:/Users/runneradmin/micromamba/envs/testing/Library/bin/flang.exe
-- Check for working Fortran compiler: C:/Users/runneradmin/micromamba/envs/testing/Library/bin/flang.exe - broken
CMake Error at C:/Users/runneradmin/micromamba/envs/testing/Library/share/cmake-3.27/Modules/CMakeTestFortranCompiler.cmake:59 (message):
-- Configuring incomplete, errors occurred!
  The Fortran compiler

    "C:/Users/runneradmin/micromamba/envs/testing/Library/bin/flang.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: 'D:/a/bmi-fortran/bmi-fortran/build/CMakeFiles/CMakeScratch/TryCompile-5dt14k'
    
    Run Build Command(s): C:/Users/runneradmin/micromamba/envs/testing/Library/bin/cmake.exe -E env VERBOSE=1 nmake -f Makefile /nologo cmTC_a633f\fast
    	"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\bin\HostX64\x64\nmake.exe"  -f CMakeFiles\cmTC_a633f.dir\build.make /nologo -L                  CMakeFiles\cmTC_a633f.dir\build
    Building Fortran object CMakeFiles/cmTC_a633f.dir/testFortranCompiler.f.obj
    	C:\Users\runneradmin\micromamba\envs\testing\Library\bin\flang.exe     -o CMakeFiles\cmTC_a633f.dir\testFortranCompiler.f.obj -c D:\a\bmi-fortran\bmi-fortran\build\CMakeFiles\CMakeScratch\TryCompile-5dt14k\testFortranCompiler.f
    Linking Fortran executable cmTC_a633f.exe
    	C:\Users\runneradmin\micromamba\envs\testing\Library\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_a633f.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt="" --manifests -- link /nologo @CMakeFiles\cmTC_a633f.dir\objects1.rsp @C:\Users\RUNNER~1\AppData\Local\Temp\nm4918.tmp
    Visual Studio Incremental Link with embedded manifests
    Create CMakeFiles\cmTC_a633f.dir/manifest.rc
    Create empty: CMakeFiles\cmTC_a633f.dir/embed.manifest
    RC Pass 1:
    C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe /fo CMakeFiles\cmTC_a633f.dir/manifest.res CMakeFiles\cmTC_a633f.dir/manifest.rc
    LINK Pass 1:
    link /nologo @CMakeFiles\cmTC_a633f.dir\objects1.rsp /out:cmTC_a633f.exe /implib:cmTC_a633f.lib /pdb:D:\a\bmi-fortran\bmi-fortran\build\CMakeFiles\CMakeScratch\TryCompile-5dt14k\cmTC_a633f.pdb /version:0.0 /debug /INCREMENTAL /subsystem:console /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_a633f.dir/intermediate.manifest CMakeFiles\cmTC_a633f.dir/manifest.res
    LINK Pass 1: command "link /nologo @CMakeFiles\cmTC_a633f.dir\objects1.rsp /out:cmTC_a633f.exe /implib:cmTC_a633f.lib /pdb:D:\a\bmi-fortran\bmi-fortran\build\CMakeFiles\CMakeScratch\TryCompile-5dt14k\cmTC_a633f.pdb /version:0.0 /debug /INCREMENTAL /subsystem:console /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_a633f.dir/intermediate.manifest CMakeFiles\cmTC_a633f.dir/manifest.res" failed (exit code 1) with the following output:
    link: extra operand '/out:cmTC_a633f.exe'
    Try 'link --help' for more information.
    NMAKE : fatal error U1077: 'C:\Users\runneradmin\micromamba\envs\testing\Library\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\cmTC_a633f.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt="" --manifests -- link /nologo @CMakeFiles\cmTC_a633f.dir\objects1.rsp @C:\Users\RUNNER~1\AppData\Local\Temp\nm4918.tmp' : return code '0xffffffff'
    Stop.
    NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\bin\HostX64\x64\nmake.exe"  -f CMakeFiles\cmTC_a633f.dir\build.make /nologo -L                  CMakeFiles\cmTC_a633f.dir\build' : return code '0x2'
    Stop.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:3 (project)


NMAKE : fatal error U1052: file 'Makefile' not found
Stop.
Error: Process completed with exit code 1.

This method, described here, is a part of BMI++.