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
Prerita,
I believe that is what that means. Are you trying to compile with the moving nest option? In the configure.wrf files you sent, it looks like you are just compiling with the basic nesting option.
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.
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.
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?
@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.
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 = mpiicc
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:
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:
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:
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.