I tried compiling WRF on a Snow Leopard (SL) Mac, and found I had to make a few adjustments to my configure.wrf files. First of all, ifort version 11 appears to be needed. I also needed to revert to the (now) older version of the gcc compiler. Change "gcc" or "cc" on the SCC and CC_TOOLS lines to "gcc-4.0". I'm not sure if this is ifort's problem or mine, but at least it appears to be resolved.
The issue this resolved was a segfault in executing tools/registry for the creation of the module_state_description.F file.
Subscribe to:
Post Comments (Atom)
12 comments:
Hi Robert,
good to hear of you again!.
I'm running WRFV3.1.1 over Snow Leopard (10.6.2) compiled with both ifort and icc. I had to ask a little help from WRFhelp and they sent me a new file (protos.h) and now it's OK.
Perhaps I can send you the file to share with anyone interested in running WRF over Snow Leopard.
Cesi,
What problem did the revised protos.h fix? Was it an issue with icc, perhaps? Are you using ifort11 or an earlier version?
In any event, using ifort11 and gcc-4.0, I have compiled and run WRF in single-threaded and MPI version on a MacBook Air w/ SL (also 10.6.2). The test run ran fine. I have not tried OpenMP (yet).
Hi Robert,
Greetings from the UK!
I'm having the same sort of trouble compiling WRFV3.1.1 on 10.6.2 too. The issue is same one - registry seg. faults.
It would seem that if I force a 32-bit build with icc/ifort with -arch i386 then it at least compiles sucessfully. If however I do a 64-bit build then I get a seg. fault from registry.
Switching to CC=gcc-4.0 as you suggested worked for me but again only for 32-bit builds. If I configure for 64-bit the same seg. fault problem occurs.
I'd be interested to see the protos.h file is Cesi passed it on.
Robert,
Here is the protos.h file I obtained from Cesi. Hope this helps. If this works, I'd like to understand why I did not need it...
Hi Robert, I've taken a quick look this morning...
The new "protos.h" file, which is included in "registry.c" adds a forward declaration of the function "array_size_expression". This function returns a pointer to a character. I think that unless you define a prototype the compiler will assume the return type to be int.
Bottom line is that with the new "protos.h", with the proper forward declaration of type, registry.c compiles and runs OK and the build completes OK.
It would appear that when I do a 32-bit build I get away with it and it works. Switching to a 64-bit build, without the new prototype definition, it all goes horribly wrong and registry crashes out.
To help answer your question, can you confirm that your build of registry is a 64-bit executable: you can check by going into "WRFV3/tools" and typing "file registry" - which should return "registry: Mach-O 64-bit executable x86_64". Could you also confirm that "wrf.exe" is 64-bit too?
I think you might be building a 32-bit version - which doesn't seem to be affected by the missing declaration. The reason i think you might be building 32-bit is that my gcc-4.0 builds 32-bit object code by default (no extra flags). However, icc/ifort builds 64-bit by default hence the problem. You could force gcc-4.0 to produce 64-bit with the "-m64" flag but I've not checked to see if this works. I also wonder why I've never seen this problem before with other (linux) 64-bit builds?
Many thanks anyway as I now have a working "clean" 64-bit build of WRF on my Mac with the modified header file... I just need to check it gives the right answers now :)
Robert,
Thanks for this information. Things are a little clearer now.
I do use the -m64 flag with gcc-4.0, and my builds of wrf.exe and real.exe are indeed 64 bit. But, it turns out tools/registry is 32 bit. There's obviously some place beyond the reach of the -m64 flag I placed in configure.wrf.
This does not seem to be a concern, however, as the model runs fine and as 64 bit, and it appears the 32 bit registry executable is only used to create an intermediate Fortran text file. Still, there appears to be no reason not to use the updated protos.h file.
Hi again Robert,
Looking at the compile script it seems that "CFLAGS" isn't passed to the compiler when the code in "tools" is built.
I can confirm that I can replicate your 64-bit build with the original protos.h (with a 32-bit build of registry). The resulting model executables run fine.
I think we can consider this little mystery solved! Many thanks again,
R.
I was able to get around this issue (using ifort and gcc-4.0 on 64 bit 10.6.2) by setting
CFLAGS_LOCAL = -w -O3 -DMACOS -arch x86_64
in configure.wrf with no modification to protos.h.
Cheers,
-Steve (snesbitt@illinois.edu)
Thanks much, Steve!
Steve, Robert,
As noted before 'registry' built with gcc-4.0 is 32-bit by default. CFLAGS isn't passed to compiler when utils are built.
Since registry is only code preprocessor real.exe and wrf.exe are unaffected (and are 64-bit since CFLAGS is passed).
I can confirm resulting executables are identical irrespective.
Regards, R.
Hi, Robert:
Just wanted to let you know that WRF v. 3.2 compiled for ifort-cc-MACOS-serial-basic nesting WITH NO CODE CHANGES on my Snow Leopard (10.6.3) Mac Pro!
I am having a problem with the distributed parallel processing option. I loaded MPICH2 in /usr/local but there are mpirun, mpif90, and mpifcc files in /usr/bin. They appear to be linked to Open MPI. I keep getting error messages that "mpif90" is not enabled.
I am reluctant to delete or change the links for mpi* in /usr/bin but setting environmental variables has failed. I know you got MPICH2 running for an earlier version of WRF. Any suggestions?
Deb Baker
University of Maryland
Maryland Department of the Environment
P.S. I also installed the NCL/NCARG precompiled binary for Mac 10.6 (64-Bit). It's a gfortran/gcc build. I am loading WPS next so I'll let you know if it works
Deb,
I'm sorry it took so long for me to see and approve your comment. I turned on comment moderation because someone(s) from China are trying to spam it. Google/Blogger used to send me an email when there is a comment awaiting approval, but I'm not getting those anymore.
Regarding MPICH2, I compiled my own. If you're still having trouble, I can send you my compile flags. May be best to send an email to my UCLA acccount.
Post a Comment