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

20051024: 20051021: Gempak problem.



Mark,

Are you using the $MODEL/ data directory structure,
eg $MODEL/eta, $MODEL/gfs, $MODEL/ruc, etc that is
the default for the decoders I provide?

If everything is standard as I provide, then I can provide you
with a new 5.8.4 binary of Grap which you might want to try.
If the problem is directory structure, the same problems would persist.

Steve Chiswell
Unidata User Support


>From: Mark Tucker <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200510241514.j9OFEZ7s023758

>This is a multi-part message in MIME format.
>--------------030302090402040102050708
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>
>
>I was using the GFS grids as an example.  We get the same results (or 
>lack thereof) with the ETA, MRF, RUC, ECMWF, and UK Met grids.
>
>Unidata Support wrote:
>> Mark,
>> 
>> You might want to check the Garp_defaults entry for the thinned grid gfs
>> model key, the associated fdf, and the $GEMTBL/config/datatype.tbl template 
> entry.
>> 
>> One problem with Garp's use of modelkeys is that matches any substring-
>> which can cause confusion. This is better accomplished through the 
>> datatype.tbl templates.
>> 
>> In $GARPHOME/config/datatype.tbl, check the model key that is being used
>> for the first data set "thinned grids". I'd suggest changing this to
>> gfsthin to avoid conflicts with any other data sets that have "gfs" in them.
>> 
>> In $GARPHOME/fdf/scalar and $GARPHOME/fdf/vector, link or move the
>> "thin" directories to "gfsthin".
>> 
>> In $GEMTBL/config/datatype.tbl, set up a datatype GFSTHIN that
>> locates your thinned grids.
>> 
>> Let me know if this helps.
>> 
>> Steve Chiswell
>> Unidata User Support 
>> 
>> 
>>>From: Mark Tucker <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200510211951.j9LJpY7s000588
>> 
>> 
>>>This is a multi-part message in MIME format.
>>>--------------050309080909080600020107
>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>Content-Transfer-Encoding: 7bit
>>>
>>>We're having a problem with displaying certain model data within garp. 
>>>The same data sets can be properly viewd with nmap2 and using the 
>>>commandline tools.
>>>
>>>For example, if I open garp's model cross section dialog I can choose an 
>>>model (gfs thinned), select the levels (1000 -> 250) select the model 
>>>date/time and a parameter (Temp_C).  Garp then appears to load up the 
>>>data but nothing is displayed other than the information line at the 
>>>bottom of the display.  Looking at the network activity I do not believe 
>>>that the data is actually being read.  In the terminal where ntl was 
>>>started there is the following output:
>>>
>>>   Invoke ... /software/gempak/GEMPAK5.8.3a/bin/linux/garp
>>>   G A R P - v2.1 starting...
>>>   GEMPAK: [GDCROSS -12]  No levels--check input for GDATTIM and GVCORD.
>>>
>>>Again, we can read the same data properly with the commandline tools. 
>>>This is the same with other models and other tools, such as the "Model 
>>>Plan Projection", "Model Time Height" and "Model Vertical Profile". 
>>>Other functions in Garp appear to be working normally.
>>>
>>>We are running version 5.8.3a compiled on Slackware Linux (10.0, kernel 
>>>2.6.7).  I did a clean build and am using a Gemenviron file from the new 
>>>version so there are not any files or references left over from the 
>>>previous installation.
>>>
>>>I tried installing the binary distribution but it would not run because 
>>>it needs glibc 2.3.4.  Our Linux installation, which is only a little 
>>>more than a year old, has glibc 2.3.2 which is only a little more than a 
>>>year old.
>>>
>>>
>>>-- 
>>>Mark Tucker
>>>Meteorology Dept. Systems Administrator
>>>Lyndon State College
>>>http://apollo.lsc.vsc.edu
>>>address@hidden
>>>(802)-626-6328
>>>
>>>--------------050309080909080600020107
>>>Content-Type: text/x-vcard; charset=utf-8;
>>>name="mark.tucker.vcf"
>>>Content-Transfer-Encoding: 7bit
>>>Content-Disposition: attachment;
>>>filename="mark.tucker.vcf"
>>>
>>>begin:vcard
>>>fn:Mark Tucker
>>>n:Tucker;Mark
>>>org:LSC;Meteorology
>>>adr;dom:;;1001 College Rd.;Lyndonville;VT;05851
>>>email;internet:address@hidden
>>>title:Systems Administrator
>>>tel;work:802-626-6328
>>>tel;fax:802-626-9770
>>>x-mozilla-html:FALSE
>>>url:http://apollo.lsc.vsc.edu
>>>version:2.1
>>>end:vcard
>>>
>>>
>>>--------------050309080909080600020107--
>>>
>> 
>> --
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service              http://my.unidata.ucar.edu/content/support 
>> ----------------------------------------------------------------------------
>> NOTE: All email exchanges with Unidata User Support are recorded in the
>> Unidata inquiry tracking system and then made publicly available
>> through the web.  If you do not want to have your interactions made
>> available in this way, you must let us know in each email you send to us.
>
>
>-- 
>Mark Tucker
>Meteorology Dept. Systems Administrator
>Lyndon State College
>http://apollo.lsc.vsc.edu
>address@hidden
>(802)-626-6328
>
>--------------030302090402040102050708
>Content-Type: text/x-vcard; charset=utf-8;
> name="mark.tucker.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
> filename="mark.tucker.vcf"
>
>begin:vcard
>fn:Mark Tucker
>n:Tucker;Mark
>org:LSC;Meteorology
>adr;dom:;;1001 College Rd.;Lyndonville;VT;05851
>email;internet:address@hidden
>title:Systems Administrator
>tel;work:802-626-6328
>tel;fax:802-626-9770
>x-mozilla-html:FALSE
>url:http://apollo.lsc.vsc.edu
>version:2.1
>end:vcard
>
>
>--------------030302090402040102050708--
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.