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

Running WRF with CESM2 data

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.

maR_Kus

New member
Hi All,

I would drive WRF with output from CESM2 and I am looking for some suggestions to prepare all required variables for real.exe.
While I found 3D data (TT, UU, VV, SPECHUM) at 6h intervals, for surface variables like SOILM, SOILM and PMSL I only have daily data.
In case of 10m wind components, 2m temperature and surface humidity the lack of 6 hour data is not a big issue as I can force the model with the lowest layer of 3D data, but I was wondering how can I use the other daily surface averages to force WRF? I mean, should I run ungrib 2 times (the first with 6h 3D fields and the second with daily data) and then metgrid passing the intermediate files created with ungrib? Will metgrid complain on the lack of data and if not, how it fills the missing hours during a day?

Any suggestion is welcome,
Markus
 
Markus,
It is important to have upper level data such as T, U, V, Q, etc. We need these data to provide lateral boundary forcing for WRF.
Surface data including soil information are only required at the initial time. So technically, it should be practical to ungrib daily data and use them as initial input, although this will not be that accurate.
Please try the following steps:
(1) ungrib daily data and name them as SFC:yyyy-hh-dd_hh by setting
&ungrib
out_format = 'WPS',
prefix = 'SFC',
(2) ungrib upper level data and name them as UPA:yyy-hh-dd_hh by
&ungrib
out_format = 'WPS',
prefix = 'UPA',
(3) in your namelist.wps, set fg_name = "SFC", "UPA"
(4) run metgrid.exe.

I don't know the details of your data.But I think there is one issue you need to pay attention to: the date in SFC file you will be used must be the same as the initial time of your integration. You probably need to manually modify the date in SFC.

Please let me know whether the above works for you.
 
Ming,
thanks for the clarifications; gonna try and let you know ASAP (I need a few days to prepare all data).
Markus
 
Hi Markus,
I just edited my previous message, which includes a few typos. I am sorry for the mistakes in the message. Please take a look.
 
Ming,
After struggling a while with CESM2 data, I have been able to create grib files for WPS.
I successfully ran ungrib with daily surface and 6h 3D data and metgrid works fine setting fg_name = "SFC", "UPA". However, I noted that only the first met_em file (i.e. XXXX-01-01_00:00:00) contains soil temperature and soil moisture (with respective axes num_st_layers, num_sm_layers), while the other files of the same day do not have these variables. So, when I run real.exe I get this error at the second iteration:

Code:
 -----------------------------------------------------------------------------
  
 Domain  1: Current date being processed: 1980-01-01_06:00:00.0000, which is loop #   2 out of    5
 configflags%julyr, %julday, %gmt:        1980           1   6.000000    
 metgrid input_wrf.F first_date_input = 1980-01-01_06:00:00
 metgrid input_wrf.F first_date_nml = 1980-01-01_00:00:00
Timing for input          0 s.
 Missing surface temp, replaced with closest level, use_surface set to false.
 Missing surface u wind, replaced with closest level, use_surface set to false.
 Missing surface v wind, replaced with closest level, use_surface set to false.
Using sfcprs2 to compute psfc
  flag value of flag_qnwfa is            0
No average surface temperature for use with inland lakes
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  <stdin>  LINE:    2297
Not enough soil temperature data for Noah LSM scheme.
-------------------------------------------


Have you any suggestion to overcome this issue?
Thanks into advance for help,
Markus
 
Markus,

Since soil information is only needed at the initial time, I suppose it is fine if we skip processing soil data after the initial time. Please look at the code dyn_em/module_initialize_real.F, and find the piece of code below:
Code:
         CASE ( LSMSCHEME, NOAHMPSCHEME )
            IF ( num_st_levels_input .LT. 2 ) THEN
               CALL wrf_error_fatal ( 'Not enough soil temperature data for Noah LSM scheme.')
            END IF

You may simply comment out the above lines, then recompile WRF and run real again. I hope this will make REAL to run successfully.
Please let me know whether it works.
 
Ming,

thanks for getting back to me. Finally I decided to create pseudo 6h surface data for soil moisture and soil temperature, so each met_em file contains the proper axes; I tried this solution and both real and wrf run without any problem. Anyway, thanks for the proposed changes.

Now, I have just one last query: among 3D mandatory input variables there is the geopotential height. I have interpolated original CESM2 data from model levels to constant pressure levels and I do not provide the geopopential height as input in WPS and neither real nor WRF complain about its lack. I was wondering whether this is correct or not? I looked at Vtable.UKMO_no_heights and also for this input no information on heights is given.

By the way, I reopen the post as I forgot to ask if compiling with -DNO_LEAP_CALENDAR is enough to run WRF with CESM2 data; this latter has a 365-day calendar.

Markus
 
Markus,
Thanks for the update. I am glad that you fix the problem.
compiling with -DNO_LEAP_CALENDAR is enough to run WPS/WRF with CESM2 data. Please remember to add this option to configure.wps and configure.wrf, and recompile the codes.
 
Ming,
thanks for confirming the compilation flags.

What about my question on geopotential height I asked in the previous post ("Among 3D mandatory input variables there is the geopotential height. I have interpolated original CESM2 data from model levels to constant pressure levels and I do not provide the geopopential height as input in WPS and neither real nor WRF complain about its lack. I was wondering whether this is correct or not? I looked at Vtable.UKMO_no_heights and also for this input no information on heights is given.)"???

Markus
 
Top