Merge Vtable.GFS and Vtable.SST

Topics related to running the ungrib.exe program
Post Reply
francescomaicu
Posts: 24
Joined: Wed Nov 25, 2020 11:45 pm

Merge Vtable.GFS and Vtable.SST

Post by francescomaicu » Fri Jan 29, 2021 10:47 am

Dear WRF Supporters,
I'm trying to go a little bit into the detail of the SKINTEMP and SST.
I run WRF with NCEP GDAS data.
Once I download the grib files I run two times ungrib, first with Vtable.GFS, then with Vtable.SST.
The point is that both SKINTEMP and SST are derived (I guess looking at the Vtable) from the same field in the input grib files. Am I correct?
Then running metgrid, the two variables appear different because the interpolation/masking are different in the metgrid.tbl.
If I add the only line of Vtable.SSt in Vtable.GFS and run ungrib, the intermediate files do not contain the SST, but only the SKINTEMP.
Why this happen?

kwerner
Posts: 2287
Joined: Wed Feb 14, 2018 9:21 pm

Re: Merge Vtable.GFS and Vtable.SST

Post by kwerner » Mon Feb 01, 2021 11:39 pm

Hi,
The Vtable.SST table is meant to be run with an additional source of SST data. Most of the large-scale models include an SST or SKINTEMP component, but the data are very coarse. This is okay as long as you aren't running for more than about a week. If running a week or longer, you likely want to obtain SST data from another source that will have higher temporal and spatial resolution. The 6th slide on this presentation provides some links to SST fields, if you're interested. For those, you would use Vtable.SST. You will still need to run ungrib separately - once for the NCEP GDAS data, and again for the SST data. You can see examples for running it like this here.
NCAR/MMM

francescomaicu
Posts: 24
Joined: Wed Nov 25, 2020 11:45 pm

Re: Merge Vtable.GFS and Vtable.SST

Post by francescomaicu » Tue Feb 02, 2021 11:18 am

Hi,
thank you for the comprehensive answer.
I agree with you regarding the length of the simulation and the opportunity to change to different SST datasets.
My concern is that if I use GDAS or GFS data, both SKINTEMP and SST are derived from the TMP variable in the grib files, so their content is the same except for the interpolation/masking ....
In this case I can avoid to ungrib separately the SST, and METGRID will generate only the SKINTEMP variable.
Finally REAL, will produce (I ask the SST_update) the wrflowinp file with the SST, even though SST is not in the metgrid files.
This is good, but I guess a little bit confusing at a first look. By the way, do you think this procedure is correct if I run a 4 days long simulation.
Things are different with ECMWF grib files which contain both SSTK (sea surface temp) and SKT (skin temp), so I run ungrib just once.
By the way, in the Vtable.ECMWF, it is clear that SST and SKINTEMP are extracted from two different fields, even though SKT has metgrid description as Sea-surface temperature.
The result is that in the metgrid files I find both SKINTEMP and SST, and interestingly they are different since their difference is not zero on the ocean.
Thank you!

kwerner
Posts: 2287
Joined: Wed Feb 14, 2018 9:21 pm

Re: Merge Vtable.GFS and Vtable.SST

Post by kwerner » Wed Feb 03, 2021 1:01 am

Hi,
Thank you for the explanation. It is perfectly fine that the SST field is derived from SKINTEMP; however, if you are not using high-resolution time-varying SST data input, there really is no need to use the sst_update option. If you are only running for 4 days, it shouldn't be necessary. You can read more about the sst_update option in our Users' Guide.
NCAR/MMM

Post Reply

Return to “ungrib”