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

(RESOLVED) Problem Compiling WRFV4.0 on Fedora 28: landread error

C

chee10

New member
When I try to follow the instruction compiling the WRF on my Fedora 28 system, I had a problem compiling the WRF. The compliation process run, and run for about 20 minutes, but I just don't get the executables. I deleted everything and recompiled it once, and got the same error. I have attached my log.compile, and configure.wrf in the attachment. I also compiled WPS, and it seems like worked. By the way, I used all the tests provided to test my system installation, and all of them were success. Thank you!
 

Attachments

  • configure.wrf
    20.1 KB · Views: 146
  • 20180823.log.compile
    1 MB · Views: 215
Hi,

The error in your compile log is:
rm -f landread.o
mpicc -cc=gcc -DFSEEKO64_OK -o landread.o -c -w -O3 -c -DDM_PARALLEL -DMAX_HISTORY=25 -DNMM_CORE=0 landread.c
landread.c:68:10: fatal error: rpc/types.h: No such file or directory
#include <rpc/types.h>
^~~~~~~~~~~~~
compilation terminated.
make[2]: [../configure.wrf:372: landread.o] Error 1 (ignored)

We've seen a few reports of this, and it seems to be specific to particular Linux systems. We have not been able to repeat this at NCAR on our Macs, our department Linux server, or on our Linux HPC, and therefore we haven't come up with a long-term solution yet. However, a work-around would be to do the following:

Issue a ‘clean -a’ and then reconfigure. Then go into your configure.wrf file and look for the line:
CFLAGS = $(CFLAGS_LOCAL) -DDM_PARALLEL -DSTUBMPI \
-DMAX_HISTORY=$(MAX_HISTORY) -DNMM_CORE=$(WRF_NMM_CORE)

Onto the end of that, add -DLANDREAD_STUFF, so that it now looks like:
CFLAGS = $(CFLAGS_LOCAL) -DDM_PARALLEL -DSTUBMPI \
-DMAX_HISTORY=$(MAX_HISTORY) -DNMM_CORE=$(WRF_NMM_CORE) -DLANDREAD_STUB

Then save that configure file and recompile. This should get your past the problem. Please let us know if that works for you.
Thanks!
 
It worked! The executables are built in the "main" directory, and the log.compile file also confirmed the executables are successfully built. Thank you so much!
 
Hi,
We have just hit this issue on our computer and have identified it as our Centos OS8 having moved
rpc to a subdirectory of tirpc. The general workaround is to add -I/usr/include/tirpc to the compiler flags.
However, as LANDREAD_STUB is a WRF specific solution, and quite a significant change, with
futureproofing in mind, we were wondering whether there was any update to this advice.
Additionally, we are trying to compile older WRF versions (3.9.1.1 and 3.7.1) and we are wondering if using LANDREAD_STUB is valid for all versions or not.

Claire
 
Hi Claire,
It doesn't look like there has been an update to this, just by looking at the repository commit notes. I'll run it by our software engineers to see if they know of anything, and let you know if I have any information.
 
1. The LANDREAD_STUB option removes the ability for a moving nest to horizontally interpolate high-resolution topography and landuse fields. Very few use this option, so this is typically a safe recourse.

2. For those who do need the capability of a moving nest with the high-resolution static fields, if the location of types.h is not found in /usr/include, the alternative would be to look in /usr/include/tirpc.

We can put together a github pull request, but we will need a couple of users to verify that the proposed fix still provide code that works for us and additionally works for the those that have reported the build troubles with WRF.
 
Dear WRF Forum Users Who Found This Trouble,
@chee10 @cccarouge @kwerner

Would you please test this pull request:
https://github.com/wrf-model/WRF/pull/1072

Dave
 
Hi,

I am encountering a similar issue when compiling V3.9.1.1 and the above solution does not seem to work for me.
I add the following to my configure.wrf file -
Code: 
CFLAGS          =    $(CFLAGS_LOCAL) -DDM_PARALLEL  \
                      -DMAX_HISTORY=$(MAX_HISTORY) -DNMM_CORE=$(WRF_NMM_CORE)-DLANDREAD_STUB

