-
Notifications
You must be signed in to change notification settings - Fork 700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Case insensitive F90 compile rule #2057
Case insensitive F90 compile rule #2057
Conversation
Pleim-Xiu LSM MODIS LCZ Compatibility & Surface Evaporation Update TYPE: bug fix & physics refinement KEYWORDS: MODIS, LCZ, P-X LSM, Latent Heat Flux SOURCE: Robert Gilliam & Jon Pleim, US EPA DESCRIPTION OF CHANGES: Problem: User indicated that the P-X LSM errored for MODIS LCZ 61 NUM_LAND_CAT configuration. Currently, we account for evaporation from transpiration, soil in both vegetated and non-veg parts, and wet leaves. But we only account for the latent heat effects on Tg from transpiration and evaporation from non-veg soil. This fix adds latent heat effects on Tg from soil in vegetated parts and from wet leaves. Fix for rare case where GRDFLX goes NaN because of a divide by zero based on a soil parameter when a water cell turns to sea ice. Solution: Logic checks in module_physics_init.F and module_sf_pxlsm.F were adjusted for 61 category inputs. P-X LSM data table, module_sf_pxlsm_data.F was updated for MODIS 61 categories. Default for LCZ 51-61 was set to MODIS urban class. We also added updates for the evaporation from vegetation and wet canopy. ISSUE: Fixes: wrf-model#1965 LIST OF MODIFIED FILES: M phys/module_physics_init.F M phys/module_sf_pxlsm.F M phys/module_sf_pxlsm_data.F - Tested 61 class LCZ with PX LSM for a 1 day simulation with updated codes. Ran base MODIS 21 class scheme with same code before and after LCZ update. The results were identical after a 24 hour simulation. This confirms updates do not impact other MODIS settings in the P-X LSM. The MODIS 21 was by nature not identical to the MODIS 61, but similar enough and differences follow underlying differences in MODIS datasets. - The Jenkins tests are all passing. RELEASE NOTE: Pleim-Xiu LSM is now compatible with 61 category MODIS LCZ landuse dataset. A mode of latent heat effects on Tg from vegetated parts and from wet leaves is added to Pleim-Xiu LSM.
…lang because Apple clang does not support it arch/postamble : Simplified .F90.o to remove creation of the .f90 intermediary because it clobbers the .F90 on case-insensitive file systems (Mac)
The regression test results:
|
arch/configure.defaults
Outdated
@@ -915,7 +915,7 @@ DESCRIPTION = INTEL ($SFC/$SCC) | |||
DMPARALLEL = # 1 | |||
OMPCPP = # -D_OPENMP | |||
OMP = # -qopenmp -fpp -auto | |||
OMPCC = # -qopenmp | |||
OMPCC = # |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
arch/postamble
Outdated
$(SED_FTN) $*.bb | $(CPP) $(TRADFLAG) > $*.f90 | ||
$(RM) $*.G $*.bb | ||
$(FC) -o $@ -c $(FCFLAGS) $(OMP) $(MODULE_DIRS) $(PROMOTION) $(FCSUFFIX) $*.f90 | ||
$(FC) -o $@ -c -I$(WRF_SRC_ROOT_DIR)/inc $(OMPCPP) $(FCFLAGS) $(ARCHFLAGS) $(OMP) $(MODULE_DIRS) $(PROMOTION) $(FCSUFFIX) $*.F90 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair. The current codes in physics_mmm have hardly any preprocessing, but there's no guarantee of that always being the case.
Sorry it took so long, but I reverted configure.defaults so that it can be a separate thing. |
@islas @weiwangncar Should we target the |
@mgduda I think that should work especially with the more conservative approach of |
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:
Solution:
ISSUE: Addresses .F90.f90 issue raised in #1989
LIST OF MODIFIED FILES:
arch/postamble
arch/configure.defaults
TESTS CONDUCTED:
RELEASE NOTE: Fixed a compile problem with .F90 source files on case-insensitive file systems.