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

(RESOLVED) LANDSEA mask best practices

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.

B

bartbrashers

New member
Quick question:

The example netcdf-to-intermediate.f at https://www2.mmm.ucar.edu/wrf/src/netcdf-to-intermediate.f writes a LANDSEA mask in the same file as the SST field, for each time-stamp.

Is that because METGRID can correctly handle a LANDSEA field in the SST:YYYY-MM-DD_HH files, and another (different) LANDSEA field in the output from UNGRIB of whatever dataset we're using (ERA5, GFS, etc.; which I usually write to FILE:YYYY-MM-DD_HH files)?

Or should the user delete the line for LANDSEA from the Vtable for the UNGRIB run that creates FILE:YYYY-MM-DD_HH files, and avoid giving a separate invariant file in &metgrid >> constants_name, so METGRID only gets one LANDSEA field? Pick the one with highest resolution to give to METGRID?
 
Bart,
METGRID needs both LANDSEA from your SST data and LANDSEA from GEOGRID to correctly process the land surface and soil data (lu_idex, soil, soil, etc.). So please keep both in your intermediate files.
 
Once you create your own SST intermediate files, the 'OLD' SST from UNGRIB output will be replaced by the 'NEW' SST.
 
Understood!

However, when I tried to write LANDSEA as a second data chunk following the example at https://www2.mmm.ucar.edu/wrf/src/netcdf-to-intermediate.f, METGRID was not happy. I'll try again.

The example netcdf-to-intermediate.f also lacks the wind_grid_rel found in metgrid/src/read_met_module.f90:

Code: 
!  3) WRITE WIND ROTATION FLAG
     write(12) wind_grid_rel

Should I just skip writing that logical flag for non-vector WPS Intermediate files? If so, maybe the example could add a comment to that effect.

Bart
 
Bart,
I believe it is OK that you skip the logical variable wind_grid_rel for non-vector WPS intermediate file. This variable is initialized to be .true. in metgrid/src/process_domain_module.F, and later replaced by the its "true" value based on input. It doesn't affect interpolation of non-vector variables.
 
OK, what about map_source?

It's in https://www2.mmm.ucar.edu/wrf/users...guide_chap3.html#_Writing_Meteorological_Data:

Code: 
character (len=32) :: map_source  !  Source model / originating center
...snip...
if (iproj == 0) then
      write(unit=ounit) hdate, xfcst, map_source, field, &
                        units, desc, xlvl, nx, ny, iproj
      write(unit=ounit) startloc, startlat, startlon, &
                        deltalat, deltalon, earth_radius

But it's not included in https://www2.mmm.ucar.edu/wrf/src/netcdf-to-intermediate.f:

Code: 
     write(11) 3
     write(11) hdate, xfcst, field, units, Desc, 200100.0, 1440, 720, 0
     write(11) -89.875, 0.125, 0.25, 0.25

Seems like including/excluding 32 bytes might cause problems.

Which example is correct?

Bart
 
Using WPS/util/src/int2nc.exe on an intermediate file that contains both an SST and LANDSEA blocks creates a netCDF file with only the SST part. So I can't verify that the LANDSEA is written correctly.

Another thing to add to the list of requested updates?

Bart
 
Can anyone suggest a method for dealing with the land/sea mask from a non-global dataset?

Many high-res SST datasets are regional (e.g. Australia/NZ, or the Baltic) and many more cover only -80 to +80 in latitude. I can extract and write the landmask from one of those "almost global" datasets, but the SST_MASK I create has a hole of missing data at the poles. I can get around that using these lines in METGRID.TBL:

Code: 
name=SST_MASK
        interp_option=nearest_neighbor
        missing_value=0.
        fill_missing=0.   # Northern hemisphere > +80 deg is water
        # fill_missing=1. # Southern hemisphere < -80 deg is land
        fill_lev=200100:SST_MASK(1)

Using ncview the SST_MASK looks OK, 0's over the water and under the polar ice, and 1 over land. But the resulting SST field has values of 0 inside 80N.

When I supply SNODAS data (US CONUS only) the resulting SNOW and SNOWH fields are from SNODAS where it exists, and from the coarser reanalysis dataset where the SNODAS has missing values and outside its sub-domain.

Why doesn't SST do the same thing, and use the ERA5 values outside of where my non-global yet high-res SST dataset exists? Is that because I don't supply and landmask with SNODAS data? Ming Chen says I should...

It seems like METGRID should overlay the two SST datasets first, then apply the landmask.
 
A summary of LAND-SEA Mask best practices, as I understand them, just to close out this thread.

When using an SST dataset that's finer resolution than the rest of your input data (e.g. ERA5 or GFS or ...) it's best to supply a land-sea mask.

Do NOT name the field "LANDSEA" or it will conflict with the field in the rest of your input data. Use "SST_MASK" or something else.

You can append the SST_MASK field after each SST field in individual WPS Intermediate files (SST:YYYY-MM-DD_HH), or use a static file.

Do NOT use a land-sea mask if your SST dataset's geographical coverage is smaller than your outer-most WRF domain (d01). It won't work, because METGRID complains about missing SST and stops. Had METGRID layered the limited-area SST data on top of the global SST field first, then applied the land-sea mask, it might have worked.

The only work-around I can think of would be to run METGRID separately for those domains whose geographic coverage exceeds the limited-area dataset, then again for the finer domains.
 
Thank you for updating with your experiences and guidance. Hopefully this will be helpful so someone else in the future.
 
You must log in or register to reply here.
Top