Hi all,
When activating process analysis, I find that the overall concentration change of particle nitrate (hourly difference of data from CONC file) does not equal to the sum of the contributions of the 12 processes (CHEM+EMIS+…).
I check that the equality does hold for ozone concentration, where AERO (NPF + COND + COAG + GROW) contributes 0. I also check OH and HNO3 (g), the former AERO contributes 0 while the latter not, and the former holds equality while the latter not.
Then I guess the problem may come from PA of AERO, and I find that CMAQ 5.3 updated PA for aerosol subprocesses.
Is this problem a bug or due to my mistakes? Does anyone have any suggestion?
Hi Zhizhua,
It sounds like you have done the right sort of tests to demonstrate a problem. How large is the mass closure issue in a given time step, on an absolute and relative basis? Are the errors at the surface, or aloft?
Thank you for you reply, cgnolte. The concentration difference is very large for ANO3. I only calculate one day, and the absolute difference is from -19 to 20 ug/m3/hr, and relative difference is -1590% to 1786%. I also calculate “inert” species (Na and EC), the concentration differences are negligible since the contributions of AERO are negligible (not 0).
The error is at the surface. I have not checked aloft yet.
Hi Zhizhua,
Thanks for your description and sorry you are seeing these issues. May I ask you a few more clarifying questions to think more deeply about this problem?
- What domain are you running your simulation for?
- I’m wondering what you see for a pollutant like ASO4 which will have condensation but no evaporation?
- Are you summing multiple aerosol modes for these values? That shouldn’t be a problem but useful to know when thinking these things through. The coagulation contribution should also be 0 for the sum of i and j mode variables of a particular species so that’s one additional thing to check.
Best regards,
Ben
Hi Ben,
Thanks for your reply. The following are answers to your questions, and I hope these could make the problem clearer.
-
The domain is east and southeast Asia, but I only chose an area about 70,000 km2 in China (highly polluted area) to calculate.
-
The differences of ASO4 are also very large (data for another day: 0.014~1.014 ug/m3/hr, -623%~1493%; avg. 0.324 ug/m3/hr, 85%). By the way, only COND has non-negligible contribution for both ASO4 and ANO3.
-
Yes. I summed i and j modes. However, the contribution of COAG is not 0, both for ANO3 and ASO4 (though very small, of 10^-7 order of the net effect, while the contribution of NPF is exact 0 for ANO3).
Hi Zhizhua,
Thank you for your answers. Unfortunately, this does not sound like a problem with an easy fix, and I’m uncertain why it is happening on your domain and not on ours. Can you please send me your process analysis input file and the output file as well? I will direct message you with my email address.
Ben
We have successfully diagnosed this problem and are investigating a potential solution. Once it has cleared our internal code review process, we will post the update. The bottom line is that aerosol processes are being double-counted for the process analysis fields for all time steps beyond the first one of each output time step. This error does not impact the results of the core model – the predicted concentrations are not corrupted by this error.
-Ben
Hi Ben,
I want to know if the problem has been solved for CMAQ 5.3.2.
Best regards,
Yunqing
Hi Yunqing,
We have found a solution but it is still under review since it is lumped with a few other updates. I have tried to distill just the pertinent bug fix in the update to the file uploaded here. Please remove the .txt extension and add it to the CCTM/src/procan/pa folder. I have not tested it, so please let me know if it fails to compile or run.
pa_update.F.txt (30.6 KB)
Please also modify the call to pa_update_aero in scriproc.F to the following:
IF ( LIPR ) CALL PA_UPDATE_AERO ( CGRID, JDATE, JTIME )
Best wishes,
Ben
Hi Ben,
Thanks for your help, I’ll give it a try.
Best wishes,
Yunqing
Hi Ben,
I tried to compile CMAQ 5.3.2 with the pa_update.F file you gave to me, but it failed with some errors.
(I can compile original CMAQ 5.3.2 successfully with the exact same configuration.)
Attached is my build log.build.txt (338.3 KB)
Yunqing
Hi Yunqing,
My mistake, those files were not ready. I’ve compiled and tested these. Please see if they fix your issue.
Cheers,
Benpa_update.F.txt (31.3 KB) sciproc.F.txt (14.0 KB)
Hi Ben,
Sorry for the late reply. I’ve been trying out the *.F files you gave me.
I can compile these files successfully, but there are still some problems with PA output.
I checked nitrate and CO for the output, the same problem still exist(mass closure problem with AERO).
Here are my pa.ctl, pa_report and output.mass_closure.csv (51.6 KB) pa_cb6r3_ae7_aq.ctl.txt (1.8 KB) PA_REPORT.20201210.txt (9.2 KB)
I ran the model for 96 hours and extract the output for two grids((1,1) & (7,14) for PA domain).
Yunqing
Hi Yunqing,
Ben gave me three files to replace the old ones, and I tested them successfully. Hope they are helpful to you. sciproc.F.txt (14.0 KB) pa_update.F.txt (32.9 KB) aero_subs.F.txt (136.0 KB)
Zhizhua
Thanks for sending those Zhizhua. I had lost track of our exchange last fall.
@Yunqing: please see if those files from Zhizhua help your case. I tried them myself and it didn’t change any of my results. It’s possible that the problems you are seeing are a result of the inherent flaw in using concentration-based process analysis (rather than a mass-based approach) to try to quantify mass closure. However, the extreme deviation that you see for ANO3J makes me think otherwise.
For grid cell 7,14 you report pretty massive gains by PA that are unsupported by the concentration change in the early hours of the simulaiton. Can you determine which process(es) are dominating that increase?
Best,
Ben
Thank you for sending me those files Zhizhua. I’ll give it a try.
Yunqing
Thanks for your reply Ben.
The difference was mainly caused by process TRNM.mass_closure.csv (98.2 KB)
Best
Yunqing
Can you tell me what advection option you are using? Is it ‘local’ or ‘wrf’?
Also, if it’s not too much trouble, it might be useful to rerun with some of the sub-processes within TRNM separated out (e.g. VDIF, HDIF, HADV, and ZADV) to see which is contributing the apparent error.
-Ben
Hi Ben,
I’m using ‘wrf’ advection option and wrf meteorological output.
I rerun the model (with files you gave me), it shows that ‘VDIF’ contribute the most.mass_closure.csv (134.6 KB)
Yunqing
Hi Yunqing,
Just so you’re aware, I’m still working on this issue on my side in between other projects. I have some new updates I’ve made that will hopefully alleviate the issue you’re seeing. However, I’m still testing them. When they are ready, would you consider running some tests yourself to see if they resolve your issue?
Best wishes,
Ben