Extrapolation in Regrid_Data_Plane #1570
-
I am using nearest neighbor method to interpolate from a 0.5 degree grid domain to a 0.25 degree grid domain but there is now a new column after regridding and the array elements there are undefined because of extrapolation. How should I handle this? I don't see a keyword in Regrid_Data_Plane for choosing an extrapolation technique. Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
Hi Chris: Do you have a file you would be able to share with us so we can better understand what is happening. Instructions to send data can be found here: #954 Thanks, |
Beta Was this translation helpful? Give feedback.
-
@cjmelick I'll try to clarify the existing logic to help us decide what, if anything, should be done about it. First, the regridding logic mostly resides in the vx_regrid library. The met_regrid_generic() function handles many of the regridding types. The from_grid and to_grid variables store the definition of the source and destination grids. And the high-level logic is this:
You mentioned that regridding from 1/2 degree to 1/4 degree introduces a column of missing values. I'm wondering what version of MET you're using because our support for wrapping global grids is very recent. Here's some commands to illustrate. Rather than using NCEP Grid 193 to demonstrate I manually defined a grid to move the wrap longitude from the edge to the middle. Regrid 0.5 deg GFS to 0.25 degree using MET version 10.1.0:
The following log messages indicate that the input is on a global grid for which the longitudes should be wrapped:
Plot the output file and see no line down the middle:
But if you rerun the same commands using MET version 10.0.0, you DO get a line of missing data down the middle!!! This issue was identified in MET version 10.0.0 and fixed in MET version 10.1.0. You can find the following info about it in the MET-10.1.0 Release Notes. Enhance MET to use point observations falling between the first and last columns of a global grid (#1823). Hope that helps explain it. |
Beta Was this translation helpful? Give feedback.
-
John and Christina,
Sorry I am just now responding but I have not felt well recently. Thanks
for the input.
John, I think what you described is exactly what my problem is and, as you
know, the Air Force is still on a much older version of MET that we hope we
can remedy soon. The artifact that you showed is what I was seeing too.
I had a clever workaround just doing some array slicing and arithmetic
operations (and averaging of the first and second to last columns) in
Python.
Thanks again for your help,
Chris
…On Mon, Apr 18, 2022 at 3:18 PM johnhg ***@***.***> wrote:
@cjmelick <https://github.com/cjmelick> I'll try to clarify the existing
logic to help us decide what, if anything, should be done about it.
First, the regridding logic mostly resides in the vx_regrid
<https://github.com/dtcenter/MET/tree/main_v10.1/met/src/libcode/vx_regrid>
library. The met_regrid_generic()
<https://github.com/dtcenter/MET/blob/205fc9476aebac5bbfc18dfdb2fea38bd1959531/met/src/libcode/vx_regrid/vx_regrid.cc#L112>
function handles many of the regridding types. The from_grid and to_grid
variables store the definition of the source and destination grids. And the
high-level logic is this:
1. Loop over the to_grid (x, y) points and convert each to (lat, lon).
2. Convert that (lat, lon) to from_grid (x, y) coordinates.
3. If that (x, y) point is off the from_grid AND the from_grid is NOT
a global grid, the result is bad data.
4. Otherwise interpolate nearby values to that from (x, y) grid point
location.
You mentioned that regridding from 1/2 degree to 1/4 degree introduces a
column of missing values. I'm wondering what version of MET you're using
because our support for wrapping global grids is very recent.
Here's some commands to illustrate. Rather than using NCEP Grid 193
<https://www.nco.ncep.noaa.gov/pmb/docs/on388/tableb.html#GRID193> to
demonstrate I manually defined a grid to move the wrap point from the edge
to the middle.
Regrid 0.5 deg GFS to 0.25 degree using MET version 10.1.0
met-10.1.0/bin/regrid_data_plane \
gfs_2012040900_F012.grib2 \
'latlon 1440 721 -90 -180 0.25 0.25' \TMP_P500_regrid_met_10.1.0.nc \
-field 'name="TMP"; level="P500";' -v 4
Note these log messages indicate that the code has figured out that this
is a global data for which the longitudes should be wrapped:
DEBUG 4: Projection: Lat/Lon
DEBUG 4: Nx: 720
DEBUG 4: Ny: 361
DEBUG 4: lat_ll: -90.000
DEBUG 4: lon_ll: -0.000
DEBUG 4: delta_lat: 0.500
DEBUG 4: delta_lon: 0.500
DEBUG 4: wrapLon: true
Plot the output file and see no line down the middle:
met-10.1.0/bin/plot_data_plane TMP_P500_regrid_met_10.1.0.nc TMP_P500_regrid_met_10.1.0.ps \
'name="TMP_P500"; level="(*,*)";'
[image: Screen Shot 2022-04-18 at 2 10 49 PM]
<https://user-images.githubusercontent.com/21087144/163870390-809d4e7d-1b37-4040-8a89-86ab498fcf7a.png>
But if you rerun the same commands using MET version 10.0.0, you DO get a
line of missing data down the middle!!!
[image: Screen Shot 2022-04-18 at 2 13 09 PM]
<https://user-images.githubusercontent.com/21087144/163870687-a629d9f3-297e-43a6-999b-5f93cfb5acd2.png>
You can find the following about this in the MET-10.1.0 Release Notes
<https://met.readthedocs.io/en/latest/Users_Guide/overview.html#met-release-notes>
...
Enhance MET to use point observations falling between the first and last
columns of a global grid (#1823
<dtcenter/MET#1823>).
Hope that helps explain it.
—
Reply to this email directly, view it on GitHub
<#1570 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AL3DNGQ66Q5TNKP27JD5EWTVFW7PLANCNFSM5TOP3OYQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
*Christopher J. Melick, PhD*
|
Beta Was this translation helpful? Give feedback.
@cjmelick I'll try to clarify the existing logic to help us decide what, if anything, should be done about it.
First, the regridding logic mostly resides in the vx_regrid library. The met_regrid_generic() function handles many of the regridding types. The from_grid and to_grid variables store the definition of the source and destination grids. And the high-level logic is this:
You men…