Definition of interoperable real kind

[hrajagers]

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.

[mdpiper]

@hrajagers This is a design decision I've come to regret. I wanted the Fortran BMI specification to be as basic and as Fortran-like as possible, minimizing the use of other modules, so instead of including the bind(c) layer in the specification, I chose to implement it in the babelizer, where it is buried deeply.

My design choice makes sense from a CSDMS-only perspective: I want to minimize the effort researchers have to expend to wrap their code with a BMI; we (at CSDMS) take care of interoperability through the babelizer and pymt. My design choice fails for researchers outside of CSDMS who want an interoperable Fortran BMI and don't want or need to use the babelizer.

I lay out some of this in csdms/bmi#66. When we next update BMI, we should either make a separate Fortran BMI that includes the bind(c) layer, like @jdhughes-usgs suggests, or we should just include the bind(c) layer in the Fortran specification, as you suggest.

[samharrison7]

I can here to raise this issue too :)

If you decide to go down the separate interfaces route, can we change the pure Fortran BMI to use iso_fortran_env? I.e.

use iso_fortran_env, only: real64

real(real64) :: a

My understanding (which could be wrong) is that the kinds from iso_fortran_env (real32, real64 etc) almost always match the correspond kinds from iso_c_binding (c_float, c_double etc), especially for modern compilers, but there might be edge cases on historic systems where this isn't true.