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

20051213: 20051206: gempak segmentation faults



>From: Frank Colby <address@hidden>
>Organization: UMass Lowell
>Keywords: 200512131702.jBDH2P7s010915

>This is a multi-part message in MIME format.
>--------------090107000605010304030307
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Steve,
>
>Well, I went back to the dcgrib2 logs, and they had processed 133 
>records.  So I decided to start over, making sure of each step, with the 
>idea that it would either work, or would be clearly documented where it 
>didn't.  I dcgribbed on time, and this time, gdinfo found all kinds of 
>fields -- a completely different outcome.  Then gdplot2 worked fine, but 
>I still got a segmentation fault in Garp, so I knew the problem was 
>likely in Garp_defaults.  And sure enough, I hadn't done the ruc 
>configuration correctly in the modelkeys. Once that was fixed, Garp 
>worked fine. 
>
>I do have two questions, however.  First, how do I get Garp to use the 
>ruc-specific menus?  I thought by naming the file yyyymmddhh_ruc236.gem, 
>it would use the ruc236 fdf menus, but I don't see that happening.  It 
>would be convenient, since the sea-level pressure variable is mmsl 
>rather than psml or esml.

Frank,

The $GARPHOME/fdf directories use the name that matches the model_keys.
If you are using the model_key "ruc2", the datatype.tbl alias for the ruc236 
dataset,
then you will want to create a symbolic link from the ruc236 directories in the 
$GARPHOME/fdf/scalar, vector, etc directories to ruc2.

This got somewhat confising since the Garp template method required all grid 
files to
reside in one directory. If all your data were in one directory, the ruc236 
string would work...
but with larger files now, it gets difficult to manage all files in one 
directory.
By using the GEMPAK datatype.tbl alias of "ruc2", it allows the model
data to be found in a sepatate directory from other grid files...but as you 
point
out, I should add these symbolic links to the next release.





>
>Second, the dcgrib process produces three forecast hours, of which only 
>the first has any data.  I downloaded only the initial analyses (F000), 
>but after decoding one of these, the Garp display shows F001 and F002, 
>both of which have no data.  I suspect there is a flag for dcgrib2 that 
>I 'm not setting correctly, but I don't see it.  It's not critical, but 
>it makes choosing multiple times in Garp awkward, since you have to 
>select every third time. 

If dcgrib2 generates 3 forecast hours, then there are grids at those times.
You can use gdinfo to see what grids are being decoded at those times. Its 
possible
that the file you downloaded has an average or accumulation field...which
probably is not a grid available at pressure levels in the menu, but in one of 
the other
coordinates. The info button within Garp should work similar to gdinfo.

Steve Chiswell
Unidata User Support





>
>Thanks again for your help.
>
>Frank
>Unidata Support wrote:
>
>>Frank,
>>
>>Your dcgrib2 output shows that 0 bulletins were decoded.
>>That obviously doesn't match your gdinfo output that shows 133 
>>grids exist in your grid file, so there is a mismatch there somewhere.
>>Your previous message said that the log file showed bulletins being decoded.
>>
>>The RUC2 grid236 grib file should handled by all the normal configurations,
>>since its is a typical data set we decode in real-time.
>>
>>The expected location of the RUC data aftare its decoded will be
>>$MODEL/ruc/YYYYMMDDHH_ruc236.gem, which is the template that
>>Garp would be using. That doesn't match the file name that
>>you are using, which is one problem. Did you modify the RUC2 template
>>in $GEMTBL/config/datatype.tbl?
>>
>>The problem that Garp is having is likely a file template problem,
>>since the files are not named as expected in the datatype.tbl file.
>>
>>I tested Garp here, which is decodeing the 40km #236 grids in realtime and
>>plotting does work.
>>
>>Steve Chiswell
>>Unidata User Support
>>  
>>
>
>
>
>--------------090107000605010304030307
>Content-Type: text/x-vcard; charset=utf-8;
> name="Frank_Colby.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
> filename="Frank_Colby.vcf"
>
>begin:vcard
>fn:Frank Colby
>n:Colby;Frank
>org:University of Massachusetts Lowell;Environmental, Earth & Atmospheric Scie
> nces
>email;internet:address@hidden
>title:Professor of Meteorology
>tel;work:(978) 934-3906
>version:2.1
>end:vcard
>
>
>--------------090107000605010304030307--
>
--
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.