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.
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