Convert CMAQ output to vertical column density with the unit of molec/cm2

Dear staffs,
I am working on comparing my CMAQ model output of NO2 with OMI derived NO2 vertical column density. As far as I know, I can use the IOAPI tool named vertot to do so. However, the vertot only sum up the NO2 concentration at different levels and the unit is still ppmv. Therefore, I wonder how can I convert the modeled NO2 concentration to the vertical column density (the unit for OMI NO2 is molec/cm2).
Any details are highly appreciated!


Look at M3Tools program vertintegral (; you may need to do an additional conversion to get molecules per square centimeter.

Hi Dr.Coats,
Thanks for pointing it out. I tried to use the M3Tools program vertintegral but it did report segmentation fault (But I can do the vertot program). I have no idea about this issue.
Do you have any suggestions?

What does

    *limit stacksize unlimited*


Please see the screenshot attached below:

I also note that the timestep for METCRO3D and CONC file is not same (CONC file has 24 hour duration while the METCRO3D has 25 hour duration). Does the discrepancy have effects on the program?


last question first: …the timestep for METCRO3D and CONC file is not same…Does the discrepancy have effects on the program? No. The point of an object-based direct access file interface like the I/O API is that you request data by a specific date&time; it doesn’t matter what other dates&times are there (as long as the requested one is). It would be perfectly reasonable to have a decade-long METCRO3D and do vertintegral for any day and hour you wanted to within that decade; in fact, you would not even have any performance penalty for doing so: READ3 skips directly to the requested data without having to read through the intervening dates&times. Note that this is very unlike sequential-file behavior…

BTW, what I/O API and M3Tools version are you running? The files and line numbers do not match up with the corresponding files from either 3.1 or 3.2 (and for 3.2, vertintegral is built from vertintegral.f90 not vertintegral.f)

You might try downloading I/O API 3.2 (keep it in a separate directory), building it and using it… see

Hi Dr.Coats,
You are right. The segmentation fault is attributed by the IOAPI version. The CONC and METCRO3D files are generated from CMAQ5.3.1 and MCIP5.0 while I use the M3Tools program vertintegral in IOAPI3.1.
Now I try to use IOAPI3.2 and the segmentation fault is solved. However, it does report another issue that shown below: (Please see figures attached)

Please note that my CONC file name is and CRO3D filename is
Do you have any comments?


Two problems here: “Variable(s) ZF,DENS not found in met file” and “Bad environment variable”.

The second of these is on me: at lines 378 and 385 of vertintegral.f90, the tests should be:
I’ll get this fixed as soon as I can. As a hack in the mean-time, your script could
setenv LAY_LO 1
setenv LAY_HI 29
As for the first? What does ncdump -h say about the variables in the file? Are ZF and DENS there? …if not, we have a problematic METCRO3D file…

I did the ncdump and find that ZF and DENS are in But the program reported no (a little bit strange). Please see the dump file attached.dump.txt (9.7 KB)
Besides, as for the second issue, do you mean that I need to write a csh script and set the following two lines in my csh script?
setenv LAY_LO 1
setenv LAY_HI 29
Do I need to revise the vertintegral.f90 accordingly?

Just for grins, what does M3Tools program m3stat say about this met-file?

You can do the setenvs interactively before you run vertintegral, or you can write a script. Either will work. Or you can change the .LT.s to .GT.s at lines 378 and 385, and re-make.

It seems m3stat cannot generate report for the met-file.
Please see figures below:

This version of m3stat is code that’s been in frequent use since 2010 – and it’s seg-faulting at a place that was in the original 1993 version.

Where did this met-file come from?

The met file is generated by MCIPv5.0. And the WRF version is 3.9.1.

You can also obtain column density for O3, NO2, CO, HCHO, and SO2 directly when running CMAQ by turning on the CTM_PHOTDIAG variable in your run script. These column quantities will be written to the
CCTM_PHOTDIAG1 output file and are called OZONE_COLUMN, NO2_COLUMN, CO_COLUMN, HCHO_COLUMN, and SO2_COLUMN, respectively.

Hi Christian,
Thanks for pointing it out. I will try to do so right now.

Hi Christian,
Just want to make sure that these variables in CCTM_PHOTDIAG1 output file are tropospheric column density. Am I right?


These variables represent the vertical column integrated through all CMAQ layers. Depending on your model top, this may include parts of the lower stratosphere. The actual calculation is performed by the subroutine column_gas in phot.F.

1 Like

Got it, thanks so much!

Hi Christian,
I just rerun my CMAQv5.2.1 simulation and get the CCTM_PHOTDIAG1 and CCTM_PHOTDIAG2. But I didn’t find column density for NO2, CO, HCHO, and SO2 (there is only ozone column density in the CCTM_PHOTDIAG1).
Could you please check this issue?
Please find my ncdump file attached in this reply.
1.txt (21.2 KB)
2.txt (17.7 KB)

Hi Ryan,

I did not realize that you were running an older version of CMAQ. The feature to compute NO2, CO, HCHO, and SO2 columns as part of the PHOTDIAG1 output file was introduced in CMAQv5.3.

You might be able to adapt the CMAQv5.2.1 phot.F code to perform the computations introduced in CMAQv5.3, but it may not be straightforward since other changes were made to this portion of the code, too. Therefore, if inline computation of column densities is important to your application, you probably are better off switching to CMAQv5.3.

Alternatively, you could pursue the offline calculation approach, either by following the path outlined by @cjcoats or by developing your own tool building on the code in the CMAQv5.3 version of phot.F