and I am still getting the follwoing errors (the first 'Error') in my log.compile file

Code: 
mpicc -cc=icc -DMPI2_SUPPORT -DFSEEKO64_OK  -o landread.o -c -w -O3 -ip  -DDM_PARALLEL -DMAX_HISTORY=25 -DNMM_CORE=0-DLANDREAD_STUB landread.c
landread.c(68): catastrophic error: cannot open source file "rpc/types.h"
  #include <rpc/types.h>
                        ^

make[2]: [../configure.wrf:407: landread.o] Error 4 (ignored)
rm -f wrf_fddaobs_in.o

There are 'Errors' at 4 more places after this. I am attching my configure.wrf and the log.compile files. I am using intel-compilers-19/19.0.0.117.

View attachment log9102020.compile
View attachment configure9102020.wrf

Kindly help me solve this compilation error.
Best,
Prerita
 
Prerita,
The actual fix for this error is discussed in this GitHub code modification. You will have to modify the 2 files (click the "Files changed" tab to see the files and changes). You will then need to recompile the code, after issuing a "clean -a" and reconfiguring.
 
Hi,
Thanks for the information.
I made the required changes in configure and share/landread.c files and issued ./clean -a command.
However, I see this warning at the end of configure.wrf

Code: 
************************** W A R N I N G ************************************

The moving nest option is not available due to missing rpc/types.h file.
Copy landread.c.dist to landread.c in share directory to bypass compile error.

*****************************************************************************

Is this okay?

UPDATE- The compile failed again after making these changes.
Could you please suggest what could be wrong?
Thanks a lot for the help.


Best,
Prerita
 
Hi
Update - I found the location of the types.h file in my system and replaced the following line in the code in configure
from
Code: 
elif [ -f /usr/include/tirpc/rpc/types.h ] ; then
to
Code: 
elif [ -f /lustre/sw/libtirpc/1.2.6/include/tirpc/rpc/types.h] ; then

which is the location of the types.h header file in my machine.

I made the following changes to the configure.wrf file as well (As mentioned above)

Code: 
CFLAGS          =    $(CFLAGS_LOCAL) -DDM_PARALLEL  \
                      -DMAX_HISTORY=$(MAX_HISTORY) -DNMM_CORE=$(WRF_NMM_CORE)-DLANDREAD_STUB

I am still facing the issue while compiling WRF code (attaching the configure.wrf and compile log files).

The first error looks like this-

make[2]: [../configure.wrf:407: landread.o] Error 2 (ignored)
rm -f wrf_fddaobs_in.o


View attachment configure_wrf_cirrus12102020.wrf
View attachment compile_log12102020.log


I'd very much appreciate help in solving the error.
TIA
Prerita
 
Thanks for sending those. In the step above, you said that you modified the configure file to point to the correct path, and that you also modified configure.wrf. Can you issue a "clean -a" and then reconfigure, and this time DON'T modify the configure.wrf file in any way, and then compile again to see what happens? When it fails again, please send the new configure.wrf and compile log. Thanks!
 
Hi,
The error related to cpp was the first error I got and I found that the location of cpp in my machine is different so I changed the path in configure.wrf from
Code: 
CPP             =      /lib/cpp -P -nostdinc

to this

Code: 
CPP             =      /lustre/sw/gcc/8.2.0/bin/cpp -P -nostdinc

this solved the cpp error. After fixing this issue I recompiled.
That gave me error at 4 other places in the log.compile file which I attach below.


View attachment configure_wrf_13102020.wrf
View attachment log_compile13102020.compile

Thank you for the help.

Prerita
 
Hi,

Update - I was able to solve the error.
I had to Copy landread.c.dist to landread.c in share directory for WRFV3 and that solved the issue.
However, I am not sure what does that do? Does this mean moving nest option won't be available with this build?

I'd really appreciate any insights into this.

Thanks, Prerita
 
You must log in or register to reply here.
Top