I’m currently testing some simulation cases using CMAQ-ready inputs from EQUATES with ptfire emissions turned off. However, the simulations crash due to the presence of NaN or Infinity values in the HADV.
For instance, I found that the BCON_CONC_12US1_CMAQv53_TS_108NHEMI_regrid_201611.nc file contains some extreme values (e.g., -9.99900E+36). I’ve attached the relevant log files for your reference:
Strangely, the CMAQ run completes successfully when all emission sources are included, which makes the issue even more puzzling.
Do I need to force all Infinity or fill-value placeholders to zero in the BCON file? Are there any recommended tools or workflows for identifying and correcting these problematic values? Also, do you have any insights into why this might occur only when ptfire emissions are excluded?
could you please provide more information about which time steps and variables you see -9.99900E+36 values for in file BCON_CONC_12US1_CMAQv53_TS_108NHEMI_regrid_201611.nc? I checked the copy of that file on our tape archive as well as the EQUATES CMAS warehouse gdrive folder and could not see any missing time steps in the file that would be the typical cause for such behavior, but I may be overlooking something.
Looking at your CTM_LOG file, I noticed that the run is still specifying a PT_WILDFIRES file (/home/jh94030/scratch/CMAQ-input/emis/12US1/nc_classic/2016/ptfire-wild/inln_mole_ptfire-wild_20161116_12US1_cmaq_cb6ae7_2017gb_17j.nc). I also noticed that this file, in contrast to all other file files (ptagfire, ptfire_grass, ptfire_othna) has a start date of November 15 for the file labeled 20161116. This is not a problem per se because of the use of the symbolic emission date flag, but I’m curious which approach you took to set up your run with ptfire turned off vs. the base run which didn’t crash. Did you manually modify the emissions in the ptfire-wild file to set them to zero, rather than just not specifying a ptfire input file or zeroing it out with DESID? In case you manually modified one or more of the emissions files for your run with ptfire turned off, the problem may originate there, though your observation of -9.99900E+36 values in the BCON file also needs to be investigated.
I used m3stat to find some infinite values existing in the variable W_VEL from BCON files, for example:
File: INFILE (BCON_CONC_12US1_CMAQv53_TS_108NHEMI_regrid_201611.nc)
Date and time:2016323:000000 0:00:00 Nov 18, 2016
Variable: W_VEL 3-D boundary statistics
Max 0.00000E+00 @(c,r,l)=(460,271, 34)
Min -9.99900E+36 @(c,r,l)=( 39, 0, 3)
Mean -7.44039E+34
Sigma Infinity
Just wanted to clarify that I only turned off the ptfire-rx emissions as I separated ptfire-wild and ptfire-rx emission inventories and ran the SMOKE accordingly using the methods from my previous post: Ptfire Inventory Formatting Issues (2017 platform) - SMOKE / Emissions Inventory - CMAS CENTER FORUM. The other files with date stamps, such as ptagfire, ptfire_grass, ptfire_othna, were directly downloaded from the EQUATES CMAS warehouse gdrive folder without any modifications.
ah, I see. Yes, the W_VEL variable in the BCON files has bad/missing values at the first hour of each day, but that variable is not read in by CMAQ. It was written as a diagnostic variable to the 108 km hemispheric CMAQ 3D CCTM_CONC files from which the EQUATES boundary conditions were generated, and in that CMAQ version, this diagnostic variable did not have a meaningful value at the first hour of each day. The BCON program passed through this W_VEL variable to the BCON_CONC_12US1_CMAQv53_TS_108NHEMI_regrid files but it is ignored when CMAQ reads the boundary conditions since it is not a chemical species.
So, these bad/missing WVEL values in the BCON files are not the cause of the CMAQ crash. The fact that you ended up generating a new emissions file that’s used in the run that crashes vs. using only EQUATES emission files in the run that didn’t crash does point to a problem with this new emissions file. Can you clarify why you are trying to use the wildfire emissions for November 15 when you are modeling November 16? These types of representative day emissions supported by CMAQ usually aren’t used for sectors like fires or EGUs for which detailed temporal activity and emissions information is available.
"STK_EMIS_005" opened as OLD:READ-ONLY
File name "/home/jh94030/scratch/CMAQ-input/emis/12US1/nc_classic/2016/ptfire-wild/inln_mole_ptfire-wild_20161116_12US1_cmaq_cb6ae7_2017gb_17j.nc"
File type GRDDED3
Execution ID "????????????????"
Grid name "12US1"
Dimensions: 203 rows, 1 cols, 1 lays, 62 vbles
NetCDF ID: 1769472 opened as READONLY
Starting date and time 2016320:000000 (0:00:00 Nov 15, 2016)
Timestep 010000 (1:00:00 hh:mm:ss)
Maximum current record number 25
STK_EM_SYM_DATE_005 | T
I identified the issue. It is related to the timestamp shift I applied. I had shifted the November and December 2017 ptfire-wild emissions to align with the corresponding 2016 emissions files (a leap year), which introduced a one-day gap that needs to be addressed.
However, I do not believe this is the root cause of the modeling crashes, as other simulation cases are encountering the same issue even when starting from 2017-03-16.
thanks. Is there anything unusual you see when you run m3stat on one of the new emissions file you created? Which tool(s) did you use to create these new emissions files - SMOKE, custom python code? Your other post suggests you used SMOKE after updating the inventory by removing the prescribed fies, but didn’t go into specific details.
As a further test, what happens when you modify your “no fire” case run script by removing the file you created while keeping the EQUATES files and then run it again?