LouisMarelle
New member
Dear WRF users,
There is a bug in the WRF ARW 4.0 I/O code when using WRF-Chem, in
external/io_netcdf/wrf_io.F90
The following test does not function properly, and even when WRF_CHEM is set to 1 it defaults to the #else case.
This cannot be due to a mistake in setting WRF_CHEM in my compilation, because where #if(WRF_CHEM == 1) is tested elsewhere in the code it works properly. For now I have gone around this problem by removing the #if...#else test (defaulting to MaxVars = 10000). It seems like this was also a problem in earlier WRF versions, since I found the following comment in the same routine in 3.5.1, where no such test on the value of WRF_CHEM was present:
This causes problems when running WRF-Chem. Because of this bug, the number of variables in the wrfbdy file is capped to 3000, and when running real for the most heavy chemical mechanisms, the chemical boundary variables from WRF-Chem overwrite the dynamical boundary variables from WRF in the wrfbdy file. As a result, no QVAPOR*, T*, etc. variables are present in the wrfbdy file produced by real, and problems occur while running the wrf.exe step since these boundary conditions are set to strange values instead.
Another worrying problem is that no error message is displayed when running real (even though MaxVars is exceeded), or when running WRF (even though there is no boundary condition present for QVAPOR, T, etc. in wrfbdy). As a result the model did not even crash in my case, although the boundary condition for many variables was set to unrealistic values.
In case this helps, I experienced this issue with WRF Chem 4.0, compiled with INTEL (dmpar), on a Linux x86_64 cluster.
Best regards,
Louis Marelle
There is a bug in the WRF ARW 4.0 I/O code when using WRF-Chem, in
external/io_netcdf/wrf_io.F90
The following test does not function properly, and even when WRF_CHEM is set to 1 it defaults to the #else case.
Code:
#if(WRF_CHEM == 1)
integer , parameter :: MaxVars = 10000
#else
integer , parameter :: MaxVars = 3000
#endif
This cannot be due to a mistake in setting WRF_CHEM in my compilation, because where #if(WRF_CHEM == 1) is tested elsewhere in the code it works properly. For now I have gone around this problem by removing the #if...#else test (defaulting to MaxVars = 10000). It seems like this was also a problem in earlier WRF versions, since I found the following comment in the same routine in 3.5.1, where no such test on the value of WRF_CHEM was present:
Code:
!BSINGH - MaxVars variable decides maximum number of variables to be
!included in wrfbdy file. Presently set to 8000 to accomodate some of
!chemistry packages which have a lot of species. Please note that
!WRF_CHEM CPP directive doesn't work here (may be Makefile needs to be
!modified to accomodate WRF_CHEM)
This causes problems when running WRF-Chem. Because of this bug, the number of variables in the wrfbdy file is capped to 3000, and when running real for the most heavy chemical mechanisms, the chemical boundary variables from WRF-Chem overwrite the dynamical boundary variables from WRF in the wrfbdy file. As a result, no QVAPOR*, T*, etc. variables are present in the wrfbdy file produced by real, and problems occur while running the wrf.exe step since these boundary conditions are set to strange values instead.
Another worrying problem is that no error message is displayed when running real (even though MaxVars is exceeded), or when running WRF (even though there is no boundary condition present for QVAPOR, T, etc. in wrfbdy). As a result the model did not even crash in my case, although the boundary condition for many variables was set to unrealistic values.
In case this helps, I experienced this issue with WRF Chem 4.0, compiled with INTEL (dmpar), on a Linux x86_64 cluster.
Best regards,
Louis Marelle