[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GEMPAK #RJR-299468]: GDPVSF Status

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Subject: [GEMPAK #RJR-299468]: GDPVSF Status
Date: Wed, 13 Mar 2013 08:56:40 -0600
Hi Tim,

I'm not there yet but I think I know what to try.  I need to block off some 
time for this.

Michael


> Hi Michael,
> 
> Thanks for responding to my questions about the errors I was having with 
> GDPVSF. Have you been able to determine the cause of these issues or devise a 
> solution for them? Let me know if you have made any progress on fixing the 
> code or if you need any more data samples.
> 
> Thanks,
> Tim Lahmers
> 
> On Feb 22, 2013, at 3:52 PM, Unidata GEMPAK Support wrote:
> 
> > in gdpvlv.f, funny enough it says:
> >
> > C*      Note: the following code is not always quite correct. -JN
> >        DO WHILE ( i .lt. nlev .and.
> >     +           (istrt .eq. 0 .or. istop .eq. 0 ) )
> >          IF ( (ystrt .ge. rlvl ( i-1 ) .and. ystrt .lt. rlvl ( i ) )
> >     +                               .or.
> >     +         (ystrt .le. rlvl ( i-1 ) .and. ystrt .gt. rlvl ( i ) ) )
> >     +      istrt = i - 1
> >          IF ( (ystop .gt. rlvl ( i-1 ) .and. ystop .le. rlvl ( i ) )
> >     +                               .or.
> >     +         (ystop .lt. rlvl ( i-1 ) .and. ystop .ge. rlvl ( i ) ) )
> >     +      istop = i
> >          i = i + 1
> >        END DO
> >
> > this block is not setting istart and istop so later on the program assumes 
> > all levels are to be used.
> >
> > more later.
> >
> > Michael
> >
> >
> >>
> >> Hi Tim,
> >>
> >> Thanks for providing as much detail as you did.  I have run three tests of 
> >> different levels with GDVINT and GDPVSF on the NAM file to confirm that 
> >> the grids look different and I suspect there may be something in the code 
> >> which matches levels in the input to those specified by STARTL and STOPL.  
> >> I'll update you when I know more.
> >>
> >> Michael
> >>
> >>
> >>
> >>
> >>> Hi Michael,
> >>>
> >>> Thank you for update on the GDPVSF tool. I am having some more problems 
> >>> with the GDPVSF tool, and I think there may be a coding issue. The data 
> >>> that I am using are in pressure coordinates, so I have to use GDVINT to 
> >>> interpolate the dataset to theta coordinates. When I make this conversion 
> >>> and run GDPVSF, the output that is plotted tends to have gaps in the 
> >>> dataset. The amount of data that comes through seems to be dependent upon 
> >>> the range of theta values that I interpolate the pressure data to. I have 
> >>> tried to do this with both archived operational NAM data and NARR data 
> >>> that I converted from GRIB files. In this particular example, I 
> >>> downloaded the file 2011081500_nam212.gem from the following link. 
> >>> http://mtarchive.geol.iastate.edu/2011/08/15/gempak/model/ The file was 
> >>> re-saved with the .grd extension. The settings that I am using for GDVINT 
> >>> are as follows:
> >>>
> >>> GDFILE = 2011081500_nam212.grd
> >>> GDOUTF = dtnam_test.grd
> >>> GDATTIM = f00
> >>> GLEVEL = 280-380-5
> >>> GVCORD = pres/thta
> >>> MAXGRD = 4000
> >>> GAREA = 15;-130;50;-70
> >>> VCOORD  = pres
> >>>
> >>> Upon interpolating the pressure coordinate data to theta coordinates, I 
> >>> then run GDPVSF with the following settings:
> >>>
> >>> GDFILE   =  dtnam_test.grd
> >>> GDOUTF   =  dtnam_test.grd
> >>> GFUNC    =  abs(pvor(pres,wnd))
> >>> GDATTIM  =  f00
> >>> GVCORD   =  thta
> >>> STARTL   =  380
> >>> STOPL    =  280
> >>> DESIRE   =  0.00000015
> >>> GDOUTL   =  15
> >>> GVOUTC   =  pvab
> >>> GPACK    =
> >>> GLIST    =  thta;pres
> >>> PMAX     =  800
> >>>
> >>> This process produced a DT surface with holes at higher values of theta 
> >>> (see attached file). I also tried to rerun all of these tools with an 
> >>> increased range of potential temperature (280-420k). The end result 
> >>> yields a DT surface with  most of the values over the CONUS missing. Do 
> >>> you know what is causing this inconsistent output with these dynamic 
> >>> tropopause surfaces?
> >>>
> >>> Thanks,
> >>> Tim Lahmers
> >>>
> >>>
> >>>
> >>>
> >>> On Feb 5, 2013, at 9:55 AM, Unidata GEMPAK Support wrote:
> >>>
> >>>> Hi Tim,
> >>>>
> >>>> I've added the fix for GDPVSf in GEMPAK 6.8.0 which can be downloaded at 
> >>>> http://www.unidata.ucar.edu/downloads/gempak/ or from github at 
> >>>> https://github.com/Unidata/gempak/tree/master/gempak/source/programs/gd/gdpvsf
> >>>>
> >>>> if you don't want to reinstall 6.8.0, you can download the contents of 
> >>>> that gdpvsf direvctory and in $GEMPAK/source/programs/gd/gdpvsf/ run "rm 
> >>>> $OS_LIB/gdpvsf.a; make everything"
> >>>>
> >>>> -Michael
> >>>>
> >>>>> Quick update.
> >>>>>
> >>>>> I've got the program working on the hrcbob data set once again.  Yet to 
> >>>>> test it on the nam and your other GD input, but if that seems okay I'll 
> >>>>> send you the update tomorrow.
> >>>>>
> >>>>> Michael
> >>>>>
> >>>>>
> >>>>>> Hi Tim,
> >>>>>>
> >>>>>> GDPVSF is a mess right now, yes.  I'm trying to fix it this morning 
> >>>>>> and seeing some problems with how the grid files are opened and read, 
> >>>>>> likely due to not keeping up with changes in the grid diagnostic 
> >>>>>> library.  I'll let you know what I find.
> >>>>>>
> >>>>>> Michael James
> >>>>>> Unidata
> >>>>>>
> >>>>>>
> >>>>>>> Hi GEMPAK Support,
> >>>>>>>
> >>>>>>> I am currently working on a project that requires me to use the GDPVSF
> >>>>>>> function in GEMPAK 6.7.0  to compute Dynamic Tropopause surfaces. 
> >>>>>>> When I
> >>>>>>> run GDPVSF, there is no output file created; however, the program does
> >>>>>>> not list any errors. I read from the below link from your support site
> >>>>>>> that GDPVSF has not been working properly due to changes from past
> >>>>>>> updates.
> >>>>>>>
> >>>>>>> http://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg06131.html
> >>>>>>>
> >>>>>>> Do you know if the problems I am having are related to the same issues
> >>>>>>> described above with GDPVSF? What is the status of the GDPVSF 
> >>>>>>> function,
> >>>>>>> and do you know when a working version of it will be available? The
> >>>>>>> input parameters that I am using are listed at the bottom of this
> >>>>>>> message. These parameters originally came from a tutorial concerning 
> >>>>>>> the
> >>>>>>> function that I found from a university website (listed below); 
> >>>>>>> however,
> >>>>>>> I used a different input file.
> >>>>>>>
> >>>>>>> http://www.atmos.albany.edu/ftp/gempak/gdpvsf.readme
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Tim Lahmers
> >>>>>>>
> >>>>>>> GDFILE   =  2012081700_nam212.gem
> >>>>>>> GDOUTF   =  DT_test1.grd
> >>>>>>> GFUNC    =  mul(avor(obs),stap)
> >>>>>>> GDATTIM  =  last
> >>>>>>> GVCORD   =  thta
> >>>>>>> STARTL   =  260
> >>>>>>> STOPL    =  350
> >>>>>>> DESIRE   =  0.00000015
> >>>>>>> GDOUTL   =  15
> >>>>>>> GVOUTC   =  pvbl
> >>>>>>> GPACK    =
> >>>>>>> GLIST    =  uwnd;vwnd;pres
> >>>>>>> PMAX     =  700
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> Ticket Details
> >>>> ===================
> >>>> Ticket ID: RJR-299468
> >>>> Department: Support GEMPAK
> >>>> Priority: Normal
> >>>> Status: Open
> >>>>
> >>>
> >>>
> >>>
> >>> Hi Michael,
> >>>
> >>> Thank you for update on the GDPVSF tool. I am having some more problems 
> >>> with the GDPVSF tool, and I think there may be a coding issue. The data 
> >>> that I am using are in pressure coordinates, so I have to use GDVINT to 
> >>> interpolate the dataset to theta coordinates. When I make this conversion 
> >>> and run GDPVSF, the output that is plotted tends to have gaps in the 
> >>> dataset. The amount of data that comes through seems to be dependent upon 
> >>> the range of theta values that I interpolate the pressure data to. I have 
> >>> tried to do this with both archived operational NAM data and NARR data 
> >>> that I converted from GRIB files. In this particular example, I 
> >>> downloaded the file 2011081500_nam212.gem from the following link. 
> >>> http://mtarchive.geol.iastate.edu/2011/08/15/gempak/model/ The file was 
> >>> re-saved with the .grd extension. The settings that I am using for GDVINT 
> >>> are as follows:
> >>>
> >>> GDFILE = 2011081500_nam212.grd
> >>> GDOUTF = dtnam_test.grd
> >>> GDATTIM = f00
> >>> GLEVEL = 280-380-5
> >>> GVCORD = pres/thta
> >>> MAXGRD = 4000
> >>> GAREA = 15;-130;50;-70
> >>> VCOORD  = pres
> >>>
> >>> Upon interpolating the pressure coordinate data to theta coordinates, I 
> >>> then run GDPVSF with the following settings:
> >>>
> >>> GDFILE   =  dtnam_test.grd
> >>> GDOUTF   =  dtnam_test.grd
> >>> GFUNC    =  abs(pvor(pres,wnd))
> >>> GDATTIM  =  f00
> >>> GVCORD   =  thta
> >>> STARTL   =  380
> >>> STOPL    =  280
> >>> DESIRE   =  0.00000015
> >>> GDOUTL   =  15
> >>> GVOUTC   =  pvab
> >>> GPACK    =
> >>> GLIST    =  thta;pres
> >>> PMAX     =  800
> >>>
> >>> This process produced a DT surface with holes at higher values of theta 
> >>> (see attached file). I also tried to rerun all of these tools with an 
> >>> increased range of potential temperature (280-420k). The end result 
> >>> yields a DT surface with  most of the values over the CONUS missing. Do 
> >>> you know what is causing this inconsistent output with these dynamic 
> >>> tropopause surfaces?
> >>>
> >>> Thanks,
> >>> Tim Lahmers
> >>>
> >>>
> >>>
> >>>
> >>> On Feb 5, 2013, at 9:55 AM, Unidata GEMPAK Support wrote:
> >>>
> >>>> Hi Tim,
> >>>>
> >>>> I've added the fix for GDPVSf in GEMPAK 6.8.0 which can be downloaded at 
> >>>> http://www.unidata.ucar.edu/downloads/gempak/ or from github at 
> >>>> https://github.com/Unidata/gempak/tree/master/gempak/source/programs/gd/gdpvsf
> >>>>
> >>>> if you don't want to reinstall 6.8.0, you can download the contents of 
> >>>> that gdpvsf direvctory and in $GEMPAK/source/programs/gd/gdpvsf/ run "rm 
> >>>> $OS_LIB/gdpvsf.a; make everything"
> >>>>
> >>>> -Michael
> >>>>
> >>>>> Quick update.
> >>>>>
> >>>>> I've got the program working on the hrcbob data set once again.  Yet to 
> >>>>> test it on the nam and your other GD input, but if that seems okay I'll 
> >>>>> send you the update tomorrow.
> >>>>>
> >>>>> Michael
> >>>>>
> >>>>>
> >>>>>> Hi Tim,
> >>>>>>
> >>>>>> GDPVSF is a mess right now, yes.  I'm trying to fix it this morning 
> >>>>>> and seeing some problems with how the grid files are opened and read, 
> >>>>>> likely due to not keeping up with changes in the grid diagnostic 
> >>>>>> library.  I'll let you know what I find.
> >>>>>>
> >>>>>> Michael James
> >>>>>> Unidata
> >>>>>>
> >>>>>>
> >>>>>>> Hi GEMPAK Support,
> >>>>>>>
> >>>>>>> I am currently working on a project that requires me to use the GDPVSF
> >>>>>>> function in GEMPAK 6.7.0  to compute Dynamic Tropopause surfaces. 
> >>>>>>> When I
> >>>>>>> run GDPVSF, there is no output file created; however, the program does
> >>>>>>> not list any errors. I read from the below link from your support site
> >>>>>>> that GDPVSF has not been working properly due to changes from past
> >>>>>>> updates.
> >>>>>>>
> >>>>>>> http://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg06131.html
> >>>>>>>
> >>>>>>> Do you know if the problems I am having are related to the same issues
> >>>>>>> described above with GDPVSF? What is the status of the GDPVSF 
> >>>>>>> function,
> >>>>>>> and do you know when a working version of it will be available? The
> >>>>>>> input parameters that I am using are listed at the bottom of this
> >>>>>>> message. These parameters originally came from a tutorial concerning 
> >>>>>>> the
> >>>>>>> function that I found from a university website (listed below); 
> >>>>>>> however,
> >>>>>>> I used a different input file.
> >>>>>>>
> >>>>>>> http://www.atmos.albany.edu/ftp/gempak/gdpvsf.readme
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Tim Lahmers
> >>>>>>>
> >>>>>>> GDFILE   =  2012081700_nam212.gem
> >>>>>>> GDOUTF   =  DT_test1.grd
> >>>>>>> GFUNC    =  mul(avor(obs),stap)
> >>>>>>> GDATTIM  =  last
> >>>>>>> GVCORD   =  thta
> >>>>>>> STARTL   =  260
> >>>>>>> STOPL    =  350
> >>>>>>> DESIRE   =  0.00000015
> >>>>>>> GDOUTL   =  15
> >>>>>>> GVOUTC   =  pvbl
> >>>>>>> GPACK    =
> >>>>>>> GLIST    =  uwnd;vwnd;pres
> >>>>>>> PMAX     =  700
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> Ticket Details
> >>>> ===================
> >>>> Ticket ID: RJR-299468
> >>>> Department: Support GEMPAK
> >>>> Priority: Normal
> >>>> Status: Open
> >>>>
> >>>
> >>>
> >>>
> >>> Hi Michael,
> >>>
> >>> Thank you for update on the GDPVSF tool. I am having some more problems 
> >>> with the GDPVSF tool, and I think there may be a coding issue. The data 
> >>> that I am using are in pressure coordinates, so I have to use GDVINT to 
> >>> interpolate the dataset to theta coordinates. When I make this conversion 
> >>> and run GDPVSF, the output that is plotted tends to have gaps in the 
> >>> dataset. The amount of data that comes through seems to be dependent upon 
> >>> the range of theta values that I interpolate the pressure data to. I have 
> >>> tried to do this with both archived operational NAM data and NARR data 
> >>> that I converted from GRIB files. In this particular example, I 
> >>> downloaded the file 2011081500_nam212.gem from the following link. 
> >>> http://mtarchive.geol.iastate.edu/2011/08/15/gempak/model/ The file was 
> >>> re-saved with the .grd extension. The settings that I am using for GDVINT 
> >>> are as follows:
> >>>
> >>> GDFILE = 2011081500_nam212.grd
> >>> GDOUTF = dtnam_test.grd
> >>> GDATTIM = f00
> >>> GLEVEL = 280-380-5
> >>> GVCORD = pres/thta
> >>> MAXGRD = 4000
> >>> GAREA = 15;-130;50;-70
> >>> VCOORD  = pres
> >>>
> >>> Upon interpolating the pressure coordinate data to theta coordinates, I 
> >>> then run GDPVSF with the following settings:
> >>>
> >>> GDFILE   =  dtnam_test.grd
> >>> GDOUTF   =  dtnam_test.grd
> >>> GFUNC    =  abs(pvor(pres,wnd))
> >>> GDATTIM  =  f00
> >>> GVCORD   =  thta
> >>> STARTL   =  380
> >>> STOPL    =  280
> >>> DESIRE   =  0.00000015
> >>> GDOUTL   =  15
> >>> GVOUTC   =  pvab
> >>> GPACK    =
> >>> GLIST    =  thta;pres
> >>> PMAX     =  800
> >>>
> >>> This process produced a DT surface with holes at higher values of theta 
> >>> (see attached file). I also tried to rerun all of these tools with an 
> >>> increased range of potential temperature (280-420k). The end result 
> >>> yields a DT surface with  most of the values over the CONUS missing. Do 
> >>> you know what is causing this inconsistent output with these dynamic 
> >>> tropopause surfaces?
> >>>
> >>> Thanks,
> >>> Tim Lahmers
> >>>
> >>>
> >>>
> >>>
> >>> On Feb 5, 2013, at 9:55 AM, Unidata GEMPAK Support wrote:
> >>>
> >>>> Hi Tim,
> >>>>
> >>>> I've added the fix for GDPVSf in GEMPAK 6.8.0 which can be downloaded at 
> >>>> http://www.unidata.ucar.edu/downloads/gempak/ or from github at 
> >>>> https://github.com/Unidata/gempak/tree/master/gempak/source/programs/gd/gdpvsf
> >>>>
> >>>> if you don't want to reinstall 6.8.0, you can download the contents of 
> >>>> that gdpvsf direvctory and in $GEMPAK/source/programs/gd/gdpvsf/ run "rm 
> >>>> $OS_LIB/gdpvsf.a; make everything"
> >>>>
> >>>> -Michael
> >>>>
> >>>>> Quick update.
> >>>>>
> >>>>> I've got the program working on the hrcbob data set once again.  Yet to 
> >>>>> test it on the nam and your other GD input, but if that seems okay I'll 
> >>>>> send you the update tomorrow.
> >>>>>
> >>>>> Michael
> >>>>>
> >>>>>
> >>>>>> Hi Tim,
> >>>>>>
> >>>>>> GDPVSF is a mess right now, yes.  I'm trying to fix it this morning 
> >>>>>> and seeing some problems with how the grid files are opened and read, 
> >>>>>> likely due to not keeping up with changes in the grid diagnostic 
> >>>>>> library.  I'll let you know what I find.
> >>>>>>
> >>>>>> Michael James
> >>>>>> Unidata
> >>>>>>
> >>>>>>
> >>>>>>> Hi GEMPAK Support,
> >>>>>>>
> >>>>>>> I am currently working on a project that requires me to use the GDPVSF
> >>>>>>> function in GEMPAK 6.7.0  to compute Dynamic Tropopause surfaces. 
> >>>>>>> When I
> >>>>>>> run GDPVSF, there is no output file created; however, the program does
> >>>>>>> not list any errors. I read from the below link from your support site
> >>>>>>> that GDPVSF has not been working properly due to changes from past
> >>>>>>> updates.
> >>>>>>>
> >>>>>>> http://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg06131.html
> >>>>>>>
> >>>>>>> Do you know if the problems I am having are related to the same issues
> >>>>>>> described above with GDPVSF? What is the status of the GDPVSF 
> >>>>>>> function,
> >>>>>>> and do you know when a working version of it will be available? The
> >>>>>>> input parameters that I am using are listed at the bottom of this
> >>>>>>> message. These parameters originally came from a tutorial concerning 
> >>>>>>> the
> >>>>>>> function that I found from a university website (listed below); 
> >>>>>>> however,
> >>>>>>> I used a different input file.
> >>>>>>>
> >>>>>>> http://www.atmos.albany.edu/ftp/gempak/gdpvsf.readme
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Tim Lahmers
> >>>>>>>
> >>>>>>> GDFILE   =  2012081700_nam212.gem
> >>>>>>> GDOUTF   =  DT_test1.grd
> >>>>>>> GFUNC    =  mul(avor(obs),stap)
> >>>>>>> GDATTIM  =  last
> >>>>>>> GVCORD   =  thta
> >>>>>>> STARTL   =  260
> >>>>>>> STOPL    =  350
> >>>>>>> DESIRE   =  0.00000015
> >>>>>>> GDOUTL   =  15
> >>>>>>> GVOUTC   =  pvbl
> >>>>>>> GPACK    =
> >>>>>>> GLIST    =  uwnd;vwnd;pres
> >>>>>>> PMAX     =  700
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> Ticket Details
> >>>> ===================
> >>>> Ticket ID: RJR-299468
> >>>> Department: Support GEMPAK
> >>>> Priority: Normal
> >>>> Status: Open
> >>>>
> >>>
> >>>
> >>>
> >>> Hi Michael,
> >>>
> >>> Thank you for update on the GDPVSF tool. I am having some more problems 
> >>> with the GDPVSF tool, and I think there may be a coding issue. The data 
> >>> that I am using are in pressure coordinates, so I have to use GDVINT to 
> >>> interpolate the dataset to theta coordinates. When I make this conversion 
> >>> and run GDPVSF, the output that is plotted tends to have gaps in the 
> >>> dataset. The amount of data that comes through seems to be dependent upon 
> >>> the range of theta values that I interpolate the pressure data to. I have 
> >>> tried to do this with both archived operational NAM data and NARR data 
> >>> that I converted from GRIB files. In this particular example, I 
> >>> downloaded the file 2011081500_nam212.gem from the following link. 
> >>> http://mtarchive.geol.iastate.edu/2011/08/15/gempak/model/ The file was 
> >>> re-saved with the .grd extension. The settings that I am using for GDVINT 
> >>> are as follows:
> >>>
> >>> GDFILE = 2011081500_nam212.grd
> >>> GDOUTF = dtnam_test.grd
> >>> GDATTIM = f00
> >>> GLEVEL = 280-380-5
> >>> GVCORD = pres/thta
> >>> MAXGRD = 4000
> >>> GAREA = 15;-130;50;-70
> >>> VCOORD  = pres
> >>>
> >>> Upon interpolating the pressure coordinate data to theta coordinates, I 
> >>> then run GDPVSF with the following settings:
> >>>
> >>> GDFILE   =  dtnam_test.grd
> >>> GDOUTF   =  dtnam_test.grd
> >>> GFUNC    =  abs(pvor(pres,wnd))
> >>> GDATTIM  =  f00
> >>> GVCORD   =  thta
> >>> STARTL   =  380
> >>> STOPL    =  280
> >>> DESIRE   =  0.00000015
> >>> GDOUTL   =  15
> >>> GVOUTC   =  pvab
> >>> GPACK    =
> >>> GLIST    =  thta;pres
> >>> PMAX     =  800
> >>>
> >>> This process produced a DT surface with holes at higher values of theta 
> >>> (see attached file). I also tried to rerun all of these tools with an 
> >>> increased range of potential temperature (280-420k). The end result 
> >>> yields a DT surface with  most of the values over the CONUS missing. Do 
> >>> you know what is causing this inconsistent output with these dynamic 
> >>> tropopause surfaces?
> >>>
> >>> Thanks,
> >>> Tim Lahmers
> >>>
> >>>
> >>>
> >>>
> >>> On Feb 5, 2013, at 9:55 AM, Unidata GEMPAK Support wrote:
> >>>
> >>>> Hi Tim,
> >>>>
> >>>> I've added the fix for GDPVSf in GEMPAK 6.8.0 which can be downloaded at 
> >>>> http://www.unidata.ucar.edu/downloads/gempak/ or from github at 
> >>>> https://github.com/Unidata/gempak/tree/master/gempak/source/programs/gd/gdpvsf
> >>>>
> >>>> if you don't want to reinstall 6.8.0, you can download the contents of 
> >>>> that gdpvsf direvctory and in $GEMPAK/source/programs/gd/gdpvsf/ run "rm 
> >>>> $OS_LIB/gdpvsf.a; make everything"
> >>>>
> >>>> -Michael
> >>>>
> >>>>> Quick update.
> >>>>>
> >>>>> I've got the program working on the hrcbob data set once again.  Yet to 
> >>>>> test it on the nam and your other GD input, but if that seems okay I'll 
> >>>>> send you the update tomorrow.
> >>>>>
> >>>>> Michael
> >>>>>
> >>>>>
> >>>>>> Hi Tim,
> >>>>>>
> >>>>>> GDPVSF is a mess right now, yes.  I'm trying to fix it this morning 
> >>>>>> and seeing some problems with how the grid files are opened and read, 
> >>>>>> likely due to not keeping up with changes in the grid diagnostic 
> >>>>>> library.  I'll let you know what I find.
> >>>>>>
> >>>>>> Michael James
> >>>>>> Unidata
> >>>>>>
> >>>>>>
> >>>>>>> Hi GEMPAK Support,
> >>>>>>>
> >>>>>>> I am currently working on a project that requires me to use the GDPVSF
> >>>>>>> function in GEMPAK 6.7.0  to compute Dynamic Tropopause surfaces. 
> >>>>>>> When I
> >>>>>>> run GDPVSF, there is no output file created; however, the program does
> >>>>>>> not list any errors. I read from the below link from your support site
> >>>>>>> that GDPVSF has not been working properly due to changes from past
> >>>>>>> updates.
> >>>>>>>
> >>>>>>> http://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg06131.html
> >>>>>>>
> >>>>>>> Do you know if the problems I am having are related to the same issues
> >>>>>>> described above with GDPVSF? What is the status of the GDPVSF 
> >>>>>>> function,
> >>>>>>> and do you know when a working version of it will be available? The
> >>>>>>> input parameters that I am using are listed at the bottom of this
> >>>>>>> message. These parameters originally came from a tutorial concerning 
> >>>>>>> the
> >>>>>>> function that I found from a university website (listed below); 
> >>>>>>> however,
> >>>>>>> I used a different input file.
> >>>>>>>
> >>>>>>> http://www.atmos.albany.edu/ftp/gempak/gdpvsf.readme
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Tim Lahmers
> >>>>>>>
> >>>>>>> GDFILE   =  2012081700_nam212.gem
> >>>>>>> GDOUTF   =  DT_test1.grd
> >>>>>>> GFUNC    =  mul(avor(obs),stap)
> >>>>>>> GDATTIM  =  last
> >>>>>>> GVCORD   =  thta
> >>>>>>> STARTL   =  260
> >>>>>>> STOPL    =  350
> >>>>>>> DESIRE   =  0.00000015
> >>>>>>> GDOUTL   =  15
> >>>>>>> GVOUTC   =  pvbl
> >>>>>>> GPACK    =
> >>>>>>> GLIST    =  uwnd;vwnd;pres
> >>>>>>> PMAX     =  700
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> Ticket Details
> >>>> ===================
> >>>> Ticket ID: RJR-299468
> >>>> Department: Support GEMPAK
> >>>> Priority: Normal
> >>>> Status: Open
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: RJR-299468
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Open
> >
> 
> 


Ticket Details
===================
Ticket ID: RJR-299468
Department: Support GEMPAK
Priority: Normal
Status: Open
Prev by Date: [GEMPAK #KCH-144722]: NAVGEM tables?
Next by Date: [GEMPAK #RJR-299468]: GDPVSF Status
Previous by thread: [GEMPAK #RJR-299468]: GDPVSF Status
Next by thread: [GEMPAK #RJR-299468]: GDPVSF Status
Index(es):
- Date
- Thread