Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

No .exe files produced compiling WRF

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

S

skew_t_pie

New member
I am installing WRF (v 4.2.1) on a Mac OsX running High Sierra (Darwin Arch Linux) on a 4-core Intel processor (i7 2.9 GHz). I have installed the libraries including separately building NetCDF-C (4.7.4) and NetCDF-Fortran (4.5.2) and set the appropriate paths/environmental variables as per the (slightly outdated) WRF Tutorial (https://www2.mmm.ucar.edu/wrf/OnLineTutorial/compilation_tutorial.php#STEP2). Trying to run a real case (em_real), I am not able to obtain executable files after configuration and compilation. I've attached my log here but the fatal errors are all regarding locating modules (I assume Fortran modules?) not being found:

Fatal Error: Cannot open module file 'module_mp_fast_sbm.mod' for reading at (1): No such file or directory

Not sure if this is an issue in setting environmental variables correctly or an issue with the NetCDF library. I ran "make check" after each library install and had no issues. I am using gfortran/gcc compilers and they work fine.
 

Attachments

  • log.compile
    64.7 KB · Views: 74
Ming Chen said:
This might be related to the version of your compiler. Which version of gcc you used?
Click to expand...

[brians-mbp:~/WRF_home/WRF/main] bjh% gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 
We know that the clang-1000.10.44.4 has trouble to compile WRF. Is it possible to install gfortran/gcc and try again?
 
Ming Chen said:
We know that the clang-1000.10.44.4 has trouble to compile WRF. Is it possible to install gfortran/gcc and try again?
Click to expand...

For whatever reason, I have successfully updated the default gfortran to 9.3.0 and not clang using homebrew; however I can't do the same with gcc and systems integrity protection won't let me link the downloaded gcc found in /usr/local/bin (used homebrew for that too) into /usr/bin (even with sudo/ in root). I've even tried to set an environmental variable to direct to this version but I run into the same compile errors.

Edit: copied some of the log.compile which shows that while it uses the downloaded gfortran it does not recognize the downloaded gcc (this was done in serial but same issues arise in parallel):

The following indicate the compilers selected to build the WRF system

Serial Fortran compiler (mostly for tool generation):
which SFC
/usr/local/bin/gfortran

Serial C compiler (mostly for tool generation):
which SCC
/usr/bin/gcc

Fortran compiler for the model source code:
which FC
/usr/local/bin/gfortran
Will use 'time' to report timing information

C compiler for the model source code:
which CC
/usr/bin/gcc
 
skew_t_pie, were you able to resolve this issue? Looking at your log.compile, I recognize the errors. I ran into something very similar and was able to resolve it.

The specific error was that the Apple LLVM distribution of cpp is unable to correctly parse the macros in module_mp_fast_sbm.F. That kept the correct .F90 file from being generated, which kept the Fortran module from being compiled, which resulted in the error you had.

There are a couple of things you can do

First, to ensure that the compile script uses the Homebrew GNU GCC installation instead of the Apple LLVM clang version, make sure "/usr/local/bin" comes before "/usr/bin". If your Homebrew installation is like mine, your executables are called gcc-9 and gfortran-9, so you should make symlinks gcc and gfortran in the /usr/local/bin folder to point to gcc-9 and gfortran-9, respectively.

If you don't want to or cant change the compiler version, you can edit the spot tripping up the preprocessor. It's lines 6055 - 6073 of phys/module_mp_fast_sbm.F, and it's literally just funky spacing but that's what throws everything off. I swear, it's a fully reproducible bug in the LLVM distribution of the c preprocessor. I made a pull request to the WRF GitHub with this small change. It should be a part of the latest version in the future. You can see the fix for yourself at https://github.com/wrf-model/WRF/pull/1221/files
 
irowe1 said:
skew_t_pie, were you able to resolve this issue? Looking at your log.compile, I recognize the errors. I ran into something very similar and was able to resolve it.

The specific error was that the Apple LLVM distribution of cpp is unable to correctly parse the macros in module_mp_fast_sbm.F. That kept the correct .F90 file from being generated, which kept the Fortran module from being compiled, which resulted in the error you had.

There are a couple of things you can do

First, to ensure that the compile script uses the Homebrew GNU GCC installation instead of the Apple LLVM clang version, make sure "/usr/local/bin" comes before "/usr/bin". If your Homebrew installation is like mine, your executables are called gcc-9 and gfortran-9, so you should make symlinks gcc and gfortran in the /usr/local/bin folder to point to gcc-9 and gfortran-9, respectively.

If you don't want to or cant change the compiler version, you can edit the spot tripping up the preprocessor. It's lines 6055 - 6073 of phys/module_mp_fast_sbm.F, and it's literally just funky spacing but that's what throws everything off. I swear, it's a fully reproducible bug in the LLVM distribution of the c preprocessor. I made a pull request to the WRF GitHub with this small change. It should be a part of the latest version in the future. You can see the fix for yourself at https://github.com/wrf-model/WRF/pull/1221/files
Click to expand...


Hi,

Yes I solved this issue but went a different route. I ended up writing a couple of sed commands in my install script to change the locations of my GNU compilers in /usr/local in the configure files themselves. Was able to generate all .exe files including the 44 for WRFDA. Thanks.
 
Glad you got it fixed, and thanks for sharing your solution! I'm hoping to help make sure more of these forum threads don't end up unresolved.
 
You must log in or register to reply here.
Top