FORTRAN 2003/2008

[jiandewang]

I would like to have some discussion and solicit opinions on the using of FORTRAN 2003/2008 in model code. For EMC forks who have experience on this, your opinion will be appreciated.

Some background information:
the development of MOM6 community is considering the possibility of adopting or condoning the use of Fortran 2003 or Fortran 2008 features in MOM6. In particular there are a handful of novel Fortran constructs that they might want to require, encourage, condone, tolerate, constrain or preclude, including:

• The allocate(..., source=...) construct for initializing allocatables or pointers (F2003, enhanced in F2008)
• The use of allocatable arrays in defined data types (F2003)
• The block / end block construct allowing for the declaration of limited-scope variables (as is common in C) (F2008)
• The do concurrent construct for looping over multiple dimensions in a single do loop (F2003)
• The contiguous attribute for array arguments (F2008)
• The use of intent attributes for pointer arguments (F2003)
• The use of semicolons preceding lines (F2008)

Some feedback from Bill Sacks of NCAR:
__...any F2003 construct is fair game, but we still want to be cautious with F2008 features. It sounds like this is Bob's proposal as well.

I will say that, although we use this F2003 feature in a number of places:
The allocate(..., source=...) construct for initializing allocatables or pointers
I believe it has been the source of a number of compiler bugs when used to allocate polymorphic variables of relatively complex classes. I have had more luck recently with typed instead of sourced allocation, in situations where either one could work (see https://www.pgroup.com/blogs/posts/f03-oop-part2.htm).

For the contiguous attribute: We have long had a cpp definition, HAS_F2008_CONTIGUOUS, defined for each compiler in config_compilers.xml. This is listed as FALSE for many compilers, but I don't know how up-to-date this is.

It doesn't work well for each component to make its own decisions about what F2008 features to support, because we need all components to be buildable by the set of compilers that CESM supports. It would be great if you could continue to keep CSEG in the loop with any F2008 features planned for inclusion in MOM6_.

Finally, a cautionary note: When we started to adopt F2003 features (around 2013 or a little later), the compilers we were using all claimed to support the features we were using. However, even though these features worked in simple cases, we ran into a ton of cases where more complex situations led to compiler bugs. This, in turn, caused a lot of pain and wasted time. This is why many of us are cautious when it comes to adopting F2008 features._

[arunchawla-NOAA]

This is a fascinating discussion. Perhaps we start with the Fortran 2003 constructs. We should identify the compilers that at a minimum we want to work with.

[climbfuji]

We should keep in mind that the UFS coding standards (and the CCPP coding standards) have some language regarding to what is allowed or not. I think both, but definitely CCPP, state that Fortran 2008 is allowed.

…

On Oct 18, 2021, at 7:55 AM, arun chawla ***@***.***> wrote: This is a fascinating discussion. Perhaps we start with the Fortran 2003 constructs. We should identify the compilers that at a minimum we want to work with. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#837 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RNEOAAKVKEBVHGT36TUHQRLLANCNFSM5E55PMYA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rgrumbine]

Perhaps this is already in hand (it is for CICE), but before making an effort to use new F2003 or 2008 constructs (co-arrays look very interesting, too), we should ensure that all code is fully F95 compliant. The most-used code likely is ok, but legacies that nobody looks at can and have retained fortran 66 constructs for decades. (And we're running out of people who know 66)