opengrads-devel

[Opengrads-devel] Regrid-like frontend for re()

[Arlindo da S. <da...@al...>]

Mike,

  You may be the best person to help me out with this. My goal is to
have a wrapper function call regrid() which behaves much like Mike's
classic regrid2() UDF. The starting point if the re() manual page:

             http://opengrads.org/doc/udxt/re/

Could you help me compile the difference in syntax between re() and
regrid2(). Here is what I am aware of:

1) Shorthand syntax.

d regrid2(expr,dlon)
d regrid2(expr,dlon,dlat)
d regrid2(expr,dlon,dlat,['ig',nyig],['ba'|'bl'|'bs'|'vt',vtmax,vtmin|'ma',min])

These have equivalent syntax in re(), but the behavior is not the
same: if the input grid is global and contains the pole, the output
grid in re() does not include the poles (pole is now a gridbox edge),
while in regrid2() the pole is the center of the gridbox (as in many
of the standard lat/lon reanalysis grids these days).

B.-J.: Is there a good reason why you chose to shift the global grids
off the poles? Would it make sense to have re() nehave like regrid2()
in this regard? (Same for the longitudinal grid).

Keeping re() as it is, the regrid() wrapper would use the long-hand
syntax to get the same rerid2() behavior:

d regrid(expr,dlon) --> d
re(expr,nlon,'linear',lon0,dlon,nlat,'linear',lat0,dlat,'ba')

where

lon0 = first longitude on the globe: prime-meridian
nlon = 1 + (lonN - lon0)/dlon,  lonN = last longitude of input grid

dlat = dlon
nlat = 1 + (latN - lat0)/dlat, lat0=90S, latN=90N

Note: regrid2() appears to always use 'ba' as the interpolation
method, while re() uses either 'ba' or 'bl' depending on whether you
are from lower to higher resolution, or vice-versa.

Mike: could you confirm that this is indeed the behavior.

2) Long-hand

I personally find the ctl-like syntax of re() much more intuitive than
the original regrid2() general syntax:

regrid(G1,X1,X2,C1,X3,X4,X5,X6)

G1 = a GrADS grid expression (e.g., z or ave(z.3(t+0,t=120,1yr))
X? = a float parameter
C1 = character string parameter

REQUIRED params:  G1, X1

where:

   G1     =  any valid GrADS grid expression
   X1     =  delta longitude (dlon) or # of gaussian longitudes on the
	        GLOBE
   X2     =  delta latitude (dlat) or # of gaussian latitudes on the GLOBE
   C1     =  character option string
   X3     =  special case options #1
   X4     =  special case options #2
   X5     =  special case options #3
   X6     =  special case options #4

The only reason for supporting the C1/X3-X6 parameters is to make it
easier for current users of regrid2() to make the transition.

Mike/B.-J.:  I'll write a simple wrapper that starts handling the
short-hand; could one of you complete the long-hand?

  Thank you,

      Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Regrid-like frontend for re()

[Ben-Jei T. <bt...@gm...>]

Dear Arlindo:

Thank you for all the efforts.

2009/3/22 Arlindo da Silva <da...@al...>

> Mike,
>
>  You may be the best person to help me out with this. My goal is to
> have a wrapper function call regrid() which behaves much like Mike's
> classic regrid2() UDF. The starting point if the re() manual page:
>
>             http://opengrads.org/doc/udxt/re/
>
> Could you help me compile the difference in syntax between re() and
> regrid2(). Here is what I am aware of:
>
> 1) Shorthand syntax.
>
> d regrid2(expr,dlon)
> d regrid2(expr,dlon,dlat)
> d
> regrid2(expr,dlon,dlat,['ig',nyig],['ba'|'bl'|'bs'|'vt',vtmax,vtmin|'ma',min])
>
> These have equivalent syntax in re(), but the behavior is not the
> same: if the input grid is global and contains the pole, the output
> grid in re() does not include the poles (pole is now a gridbox edge),
> while in regrid2() the pole is the center of the gridbox (as in many
> of the standard lat/lon reanalysis grids these days).
>
> B.-J.: Is there a good reason why you chose to shift the global grids
> off the poles? Would it make sense to have re() nehave like regrid2()
> in this regard? (Same for the longitudinal grid).
>

I use ECHAM model frequenctly. The edges of the model output are at the
poles. This is part of the reason that I shift the global grids off the
poles. But of couse, the community can decide to change it since It always
be possible to assign the desired output using the ctl-like syntax. In fact,
I think that the community should not provide many regridding functions. It
will cause confusion for users.



>
> Keeping re() as it is, the regrid() wrapper would use the long-hand
> syntax to get the same rerid2() behavior:
>
> d regrid(expr,dlon) --> d
> re(expr,nlon,'linear',lon0,dlon,nlat,'linear',lat0,dlat,'ba')
>
> where
>
> lon0 = first longitude on the globe: prime-meridian
> nlon = 1 + (lonN - lon0)/dlon,  lonN = last longitude of input grid
>

I suggest lon0 should be centered at 0 degree E.


>
> dlat = dlon
> nlat = 1 + (latN - lat0)/dlat, lat0=90S, latN=90N
>
> Note: regrid2() appears to always use 'ba' as the interpolation
> method, while re() uses either 'ba' or 'bl' depending on whether you
> are from lower to higher resolution, or vice-versa.
>

Yes. I remember that re() uses such algorithms.

>
> Mike: could you confirm that this is indeed the behavior.
>
> 2) Long-hand
>
> I personally find the ctl-like syntax of re() much more intuitive than
> the original regrid2() general syntax:
>
> regrid(G1,X1,X2,C1,X3,X4,X5,X6)
>
> G1 = a GrADS grid expression (e.g., z or ave(z.3(t+0,t=120,1yr))
> X? = a float parameter
> C1 = character string parameter
>
> REQUIRED params:  G1, X1
>
> where:
>
>   G1     =  any valid GrADS grid expression
>   X1     =  delta longitude (dlon) or # of gaussian longitudes on the
>                GLOBE
>   X2     =  delta latitude (dlat) or # of gaussian latitudes on the GLOBE
>   C1     =  character option string
>   X3     =  special case options #1
>   X4     =  special case options #2
>   X5     =  special case options #3
>   X6     =  special case options #4
>
> The only reason for supporting the C1/X3-X6 parameters is to make it
> easier for current users of regrid2() to make the transition.
>
> Mike/B.-J.:  I'll write a simple wrapper that starts handling the
> short-hand; could one of you complete the long-hand?
>
>  Thank you,
>
>      Arlindo
>
> --
> Arlindo da Silva
> da...@al...
>



-- 
Ben-Jei Tsuang
Dept. of Environmental Engineering
National Chung-Hsing University