Metgrid SST interpolation artifacts

[elkro21]

Hi all,

I have a problem with the met_em* files generated by metgrid.exe similar to this post here: metgrid - SST interpolation artifacts (not solved).

I want to run metgrid with meteorological data from ERA5 (prefix FILE:...) and climatological SST data from ERA5 (prefix SST:...). If I run metgrid without the "external" SST data (fg_name = 'FILE'), metgrid uses the SST from the meteorological input data and the interpolation works fine, resulting in smooth SST-met_em output fields. However, as soon as I try to include the "external" SST data (fg_name = 'FILE', 'SST'), I get strange interpolation artifacts in the met_em files (see screenshot).


I have produced 3-hourly metgrid files for 2004-2021 for two domains. The figure shows
the met_em.d01.2006-01-18_00:00:00.nc file. There are weird artifacts to the left and
top of D1 in all met_em files. Apart from these artifacts, the SST seems to be fine.

Both the input grib files I ran through ungrib and the SST:... intermediate files seem to be fine, so I have no idea what might be causing the interpolation artifacts in the metgrid output. I am using WPS v.4.2 with these METGRID.TBL options:

name=SST
interp_option=sixteen_pt+four_pt+wt_average_4pt+wt_average_16pt+search
masked=land
interp_mask=LANDSEA(1)
fill_missing=0.
missing_value=-1.E30
flag_in_output=FLAG_SST

I uploaded one of my yearly input grib files, a sample ungrib FILE:... and SST:... file, and one of my met_em output files here.

Do you have a hint what could be wrong?

Cheers

 

[Ming Chen]

One quick fix of the unrealistic SST along coastal areas is to replace SST by SKINTEMP. Please delete the line below from Vtable.ECMWF, then rerun ungrib.exe.


34 | 1 | 0 | | SST | K | Sea-Surface Temperature |

In this case SST will not be extracted from ERA5 and SKINTEMP will be used as SST. We believe this is reasonable because SST and SKINTEMP is almost the same over ocean.

 

[elkro21]

Hi Ming, thanks for your reply. I think this will not solve my problem unfortunately, because what I want to do as part of a sensitivity study is to change the original ERA5 SST field and replace it with climatological SST. For this reason, I am providing the SST data separately (they are also from ERA5 but are climatological fields) and want to combine them with my other input data in metgrid.

If I delete the row you suggested in the Vtable and force WRF to use SKINTEMP as SST, I cannot change the SST input and replace it with external SST, right? Also, using the original ERA5 SST does not seem to cause any problems, because if I run metgrid without the separate SST fields and use the SST from the meteorological input fields instead, the SST looks fine in the metgrid output, so there is no general interpolation problem. The artifacts only occur when I want to read in the external climatological SST. Also, the artifacts seem to occur more in the open ocean and not so much near the coast.

 

[Ming Chen]

In the case you attempt to use external SST instead of ERA5 SST, you need to provide landmask specifically for the external SST data, then modify METGRID.TBL so that metgrid.exe will know what landmask is used for horizontal interpolation.

A detailed explanation can be found at https://www2.mmm.ucar.edu/wrf/users/tutorial/presentation_pdfs/201907/duda_wps_advanced.pdf, and the slides 47-58 give an example how to process external soil data. The same approach is also applied to external SST.

Hope this is helpful.

 

[elkro21]

Thank you, I have beed considering that as well. The thing is that my "external" SST data are also from ERA5 (but representing climatological fields; details below). Consequently, the "external" SST uses the same landmask as the meteorological input data, which already come with a landsea mask (ECMWF GRIB code 172). My understanding is that there is no need to provide a separate landmask if an appropriate one is already provided by the meteorological input - is that correct?

To elaborate on my "external" SST input: In contrast to the meteorological input, the "external" SST data are climatological fields. They are based on a 366-day SST climatology for the period 1981-2010, so they are not constant over time but have some daily variation. I have synchronized these data to cover the same time period and temporal resolution (3-hourly) as the meteorological input data, ensuring that they provide a climatological SST field for every 3-hr input time.

 

[Ming Chen]

if your external SST has the same landmask as that of other data, in this caase ERA5, then yes it is right that you don't need to provide landsea mask for the external SST.

However, in ERA5, the default fill-values overland is 0K (as in -273.15ºC). If you're running in high res, the interpolation of SST leads to some wonky numbers around the landmask. Probably you can set fill_missing = 285. or some other value to remedy the problem.

Please let me know whether this works for you.

 

[elkro21]

I have just solved the issue. The problem was that in the climatological SST input I created, the latitudes ranged from -65 to -10°N, with an interval of 0.25°. However, in the meteorological input data that I had downloaded directly in grib format from the Copernicus CDS, the latitude was flipped and ranged from -10 to -65°N, spaced at -0.25°. I do not know exactly what happened in metgrid. However, the artifacts in the SST field in the metgrid output occurred exactly where the flipped land mask was, so I suspect that the different latitude specification resulted in an interpolation error due to a misplaced land mask for the SST input. I have now also reversed the latitudes in my SST input data and the metgrid output looks fine. Thanks for your advice and suggestions!

 

[Ming Chen]

Thank you for the update.