NCAR
machine.F uses unsupported kind values and should be renamed to ccpp_kinds
While using integers as kind values often does the expected thing, that usage is not mandated by the Fortran standard which gives processors (i.e., compilers) the ability to use any non-negative integer for any particular numerical representation. The current usage is unsupported. I suggest replacing the current usage with calls to the Fortran intrinsic routines, selected_real_kind and selected_int_kind. Also, please document the various kinds. For instance, when should an implementer use kind_evod, kind_taum or kind_ior instead of kind_phys?
Is there any particular reason not to use iso_fortran_env wherever possible as described here?
https://www.nag.co.uk/nagware/np/r62_doc/iso_fortran_env.html
For instance:
USE,INTRINSIC :: ISO_FORTRAN_ENV, only: real32, real64, ...
and then as assign those to kind_phys etc as needed?
While I like that idea, we need to ensure compiler support before plunging ahead. real32, real64 etc are Fortran2008 features and at least as of last June, PGI still only claimed Fortran2003 support. I believe Intel supports these types but I do not know about other compilers (e..g, Cray).
That's a good point. We do have a statement about a minimum Fortran standard somewhere in the requirements, I believe it is Fortran 2003? A lot of the ISO_C binding used for the dynamic builds is leaning more towards 2008, though. Please correct me if I am wrong. @ligiabernardet ?
I also think we should discuss this compiler support issue in one of the CCPP framework meetings. I personally, in agreement with Rusty and other folks, don't feel like making a lot of effort supporting PGI for many reasons. Our list of supported platforms and compilers has to cover what the UFS wants to support, but can extend beyond that - how far is something we have to decide in agreement.
Also, the module machine should be renamed to ccpp_kinds as noted by @gold2718 in https://github.com/NCAR/ccpp-physics/pull/288.