Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

TBOUND exceeds table limit reset wrf error


New member
My objective is to compare WRF-Urban optimum configuration for a tropical city. I was able to run WRF-BEP, WRF BEP/BEM and WRF-slab with fixed physics configurations. However, I encountered the error stated below in my WRF-SLUCM run. Pasted below is my rsl.error tail

rrtm: TBOUND exceeds table limit: reset 417.859
rrtm: TBOUND exceeds table limit: reset 441.519
rrtm: TBOUND exceeds table limit: reset 443.087
d01 2019-02-01_14:00:00 Input data is acceptable to use:
rrtm: TBOUND exceeds table limit: reset 416.662
rrtm: TBOUND exceeds table limit: reset 422.743
rrtm: TBOUND exceeds table limit: reset 425.001
rrtm: TBOUND exceeds table limit: reset 422.008
rrtm: TBOUND exceeds table limit: reset 349.922
rrtm: TBOUND exceeds table limit: reset 433.079

Also, I have attached my namelist.input file. Your insight to solve this is greatly appreciated. Thanks


  • namelist.input.txt
    5.5 KB · Views: 26
First take a look at this FAQ that discusses the error "TBOUND exceeds table limit." You may also find some helpful suggestions in this post. Let us know if this still doesn't help.
Dear Kwerner thank you for this suggestion. Unfortunately, the issue isn't solved even after increasing the frequency of the radiation calls (radt from 30 to 3), I notice that part of my domain extends to the desert. I checked the wrfout file for that domain(d01) and really, the TSK values are higher than 340K
I have a few questions about this case:
(1) which version of WRF is used?
(2) What is the forcing data?
(3) cumulus scheme should be turned oof for the 3km domain, i.e.,
cu_physics = 1, 1, 0, 0,
(4) time step should be larger, i..,e,
time_step = 150
(5) when and where did the error first occur?
Thanks for your input Ming
1. the version is wrf 4.4
2. Forced with ERA 5 met
3. Yeah, later turned off. but issue not resolved
4. okay with 150 timestep, I will try that now
5. the error occurs at around 1400 of the first day. that was after the model have ran for like 35 minutes.

Even for those other models that ran successfully(with BEP and BEM), I see that the LST is just too high when compared with MODIS terra and Aqua LST


  • WRF_urban.png
    256.4 KB · Views: 22
Please save wrfout every time step before the time when the model crash. Then look at these wrfout files, finding when and where the first unreasonable T appears. From there, you may need to look each individual term that affects T, and figure out which term goes wrong and leads to the unreasonable result.

To figure out whether urban module is an issue, you may run the same case with sf_urban_physics = 0. If the case can run successfully, then at least it tells us that something is wrong with urban module.