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

20060106: Converting MCIDAS images to GEMPAK format for Garp



Nancy,

If you downloaded the images in uncompressed format, all you should need to do 
is rename them
according to the file template that Garp is expecting. The pnga2area program 
should not be involved
in any way since they are not part of the IDD distribution.

For the GUI programs Garp and NMAP2 to display the chooser of images, you have 
to name your 
images following the expected file template,
eg $SAT/4km/IR/IR_YYYYMMDD_HHNN.

The Garp crash you had is likely trying to compute a date from the 
YYMMDD_ir.are names since
it did not match trhe expected numerical template.

The command line programs like gpmap should be able to display the images using 
any file name
you wish, but the GUIs have to follow the expected naming convention for their 
menus.

Steve Chiswell
Unidata User SUpport


>From: Nancy Selover <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200601061910.k06JAO7s023394

>This is a multi-part message in MIME format.
>
>--Boundary_(ID_tdbOsBfAX22rj0Ekt/xLbA)
>Content-type: text/plain;      charset="us-ascii"
>Content-transfer-encoding: quoted-printable
>
>Support,
>
>I have downloaded some GOES-10 images in the uncompressed MCIDAS format
>(filenames YYMMDD_band.are  where band =3D IR, WV or VIS).  They are in =
>an
>archive directory structure that mirrors the real-time data directories,
>and I have created an archive version of Gemenviron that points to the
>archive structure.  The models, surface and upper air data all work fine
>with Garp, but when I try to view the images in Garp, I get an immediate
>crash when I get to the IR directory, with the error message:  *** glibc
>detected *** free(): invalid next size (fast): 0x0flbbc98 ***   I have a
>bunch of the ...ir.are  files in that directory, but I did convert one
>with pnga2area using the statement:
>
>/huser/ldm/decoders/pnga2area -a /huser/ldm/etc/SATANNOT -b
>/huser/ldm/etc/SATBAND -f 050726_ir.are
>/huser/arcdata/gempak/data/gempak/images/sat/GOES-10/4km/IR/IR_%Y%m%d_%H
>%M     (all on one line)
>
>The converted file shows up with a size of 2816, rather than 2439296
>like the uncompressed MCIDAS, so I suspect the decoding is not working.
>
>Is the crashing problem in the decoding, or is it just that I have the
>*.are files in that directory?  It crashed the same way before I decoded
>any files.
>
>Thanks for the help.  I normally decode MCIDAS in real-time and store
>files in the GEMPAK format, so this is new to me.
>
>Nancy
>
>Nancy J. Selover, PhD.
>Asst. State Climatologist=20
>Office of Climatology tel: 480-965-0580=20
>Arizona State University fax: 480-965-1473=20
>Tempe, AZ 85287-1508 e-mail: address@hidden=20
>
>
>
>--Boundary_(ID_tdbOsBfAX22rj0Ekt/xLbA)
>Content-type: text/html;       charset="us-ascii"
>Content-transfer-encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
><HTML>
><HEAD>
><META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
>charset=3Dus-ascii">
><META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
>6.5.7638.1">
><TITLE>Converting MCIDAS images to GEMPAK format for Garp</TITLE>
></HEAD>
><BODY>
><!-- Converted from text/rtf format -->
>
><P><FONT SIZE=3D2 FACE=3D"Arial">Support,</FONT>
></P>
>
><P><FONT SIZE=3D2 FACE=3D"Arial">I have downloaded some GOES-10 images =
>in the uncompressed MCIDAS format (filenames YYMMDD_band.are&nbsp; where =
>band =3D IR, WV or VIS).&nbsp; They are in an archive directory =
>structure that mirrors the real-time data directories, and I have =
>created an archive version of Gemenviron that points to the archive =
>structure.&nbsp; The models, surface and upper air data all work fine =
>with Garp, but when I try to view the images in Garp, I get an immediate =
>crash when I get to the IR directory, with the error message:&nbsp; *** =
>glibc detected *** free(): invalid next size (fast): 0x0flbbc98 =
>***&nbsp;&nbsp; I have a bunch of the &#8230;ir.are&nbsp; files in that =
>directory, but I did convert one with pnga2area using the =
>statement:</FONT></P>
>
><P><FONT SIZE=3D2 FACE=3D"Arial">/huser/ldm/decoders/pnga2area -a =
>/huser/ldm/etc/SATANNOT -b /huser/ldm/etc/SATBAND -f 050726_ir.are =
>/huser/arcdata/gempak/data/gempak/images/sat/GOES-10/4km/IR/IR_%Y%m%d_%H%=
>M&nbsp;&nbsp;&nbsp;&nbsp; (all on one line)</FONT></P>
>
><P><FONT SIZE=3D2 FACE=3D"Arial">The converted file shows up with a size =
>of 2816, rather than 2439296 like the uncompressed MCIDAS, so I suspect =
>the decoding is not working.</FONT></P>
>
><P><FONT SIZE=3D2 FACE=3D"Arial">Is the crashing problem in the =
>decoding, or is it just that I have the *.are files in that =
>directory?&nbsp; It crashed the same way before I decoded any =
>files.</FONT></P>
>
><P><FONT SIZE=3D2 FACE=3D"Arial">Thanks for the help.&nbsp; I normally =
>decode MCIDAS in real-time and store files in the GEMPAK format, so this =
>is new to me.</FONT>
></P>
>
><P><FONT SIZE=3D2 FACE=3D"Arial">Nancy</FONT>
></P>
>
><P><B><I><FONT SIZE=3D2 FACE=3D"Arial">Nancy J. Selover, =
>PhD.</FONT></I></B><I></I><BR>
><I></I><I></I><I><FONT SIZE=3D2 FACE=3D"Arial">Asst. State =
>Climatologist</FONT></I><FONT FACE=3D"Times New Roman"><BR>
></FONT><FONT SIZE=3D2 FACE=3D"Arial">Office of Climatology tel: =
>480-965-0580</FONT><FONT FACE=3D"Times New Roman"><BR>
></FONT><FONT SIZE=3D2 FACE=3D"Arial">Arizona State University fax: =
>480-965-1473</FONT><FONT FACE=3D"Times New Roman"><BR>
></FONT><FONT SIZE=3D2 FACE=3D"Arial">Tempe, AZ 85287-1508 e-mail: =
>address@hidden</FONT><FONT FACE=3D"Times New Roman"> </FONT>
></P>
><BR>
>
></BODY>
></HTML>=
>
>--Boundary_(ID_tdbOsBfAX22rj0Ekt/xLbA)--
>
--
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.