Inconsistency in MINTEMP, MAXTEMP and time zone in MET4MOVES output

Hello all,

I am facing following issues on the MET4MOVES output:

  1. I have METCOMBO data from 25 May 2021,00:00:00 UTC to 27 May 2021, 00:00:00 UTC (attached a screenshot here). But when I run MET4MOVES for 4KM resolution in Central Florida, I could not include End time to be larger than 26 May 2021,04:00:00. I guess it is the time zone issue which is GMT-4 in FL. But although that issue, I should be able to run MET4MOVES until End time of 26 May 2021,20:00:00. I will be thankful if anyone can enlighten me with that issue.

  2. MET4MOVES output is giving inconsistent result at the Atlantic ocean region for both MAXTEMP and MINTEMP. For MINTEMP, it is giving an invalid large number (9.9E+36) and for MAXTEMP, it is giving an invalid small number (-9.9E+36) across the ocean. I guess this is because of the surrogates I used is not enough to create MIN and MAX T profile in the ocean. Currently I am using 100 (Population NO FILL),110 (Housing FILL), 308 (NLCD Low + Mid + High FILL),309 (NLCD Open + Low + Mid FILL),320(NLCD Forest Land FILL),340 (NLCD Land NO FILL),350 (NLCD Water NOFILL) as surrogates in MET4MOVES script. I would like to know which surrogates I need to input to get Temperature profile in the ocean.

Please find the attached screenshot of METCOMBO output, MINTEMP and MAXTEMP VERDI Tile Plot and MET4MOVES script that I used.


run_met4moves.csh (2.8 KB)


For #1, we always use ENDTIME = 230000 (the default). If met data is available from 5/25 0:00 – 5/27 0:00 (UTC), then the following settings should give output for two days (5/25 and 5/26). If you tried this and it did not work, what was the error?

setenv STDATE ${YEAR}145 # Starting date in Julian

setenv ENDATE ${YEAR}146 # Ending date in Julian (should be 366 for leap year)

setenv ENDTIME 230000

Regarding time zones – our met data, met4moves outputs, and SMOKE-MOVES runs are all conducted in UTC terms. In other words, both the inputs and outputs to met4moves are UTC, and the time zone shouldn’t come into play. On a related note, we use the default setting for SMK_DEFAULT_TZONE (5) – we don’t think this affects met4moves, but we could be wrong; that’s worth trying (they have it set to 0) if it looks like there are errors related to time zones.

For #2, it is okay if there is no temperature data over the ocean – what you are describing over the ocean is normal. The important thing is that the surrogates that are used in the met4moves run are the same ones to be used in SMOKE-MOVES, so that all cells with emissions also have valid MINTEMP/MAXTEMP temperature data.

#1 : The error is: Missing Meteorology data during requested episode. Please find the log files on the error.run_met4moves.log.txt (389.6 KB)

The information on how to set the timezone in SMOKE is available from the link below. When OUTZONE is set to “0”, it means that all output from SMOKE are in GMT. So, if you want to output the results in local time, please check out the timezone table from the link below:

Regarding to your error message, your current Movesmrg’s OUTZONE is set to “0”. So Movesmrg is looking for next day Met4moves MINTEMP and MAXTEMP. If you want the output to be in GMT, please add additional date for Met4Moves to generate next date met variables for Movesmrg.

Met4moves requires meteorology data for the day after the ENDATE. If that extra day of met data isn’t available, we usually copy the met from the last day that we have to the next day via m3tshift. This could be part of your issue.

I’m getting the same error message (“ERROR: Missing meteorology data during requested episode.”) when running met4moves for the first 5 days in January, but I have meteorology data for the whole month, so already have data for the day after ENDATE. Do you know what else might cause this error?

Please check the METLIST (list of METCOMBO files input to met4moves) first: does it list the meteorology files for all of January, or just the first 5 days? If the METLIST already has all of January, can you provide the met4moves log?

Depending on where you are modeling, you may provide the last day of the previous year for Met4moves to handle the time zone shifting. It won’t hurt to add one more day to your METLIST file to ensure that your met files cover your modeling period.

The METLIST has all of January, and the last day of the previous year.
The log file is:
met4moves_log.txt (398.5 KB)

The log says the METCOMBO file for the last day of the previous year (METCOMBO_112131) does not exist. Could be a typo in the METLIST – the filename should probably be METCOMBO_111231 instead?

The dates are set incorrectly. The start (STDATE) should be set to “2012001” (YYYYDDD) instead of 20121. The same rule applies to ENDATE (ending date). Check the SMOKE user’s guide for the details.

Thank you. There was a typo in the filename in METLIST for that run, but what was also causing an error was the days missing the leading 0s. Thanks, it’s working now.