MCIP and CCTM issue for CMAQ version 5.2.1

Hy @hogrefe.christian @tlspero @cjcoats ,

I’ve used the nested domain this time to run CCTM and that XCENT issue has been resolved. However, I’m having a new issue after running CCTM.

The error is like:

 Error opening file at path-name:

 netCDF error number  -51  processing file "INIT_GASC_S"

 NetCDF: Unknown file format

 NetCDF: Unknown file format

The file at that location is ICON file that I generated after running ICON program. Similarly the error also shows for BCON file. I’ve checked both ICON and BCON files using ncdump and they looks fine to me.

I’ve attached all the error in a log file using grep -i error -B 10 -A 10 CTM_LOG* command

I’ve also attached my CCTM script with this email.

Can you let me know what to do?cctm-error.log.txt (291.6 KB) run_cctm_rasel.csh_sbatch.txt (27.7 KB)

Was the same set of netCDF libraries used to build the CCTM and ICON EXEs? And was it configured with
–disable-netcdf4 --disable-dap?

@cjcoats
Yes. the same set of netCDF libraries were used to build the CCTM and ICON.exes. It was configured using --disable-netcdf-4 --disable-dap

Then the next question is: what can you tell me about that input-file –
are you sure that ICON completed successfully, with a “success” message from M3EXIT? What does ncdump -h say about this file?

@cjcoats

ICON completed successfully. The error file was asking for INIT_GASC_S which is required for CCTM-DDM run. However, I set my NEW START as True. Therefore it shouldn’t ask for these files. I use run_cmaq_rasel.sh script to run run_cctm_rasel.csh_sbatch script. And I set NEW_START as TRUE in run_cmaq_rasel.sh script. (See the attached files).

run_cmaq_rasel.sh.txt (794 Bytes) run_cctm_rasel.csh_sbatch.txt (27.5 KB)

What does ncdump -k tell you for these two files?

@hogrefe.christian

It’s saying classic.

ncdump -k ICON_v52_AQF5X_profile
classic

I need to apologize that I did not read your post and the run scripts and log files you posted carefully enough. Reading them now, it seems you are trying to perform a CMAQ DDM simulation for 6/1/2020, and as you mentioned the error messages you posted actually relate to the code trying to open the DDM sensitivity coefficient restart and boundary condition files, not the concentration initial concentration file generated by ICON.

The approach you use, i.e. calling run_cctm_rasel.csh_sbatch with run_cmaq_rasel.sh providing FALSE as the second argument value to be used by run_cctm_rasel.csh_sbatch to set NEW_START to FALSE, should work. Can you find a reference to the IC file for concentrations (ICON_v52_AQF5X_profile if NEW_START = TRUE) being successfully opened in your run logs?

You are correct that the CMAQ-DDM-3D section of the run script should set DDM3D_RST to N and INIT_*_S and BNDY_*_S to empty strings for the case when NEW_START = TRUE. I don’t know how the DDM code is set up, but I’m wondering if the errors being reported in the CTM_LOG_* files about INIT_*_S and BNDY_*_S not being ncf files actually are the cause of the crash rather than (expected though confusing) behavior in this case.

What are the errors reported in your SBATCH log files (jCMAQ-5.2-%N-%j.out and jCMAQ-5.2-%N-%j.err)?

Can you search your log file to see what “INIT_GASC_S” is set to? Or even better, please, post the full CTM_LOG_001.v52_gcc_AQF5X_20200601 file here.

Sergey

@sergey @hogrefe.christian @cjcoats

I think INIT_GASC_S is not a problem. In my log files please see row 618 where the grid cells are not aligned with each other. It’s saying:

Inconsistent values for GL_NCOLS: 442 versus 178
Inconsistent values for GL_NROWS: 265 versus 118
Inconsistent values for XORIG: -2.5080E+06 versus -1.8600E+05
Inconsistent values for YORIG: -1.7160E+06 versus -1.0860E+06

—>> WARNING in subroutine FLCHECK on PE 001
Inconsistent header data on input files
M3WARN: DTBUF 12:00:00 June 1, 2020 (2020153:120000)

