Unrealistic TSK in WRF-SLUCM

[jan1203]

Hello,

I have a problem with simulation crashes in WRF version 4.4.2 with SLUCM, which typically occurs in summer. The only relevant output in rsl files is exceedence of vertical cfl condition in some grid-points, but neither decrease of time-step nor epssm=0.4 solves the problem. When I investigated more, I noticed that TSK array is somehow strange in the last hour before crash - in some urban areas are temperatures higher than 340 K (!) - see the attached figure (domain in central Europe). Also related arrays as sensible or latent heat fluxes are affected to unrealistic values.

The same occurs in version 4.5.0, the last version that run without errors (and with realistic TSK) is 4.3.3. Namelist with setting is attached.

Have somebody similar experience or does somebody know how to fix it?

Thanks, Jan

 

[kwerner]

Hi Jan,
Is your domain covering complex terrain - especially near the boundaries? You may also need to try setting smooth_cg_topo = .true. in the &domains section of the namelist, prior to running real, to get rid of the CFL errors.

When you ran the case with V4.3.3 and it worked okay, were you using the exact same setup (i.e. identical namelist.input, same domain, dates, times, and input data)?

 

[jan1203]

Thanks for the answer. Unfortunately, your proposed option doesn't work for me. And in any case, problematic grid-points are usually far from boundaries and are not related to mountainous regions.

Yes, the domain, met_em files, namelist and all setting are the same.

Not only temperature, but overall energy balance is strange (before crash) - the members have values > 1000 W/m2, especially QFX (very opposite - great deposition on surface) and LH ~ -12000 W/m2 (!).

 

[kwerner]

Hi Jan,
I spoke to our physics specialist. They are curious what HFX does leading up to the large TSK values - does it change suddenly or grow steadily?

 

[jin199804]

Hi Jan,
I spoke to our physics specialist. They are curious what HFX does leading up to the large TSK values - does it change suddenly or grow steadily?

Hi Kwerner, my case was similar to his, in my case, in wrfout_d04_2019-08-04_04:00:00 the HFX's range was from -54 to 302 , but in wrfout_d04_2019-08-04_05:00:00 the range change suddenly from -59 to 2618.

 

[kwerner]

One other thing - are you using standard inputs, code, and tables? Can you also let me know how far into the simulation it crashes? If you create a restart file to start shortly before the crash, and start the simulation from that point, does it still crash? If so, I would like to try to recreate the issue here. For that, I'll need your wrfbdy file and your wrfrst file for that time. Those files will likely be too large to attach, so take a look at the home page of this forum for instructions on sharing large files.

 

[jin199804]

One other thing - are you using standard inputs, code, and tables? Can you also let me know how far into the simulation it crashes? If you create a restart file to start shortly before the crash, and start the simulation from that point, does it still crash? If so, I would like to try to recreate the issue here. For that, I'll need your wrfbdy file and your wrfrst file for that time. Those files will likely be too large to attach, so take a look at the home page of this forum for instructions on sharing large files.

Yes, I used the tandard inputs, code, and tables. About 1-5 hours it would crash. How short would you want? About one hour ago or one minute ago?

 

[kwerner]

If it's crashing within 1-5 hours of simulation time (not actual clock time), then it's okay to just send the wrfinput/wrfbdy files. I was concerned because your namelist is set up for a 30 day simulation, which would be a really long time for me to try to reproduce.

 

[jan1203]

In my case, the simulation crashed after app. 19 days.
I could try to make a restart run beginning before the crash point.