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

RRTMG-K SW scheme same results as FLG SW scheme

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

M

meteoadriatic

Member
Hello,

I know this is very strange topic. But here it is what I see.

I'm running series of experiments where I change one physic scheme at a time on several scenario cases, and check results against measurements in order to find best performing schemes from all categories for my area.

I've got to shortwave radiation schemes and found very strange results.

RRTMG-K scheme (ra_sw_physics = 14) gives completely the same results as FLG scheme (ra_sw_physics = 7). No difference. Also, it runs at the same speed as FLG, whereas, what I have read about RRTMG-K, it should have very similar speed to original RRTMG, but here it runs much faster.

This leads me to conclusion, that somehow, when I select ra_sw_physics = 14, WRF runs FLG scheme instead.

Is it possible? I looked at source code but cannot find obvious error there (at least in Registry all seems OK, and I don't know if schemes selection against their namelist number is actually defined somewhere else...)

I didn't yet tested longwave corresponding schemes.

Again, situation is not particularly important to me, because I'm not interested neither in RRTMG-K nor FLG at the moment, just want to let you know what I found. Let me know if you need more information from me about this.

Bye
Ivan
 
Hi,
Can you let me know which version of the code you are using, and whether you have made any modifications to the code?

Thanks,
Kelly
 
Hello,

4.1. Yes but only in module_sf_sstskin.F and module_sf_noahmplsm.F and added few related entries in Registry in order to be able to control added changes with namelist.input. I don't think those changes could cause this, but, if you think they could, I can try with completely unmodified code and report again.

Ivan
 
Ivan,
You're right that it's unlikely that any of your modifications could result in the problem, but just to be certain, do you mind trying it with a clean version - just to see if you get different results between a case with RRTMG-K and FLG?

Thanks!
 
Hello,

I got further in investigation.

I rerun with original code, the result is same as before but, I looked into changes over time and it looks they both do not work at all, that's why they are the same. No increase in temperature in domain during day, it seems that SW radiation is =0 everywhere. Left frame is init time, right frame is f06 time; you can see forcing from GFS on domain boundary (warmer temperatures) but within domain they are much the same as at init time. And yes right one is at the middle of day, it is not night.

So, namelist input is attached for you to try yourself. Code is compiled with Intel 2019.

I wonder now, could those be incompatible with adaptive timestep? I'll check that also shortly.

Ivan
 

Attachments

  • Screenshot from 2019-05-23 00-08-59.png
    Screenshot from 2019-05-23 00-08-59.png
    776.2 KB · Views: 1,561
  • namelist.input
    7.3 KB · Views: 58
Hi Ivan,

Okay, so the problem is that there are certain schemes that assume the shortwave and longwave radiation are set to the same value (i.e., the same scheme for each), which is the case for RRTMG-K and FLG. The radiation driver first calls all of the longwave routines and then moves on to shortwave. For RRTMG-K and FLG, nothing is ever done regarding shortwave because the code assumes that if you have (for e.g.) RRTMG-K set for longwave, then you have the same set for shortwave. So just changing ra_sw_physics to 14 means that, similar to what you said, it is not actually ever being called.

In general it is a best practice to use the same scheme for both long and short, and that is how we advise setting them. However, we do agree that we probably should have a check that will stop you from doing it the way you have done it (e.g., ra_sw_physics = 14, ra_lw_physics = 1) so that users will not run cases, assuming all is working correctly, and find out down the road that wasn't the case. We will plan to put in a check for this in future releases. If for some reason, you do need to have lw/sw set to different values, then unfortunately there will be quite a bit of code manipulation to do this, but if you'd like to take on that task, it should be possible with a lot of work.
 
Oh, thank you very much for precise explanation. I absolutelly agree that software check for that would be good idea, but a quick note in User's Guide should be good enough :)

I would never thought that for RRTMG-K both sw and lw should be the same, because I think that I saw that for example ra_lw_physics = 1 and ra_sw_physics = 4 is pretty common combination used.

Ivan
 
Yes, I believe the standard RRTMG scheme is a bit more flexible, which is why you likely don't see any of these same problems if you use that combination (ra_lw_physics = 1 and ra_sw_physics = 4).
 
You must log in or register to reply here.
Top