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.

Hasibul




run_met4moves.csh (2.8 KB)

Hasibul

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:

https://www.cmascenter.org/smoke/documentation/4.8.1/html/ch02s10s04.html

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.