Sensitivity of BOUN and PVO in CMAQ/DDM


I didn’t fully grasp the significance of considering boundary conditions, which encompass BOUN and PVO, while utilizing the sensitivity control file (The post doesn’t seem to display properly, as there’s an initial space before “BOUN” and “SPECIES.”).

NO, NO2, …

NO, NO2, …

The error shows:

*** ERROR ABORT in subroutine SINPUT on PE 000
Sentype not recognized: BOUN

I could not find more detail guidance in the CMAQ User’s Guide at

Could you guide me on calculating the sensitivity of boundary conditions (BOUN) and potential vorticity (PVO)? Specifically, I’m interested in evaluating the impact of the boundaries on local ozone. Can we apply a similar methodology to setting up the sensitivity control file as we did for EMIS sensitivity?



There is definitely a mistake in the documentation (in chapter 10). The keywords should be as follows:

ICON - initial conditions
BCON - boundary conditions
PVO3 - potential vorticity

I will submit a correction. Thank you for bringing this to my attention and sorry for the inconvenience.


Hi Sergey,

I am employing PVO3 (potential vorticity) within CMAQ/ISAM to assess the influence of ozone originating from higher altitudes, as indicated by the term you mentioned earlier. However, I’ve encountered an error message while running CMAQ/ISAM (v5.4.0.3), and I’m seeking assistance in identifying the underlying cause:

*** ERROR ABORT in subroutine ISAM_PV on PE 050
ERROR: Possible overspecification of ISAM tags for PV

The PVO3 is utilized in the ISAM control file in the following manner:


By the way, I enabled the “set potvortO3” option in the process of building my CMAQ/ISAM using the bldit_cctm.csh script.

Could you please assist me in understanding the reason behind this error?

In addition, How to use O3PV as inert gas phase tracer species to CMAQ?

Thank you very much.


Hi Feng,

I’ll let Sergey respond to your question about the error with the PVO3 term, but it might be helpful if you posted your full ISAM control file for the run in which you’re encountering this error.

To add O3PV as an inert gas phase tracer species, you’d edit Species_Table_TR_0.nml as follows (for traceability, you would probably want to change the name from Species_Table_TR_0.nml to something like Species_Table_TR_PVO3.nml and then update your run script accordingly):



!SPECIES     ,MOLWT   ,IC           ,IC_FAC         ,BC                ,BC_FAC      ,DEPV       ,DEPV_FAC  ,SCAV     ,SCAV_FAC ,TR2AE      ,TR2AQ ,ADVC  ,DIFF  ,DDEP  ,WDEP  ,CONC
'O3PV'       ,48.0    ,''          ,-1              ,''                ,-1          ,'VD_O3'    ,1         ,'O3'     , 1        ,''        ,''   ,'YES' ,'YES' ,'YES' ,'YES' ,'YES',

Yes, please, post the full contents of the control file. It is possible one or more species are oversubscribed. Generally, that is what that error message indicates.


Hi Christian and Sergey,

I appreciate your responses and the comprehensive information you provided regarding the configuration of O3PV as a gas phase tracer species in CMAQ.

Please find my ISAM control file attached. It appears to function smoothly when I exclude PVO3 from the control file.
isam_control.txt (3.5 KB)


Hi Feng,

thanks for posting the ISAM control file.

Just to confirm, when you compute CALIFORNIA+OTHERSTATE+MEXICO+ARIZONA+O3NAA from your gridmask file, the sum is <= 1 throughout your domain, correct?


Hi Christian,

Yes, those regions are not overlapping.


Thanks for confirming.

Could you please perform one test? Instead of specifying three different region-specific tags for PVO3 (AZ8, NA8, and US8), could you please try specifying a single non-region-specific tag like this?

!!! Domain-wide PV-O3 contribution
TAG NAME        |PVO

From a science perspective, that’s probably sufficient anyway, since you likely care about the (lower bound of) the contribution of this parameterization of stratospheric ozone, and not whether this originated from the stratosphere over a specific region.

If this test works, it might still point to a very tiny “overlap” at the borders where your regions meet, e.g. grid cells where the sum of your regions might be something like 1.0000000001 rather than 1.0. This is just speculation, and I’m not sure why the PVO3 “emission stream” might be more sensitive towards such tiny exceedances of 1.0 compared to the other “regular” emission streams, but the suggested test should give us a clue in that direction.

1 Like

Hi Christian,

Thank you very much for providing me with detailed information about PVO. I wanted to let you know that the tests you suggested have been successful. I have attached an animation depicting ozone concentrations from PVO3 across all model layers. Upon review, the results appear satisfactory in terms of both magnitude and spatial distribution.

Regarding your comment about the contribution from the upper atmosphere being needed everywhere rather than specific regions, I have made the changes as below in the isam control file attached in my previous message. CMAQ/ISAM also works with this change and have met the intended purpose effectively.


I completely agree with your assessment that even if this test proves successful, there might still be a minor issue related to “overlap” at the borders of the defined regions. Your point is well taken. My region mask file was generated using ArcGIS, assigning a value of 1.0 to grid cells fully covered by the region and fractional values for those partially covered by borders. This fractional representation may not be perfectly accurate and could lead to tiny overlaps, especially within cells shared by multiple borders. It’s interesting to note that PVO3 seems to be particularly sensitive to this, as other default tags like BCO, ICO, and MIOG do not encounter similar problems with the same masked regions.

I sincerely appreciate your valuable insights and inputs. Thank you once again for your assistance.



Hi Christian,

The CMAQ/ISAM model demonstrated satisfactory performance following my assessment of PVO3, where I employed a single, non-region-specific tag, as per your suggestion. Subsequently, I integrated this into my control file to evaluate the contribution of PVO from O3_OTH. However, I have observed a significant discrepancy in O3_PVO levels between the test run (case1) and the full version run (case2), as illustrated in the attached screenshot. This discrepancy has prompted me to question our approach to handling PVO.


Hi Feng,

to make sure I understand the question, could you please confirm that case1 used an isam_control file with just a single explicit tag (domain-wide PVO) while case2 used an isam_control file that included the same domain-wide PVO tag but also a number of other tags (possibly the 21 non-PVO tags specified in the file attached to post #5)?

If so, the reason why the PVO tags differ between the two simulations might be related to what’s discussed on pages 4 - 7 of the ISAM chemistry supplemental document. This document describes how tag values can change if the number of other specified tags changes. However, I don’t know if this discussion does apply to the special case of the PVO tag, @sergey might have further insights.

1 Like

Hi Christian,

Yes, it’s confirmed.

I’ll take a closer look at the document to see if I can identify the issue.

Thanks for your prompt response.