Hi there. I ran CMAQ5.5 with ISAM module using the cb6r5_ae7_aq mechanism successfully. In order to analyze the source of organic matter, I tried the CRACMM2 mechanism. It rworked normally in 1 and 2 domain, but a problem happened with the ISAM module in the 3rd domain.
It dosen’t look like an error, since no error was reported, but CMAQ does not work. Running from the foreground, you can see that the interface is stuck with “MPP Processor-to-Subdomain Map -=- Number of Processors = 40” and doesn’t change for hours. The size of outfiles in the CCTM run result also did not change. When I tried to remove OA_TOT from TAG CLASSES in the ISAM control file, CMAQ began to run normally. Then I removed the other factors, keeping only OA_TOT, and found that the mode was stuck again, and no errors were reported. No log file is generated because the model is not running properly.
BTW:I used SMOKEv4.7 as the pollution source file, and the chemical mechanism used was CRACMM2. I tried 256 core to run CMAQ-ISAM, but still didn’t work. Aditionally, I traced 12 emission streams in the simulation. My I/O API did not upload to 3.2-large.
Ask for your help to find out and solve the problem, thanks.
Best
pbwang
could you please clarify whether for your simulations you modified the source code as described in this known issue regarding the use of CRACMM2 with ISAM ?
We hope to make this modification available as part of the v55+ branch early next year.
In addition to the note above about an issue with the current CMAQv55 code regarding the use of ISAM with CRACMM2, in your CRACMM2 simulation, did you actually prepare emission inputs speciated for the CRACMM2 mechanism, rather than for the CB6R7_AE7 mechanism? Your log file suggests you didn’t.
EM1 | Gridded Area Emissions File 1: 29 unused variables.
AACD
ACET
ALD2
ALDX
APIN
BENZ
BENZENE
CH4
ETHA
ETHY
ETOH
FACD
FORM
IOLE
ISOP
IVOC
MEOH
NR
NVOL
OLE
PAR
PRPA
TERP
UNK
UNR
XYLMN
PMFINE
PNCOM
POC
These emissions look like they are speciated for CB6R5_AE7, not CRACMM2. In order to run CMAQ with CRACMM2, you will need to create emissions for that mechanism.
The preparation of emission inputs for CRACMM1 and CRACMM2 is documented as part of the CRACMM github repository. If you have any specific questions about CRACMM2 speciation, I suggest starting a new topic and tagging @Havala.Pye .
Just an additional note that while editing these two entries in the CMAQv55 AERO_DATA.F code is certainly needed for CRACMM2 ISAM simulations with SOA, I am not sure it explains the hanging behavior you described in your first post, or if that behavior was related to providing CB6R5_AE7 speciated emissions to the CRACMM2 executable. In our experience, using the bugged version of AERO_DATA.F in CRACMM2 ISAM runs actually led to crashes, as we noted when we posted the issue linked in my initial response.
Thanks, christian.
I edited these two species in ‘aerolist’ of the AERO_DATA.F. Unfortunately, it didn’t work, stuck again. ISAM did not crash, but stuck. So there must be other problems. I think I should prepare the species of cracmm2.
Hi christian, I can run cracmm2 with ISAM now, although I still didn’t use the emission species of cracmm2 mechanism.
I reduced the tag emissions form12 to 4, and deleted the tag species CHLORINE. So I guess it was the problem about the large IOAPI.
BTW: does CMAQ work normally，if the IOAPI library files required for CMAQ installation use large IOAPI wherever they are supported?
Thanks for your help.
Best
pbwang
If the large I/O API library was built properly and everything was linked cleanly, there’s no reason it should cause issues. It should also behave the same on all domains. That said, you don’t need to build with the large library unless the total number of species in your SA_ACONC files (calculated as the number of tracked species - which depends on the specified tag classes - times the number of tags) exceeds 2048. When you say “I can run cracmm2 with ISAM now … I reduced the tag emissions form 12 to 4 … So I guess it was the problem about the large IOAPI”, did you recompile CMAQ without the large I/O API library after reducing the number of tags? If not, it’s not the library that’s causing you issues, but some other aspect of your setup.
I don’t know for sure what’s causing you issues, but running CRACMM2 ISAM with very few emissions (because most of your CB6 emissions don’t have a CRACMM2 equivalent and will just be dropped when running the model) just doesn’t make any conceptual sense, and I would not expect any meaningful results from the outputs of such a simulation. You really need to match your emissions speciation to the chemical mechanism you are using. In addition, I wouldn’t be surprised if ISAM behaves unexpectedly in such a situation where you have very few emissions being successfully read into the model - after all, ISAM is meant to apportion concentrations to emissions, and if you don’t have meaningful CRACMM2 emissions, the source apportionment calculations likely encounter conditions for which they were not designed.
If I understand your question correctly, you’re asking if there is a downside to always compiling CMAQ with the large I/O API version even if it’s not required, i.e. if none of the files exceed 2048 variables. The general answer is that there’s an increased memory overhead when doing so, but whether or not that has a noticeable impact on your particular setup is something you have to test out yourself. My approach would be not to use it if it’s not needed.
Thank you for your response, Christian.
I don’t want to use the ISAM simulation results for this missing species emission of CRACMM2 mechanism. I just want to see if it works, and then I will solve the problem of chemical mechanism species.
I haven’t installed large-IOAPI, nor have I recompiled the CMAQv5.5.
Now let’s talk about the reasons why I reduced the number of tag emissions. I found that the total number of species under each tag emission in the SA_ACONC file is 152. When I ran the CB6r5AE7 mechanism ISAM, I found that 12 tag emissions were also being stucked, which is a total of 2280 species (plus ICO, BCO and OTH). Then I reduced it to 10 tags (13 with ICO, BCO, and OTH), that’s 1,976 species, and the model was stable.
So I tried to reduce the number of tags when running ISAM of CRACMM2, reduce to 5 tag emission, plus ICO, BCO and OTH, 1216 species, no more than 2048, but I found the task was interrupted after 2 simulation days. This also confirms the fact that the CRACMM2 mechanism works even after I removed the tag class of OA_TOT.
Now according to your reply, can I make the model run normally if I increase the number of core or get the emission species of CRACMM2, on the premise that the number of tracked species does not exceed 2048?
Best
pbwang
I misread your comments about the large I/O API library. You are correct that as long as you configure your ISAM simulation such that the ISAM output files have no more than 2048 species, you will not need to use the large I/O API library.
This is a bit surprising. In my experience, defining a larger case creating more than 2048 output variables in a single file and trying to run such a case with the regular rather than the large version of the I/O API would lead to a crash with I/O API error messages rather than just hang. Of course also note that the number of tracked species associated with each tag not only depends on the defined tag classes, but also can differ between CB6R5_AE7 and CRACMM2.
Could you describe what you mean by the task being interrupted? Did you encounter the hanging behavior you described above or did you encounter different behavior? Was there any error message in the log file when the task was interrupted?
Until you have CRACMM2 emissions, personally I wouldn’t spend too much time trying to debug a CRACMM2 ISAM simulation using CB6R5_AE7 emissions as input. If you still encounter issues with the CRACMM2 setup after providing CRACMM2 emissions, debugging any such potential remaining issues might be easier to accomplish than in the current setup.