Really large IPR EMIS results for upper layers

CMAQ
1

Hi,
I’m using IPR (CMAQ v5.3.3) to analysis PM2.5 which defined in the pa_cb6r3_ae7_aq.ctl as follow:

DEFINE FAMILY ATOTI  =  ASO4I +ANO3I +ANH4I +ANAI +ACLI +AECI
+ ALVPO1I  + ASVPO1I  + ASVPO2I  + APOCI  +APNCOMI 
+ ALVOO1I  + ALVOO2I  + ASVOO1I  + ASVOO2I + AOTHRI;

DEFINE FAMILY ATOTJ = ASO4J +ANO3J +ANH4J +ANAJ +ACLJ
+ AECJ +AOTHRJ +AFEJ +ASIJ 
+ ATIJ +ACAJ +AMGJ +AMNJ +AALJ +AKJ
+ ALVPO1J  + ASVPO1J  + ASVPO2J  + APOCJ    
+ ASVPO3J  + AIVPO1J   + APNCOMJ 
+ AISO1J + AISO2J   + AISO3J       
+ AMT1J    + AMT2J    + AMT3J    + AMT4J 
+ AMT5J    + AMT6J    + AMTNO3J 
+ AMTHYDJ  + AGLYJ    + ASQTJ            
+ AORGCJ   + AOLGBJ   + AOLGAJ          
+ ALVOO1J  + ALVOO2J  + ASVOO1J  + ASVOO2J 
+ ASVOO3J  + APCSOJ   + AAVB1J  + AAVB2J 
+ AAVB3J  + AAVB4J;

DEFINE FAMILY ATOTIJ  = ASO4I +ANO3I +ANH4I +ANAI +ACLI +AECI
+ ALVPO1I  + ASVPO1I  + ASVPO2I  + APOCI  +APNCOMI 
+ ALVOO1I  + ALVOO2I  + ASVOO1I  + ASVOO2I + AOTHRI
+ ASO4J +ANO3J +ANH4J +ANAJ +ACLJ
+ AECJ +AOTHRJ +AFEJ +ASIJ 
+ ATIJ +ACAJ +AMGJ +AMNJ +AALJ +AKJ
+ ALVPO1J  + ASVPO1J  + ASVPO2J  + APOCJ    
+ ASVPO3J  + AIVPO1J   + APNCOMJ 
+ AISO1J + AISO2J   + AISO3J       
+ AMT1J    + AMT2J    + AMT3J    + AMT4J 
+ AMT5J    + AMT6J    + AMTNO3J 
+ AMTHYDJ  + AGLYJ    + ASQTJ            
+ AORGCJ   + AOLGBJ   + AOLGAJ          
+ ALVOO1J  + ALVOO2J  + ASVOO1J  + ASVOO2J 
+ ASVOO3J  + APCSOJ   + AAVB1J  + AAVB2J 
+ AAVB3J  + AAVB4J;

the PA_BLEV_ELEV was set to “1 14”, the output of EMIS_ATOTIJ, EMIS_ATOTJ and EMIS_ATOTI had really large values (around 2e+11) at layer 3 and above.

The MCIP files has 34 layers, and the gridded emission files has only 1 layer, and the CTM_EMLAYS was set to 1 to rule out the possible error caused by plume rise calculation.

The first thought was it might be the DEFINE FAMILY error, but when I check the EMIS_ANO3J, layer 0 has values around 1 while layer 6 has values around 40, and EMIS_ASO4J has max values at layer 10, basically the EMIS for variables has really large values at upper layer.

Meanwhile, the multi-layer aconc results seems to be normal.

Any idea how to solve this error?

Thanks a lot!
Tris

2

In addition to your gridded emission file(s) that only have 1 layer, do you have any inline point source files specified as input to CMAQ?

3

Turning on the DESID diagnostic file for ALL streams should help pinpoint which sector(s) are involved.

4

Thanks for your reply,
the N_EMIS_PT was set to 0, so no point source files.

5

Thank you for posting this information. I admit that I don’t have a good theory on what might be happening. I suggest you follow the advice by @cgnolte to use DESID diagnostic files to further investigate the issue.

6

With no point source emission sectors, and CTM_EMLAYS set to 1, I don’t see how you get any emissions of ATOTI or ATOTJ in upper layers.
I just tried a run using v5.3.3, with the same PA control file commands you used, and my IPR output shows EMIS_TOTJ and EMIS_TOTI are identically zero.
Perhaps try recompiling in debug mode to see if that reveals an error.

2 Likes
7

Upon reflection, the fact that EMIS_ATOTI and EMIS_ATOTJ are zero in layer 1 as well as upper layers shows that the emissions process is not being reflected at all for aerosol species. I’ll have to check with some colleagues and look at the documentation and code a bit further. In the meantime, could you post your entire PA control file as an attachment? If that does not work, please email it to me at lastname dot firstname at epa dot gov.

8

Hello,

Thank you for explaining this problem. One simple thing to try that was incorporated into v5.4 –

In vdiffproc.F, find the following line:

ALLOCATE ( EMIS_PA( NCOLS,NROWS,EMLAYS,N_SPC_DIFF ), STAT = ASTAT )

and update EMLAYS to NLAYS as follows:

ALLOCATE ( EMIS_PA( NCOLS,NROWS,NLAYS,N_SPC_DIFF ), STAT = ASTAT )

This should help resolve your use case (with PA_BLEV_ELEV set to “1 14”). However, we are still investigating why the code crashes when BLEV is set to a value greater than 1.

1 Like
9

We believe the suggestion from @Ben_Murphy in this thread will work. Have you tried to implement it? We are marking this as solved, unless you let us know otherwise. There will also be a code fix that is currently being tested internally in a PR for the next public release.