Case insensitive F90 compile rule

[MicroTed]

The .F90 source files in physics_mmm need to be compiled directly to .o on case-insensitive file systems (like MacOS standard FS). This PR avoids the creation of a .f90 temporary, which will clobber the .F90 version.

TYPE: [bug fix]

KEYWORDS: case-insensitive filesystem

SOURCE: "Ted Mansell (NOAA/NSSL)"

DESCRIPTION OF CHANGES:
Problem:

1. On case-insensitive file systems (like MacOS standard FS), the creation of .f90 temporary files from .F90 source will clobber the source files.
2. The configure.defaults has an unrecognized option for Apple clang

Solution:

1. In postamble: Removed the .F90.f90 rule and compacted the .F90.o rule to use only the fortran compiler to do any necessary preprocessing. It is convention among fortran compilers that .F90 will be preprocessed.
2. In configure.defaults: For Darwin compile with ifort+clang, removed the -qopenmp from OMPCC (Apple clang does not support OpenMP)

ISSUE: Addresses .F90.f90 issue raised in #1989

LIST OF MODIFIED FILES:
arch/postamble
arch/configure.defaults

TESTS CONDUCTED:

1. Compiles correctly on MacOS (Intel CPU with ifort + clang) and Linux
2. Are the Jenkins tests all passing? Yes.

RELEASE NOTE: Fixed a compile problem with .F90 source files on case-insensitive file systems.

[weiwangncar]

The regression test results:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 23           24
Number of Builds       : 60           57
Number of Simulations  : 158           150        0
Number of Comparisons  : 95           86        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

[mgduda]

I may be mistaken, but I think clang does support OpenMP on Apple systems, though the flag is -fopenmp rather than -qopenmp (which may have simply been copied from the Intel Fortran compiler option to enable OpenMP).

[MicroTed]

The default built-in Xcode clang does not support the -fopenmp flag (throws an error). Users can install clang (or gcc) with homebrew, and that does support it, but I would think that users would not expect to have to do that. Is there much C code in the model that uses openmp, anyway?

[mgduda]

Those are fair points, and I don't think there's much C code in WRF that uses OpenMP. Especially since this change only affects Intel-based macOS systems, I'm fine with the change as it is.

[mgduda]

I'll let others (@weiwangncar, @islas) weigh in on whether this change should appear in a separate PR or commit since it doesn't strictly relate to case-insensitive *.F90 compilation.

[MicroTed]

Apple clang doesn't support openmp on either intel or arm64 macs. (It is possible to run ifort on an M-series mac in emulation, and it actually runs OK.) I didn't think to update the gfortran+clang section since I've never used it.

[islas]

I would prefer the arch/configure.defaults changes to be separate, as that would also make recording / release notes easier to write each up as separate fixes

[mgduda]

Under the assumption that there is a good reason for explicitly processing source files with cpp and sed, would it be safer to preserve that preprocessing, but to instead name the intermediate .f90 files something like .tmp.f90?
I think something like this might be possible (pending testing with a broader range of compilers):

.F90.o:
        $(RM) $@
        sed -e "s/^\!.*'.*//" -e "s/^ *\!.*'.*//" $*.F90 > $*.G
        $(CPP) -I$(WRF_SRC_ROOT_DIR)/inc $(CPPFLAGS) $(OMPCPP) $*.G  > $*.bb
        $(SED_FTN) $*.bb | $(CPP) $(TRADFLAG) > $*.tmp.f90
        $(RM) $*.G $*.bb
        $(FC) -o $@ -c $(FCFLAGS) $(OMP) $(MODULE_DIRS) $(PROMOTION) $(FCSUFFIX) $*.tmp.f90

[MicroTed]

I don't know the history of WRF compiling to use the cpp/sed etc., but it seems like a lot of extra effort when the built-in fpp should just work. (Maybe the old cray compilers were cranky?) A mangled name should work, too, though, if that would be preferable. I just thought it would be much simpler to just compile it straight. I have a bunch of preprocessing in my codes and haven't run into any problems with built-in fpp, but I also haven't used all possible fortran compilers.

The 'clean' function is the only thing that might need to be updated?

[mgduda]

My preference would be to stick with what has been known to work for WRF. In MPAS, we do let the Fortran compiler handle pre-processing of source files by default, but I seem to recall that WRF code contains some non-standard-isms that necessitated special pre-processing for some compilers.

I don't think anything needs to be modified for the 'clean' script, as that appears to have logic already to remove .f90 files where they are know to have been generated through explicit pre-processing: https://github.com/wrf-model/WRF/blob/v4.6.0/clean#L6-L16 .

[MicroTed]

That's fair. The current codes in physics_mmm have hardly any preprocessing, but there's no guarantee of that always being the case.