compressing wrf output NetCDF4 error in compilation for version 4.6.1

[epotter1]

Hi, I have configured and compiled WRFV4.5.1 (using GNU) without trouble. I would like to update to version 4.6.1, but I am getting an error:

NETCDF4 IO features are requested, but this installation of NetCDF
/opt/cray/pe/netcdf/4.9.0.1/gnu/9.1
DOES NOT support these IO features.

Please make sure NETCDF version is 4.1.3 or later and was built with
--enable-netcdf4

and then configure.wrf has been removed.

If I run with export NETCDF_classic=1 it configures and compiles, but my runs are quite large and the output files are now about 4 times larger than they used to be. Does anyone know what has changed between version 4.5.1 and 4.6.1 to cause this? I have checked I can reinstall 4.5.1, so the netcdf version hasn't changed.

Although the configure.wrf gets deleted from the version 4.6.1, if I pipe the output to an error log the two scripts (v4.5.1 and v4.6.1) are identical except this error message.

Is there any other way to compress WRF output?

 

[epotter1]

Has anyone else had this problem? I ended up having to change the Makefile to be closer to version 4.5.1, but assume this would be a known bug if it was necessary. There might be an environment variable I haven't set correctly.

The 4.6.1 Makefile in WRF has on line 1074:

nc4_test:
if [ -z "$(USENETCDFPAR)" ] || [ $(USENETCDFPAR) -eq 0 ] ; then \
( cd tools ; /bin/rm -f nc4_test.{exe,nc,o} ; $(SCC) -o nc4_test.exe nc4_test.c -I$(NETCDF_C)/include $(NETCDF4_DEP_LIB) ; cd .. ) ; \
else \
( cd tools ; /bin/rm -f nc4_test.{exe,nc,o} ; $(DM_CC) -o nc4_test.exe nc4_test.c -I$(NETCDF_C)/include $(NETCDF4_DEP_LIB) ; cd .. ) ; \
fi

The 4.5.1 Makefile has

nc4_test:
if [ $(USENETCDFPAR) -eq 0 ] ; then \
( cd tools ; /bin/rm -f nc4_test.{exe,nc,o} ; $(SCC) -o nc4_test.exe nc4_test.c -I$(NETCDF)/include -L$(NETCDF)/lib -lnetcdf $(NETCDF4_DEP_LIB) ; cd .. ) ; \
else \
( cd tools ; /bin/rm -f nc4_test.{exe,nc,o} ; $(DM_CC) -o nc4_test.exe nc4_test.c -I$(NETCDF)/include -L$(NETCDF)/lib -lnetcdf $(NETCDF4_DEP_LIB) ; cd .. ) ; \
fi

I've changed my Makefile in 4.6.1. to

nc4_test:
if [ -z "$(USENETCDFPAR)" ] || [ $(USENETCDFPAR) -eq 0 ] ; then \
( cd tools ; /bin/rm -f nc4_test.{exe,nc,o} ; $(SCC) -o nc4_test.exe nc4_test.c -I$(NETCDF)/include -L$(NETCDF)/lib -lnetcdf $(NETCDF4_DEP_LIB) ; cd .. ) ; \
else \
( cd tools ; /bin/rm -f nc4_test.{exe,nc,o} ; $(DM_CC) -o nc4_test.exe nc4_test.c -I$(NETCDF)/include $(NETCDF4_DEP_LIB) ; cd .. ) ; \
fi

Does anyone know what the variable NETCDF_C in the original 4.6.1 Makefile is meant to refer to, and how the code is meant to point to the lib folder in netcdf? Just setting NETCDF_C to lead to the netcdf directory is not enough.

Any help much appreciated, I'm concerned I might be creating extra problems for myself by editing the netcdf tests without really knowing what I'm doing!

 

[islas]

