I’m running scheduled daily tasks and using combine to post-process CMAQ outputs. But recent days combine will error abort which ran perfectly a few days before:
Problem evaluating: exp(118.87-24084/TEMP2[4]-6.025*log(TEMP2[4])) ERROR evaluating LOG equal to -9.9989998E+36 or 5.7113290E+00
-9.999e36 is the standard MISSING value for these files. combine should actually avoid evaluating the log of any negative number, so that would seem to be correct behavior.
Perhaps would have been better if combine detected MISSING and propagated that; doing so portably (so that round-off effects are managed correctly) is more complicated than the authors attempted to do…
If there is a reason you would expect TEMP2 to be missing in some cases, you could set up a conditional expression in your SpecDef files so that your calculation is performed only when TEMP2 is not missing. Something along these lines:
You’ll have to decide what a reasonable lower bound for TEMP2 should be in the first part of the expression above, and in the last part of the expression you can set whatever token value you’d like to use for cases when the calculation cannot be performed . The condition will be applied on a grid-by-grid basis, i.e. at each grid cell, the resulting calculated value for a given time step would either be exp(118.87-24084/TEMP2[4]-6.025*log(TEMP2[4])) or -999999 depending on the value of TEMP2.
In the SpecDef files released with CMAQ, you can view an example of these conditional calculations for the ‘precip’ variable, to guard against including RC for cases when WRF was run without convective parameterization and MCIP writes a token negative value to RC:
precip ,cm ,RC[4]>=0 ? RN[4]+RC[4] : RN[4]
If you do not expect TEMP2 to be missing in the first place, you’d obviously want to go further upstream and address the issue there.