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

Using daily surface data with 6-hour UPA -- how to configure?

jesseK97

New member
Hello,

I am trying to drive WRF with EC-Earth output which contains upper air variables(ta,ua,va,spechum) along with a few surface ones (psfc, ps) at 6-hour frequency. Both the soil and surface data is only available at daily resolution (T2,U10,V10,PSML,ST,SM). Per my understanding of WRF, it is okay to only have the UPA forcings at higher frequency since this is being used as lateral boundary conditions as well as the nudging.

This idea seems to be confirmed in this thread Running WRF with CESM2 data (but correct me if this is wrong).

When I follow the steps offered here (split the daily and hourly data, run ungrib twice), I get met_em files that contains a lot of missing values. In all the met_em files on a 6-hour time step, the daily values are missing which makes sense but I thought ungrib might have interpolated them. When I run real.exe I run into the following error once the program reaching such a time step without daily vals:

ERROR in psfc: flag_psfc = 1, flag_soilhgt = 0, flag_slp = 0, sfcp_to_sfcp = T
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 1396
not enough info for a p sfc computation
-----------------------------------------------

Any suggestions to solve this?

Thank you very much,
Jesse
 

Attachments

  • namelist.input
    5.9 KB · Views: 0
  • namelist_daily.wps
    1,014 bytes · Views: 0
  • namelist_6hour.wps
    1,015 bytes · Views: 0
Hi,
In the thread you link above, the user also got the same error you are seeing. Did you read that far and make adjustments to the code, recompile the code, and then run it again, as is discussed in that post?

Are you making sure to also include all required input fields, in addition to those you mention above?
 
Hi,
In the thread you link above, the user also got the same error you are seeing. Did you read that far and make adjustments to the code, recompile the code, and then run it again, as is discussed in that post?

Are you making sure to also include all required input fields, in addition to those you mention above?
Thanks for your response.

It indeed seems to work, including real.exe and wrf.exe, when I interpolate all the fields to 6-hour temporal resolution.

However, I worry about the accuracy of the simulation when I'm now using unphysical input, like a surface temperature (tas) without any daily cycle. It feels odd to artificially change the data in this way in order to avoid a runtime error.

- Is it correct that the surface and soil data are only used at the initial timestep, or should I change some code or options in the namelist? I want to make sure that no unphysical input is being used.
- In the original post, Ming Chen mentiones 'So technically, it should be practical to ungrib daily data and use them as initial input, although this will not be that accurate.' Why is running it in this way less accurate?

Thank you very much for your time.
Best,
Jesse
 
- Is it correct that the surface and soil data are only used at the initial timestep, or should I change some code or options in the namelist? I want to make sure that no unphysical input is being used.
- In the original post, Ming Chen mentiones 'So technically, it should be practical to ungrib daily data and use them as initial input, although this will not be that accurate.' Why is running it in this way less accurate?

It is correct that the surface/soil data are only REQUIRED at the initial time; however, it is recommended to have data available at certain intervals to provide updates at each boundary time. This is why the results may be less accurate. For a shorter simulation, this may be okay, but for longer runs where the conditions are changing over time at the surface, or within the soil, you may want to have data available more often.
 
It is correct that the surface/soil data are only REQUIRED at the initial time; however, it is recommended to have data available at certain intervals to provide updates at each boundary time. This is why the results may be less accurate. For a shorter simulation, this may be okay, but for longer runs where the conditions are changing over time at the surface, or within the soil, you may want to have data available more often.
I am doing WRF runs over a longer period of time 5-10 years, so this will be an issue for me. Especially if this means that for example the surface temperature is being updated on a 6-hour interval at the boundaries using the input meteo, as I essentially corrupted this data by interpolating.

Is there another way I could approach this problem?
Ideally the updates to the surface and soil data based on my meteo input would be applied daily, while the nudging and upper air boundary updates are still being applied at a 6-hourly interval. Is it possible to configure WRF in such a way to achieve this?

Thanks again for getting back to me.

All the best,
Jesse
 
Jesse,
See this practice exercise provided to students who attend the WRF tutorial. It discusses using 3-hourly data for standard input, and then 24-hourly data for SST. Although your variables are different, you should be able to follow the same approach by having WPS interpolate the 24-hourly data to the 6-hourly intervals of the rest of your data.
 
Top