—>> WARNING in subroutine GET_EMIS:INTERPX
Bad window dimension(s)
M3WARN: DTBUF 12:02:30 June 1, 2020 (2020153:120230)

My emission data is for the whole US domain. My modeling domain is a smaller domain. I think modeling grid definition is half cell off from the EMIS grid which is a problem needs to be solved. Is there any way I can resolve that? I’ve also included my MCIP script here.

CTM_LOG_001.v52_gcc_AQF5X_20200601.txt (75.0 KB) run_mcip_43.csh.txt (20.8 KB)

Yes, you are correct, your issue still is related to the one you posted about in your first post above (post #13). The origins of the two grids you’re using now for your attempted CMAQ run (MCIP / GRIDDESC vs. emission files) are indeed off by a non-integer multiple of the grid size (assuming you’re using a 12 km grid size as you mentioned before), so no windowing is possible.

What did you end up doing when you posted “I’ve used the nested domain this time to run CCTM and that XCENT issue has been resolved.”? We had recommended using m3wndw and bcwndw to subset the gridded files (MCIP, ICON, emissions, etc.) from your successful run for the full 12 km US domain to your desired smaller 12 km domain, assuming that the desired smaller domain is a subset of the larger domain.

It seems you may have rerun MCIP, and it seems you may have rerun WRF for a nested domain and created new wrfout files for that smaller domain and used those as input to MCIP since your BTRIM setting in the MCIP run script is zero and your post says that the new MCIP files have 178 x 118 grid cells. This is just speculation, you need to clarify what you did exactly.

What is your ultimate objective for running CMAQ on the smaller domain? Do you need to use different WRF fields than the ones you used for the successful run over the entire US, but want to keep (a windowed subset of) the same gridded emissions from that successful run? In that case, the issue goes back to defining a smaller WRF domain processed through MCIP that fits exactly within the larger grid. If you’re o.k. with reusing the gridded files from your large domain run (MCIP, emissions, etc.), the m3wndw / bcwndw approach would probably be the easiest to implement.

@hogrefe.christian
You are right. I’ve rerun WRF for a nested domain and created new wrfout files and then I ran MCIP, ICON, BCON on the new wrfout files. I normally get emission data from other sources and they run SMOKE for the whole US domain. In my case due to computational efficiency, I wanted to work on a smaller domain (mostly the eastern part of the US). After running CCTM with my newly created MCIP, ICON, and BCON file, I got the above-mentioned errors.

Is there any sample batch script for using m3wnd and bcwndw tools on MCIP, ICON, EMIS files of large domain?

You can find m3wndw and bcwndw documentation here:

m3wndw
bcwndw

As noted in that documentation, it’s always a good idea to run these interactively first before creating a batch script. Here is an example of a batch script windowing a certain set of gridded files from a full US 12 km domain to a 12 km subdomain over the Western U.S (“12WUS1”), where LOCOL, HICOL, LOROW and HIROW are 16, 240, 43, and 255 in this case . Note that there should be three blank lines between INFILE and 12US1, I can’t quite figure out the markdown formatting here.

#!/bin/csh

set INDIR = /work/MOD3DATA/2014_12US1/met/lightning
set OUTDIR = /work/MOD3DATA/2014_12WUS2/met/lightning
cd $INDIR

foreach month (07 08)
foreach file (NLDN.12US1.2014${month}*)
set YYYYMMDD = echo ${file} | cut -f3 -d'.'
setenv INFILE $INDIR/$file
setenv OUTFILE $OUTDIR/NLDN.12WUS2.$YYYYMMDD.ioapi

m3wndw << EOF
INFILE

12WUS2
16
240
43
255
OUTFILE
EOF
end
end

There are program-manuals, in the expected place:
https://cjcoats.github.io/ioapi/BCWNDW.html
https://cjcoats.github.io/ioapi/M3WNDW.html

The programs begin with a brief “splash screen” that describes usage; they are intended to be run interactively from the command line.

And if you do have access to the original large domain wrfout files, it might be faster to rerun MCIP using these as inputs and defining your desired subdomain by setting BTRIM to -1 and making use of the X0, Y0, NCOLS and NROWS run script parameters to prepare MCIP files for your desired subdomain. With the m3wndw/bcwndw approach, you’ll have to do separate setups to create the METBDY, DOT, and CRO files as well as potentially adapt your run scripts to handle the time-dependent MET vs time-independent GRID files.

Hello,

I’m facing an issue with my CCTM run. I’m trying to run the CCTM from June 4, 2020, to June 6, 2020. My emission datasets are for the whole US domain. However, my mcip files are for a smaller subdomain of the whole US domain. I made sure my grid cells aligned with each other so that interpx can do a windowing process. My job runs fine for the first day (June 4, 2020) but when it goes to June 5, 2020, then jobs get terminated. I’ve tried to look into LOG files, job output files but couldn’t figure out what went wrong.

Can you please take a look at my scripts and log files and see if you can find something that’s causing an error in my run?

Thanks,
Rasel
run_cmaq_rasel.sh.txt (797 Bytes)
run_cctm_rasel_all.csh_sbatch.txt (27.9 KB)
jCMAQ-5.2-NODE045-479076.err.txt (52.3 KB)
jCMAQ-5.2-NODE045-479076.out.txt (876.0 KB)
CTM_LOG2.txt (542.4 KB)
CTM_LOGS.txt (403.3 KB)

Here’s the problem (“My emission datasets are for the whole US domain”):

"EMIS_1" opened as OLD:READ-ONLY   
     File name "/scratch/mrasel/data/cmaq/tempcmaqdata/emis/all/emis_mole_all_20200604_AQF5X_nobeis_2016fh_16j.ncf"
     File type GRDDED3 
     Execution ID "????????????????"
     Grid name "AQF5X"
     Dimensions: 265 rows, 442 cols, 1 lays, 62 vbles
     NetCDF ID:    524288  opened as READONLY            
     Starting date and time  2020156:120000 (12:00:00  June 4, 2020)
     Timestep                          010000 (1:00:00 hh:mm:ss)
     Maximum current record number        25
     Checking header data for file: EMIS_1
         Inconsistent values for GL_NCOLS: 442 versus 200
         Inconsistent values for GL_NROWS: 265 versus 120
         Inconsistent values for XORIG: -2.5080E+06 versus -5.2800E+05
         Inconsistent values for YORIG: -1.7160E+06 versus -1.1280E+06

You need to use M3Tools program m3wndw to window the emissions files to the grid of the (200x120) modeling domain.

Hy,

I’ve made sure my domain’s grid cell falls on my emission files grid cell so that interpx can do the windowing process.

I changed the date now to run the simulation from June 03 to 06, 2020, and what I’ve found is, the simulation runs ok for June 03, 2020 (12 UTC June 03 - 11 UTC June 04, 2020). Then it started to run the simulation for June 04 (12 UTC June 04). The model crashed at the first hour of June 05, 2020 (00 UTC June 05, 2020).

I’m still not sure if this has to do anything with my model domain or not. I made sure my domain’s grid cell falls on emission grid she’ll so that there is no problem with windowing. I’ve looked into my emission files and they seemed okay to me.

CTM_LOG_001.v52_gcc_AQF5X_20200606.txt (4.5 KB)
CTM_LOG_001.v52_gcc_AQF5X_20200605.txt (4.5 KB)
CTM_LOG_001.v52_gcc_AQF5X_20200604.txt (538.5 KB)
CTM_LOG_001.v52_gcc_AQF5X_20200603.txt (1.1 MB)


jCMAQ-5.2-NODE043-479229.err.txt (68.8 KB)
jCMAQ-5.2-NODE043-479229.out.txt (2.0 MB)
run_cctm_rasel.csh_sbatch.txt (29.5 KB)
run_cmaq_rasel.sh.txt (797 Bytes)

Please see the attached files.

Regards,
Rasel

That’s not the way it works.

Please go back and read the earlier reply: the emissions-file grid must be the same as the model-grid.

This was not a widely-advertised feature, but it used to be the case that CMAQ could accept input files that were aligned with but larger than the modeling domain specified via the GRIDDESC file. However, in restructurings that occurred with version 5.3, that functionality was dropped. A fix to restore that functionality has been prepared and is expected to be included in the next release.

In the meantime, you will need to do as suggested, which is to use m3wndw to window your emissions (and any other input files) so that they correspond to the same domain.