You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
(RESOLVED) Problem Compiling WRFV4.0 on Fedora 28: landread error
- Thread starter chee10
- Start date
preritaagarwal
Member
Hi,
I am not using the moving nest option and perhaps may not require for my purpose.
To confirm, given this my build should work fine for basic nesting?
Just to reiterate I solved by copying the contents of landread.c.dist to landread.c in share directory in WRFV3.
I also had to change the paths of CPP, types.h files in the source code.
Thanks,
Prerita
I am not using the moving nest option and perhaps may not require for my purpose.
To confirm, given this my build should work fine for basic nesting?
Just to reiterate I solved by copying the contents of landread.c.dist to landread.c in share directory in WRFV3.
I also had to change the paths of CPP, types.h files in the source code.
Thanks,
Prerita
Hi,
I want to report that I met the same issue but solved it by modifying the configure.wrf
Our cluster/HPC just migrating from CentOS 7 to CentOS8 and then I got this problem. And thanks for the developers, I can fix it without pain.
WRF version: 3.7.1
cat /etc/os-release
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
I want to report that I met the same issue but solved it by modifying the configure.wrf
Our cluster/HPC just migrating from CentOS 7 to CentOS8 and then I got this problem. And thanks for the developers, I can fix it without pain.
WRF version: 3.7.1
cat /etc/os-release
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
MichaelIgb
New member
Hey, how did you copy the landread.c.dist to the landread.c?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
preritaagarwal
Member
Hi MichaelIgb,
Just cd share/ and do cp landread.c.dist landread.c
Prerita
Just cd share/ and do cp landread.c.dist landread.c
Prerita
MichaelIgb
New member
I tried this earlier, and it did not work unfortunatelyHi MichaelIgb,
Just cd share/ and do cp landread.c.dist landread.c
Prerita
@MichaelIgb
If the "cp" command is not working on your system, you will need to talk to a systems administrator at your institution to see if they can help.
If the "cp" command is not working on your system, you will need to talk to a systems administrator at your institution to see if they can help.
preritaagarwal
Member
Hi there!I tried this earlier, and it did not work unfortunately
It may also be useful to do a
$grep -C2 Error compile.log to check where the error is coming from.Prerita
RSAPIAIN_DMC
New member
Hello!
I'm new in here, and this thread gave me ideas (had this issue as well, and it seems the scenario of the institution requires using landread.c).
Also, maybe it's a known issue: WRF seems to build only with libjasper v1.900.1 (built from source); it should work until 1.900.24, but I haven´t been able to wrap my head around how cmake works for building the lib, also in a custom path.
In case someone needs to build with the landread.c (without having any LANDREAD_STUB), there are some modifications to be made both to the Operating System and the resulting WRF build configuration.
Also built with variables
I tested my build in Rocky Linux 9, but should work for most operating systems that had the rpc/types.h and other headers inside ''/usr/include/tirpc" instead of "/usr/include/"
It also workarounds an issue that maintainers seem to be unaware of:
I include my configure.wrf as reference (for 4.5.1; I guess that some extra changes should be made for 3.9.1.1)
1.- Changes in configure.wrf:
Add explicit linking to libtirpc in LIB_EXTERNAL: -L/usr/lib64 -ltirpc (Rocky9 has them in that path, check in your case/system).
2.- Workaround for .h files: Create symbolic links as root:
Not elegant, but gets the job done... until the maintainers of every OS fix the issue in their respective versions/distros.
I assume that you know that working as root, you should be very careful.
Press the button below to see:
After creating all the previous symlinks, WRF should compile and work as in CentOS/RHEL 7 systems.
I'm new in here, and this thread gave me ideas (had this issue as well, and it seems the scenario of the institution requires using landread.c).
Also, maybe it's a known issue: WRF seems to build only with libjasper v1.900.1 (built from source); it should work until 1.900.24, but I haven´t been able to wrap my head around how cmake works for building the lib, also in a custom path.
In case someone needs to build with the landread.c (without having any LANDREAD_STUB), there are some modifications to be made both to the Operating System and the resulting WRF build configuration.
Also built with variables
SFC = ifort
SCC = icc
CCOMP = icc
DM_FC = mpiifort
DM_CC = mpiiccI tested my build in Rocky Linux 9, but should work for most operating systems that had the rpc/types.h and other headers inside ''/usr/include/tirpc" instead of "/usr/include/"
It also workarounds an issue that maintainers seem to be unaware of:
- There are interdependencies inside the tirpc package header files, that also do #include <rpc/types.h> instead of #include <tirpc/rpc/types.h> (it made my builds fail several times, until I made a workaround in the system).
I include my configure.wrf as reference (for 4.5.1; I guess that some extra changes should be made for 3.9.1.1)
1.- Changes in configure.wrf:
Add explicit linking to libtirpc in LIB_EXTERNAL: -L/usr/lib64 -ltirpc (Rocky9 has them in that path, check in your case/system).
2.- Workaround for .h files: Create symbolic links as root:
Not elegant, but gets the job done... until the maintainers of every OS fix the issue in their respective versions/distros.
I assume that you know that working as root, you should be very careful.
Press the button below to see:
cd /usr/include
ln -s tirpc/netconfig.h netconfig.h
cd /usr/include/rpc
ln -s ../tirpc/rpc/auth_des.h auth_des.h
ln -s ../tirpc/rpc/auth_gss.h auth_gss.h
ln -s ../tirpc/rpc/auth.h auth.h
ln -s ../tirpc/rpc/auth_unix.h auth_unix.h
ln -s ../tirpc/rpc/clnt.h clnt.h
ln -s ../tirpc/rpc/clnt_soc.h clnt_soc.h
ln -s ../tirpc/rpc/clnt_stat.h clnt_stat.h
ln -s ../tirpc/rpc/des_crypt.h des_crypt.h
ln -s ../tirpc/rpc/des.h des.h
ln -s ../tirpc/rpc/key_prot.h key_prot.h
ln -s ../tirpc/rpc/nettype.h nettype.h
ln -s ../tirpc/rpc/pmap_clnt.h pmap_clnt.h
ln -s ../tirpc/rpc/pmap_prot.h pmap_prot.h
ln -s ../tirpc/rpc/pmap_rmt.h pmap_rmt.h
ln -s ../tirpc/rpc/raw.h raw.h
ln -s ../tirpc/rpc/rpcb_clnt.h rpcb_clnt.h
ln -s ../tirpc/rpc/rpcb_prot.h rpcb_prot.h
ln -s ../tirpc/rpc/rpc_com.h rpc_com.h
ln -s ../tirpc/rpc/rpcent.h rpcent.h
ln -s ../tirpc/rpc/rpc.h rpc.h
ln -s ../tirpc/rpc/rpc_msg.h rpc_msg.h
ln -s ../tirpc/rpc/rpcsec_gss.h rpcsec_gss.h
ln -s ../tirpc/rpc/svc_auth_gss.h svc_auth_gss.h
ln -s ../tirpc/rpc/svc_auth.h svc_auth.h
ln -s ../tirpc/rpc/svc_dg.h svc_dg.h
ln -s ../tirpc/rpc/svc.h svc.h
ln -s ../tirpc/rpc/svc_mt.h svc_mt.h
ln -s ../tirpc/rpc/svc_soc.h svc_soc.h
ln -s ../tirpc/rpc/types.h types.h
ln -s ../tirpc/rpc/xdr.h xdr.h
mkdir /usr/include/rpcsvc
cd /usr/include/rpcsvc
ln -s ../tirpc/rpcsvc/crypt.h crypt.h
ln -s ../tirpc/rpcsvc/crypt.x crypt.x
After creating all the previous symlinks, WRF should compile and work as in CentOS/RHEL 7 systems.
Attachments
I thought it would be helpful to report that the solutions mentioned in this thread worked for me when compiling WRF v3.9.1.1 for ideal simulations on NCAR's HPC Casper.
Specifically, I did the following:
I was able to compile for option 13 (serial, intel). I did not try the parallel option.
Specifically, I did the following:
- load module intel-classic
- replace the files in arch/ with those in this commit: BF full landread.c file should not be compiled by default by davegill · Pull Request #766 · wrf-model/WRF (the files I had looked very different, so I just updated those two files entirely)
- check for -DLANDREADSTUB in configure.wrf (I think I still had to include it)
- Lastly, copy landread.c.dist to landread.c in share directory
I was able to compile for option 13 (serial, intel). I did not try the parallel option.