Hi. I am running NEI platform 2016, the mobile sector. When running the mobile sector, I keep getting a Grid cell temperature out of range of minimum emission factor data (EF tables) with the meteorology files I am using. Besides generating new EF lookup tables in MOVES, are there are any other solutions that might be more efficient.
@abi0010. You can use this flag “TEMP_BUFFER_BIN” to expand the coverage of temperature ranges of MOVES lookup tables.
The default is set to 0.0 and it allows Movesmrg to cover the outside of min/max temperature range from Met4moves for Movesmrg RPP processing. If TEMP_BUFFER_BIN is set to 10.0, the original max temperature which is 90.0°F will be treated as 100.0°F, and minimum temperaure (=30°F) will be treated as 20.0°F internally in Movesmrg. Emission rates for those temperatures outside of the original temperature range will share the ones from original max/min temperatures.
Here is the details of Movesmrg program:
https://www.cmascenter.org/smoke/documentation/4.7/html/ch06s08s03.html
@bbaek
Hello…this worked so well. I wish I had asked and done this much sooner. Would have saved me a lot of headache, time and pain. This was the perfect solution. Thank you!
What emission factor tables are you using? And what area are you trying to run?
There are two sets of emission factor tables – one for summer months (has a 7 in the file names) and one for winter months (has a 1 in the file names). Which files are you using and which month are you trying to run for what region?
Hi @eyth.alison I was running for January so It should have been using the 1 in the file names. when I looked at the log scripts, it was using the correct month. I have also come across this issue when running summer months with the EF tables that end in 7. Some of the meteorology inputs that I use exceed the ranges in the EF tables. Which is why I was either looking to generate EF that would cover the temperature range I needed. But so far the Temp buffer appears to be working well. Almost done with the sector so I’ll see soon…
@bbaek Thanks again for the solution. It worked well for almost all the mobile sectors (RPD, RPH, RPV) before I ran into a snag with RPP. I would get an error saying that the maximum input temperature, is below the lowest temperature in the emission factor tables. This despite the TEMP BUFFER_BIN being set to expand temperature coverage. Any thoughts on this? I used a work around but I found it odd. I should explain that I doing the run in January and it only was the case for 3 days (Jan 17 - 19) that this error occurred for…
We are wondering what county are you working in and what year, and what is the temperature giving you the error?
Hi @eyth.alison It is US. I’m using meterology from a forecast model. The year is 2016.
@abi0010. I believe this is a known issue while processing RPP with daily min/max temperatures from Met4moves program. I think there is a bad value like -9.999*10^23 in your METMOVES input file to Movesmrg. This could happen when there are missing grid cells that Met4moves did not process to estimate min/max temperature values. When this happens, Met4moves will output default bad values. To avoid this issue, you need to list more surrogates including 100, 230 (land use), and more to cover most of the grid cells that Movesmrg needs. Met4moves relies on the list of surrogates to figure out the intersection between grid cell and counties, and estimate their min/max temperatures. You need to rerun Movesmrg with more coverage surrogates to cover all grid cells needed in RPP run.
I wish I could systematically implement this gap but unfortunately, there is no way around it.
@bbaek That is rather enlightening. I didn’t realize that at all. That makes a lot of sense because I couldn’t figure out why the temperature input range would be that low. But this makes sense as the temperature input for the movesmerge program is coming from the Met4moves output, not directly from the mcip files, the surrogates would affect it. I will go back and re-run to see what happens with more surrogates. This is really good to know. Thanks so very much.
I have a similar problem. The lowest profile minimum temperature is higher than the county minimum temperature. When I try to increase the temp profile range by adding the TEMP_BUFFER_BIN flag with different values, I still got the same error. Actually, the lowest profile minimum temperature does not change by adding TEMP_BUFFER_BIN. It should be mentioned that I ran met4moves with different TEMP_BUFFER_BIN as well, but still, I got the error while running the RPP sector.
The domain is 12US1, and I’m using the NEI2017 platform.
The surrogate list I used in met4moves run script are:
“100 202 205 212 222 230 232 239 242 258 259 304 306 307 308 506”
The following snapshots show that the lowest profile minimum temperature does not change with the different values of TEMP_BUFFER_BIN.
@ali.mousavi.nezhad90 Try to add water surrogates.
Have you used the same surrogates that are set up in the 2016 platform?
I’ve used the surrogates that are set up in the 2017 platform.
Thank you. I’ll try that.