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

Bug in WRF-Chem 4.0, I/O NetCDF files capped to 3000 variables

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.


New member
Dear WRF users,

There is a bug in the WRF ARW 4.0 I/O code when using WRF-Chem, in


The following test does not function properly, and even when WRF_CHEM is set to 1 it defaults to the #else case.

#if(WRF_CHEM == 1)
  integer                , parameter      :: MaxVars          = 10000
  integer                , parameter      :: MaxVars          = 3000

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:

  !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