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