I am using CMAQ to do the simulation for 01/01/2015 using the SMOKE output files generated by myself. I ran the benchmark case successfully. I ran SMOKE several times and the output looked normal but I got the error “CGRID file not written” all the time. Here is the script I am using and the log files I got (cctm.log.20150101.txt (11.2 KB) CTM_LOG_000.v53_intel_2015_12US1_459X299_20150101.txt (10.0 KB) run_cctm_2015_12US1_459X299.csh (32.0 KB) ). Would so appreciate it if you can take a look at them and tell me what I should do next.
Hi Qian,
It looks like you are trying to run this case on 1 processor. The CGRID file not written message is an error message that is written out on the second day, as it can’t find the initial condition file to start. The problem is that the first day run failed.
Please change the end date to 2015-01-01 to run for only 1 day.
change
set END_DATE = "2015-01-02"
to
set END_DATE = "2015-01-01"
There is not enough information in your log file to determine why the model is crashing, but I would guess that there is not enough memory on your machine to run this case on 1 processor. Can you try to run on 16 processors, and see if you get any further with the run? Change this line of your run script:
Thanks so much for your prompt response. I changed the script based on your suggestion but got the same error. Again, I did not find any error message in the log files for each processor.
There is no error message in the CTM_LOG or log file.
Please try compiling CMAQv5.2 using debug mode.
in the bldit_cctm.csh file, uncomment the line “#set Debug_CCTM”.
This changes the Fortran compiler flags from those defined as “myFSTD” to those defined as “myDBG” in config_cmaq.csh
Try to re-run the first day, and see if that provides any meaningful output.
Is there a reason you are using CMAQv5.2 instead of the latest release CMAQv5.3.2?
Thanks, Liz. So what I am using now is CMAQv5.3. Is there a big difference between v5.3 and v5.3.2? Anyway, I will follow your suggestion and compile v5.3.2 using debug mode.
Yes, that thread was also posted by me. I followed your suggestions to rerun the benchmark case and it worked. I also rerun SMOKE to generate the emission files and they look normal. Because the issue was not solved, I posted a new thread. I will use the latest version of CMAQ and let you know if the issue is solved.
I have complied CMAQ5.3.2 and ran the benchmark case successfully. However, I still got the “==d== NO ncols nrows” (CTM_LOG_029.v532_intel2018_2015_12US1_459X299_20150101.txt (9.6 KB) log.201501.txt (13.1 KB) ). Since the program stopped after reading the initial condition file, I am wondering if there is something wrong with it. However, I checked it with ncdump and Verdi and could figure out whether it is normal or abnormal. So I attached it here (https://drive.google.com/file/d/1M_CsZ_W5yiTu6vfXx-qUB3q-S05I84Mh/view?usp=sharing) and will so appreciate it if you can take a look at these log files and input file.
Hi Qian,
Looking at the log file and the code, it seems that there is an inconsistency in the grid definition (defined in the GRIDDESC) and your METCRO2D file.
Further examination of the log files show the METCRO2D file with inconsistent horizontal grid definition. The met files computed at the cross points should be one smaller than the dot points. Looking at the log files I see METCRO2D has:
460x300x1
This is inconsistent with the definition provided here:
&
The generated METCRO2D file should be 459x299x1.
Did you use MCIP to generate these files or did you manually generate them?
Thanks for spending time looking at them. I actually download the data from cmas data warehouse and it is for 2015 using 12US1. Do you know how these met data files are generated?
"MET_CRO_3D" opened as OLD:READ-ONLY
File name "/rsstu/users/f/fgarcia4/garcia_grp/ERCOT_EJ/cmaq-5.3-intel2017/CMAQ_REPO/data/2015_12US1_459X299/met/METCRO3D.12US1.35L.150101"
File type GRDDED3
Execution ID "mcip"
Grid name "METCRO_12US1_CRO"
Dimensions: 299 rows, 459 cols, 35 lays, 17 vbles
And here is the header from MET_CRO_2D:
"MET_CRO_2D" opened as OLD:READ-ONLY
File name "/rsstu/users/f/fgarcia4/garcia_grp/ERCOT_EJ/cmaq-5.3-intel2017/CMAQ_REPO/data/2015_12US1_459X299/met/METCRO2D.12US1.35L.150101"
File type GRDDED3
Execution ID "mcip"
Grid name "GRIDOUT_12US1_DO"
Dimensions: 300 rows, 460 cols, 1 lays, 9 vbles
These should have the same dimensions, but they do not. They really should come from the same execution from MCIP; the fact that they have different values for “Grid name” indicates they are from different executions of MCIP.
Thanks for pointing it out. I just checked all the met files and found that all the met files from the CMAS warehouse have different grid names. CRIDBDY2D, GRIDCRO2D, METBDY3D, and METCRO3D have a dimension of 459X299, consistent with the domain in my setting. However, GRIDDOT2D, METCRO2D, and METDOT3D have a dimension of 460X300. As I said these files were downloaded from the data warehouse, I did not have the original WRF output. Is there a way to convert the dimension without running WRF and MCIP?
As Liz said, the DOT files should have one more column and row than the CRO and BDY files. The problem is your METCRO2D file.
Yes, it is possible to subset the file, assuming it overlaps the area you need, using a tool such as m3wndw. But this inconsistency really should not occur. You need a consistent set of meteorological input files to run CMAQ.
Double check to make sure you downloaded all files from the same directory on the CMAS warehouse. If so, I’ll let Liz or someone else from CMAS comment on how to resolve the issue. Be aware that tomorrow is a federal holiday, so further responses may be delayed.
Yes, I just checked and only issue is from METCRO2D files. I downloaded the met files again and it solved this problem for now. Thanks so much, @cgnolte and @lizadams!