@epotter1 Could you post the output of nc-config --all ? The NETCDF_C variable is meant to be used for when libnetcdf.* and libnetcdff.* are installed in two different locations (it doesn't actually work as expected as there is a bug).

You may also try using configure_new and compile_new (using CMake) to see if that works for your use case. The newer configuration methods [should] address most of these compilation issues.

 

[epotter1]

HI, thanks very much. I attach the output from nc-config --all, but can't see anything on it about libnetcdf.* etc.

I'm trying to use configure_new now, with the following options:

./configure_new
Select configuration [0-0] Default [0] (note !!) : 0
Select option for WRF_CORE from WRF_CORE_OPTIONS [0-4]: 0:ARW
Select option for WRF_NESTING from WRF_NESTING_OPTIONS [0-3]: 1: BASIC
Select option for WRF_CASE from WRF_CASE_OPTIONS [0-14]: 0: EM_REAL
[DM] Use MPI? Default [Y] [Y/n] : Y
[SM] Use OpenMP? Default [N] [y/N] : N
No extra configuration options.

This has given a number of errors, the key ones seem to be:
CMake Error at cmake/target_source_properties.cmake:41 (define_property):
define_property not given a BRIEF_DOCS <brief-doc> argument.

CMake Error at cmake/modules/FindnetCDF-Fortran.cmake:85 (string):
string sub-command REGEX, mode MATCH needs at least 5 arguments total to
command.


Are there any instructions on using configure_new or CMake? I'm struggling to match it up to the old configuration. I'm compiling the UK supercomputer, and in the old versions had to alter some options in configure.wrf:

# The configure option is "34": dmpar for gcc/gfortran
# but we must edit the resulting configure.wrf to replace
# gfortran by ftn etc. "mpicc -cc=$(SCC)" is just replaced
# by "cc"

sed -i s/gcc/cc/ configure.wrf
sed -i s/mpicc\ -cc\$\(SCC\)/cc/ configure.wrf
sed -i s/gfortran/ftn/ configure.wrf
sed -i s/mpif90/ftn/ configure.wrf


I'm not sure how this relates to what I'd need to to edit confingure_new?

 

[islas]

Your nc-config output looks fine, and given that you were using nc4 options before on v4.5.1 I suspect that the nc4_test itself has an error. When you configure there should be a tools/nc4_test.log file on a failed configuration. I believe that may have a compile failure unrelated to nc4 features but which is causing the configuration to incorrectly think the netCDF library caused the compile failure and thus does not support these features. Could you paste / upload the tools/nc4_test.log?


The following is a description of the CMake build, some of the issues you've encountered, and how you might adapt it to your system. While it does improve upon the build flow of WRF, it is still new and is actively being fixed as more people use it in a variety of environments. The fixes noted below have yet to go into an official release, but are available in the develop branch right now.

---

For the new configuration, the docs are in doc/README.cmake_build
One of the errors you are getting is addressed in CMake Add documentation to custom defined properties by islas · Pull Request #2131 · wrf-model/WRF for the BRIEF_DOC issue. The other.. I'm not sure. It seems like the output of nf-config --flibs may be empty. I'd be interested in seeing the output of nf-config (note: nf-config does not have an --all option) to make sure a fix can be made if needed.

To match the new configuration method to the old, you can either modify (by default) _build/wrf_config.cmake (this is the CMake equivalent of configure.wrf that takes the selected stanza and feeds it into the configuration) or modify the stanzas directly. The sed commands you've outlined should work on the _build/wrf_config.cmake file (save for maybe sed -i s/mpicc\ -cc\$\(SCC\)/cc/ configure.wrf : this is addressed in CMake Fix split command flags to be correctly populated by islas · Pull Request #2108 · wrf-model/WRF)

Stanzas in the new method are assigned a number for command line selection purposes only, but these cannot be correlated to the original "34"/dmpar/gcc/gfortran selections. Instead, they are uniquely identified by their DESCRIPTION in arch/configure.defaults, e.g.

 1967  ###########################################################
 1968  #ARCH    CYGWIN_NT i686 x86_64 Cygwin, gfortran compiler with gcc  #serial smpar dmpar dm+sm
 1969  #
 1970  DESCRIPTION     =       GNU ($SFC/$SCC)
 1971  DMPARALLEL      =       # 1
 1972  OMPCPP          =       # -D_OPENMP
 1973  OMP             =       # -fopenmp
 1974  OMPCC           =       # -fopenmp
 1975  SFC             =       gfortran
 1976  SCC             =       gcc
 1977  CCOMP           =       gcc
 1978  DM_FC           =       mpif90
 1979  DM_CC           =       mpicc

which is often referred to as 34 when selecting the dmpar compilation would now be:

./configure_new 
Using default build directory : _build
Using default install directory : /home/aislas/wrf-model/wrf_alt/install
0   Linux         gfortran    /    gcc         /    mpif90      /    mpicc      GNU (gfortran/gcc)
!! - Compiler not found, some configurations will not work and will be hidden
...some options later...
[DM] Use MPI?    Default [Y] [Y/n] :y
...

where we've selected GNU (gfortran/gcc) (option 0) with dmpar/MPI selected later.

 

[epotter1]

Hi,

Thanks very much for your help. I attach the nc4_test.log. After changing the Makefile as I discussed in the first post, WRF and WPS have compiled successfully. Assuming WRF runs as expected, is there any obvious danger to having configured like this? It appears, as you mentioned, to be the test that's causing problems, not the actual netcdf setup, but I'm not sure if this might cause unexpected problems?

I'm happy to keep testing and trying to fix configure_new if it's helpful to know how it behaves on different machines, but I'm keen to start my WRF runs at the same time as a few people are waiting for the data!

------------------------------------------------------------------------------------------------

I've edited the target_source_properties.cmake file as described in the post you linked, which seems to have solved that error, and I think you're correct about the flibs, here is the nf-config file:



This netCDF-Fortran 4.5.3 has been built with the following features:

--cc -> cc
--cflags -> -DpgiFortran

--fc -> ftn
--fflags ->
--flibs ->
--has-f90 ->
--has-f03 -> yes

--has-nc2 -> yes
--has-nc4 -> yes

--prefix -> /opt/cray/pe/netcdf/4.9.0.1/gnu/9.1
--includedir-> /opt/cray/pe/netcdf/4.9.0.1/gnu/9.1/include
--version -> netCDF-Fortran 4.5.3

 

[islas]

Yes, assuming both compiled well there should be no issue. You can use the compiled model as needed.

I think overall, the issues (both for the make system and the outstanding CMake issue) stem from the fact that both nf-config and nc-config have been created in such a way that the --flibs/--libs output on both, respectively, is blank. Looking at the code for each version, there doesn't seem to be any obvious way for that to occur outside of post-install manipulation:
netCDF @ v4.9.0 SHA netcdf-c/nc-config.in at d56c50491692659e3769750d44398ddd9c84d05e · Unidata/netcdf-c
netCDF-Fortran @ v4.5.3 SHA netcdf-fortran/nf-config.in at bcd4d91cbf018da1d9abeef41666e82e7a00f2fb · Unidata/netcdf-fortran

I suspect if you did less `which nf-config` (i.e. view the actual contents of the nf-config command) and the same for nc-config the respective libs variable would be blank. I'm not sure how that happened, but may be something to ask your system administrators about.

A potential fix for the CMake build can be patched using the following fix :

CMake Better nf-config libdir detection by islas · Pull Request #2161 · wrf-model/WRF

TYPE: enhancement KEYWORDS: cmake, netcdf, netcdf-fortran, nf-config SOURCE: internal DESCRIPTION OF CHANGES: Problem: As nf-config does not provide an equivalent --libdir output we must derive the...

github.com

Given the nature of the bug, I will be noting the fix as an enhancement rather than a bug.