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.
This is the thread. Kindly help, please.
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.
I have tried your suggestion but still encountered similar error. How do I resolve this, please? @cgnolte
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.