Error in compiling WRF: make: *** [Makefile:68: configcheck] Error 1

[beuraieon_a]

Hello, I need assistance with an error I encountered when I tried to compile WRF. I already have WRF installed in my computer via an installation script by Hatheway et al. (2023); thus, all compilers and essential libraries were already installed/built. But it was configured with basic nesting.

I intended to configure and compile WRF with nesting as vortex following (with dmpar GNU compiler), having all relevant folders and files in a separate folder from the already installed WRF with basic nesting. The configuration was successful, but the compilation (./compile -j 2 em_real 2>&1 | tee compile.wrf1.log) ended with a error:

Neither WRF_EM_CORE nor WRF_PLUS_CORE
are explicitly specified in shell environment....

==============================================================================================

V4.5.2
No git found or not a git repository, git commit version not available.

Compiling: WRF_EM_CORE
WRFIO_NCD_LARGE_FILE_SUPPORT=1

Linux brianwrf 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

GNU Fortran (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


==============================================================================================

setting parallel make -j 2

==============================================================================================

The following indicate the compilers selected to build the WRF system

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

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

Fortran compiler for the model source code:
which FC
Will use 'time' to report timing information

C compiler for the model source code:
which CC
make: *** [Makefile:68: configcheck] Error 1

I have attached the configuration and compilation logs for your perusal. As a beginner in WRF and Linux, I am confused that such error occurred despite my compilers already present in the computer, so I really need your assistance on the procedure to properly troubleshoot this problem.

Thank you very much in advance.

 

[beuraieon_a]

Hello, I was able to solve this problem by editing the .bashrc file to ensure all compilers (including CC) and libraries that needed to be "exported" are present in the file. Now, I'm able to proceed to compilation.

I am still worried though about the "missing rpc/types.h" in the WRF configuration since I'm compiling WRF with the vortex following feature:

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.

Do I simply "copy landread.c.dist to landread.c in share directory", or are there other additional steps to solve this issue?

Thank you very much in advance for your response.

 

[beuraieon_a]

Hello, I successfully finished compiling WRF with the vortex following feature, despite the "missing rpc/types.h file" message in the configuration. Does this mean that WRF may still not function properly if I attempt to implement a moving nest for a tropical cyclone despite this successful compilation? Do I simply "copy landread.c.dist to landread.c in share directory" in order to solve the issue, or are there other additional steps for this? Also, by "copy" does it literally mean that I copy the contents (i.e. text) of the "landread.c.dist" file to the "landread.c" file?

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.

Thank you very much in advance for your response.

 

[kwerner]

Hi,
Yes, you will need to follow the instructions to copy landread.c.dist to landread.c in the share directory BEFORE you compile. Then issue a clean -a, then reconfigure for vortex-following, and then recompile.

 

[beuraieon_a]

Thank you for your response, I did exactly as you had recommended. But I noticed something odd about the model output of WRF vortex-following. I recently tried running WRF with vortex-following for an intense Western North Pacific tropical cyclone. And I observed that while the automatically moving nested domain did "automatically move" along with the cyclonic vortex, the nested domain remained stuck at its initial position (as set in the "namelist.wps") when I visualized it using post-processing tools. I was expecting that the nested domain will "move across the map" along with the movement of the cyclonic vortex being tracked.

This is shown in the attached GIF animation of the WRF output for 10-meter wind speed and direction. I also attached my namelist files for your perusal. I opted to apply the default vortex-following settings, that's why their relevant variables (vortex_interval, max_vortex_speed, track_level etc.) are not present in the &domains section of my "namelist.input" file.

I tried simulating Typhoon Surigae (2021) around the time when it was at its peak intensity (simulation period: 12:00:00 UTC 2021 April 17 to 12:00:00 UTC 2021 April 18), using GFS analysis as input data. As you can see in the animation, the nested domain automatically moved along with Surigae's vortex, but it appears to be stuck at its initial position off the eastern coast of central Philippines. I thought that the nested domain will also appear to translate across the map or across its parent domain, in unison with Surigae's movement. Since Surigae was moving northwestward during the simulation period, the rough "outlines" of Eastern Visayas and Bicol Region can be observed near the end of the animation (in the southwest corner of the nested domain) when Surigae was at its closest approach towards the Philippines.

I used Panoply for the visualization in the attached GIF animation. I also tried visualizing the WRF output using GrADS, but I still observed the same behavior of the nested domain appearing stuck at initial position.

So I'm wondering: is this how WRF vortex-following really works? Or is there a tool, technique or strategy that can be applied so that the automatically-moving nested domain will also appear to automatically move or track across the map along with the vortex's movement?

Thank you very much in advance for your responses and recommendations.

 

[kwerner]

Hi,
Since your new question is a different topic than the original question posted here, please open up a new thread to ask this question. This helps keeps threads organized with a single topic for each one, which makes is easier for others to search and read through when they experience similar issues. Thanks!