Hi,
I’m running CMAQ v5.3.2. The ICON/BCON running for ‘profile’ type was good, but it went wrong with ‘regrid’ mode. I recompiled it in debug version and got error message as follows:
forrtl: severe (408): fort: (3): Subscript #1 of the array VGDESC has value -9999 which is less than the lower bound of 1
Image PC Routine Line Source
ICON_v532.exe 000000000055513F Unknown Unknown Unknown
ICON_v532.exe 0000000000434D1E m3_vinterp_ 259 m3_vinterp.F
ICON_v532.exe 000000000042FB00 m3_icout_ 456 m3_icout.F
ICON_v532.exe 0000000000426557 m3_inic_ 304 m3_driver.F
ICON_v532.exe 000000000040FEF0 MAIN__ 142 icon.F
ICON_v532.exe 000000000040DDE2 Unknown Unknown Unknown
libc-2.17.so 00002BA7D6AB6505 __libc_start_main Unknown Unknown
ICON_v532.exe 000000000040DCE9 Unknown Unknown Unknown
I checked the files that ICON/BCON required and found that the values of these files for VGTYP (value of array VGDESC) are -9999 instead of 1-7 according to correspounding fortran scripts required. All the files generated by MCIP didn’t contain the correct value of VGTYP. Meanwhile i also received warnings in running MCIP: WARNING: Vertical grid/coordinate type: -9999 "MISSING" in file "MET_CRO_3D"
So i was wondering if i had any mistakes in setting MCIP run scripts or the output of wrf contained not vertical grid type. If so, how can I confirm the vertical grip type values in wrfout files?
MCIP and downstream CMAQ programs like ICON, BCON, and CCTM use VGTYP=-9999 to indicate the hybrid vertical coordinate system used as default in WRF starting with WRF version 4 (or thereabouts). The ICON and BCON handling of this VGTYP=-9999 indicator was updated in CMAQv5.3.3, so we recommend that you update your code to this latest version. For additional details, please see the relevant section of the CMAQv5.3.3 release notes.
Hi, I updated CMAQ to v5.3.3 and ran through mcip to generate corresponding files for ICON/BCON.
However this time i encoutered warnings and errors as follows:
` >>—>> WARNING in subroutine M3_VINTERP:INTERP3
Size error for ZH from MET_CRO_3D_CRS–REQ: 46689 ACT: 653646
M3WARN: DTBUF 0:00:00 Jan. 1, 2018 (2018001:000000)
*** ERROR ABORT in subroutine M3_VINTERP
Could not read layer heights from file MET_CRO_3D_CRS
Date and time 0:00:00 Jan. 1, 2018 (2018001:000000)`
Do you have any suggestions or solutions to this problem. I really appreciate it!
This looks like a grid-mixup between the MET_CRO_3D_CRS and the BCON run: check whether the grid descriptions from the file header (do the command ncdump -h $MET_CRO_3D_CRS) and from the BCON run are the same.
I’ve checked the METCRO3D files used for ICON/BCON, and there were ZH and PRES data. The values of ZH seemed to be fine. I have no idea what does the warning ‘size error for ZH’ mean.
Which fortran scripts in ICON/BCON should i check for errors besides M3_VINTERP.F
On the other hand, I’m using same file for MET_CRO_3D_CRS and MET_CRO_3D_FIN. Meanwhile the CONC file is also generated by these MCIP files. I’m wondering why i’m receiving message The COORD.EXT and CTM vertical grid types are different. Vertical interpolation using ZH from the MET_CRO_3D files. And how should i check the vertical grid type for these files?
I’m using same file for MET_CRO_3D_CRS and MET_CRO_3D_FIN
This does not work.
Among other things, the grid-dimensions for the CRS and FIN grids are different, and INTERP3 is complaining of a dimension-mismatch between what;'s on the file and what it expects (preventing further errors on your part)…
To add to @cjcoats’ comment, could you please elaborate on what you are trying to do? The intended use of BCON and ICON in “regrid” mode is to take model output from a larger domain (typically but not necessarily with a coarser grid spacing) to prepare initial and boundary conditions for a smaller domain (typically but not necessarily with a finer grid spacing).
For this to work, BCON needs a) the coarse grid concentration file (CTM_CONC_1), b) the coarse grid meteorological file (typically from MCIP) containing ZH and PRES data (MET_CRO_3D_CRS), and c) the fine grid MCIP METBDY3D file defining the boundary of the fine grid, also containing ZH and PRES (MET_BDY_3D_FIN). [as an aside, CTM_CONC_1 and MET_CRO_3D_CRS can point to the same file if that file contains both concentrations and the required meteorological fields ZH and PRES]. The requirements for ICON are the same, except that c) needs to be the fine grid MCIP meteorological file defining the fine grid and containing ZH and PRES (MET_CRO_3D_FIN).
My research domain was a 27km resolution grid nested with a 9km grid. I ran CMAQ with profiled ICON/BCON to obtain concentration file for the coarse grid of 27km. And was testing nested (regrid) ICON/BCON for the finer grid of 9km.
So currently I have a coarser grid concentration file (CTM_CONC_1_27km) and also the MCIP files (MET_CRO_3D and MET_BDY_3D) for 27km grid. Meanwhile, MET_CRO_3D_FIN file was generated from MCIP using wrfout files for 9km resolution grid.
I’ve checked the headers of MET_CRO_3D_CRS file and ICON/BCON output files (unfinished). Global attributes defining grid dimension were the same. So I was wondering what could cause the mismatch between them. I’m attaching the headers of the two files in following txts. ICON_regrid.txt (80.3 KB) METCRO3D.txt (11.0 KB)
Besides, the only difference is that my CTM_CONC_1 file had 1 layer output (NLAYS=1). Could it be this causing errors?
Thanks for the additional information. A few thoughts:
In the ICON run script used to generated the (unfinished) regridded ICON file for which you posted the header, are you sure that you specified the 9km METCRO3D file from MCIP rather than the 27km METCRO3D file from MCIP as MET_CRO_3D_FIN? The ICON header shows the same grid information as for the coarse 27 km domain defined in the METCRO3.txt file you posted. If you previously tried to run ICON with the 27 km METCRO3D file as MET_CRO_3D_FIN and then changed the run script to point to the 9 km METCRO3D file, make sure to delete the incomplete ICON file prior to rerunning.
Yes, your CTM_CONC_1 file for the coarse domain absolutely needs to span the entire vertical extent of your intended fine domain. In order for ICON and BCON to compute boundary and initial conditions for all layers of the fine domain, 3D information needs to be available from the coarse domain.
Please post your ICON and BCON run scripts if you continue to encounter issues after checking and addressing the points above.
It worked! I span the vertical domain of CTM_CONC_1 to whole layers, which is equivalent to MET_CRO_3D files and BCON/ICON finished successfully. Also I looked up ioapi documentations from cmascenter which described the how INTERP3() function works. https://www.cmascenter.org/ioapi/documentation/all_versions/html/AA.html#ioapi
It requires the grid size of CTM_CONC_1 (NROWSNCOLSNLAYS) to be consistent with MET_CRO_3D_CRS, which in my case it is not, causing size errors.
Thanks for the replies and advices from both of you! I really appreciate it.
Thank you for sharing your solution and insights! I am currently facing the same error:
" *** ERROR ABORT in subroutine M3_VINTERP
Could not read layer heights from file MET_CRO_3D_CRS
Date and time 0:00:00 July 2, 2017 (2017183:000000)."
In my case, the NLAYS value in the CTM_CONC_1 file is 1, while the corresponding MET_CRO_3D_CRS file has 35 layers. This mismatch might be causing the issue. Could you provide guidance on how to properly run INTERP3 to address this?
Any additional tips from your experience would be greatly appreciated.
in order to create initial and boundary conditions for an inner domain, you need 3D outputs from your outer domain. This means that when you perform CCTM simulations for your outer domain, you should use setenv CONC_BLEV_ELEV " 1 35" in your run script (since you say your MET_CRO_3D_CRS file has 35 layers), or comment out this line altogether. in which case the number of layers in the CCTM_CONC file automatically will match the number of layers in the MET_CRO_3D_CRS.
Thank you so much for your helpful insight! I’ll make sure to be cautious about the CONC_BLEV_ELEV setting in future runs, as it’s critical to ensure consistency with the number of layers in the MET_CRO_3D_CRS file. This will undoubtedly save me from similar issues.
Follow-up Question:
I was wondering if there are any alternative ways to process CMAQ results when working with data that only has one vertical layer (NLAYS=1). I am using input data files from a previous study to run ICON/BCON for the 4km domain, but I’ve encountered grid mismatches between these input files. These mismatches are making it difficult to align the data. Do you have any suggestions or tips on how to address these challenges effectively?
Could you please elaborate on what you mean by “process CMAQ results”? If you refer to generating initial and boundary conditions from CMAQ output that contains data for the surface layer only, then no, that’s generally not possibly, unless you make some assumptions about the vertical profiles of all pollutants and write code to manually apply these profiles to generate 3D fields from your existing 2D fields.
You could theoretically also fall back to running ICON and BCON in profile mode using the profile file distributed with CMAQ in the PREP/bcon/src/profile folders, but since this profile represents clean background conditions over a marine environment during a specific year and using a specific version of hemispheric CMAQ, it might not at all be applicable to your domain of interest where pollutant inflow might be important.
Without specific details on the challenges you are encountering, we cannot provide suggestions on how to address them.
I am currently running CMAQ / ICON-BCON v5.4 to generate initial conditions (IC) and boundary conditions (BC) for the inner domain (4km) using the “regrid” method. The input for the inner domain is based on the output from a previous CMAQ run for the outer domain (12km). However, during this process, I encountered the following warnings and errors:
Vertical interpolation method: Linear
The COORD.EXT and CTM vertical grid types are different.
Vertical interpolation using ZH from the MET_CRO_3D files
>>--->> WARNING in subroutine M3_VINTERP:INTERP3
Size error for ZH from MET_CRO_3D_CRS--REQ: 117130 ACT:4099550
M3WARN: DTBUF 0:00:00 July 2, 2017 (2017183:000000)
*** ERROR ABORT in subroutine M3_VINTERP
Could not read layer heights from file MET_CRO_3D_CRS
Date and time 0:00:00 July 2, 2017 (2017183:000000)
To provide additional context, I have attached the log files for your review.
Well, right, this is the problem caused by trying to use a 2D rather than a 3D CONC file from your 12 km domain to generate initial and boundary conditions for your 4 km domain. The only solution is to have your 12 km simulation output 3D CONC files, the same solution confirmed by @Henry in post #9 to have solved their identical issue. This is not an issue of a ‘grid mismatch’ causing problems with ‘data alignment’, it’s purely a 12 km run script output option issue.
If you do not have the option of rerunning your 12 km simulation to generate 3D output files, you will have to look for alternate data sources to generate initial and boundary conditions, such as archived 3D hemispheric CMAQ output data. However, you will have to carefully examine whether this or any other alternate source of 3D data to create initial and boundary conditions is appropriate for your domain and time period.