search

NCAR / ccpp-physics

GFS physics for CCPP
Other
55 stars 144 forks source link

machine.F uses unsupported kind values and should be renamed to ccpp_kinds #194

Open gold2718 opened 5 years ago

gold2718 commented 5 years ago

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?

climbfuji commented 5 years ago

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?

gold2718 commented 5 years ago

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).

climbfuji commented 5 years ago

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 ?

climbfuji commented 5 years ago

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.

climbfuji commented 4 years ago

Also, the module machine should be renamed to ccpp_kinds as noted by @gold2718 in https://github.com/NCAR/ccpp-physics/pull/288.

climbfuji commented 4 years ago

This should be addressed before/for the UFS release.