I’m not convinced it’s not the problem though. One easy way to check: change the M3EXIT call just after 2412 to M3WARN. You’ll also need to remove the 2 at the end of the call statement. With the error disabled, DESID should log the unexpected units for the GDAY variable, print that it does not recognize GDAY, and then it may continue on.
Catalyst,
-
So that this forum can benefit the broad user community, we do not want long threads of support to individual users as they work through multiple unrelated problems. Since this is no longer a compilation issue, please create a new thread.
-
Ben proposed a solution. Did you try that code modification? If so, what was the outcome?
-
There is no need to tag individual members of the CMAQ team. At least, that should not be done routinely, immediately upon posting. Please wait at least a few days before a targeted follow-up like that.
Dear @Ben_Murphy,
I have tried your suggestion but still encountered similar error. How do I resolve this, please? @cgnolte
Hi Catalyst,
Sorry to hear that it failed. It should have printed the warning though, letting you know which variables were causing problems. If this didn’t happen then I’m confused why the backtrace indicated the problem was at this particular M3EXIT call. You may try entering a print statement before the XMSG variable is written to see if there is a problem in that line.
-Ben
Dear @Ben_Murphy @lizadams @cjcoats @sergey
@Ben_Murphy was right. The “day” units was actually causing the error. I have found solution to this error by modifying the “day” units in my emission files and CMAQ-5.3.2 is running perfectly now.
Thanks and best regards,
Catalyst
1 Like
I’ve met the same error with CMAQ5.3.1. Can you tell me what I should modify this unit into? Thanks a lot.
Hi Axueaha,
When you say you have the same error, can you be more specific? There were several errors and fixes discussed in this thread. If your problem is having a variable on your emission file with units that are non-standard and thus unexpected, I recommend deleting those variables from the file or changing their units to an expected value like moles/s or g/s.
Best wishes,
Ben
Dear Ben_Murphy,
I’m sorry I tried to reply to Catalyst. Since my emission file from megan2.10 has the same variable GDAY(unit:day), and the unit of other variables should be correct. I wanted to ask how to modify this unit. When I delete GDAY, I run an error saying there is no time variable. Thanks a lot. Thanks for your reply.
Thanks Axueaha,
Can you please send the output (via text file) from running ncdump on the emission file before and after you remove the GDAY variable?
-Ben
Yes. I uploaded some files. Thanks a lot.
cctm.log.txt (16.8 KB)
CTM_LOG_003.txt (40.7 KB)
CTM_LOG_removing the variable(GDAY).txt (9.8 KB)
meganout.log.txt (11.5 KB)
Thanks for posting these files. Could you please also post an ncdump of the MEGAN file after you removed the GDAY variable, i.e. a file like the “meganout.log.txt” variable generated after removing GDAM from the MEGAN file?
Which tool(s) did you use to remove GDAY from the file? Based on the CMAQ log file you posted for the run using the file after GDAY was removed, I’m guessing that the VAR-LIST attribute still contains GDAY. To subset variables from an existing emissions file (in this case, to remove variable GDAY), one of the safest ways to do so is to use m3tools program mxtract.
I did the same way. I am using CMAQ5.2 already and know the steps but the CMAQ-5.3.2 seems quite different entirely in compilation.
I’m sorry I tried to reply to Catalyst. Since my emission file from megan2.10 has the same variable GDAY(unit:day), and the unit of other variables should be correct. .
Sorry answer so lately. I’ve solved the problem by changing the GDAY unit to moles/s, and reset the value to 0 to avoid the program reading it as an emission source. Thanks a lot.