(RESOLVED) Error in ext_pkg_write_field

[francescomaicu]

HI everyone,
maybe the title id misleading because the issue is crosscutting between METGRID and GEOGRID.
I have to compare two runs of WRF on the same domain, one with WRF3.5.1 and the other with WRF4.1 .
The run with WRF4.1 was successfully ended.
I figure that it is necessary to recreate the input file (domain and meteo files) using ungrib and metgrid with their own tables.
This means the Vtable.GFS_new since I use GDAS data of september 2020, and the METGRID.TBL.ARW of the WPS3.5.1 release (bacause I want to run WRF3.5.1).
Metgrid doesn't work, there is a problem (I guess) with a landmask.
I supposed I could use the same domain file generated for the 4.1 run.
So I came to GEOGRID and my question is: have I to regenerate the domain with GEOGRID of WPS3.5.1 ? In case i have to generate a new domain, shall I use the most recent static data, and with which GEOGRID.TBL I have to use? The one of WPS3.5.1 or WPS4.1?
Thank you very much

 

[kwerner]

Hi,
You should be able to use WPSV4.1 for both of your tests. The WPS is simply a pre-processor for the WRF code, so if you are wanting to compare output for WRF versions, you can just use the same met_em* files for both versions of WRF. This is probably what you should do, anyway, as the default static data for WPSV3.5.1 was USGS, and in V4.1, the default is MODIS. You will want your input to be identical to make model comparisons.

 

[francescomaicu]

Hi,
You should be able to use WPSV4.1 for both of your tests. The WPS is simply a pre-processor for the WRF code, so if you are wanting to compare output for WRF versions, you can just use the same met_em* files for both versions of WRF. This is probably what you should do, anyway, as the default static data for WPSV3.5.1 was USGS, and in V4.1, the default is MODIS. You will want your input to be identical to make model comparisons.

Hi,
My apologise because I'm pretty sure that this is not a problem of land mask, as I wrote in the post title.
Definitely metgrid is not able to write the netcdf, as shown in the last line of the log file.
This is a cross-cutting issue I'm experiencing in the WRF/WPS_3.5.1 installation/compilation.
metgrid, real and wrf are not able to write netcdf files.
geogrid works
Please take a look to my other post
https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=40&t=9792

 

[kwerner]

Hi,
I was able to take a look at your namelist.input file from the other forum thread you mentioned. Based on the size of your domain and the high resolution, I would assume your output files are very large. Prior to V3.9, it was not default for the code to compile with large-file support, but it is now. Large-file support allows files to be written that are larger than 2 GB. I am not certain, but I suspect this is the issue. Try recompiling WPS and WRF with large-file support. You'll need to clean the code (./clean -a), then issue
setenv WRFIO_NCD_LARGE_FILE_SUPPORT 1
or if using bash,
export WRFIO_NCD_LARGE_FILE_SUPPORT=1

and then reconfigure and recompile WRF, and then WPS. If you happen to log-out of your terminal window or machine, you'll need to issue the above setting again before compiling. Once that is done, try to run metgrid and then real again.

 

[francescomaicu]

Dear kwerner,
I can definitely affirm the issue is solved.
Two findings to highlight for WRF3.5.1 (in my specific case):

• In my case the module containing the netcdf library: intel19.5/netcdf/C_4.7.2-F_4.5.2_CXX_4.3.1 was not able to compile any executables. (I still have some doubt because of a previous successful compilation...)

• the module intel20.1/netcdf/C_4.7.4-F_4.5.3_CXX_4.3.1 is able to compile correctly the executables, BUT it was absolutely necessary to export the variable WRFIO_NCD_LARGE_FILE_SUPPORT=1 to make real.exe, wrf.exe to write the nc files

Thank you very much

 

[kwerner]

I'm so glad you were able to resolve the problem. Thank you for updating the post.