[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990804: gdbiint

Brett,

In your previous message:

>       I have been working with the GDBIINT program but I have a
>question. I create a file (i.e. my own file with PROJ=CED and a
>particular region of the Pacific/West Coast: 29;-161;58;-90). I am trying
>to interpolate the AVN thinned grids to this new grid.


So that was the projection I was testing. In your message below, you say 
you are using proj=lcc, GRDAREA=29;-161;58;-94, so now I tried that.

I also notice that I have ~8616 grids in today's eta104 grid which
exceeds your maxgrid=3000, so I moved that up to 9000. The eta104 grids
are every 25mb already so I haven't run gdvint first.

I tested under solaris, and obtained reasonable values, and profiled
the code for potential memory and array bounds exception but turned
up nothing there- so I would like to test using your data set. If you could
ftp me both the input eta file, and the output file you created
with gdcfil, I will convert the data over and see if I can duplicate your
values for tmpk@800.

You can ftp the files into the ~gbuddy/incoming directory using the
gempak distribution password.

Thanks,

Steve







>From: Brett Newkirk <address@hidden>
>Organization: .
>Keywords: 199908042129.PAA15787

>Hi Steve:
>       I am trying to recreate the problem from eariler. I forgot to
>mention that I first performed gdvint on the avn grids, interpolating to
>pressure levels every 50mb from 1000mb to 100mb. I did this for the ETA
>grids as well. I checked the newly vertically interpolated grids for
>TMPK@800 and the values were fine. The next step was to then interpolate
>this higher vertical resolution data to the ~90km grid using gdbiint.
>       Using GDCFIL, I had:
>PROJ=lcc
>GRDAREA=29;-161;58;-94
>KXKY=48;30
>MAXGRD=3000
>CPYFIL=
>ANLYSS=
>.
>       Then I used GDBIINT on the vertically interpolated data set and
>get the erroneous values from the data. I made sure that I was not
>getting the warning that there were poins on the output array that were
>outside of the input array. I am running the programs on Sun Solaris,
>version 5.0 I believe.
>       The floating point error came up again as well (div by 0). What I
>could do is send you the vertically interpolated version of the ETA 104
>grids that I have with reasonable values and let you work off this, if it
>would help you. 
>       I am not exceeding the maximum number of grid points in the
>calculations. If you still cannot get this error, please let me know and I
>will get this grid file over to you.
>       Thanks again for your help with this problem---
>Brett
>> 
>> So, the one piece of information I didn't have is what your kxky
>> value is for this interpolation domain...presumably you don't have
>> more than the maximum number of grid points allowed in the interpolation
>> array (should be ~97,000).
>> 
>> What OS are you running on (solaris, Dec Unix, etc.).
>> 
>> I didn't see any division by zero errors that you had previously mentioned,
>> but I was wondering if this may be specific to the OS/compiler settings used
> .
>> 
>> Any more information would help.
>> 
>> Thanks,
>> 
>> Steve
>> 
>> 
>> >From: Brett Newkirk <address@hidden>
>> >Organization: .
>> >Keywords: 199907192220.QAA02818
>> 
>> >Hi Steve:
>> >    I have been working with the GDBIINT program but I have a
>> >question. I create a file (i.e. my own file with PROJ=CED and a
>> >particular region of the Pacific/West Coast: 29;-161;58;-90). I am trying
>> >to interpolate the AVN thinned grids to this new grid. The interior points
>> >look fine, but the boundary points have RMISSD values along with some
>> >other large negative values in TMPK at 800mb values for example. Did you
>> >notice problems in the testing of this routine or is there something that
>> >I am missing in using the program? Can one use the program to go from one
>> >projection to another with varying resolutions as long as the navigation
>> >blocks are defined?
>> >    I am noticing this problem in converting the ETA grids to this
>> >grid as well. However, the NOGAPS grid (CED, global coverage) does not
>> >have this boundary problem. Any insight that you could give on this issue
>> >I would greatly appreciate.
>> >    Also, I spoke to David Ovens and he had a bicubic spline routine
>> >written (usable by GR_INTP, for example). Thanks again for your help---
>> >Brett
>> >
>> >Brett Newkirk    E-MAIL: address@hidden
>> >Office: ATG 424  Atmospheric Science/Geophysics Building
>> >Mailing Address: Department of Atmospheric Sciences, University of Washingt
> on
>> >                 Box 351640
>> >                 Seattle, WA 98195-1640
>> >Office Phone: (206) 685-2183
>> >
>> 
>> 
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>