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

20010912: 20010831: 20010825: Goes-10 and Mosaic 8km images not working

Sean,

The problem with the images you posted is that the
scale value of the calibration is being set to "0" which
leads to the division by zero when trying to compute the
color bar labels. This is the portion of code which determines 
the units and scaled values represented by the pixels in
the image. In the image I looked at, the file was identified
as a "PROD", with pixel values from 0-255 and image values
from 0-255.  Eg, these are no longer BRIT values for temperature,
so there may be something screwed up in their creation
of the product.

The calibration reading module is something that was added to
be able to display the GOES products in the Unidata MCIDAS
data stream for PW, CAPE, SST, CTP, LI, OZONE GOES products.

Anyhow, I was able to make the imcalib.f routine handle this
case. I can send you the source code if you want to recompile
your GEMPAK distribution. If you are using a binary distribution,
let me know what programs you need recompiled and for what OS.

The work around will be in the next GEMPAK release.

Steve Chiswell
Unidata User Support







>From: Sean Daida <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200109121534.f8CFYt128894

>Hi there Steve,
>
>Yes, all of the unidata (McIDAS) images that I work with are just fine.
>
>We are getting satellite images directly via an FTP link with the NWS
>Honolulu Office (in the same building).  I checked with the SU and he is
>able to view the images on his end.  The SU also said that they make the
>mosaic's locally.
>
>You can take a look at vision(or lumahai).soest.hawaii.edu, and then
>click
>on the satellite image link.  That gives a pretty good digest of which
>images work and which don't.  If you click on the animaged gif links
>below
>the thumbnails, there sometimes will be a few frames that did indeed
>make
>it in the NWS GOES-10 8km WV.
>
>I think it would be easier for you if I left the image files on my
>personal web directory.  It can be found at:
>www.soest.hawaii.edu/~daidasea/unidata_support/
>
>The files that I put there are:
>200109111500.mi8
>200109111500.mw8  (don't work)
>200109111530.nw8
>
>200109111500.nw8  (worked every time I tried to view it with gpmap. 
>This 
>                   was in the same shell environment and general
>computer 
>                   load as the previous three images which didn't
>                   work.  At least this problem is specific to
>individual
>                   images and not random.)
>
>hokukea.env.txt   (a saved image of the working environment variables
>                   including the working path)
>
>
>Another thing I just recently tried was to make the relevant portions of
>the imgtyp.tbl identical to the settings the SU had.  This didn't change
>anything.  
>
>BTW, did you get my first email from a long time ago, in which I
>mentioned
>the unidata training?  Sorry I missed ya the morning you visited the
>mcidas or ldm class.
>
>Cheers,
>Sean Daida
>University of Hawaii
>(808)956-4593
>
>On Tue, 4 Sep 2001, Unidata Support wrote:
>
>> 
>> Sean,
>> 
>> You seem to be saying that the satellite images from the MCIDAS
>> feed do work correctly, eg: the 4km and 8km unidata images.
>> 
>> So, you are getting other images from other locations?
>> Are these the GINI images from NOAAPORT? I have no trouble
>> viewing those here.
>> 
>> Perhaps you can send me one of the images in question.
>> 
>> It is likely a problem between your PATH which gets set in Gemenviron
>> and your other environmental variables if 5.4 used to work and no longer
>> does. That probably says that the gplt or xw device are coming from a 
>> different distristribution (eg 5.6 vs 5.4). To check that out, a
>> listing of your $PATH and ENV locations would be helpful.
>> 
>> Steve Chiswell
>> 
>> 
>> 
>> >From: Sean Daida <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200109010115.f811Fv102996
>> 
>> >
>> >--------------000309000300070500030401
>> >Content-Type: text/plain; charset=us-ascii; format=flowed
>> >Content-Transfer-Encoding: 7bit
>> >
>> >Hi there Steve,
>> >
>> >Thank you for your reply.  BTW, your suggestion on how to make the 
>> >stability indicies show up on the skew-t plot worked beautifully.
>> >
>> >What information from me would be helpful in sorting out the 8km 
>> >watervapor and mosaic imagery problem in gpmap?  I tried going back to 
>> >NAWIPS-5.4.  The only thing I changed between the two setups were the 
>> >Gemenviron files and their entry in the .cshrc.  Nothing else in .cshrc 
>> >or .login were changed.  Interesting thing, you would think that 
>> >sourcing the old 5.4 gemenviron file (I had removed the 5.6 gemenviron 
>> >file before relogging in) would have worked like it did before...it 
>> >didn't.  I now get the same:
>> >*** TERMINATING gpmap
>> >*** Received signal 11 SIGSEGV
>> >Segmentation Fault (core dumped)
>> >
>> >I noticed a couple further things: 1) when either the lutsfile or binary 
>> >setting is wrong in the imgtyp.tbl file, I get an image type not found 
>> >error and then the above error.  2) when the image type seems to be 
>> >found I just get the *** TERMINATING error (as above) and no gempak 
>> >error message.  Also, The image will show up (sometimes the image is ok, 
>> >sometimes it looks really off), but no graphics are plotted on the 
>> >image.  After I type gpend, the colorbar and mapoutlines show up for a 
>> >second before the window is closed.  
>> >
>> >One check I did was to kill the cronjobs and reboot the machine.  The 
>> >only gempak related program running was gpmap.  This still crashed when 
>> >trying to process these images.  I've also tried running gempak from 
>> >other machines and sending the display through xhost and setenv.  This 
>> >didn't work either.
>> >
>> >I have checked the environment variables when using gemenviron for 5.4 
>> >and for 5.6.  I don't see any conflicts.  Should I send you the ENV, SET 
>> >printout and the Gemenviron files for both versions?  Would areaInfo -v 
>> >output, imgtyp.tbl, and the luts help too?  
>> >
>> >I've tried almost everything.  The interesting thing is that all of the 
>> >4km images do work.  And the 8km resolution images from the Unidata feed 
>> >also work.  Could the color table at the OS level still be the problem 
>> >when other images still work?
>> >
>> >Sincerely,
>> >Sean Daida
>> >address@hidden
>> >(808)956-4593
>> >
>> >Unidata Support wrote:
>> >
>> >>>From: Sean Daida <address@hidden>
>> >>>Organization: UCAR/Unidata
>> >>>Keywords: 200108260204.f7Q24M114934
>> >>>
>> >>
>> >>>Hi there,
>> >>>
>> >>>I recently installed the solaris sparc binary version of gempak
>> >>>5.6.d.1.  It's mostly working fine.  One issue I can't seem to figure
>> >>>out is when I try to run GPMAP (either from a script or from the command
>> >>>line) and select a GOES10 8km WV or a MOSAIC (GMS/GOES10) 8km WV or IR
>> >>>image, I get "Abort (core dumped)".  I tried to go back to gempak 5.4
>> >>>but for some reason (although I didn't change anything in the older
>> >>>installation) none of the satellite images work for me.  I ran gpmap on
>> >>>older images that had worked before and those didn't work either.
>> >>>
>> >>>I checked areaInfo -v and I think the imgtyp.tbl is set up right.  The
>> >>>other types of imagery are working fine (4km IR,VIS,WV, and 8km IR).
>> >>>Any ideas?  Anything you need from me to figure this out?  I have been
>> >>>working on this and the other various problems with upgrading for about
>> >>>a week now.  I'm running out of ideas.
>> >>>
>> >>>Sincerely,
>> >>>Sean Daida
>> >>>address@hidden
>> >>>
>> >>
>> >>
>> >>Sean,
>> >>
>> >>It sounds like there is some problem with the color map, or a version
>> >>incompatibility.
>> >>
>> >>Make sure that you are running ntl so that you know you have enough colors
>  
>> >>to display the satellite image with the xw driver. If you try to launch
>> >>ntl and it tells you that you do not have enough colors, then that
>> >>would be the cause for your abort/dump message. Make sure any xw or gplt
>> >>processes that may have been orphaned are killed and the message queues
>> >>are deleted. If you can't launch ntl with the default number of
>> >>95 colors for satellite images, then you can adjust the number using
>> >>the -s option such as "ntl -s 32".
>> >>
>> >>Also, make sure you don't have any old gplt or xw programs running from
>> >>other versions of GEMPAK. You want to ensure that your path only have
>> >>the executables for your current $GEMEXE distribution in it, so
>> >>there is no confusion on finding a gpmap or gplt from one version
>> >>of GEMPAK, and a xw from another version of the software.
>> >>
>> >>Steve Chiswell
>> >>**************************************************************************
> ** 
>> >>Unidata User Support                                    UCAR Unidata Progr
> am 
>> >>(303)497-8644                                                  P.O. Box 30
> 00 
>> >>address@hidden                                   Boulder, CO 803
> 07 
>> >>--------------------------------------------------------------------------
> -- 
>> >>Unidata WWW Service                        http://www.unidata.ucar.edu/   
>    
>> >>**************************************************************************
> ** 
>> >>
>> >
>> >
>> >--------------000309000300070500030401
>> >Content-Type: text/html; charset=us-ascii
>> >Content-Transfer-Encoding: 7bit
>> >
>> ><html>
>> ><head>
>> ></head>
>> ><body>
>> >Hi there Steve,<br>
>> ><br>
>> >Thank you for your reply. &nbsp;BTW, your suggestion on how to make the sta
> bil
>> > ity
>> >indicies show up on the skew-t plot worked beautifully.<br>
>> ><br>
>> >What information from me would be helpful in sorting out the 8km watervapor
>> >and mosaic imagery problem in gpmap? &nbsp;I tried going back to NAWIPS-5.4
> . &
>> > nbsp;The
>> >only thing I changed between the two setups were the Gemenviron files and
>> >their entry in the .cshrc. &nbsp;Nothing else in .cshrc or .login were chan
> ged
>> > .
>> >&nbsp;Interesting thing, you would think that sourcing the old 5.4 gemenvir
> on
>> >file (I had removed the 5.6 gemenviron file before relogging in) would have
>> >worked like it did before...it didn't. &nbsp;I now get the same:<br>
>> >*** TERMINATING gpmap<br>
>> >*** Received signal 11 SIGSEGV<br>
>> >Segmentation Fault (core dumped)<br>
>> ><br>
>> >I noticed a couple further things: 1) when either the lutsfile or binary
>> >setting is wrong in the imgtyp.tbl file, I get an image type not found erro
> r
>> >and then the above error. &nbsp;2) when the image type seems to be found I 
> jus
>> > t
>> >get the *** TERMINATING error (as above) and no gempak error message. &nbsp
> ;Al
>> > so,
>> >The image will show up (sometimes the image is ok, sometimes it looks reall
> y
>> >off), but no graphics are plotted on the image. &nbsp;After I type gpend, t
> he
>> >colorbar and mapoutlines show up for a second before the window is closed.
>> >&nbsp;<br>
>> ><br>
>> >One check I did was to kill the cronjobs and reboot the machine. &nbsp;The 
> onl
>> > y
>> >gempak related program running was gpmap. &nbsp;This still crashed when try
> ing
>> >to process these images. &nbsp;I've also tried running gempak from other ma
> chi
>> > nes
>> >and sending the display through xhost and setenv. &nbsp;This didn't work ei
> the
>> > r.<br>
>> ><br>
>> >I have checked the environment variables when using gemenviron for 5.4 and
>> >for 5.6. &nbsp;I don't see any conflicts. &nbsp;Should I send you the ENV, 
> SET
>> >  printout
>> >and the Gemenviron files for both versions? &nbsp;Would areaInfo -v output,
>  im
>> > gtyp.tbl,
>> >and the luts help too? &nbsp;<br>
>> ><br>
>> >I've tried almost everything. &nbsp;The interesting thing is that all of th
> e 4
>> > km
>> >images do work. &nbsp;And the 8km resolution images from the Unidata feed a
> lso
>> >work. &nbsp;Could the color table at the OS level still be the problem when
>  ot
>> > her
>> >images still work?<br>
>> ><br>
>> >Sincerely,<br>
>> >Sean Daida<br>
>> ><a class="moz-txt-link-abbreviated" href="mailto:address@hidden";
> >da
>> > address@hidden</a><br>
>> >(808)956-4593<br>
>> ><br>
>> >Unidata Support wrote:<br>
>> ><blockquote type="cite" cite="mid:address@hidden
> u">
>> >  <blockquote type="cite"><pre wrap="">From: Sean Daida <a class="moz-txt-l
> ink
>> > -rfc2396E" href="mailto:address@hidden";>&lt;address@hidden
> ii.
>> > edu&gt;</a><br>Organization: UCAR/Unidata<br>Keywords: 200108260204.f7Q24M
> 114
>> > 934<br></pre>
>> >    </blockquote>
>> >    <pre wrap=""><!----><br></pre>
>> >    <blockquote type="cite"><pre wrap="">Hi there,<br><br>I recently instal
> led
>> >  the solaris sparc binary version of gempak<br>5.6.d.1.  It's mostly worki
> ng 
>> > fine.  One issue I can't seem to figure<br>out is when I try to run GPMAP 
> (ei
>> > ther from a script or from the command<br>line) and select a GOES10 8km WV
>  or
>> >  a MOSAIC (GMS/GOES10) 8km WV or IR<br>image, I get "Abort (core dumped)".
>   I
>> >  tried to go back to gempak 5.4<br>but for some reason (although I didn't 
> cha
>> > nge anything in the older<br>installation) none of the satellite images wo
> rk 
>> > for me.  I ran gpmap on<br>older images that had worked before and those d
> idn
>> > 't work either.<br><br>I checked areaInfo -v and I think the imgtyp.tbl is
>  se
>> > t up right.  The<br>other types of imagery are working fine (4km IR,VIS,WV
> , a
>> > nd 8km IR).<br>Any ideas?  Anything you need from me to figure this out?  
> I h
>> > ave been<br>working on this and the other various problems with upgrading 
> for
>> >  about<br>a week now.  I'm running out of ideas.<br><br>Sincerely,!
>> ><br>Sean Daida<br><a class="moz-txt-link-abbreviated" href="mailto:daidasea
> @so
>> > est.hawaii.edu">address@hidden</a><br><br></pre>
>> >      </blockquote>
>> >      <pre wrap=""><!----><br><br>Sean,<br><br>It sounds like there is some
>  pr
>> > oblem with the color map, or a version<br>incompatibility.<br><br>Make sur
> e t
>> > hat you are running ntl so that you know you have enough colors <br>to dis
> pla
>> > y the satellite image with the xw driver. If you try to launch<br>ntl and 
> it 
>> > tells you that you do not have enough colors, then that<br>would be the ca
> use
>> >  for your abort/dump message. Make sure any xw or gplt<br>processes that m
> ay 
>> > have been orphaned are killed and the message queues<br>are deleted. If yo
> u c
>> > an't launch ntl with the default number of<br>95 colors for satellite imag
> es,
>> >  then you can adjust the number using<br>the -s option such as "ntl -s 32"
> .<b
>> > r><br>Also, make sure you don't have any old gplt or xw programs running f
> rom
>> > <br>other versions of GEMPAK. You want to ensure that your path only have<
> br>
>> > the executables for your current $GEMEXE distribution in it, so<br>there i
> s n
>> > o confusion on finding a gpmap or gplt from one version<br>of GEMP!
>> >AK, and a xw from another version of the software.<br><br>Steve Chiswell<br
> >**
>> > **************************************************************************
>  &l
>> > t;<br>Unidata User Support                                    UCAR Unidata
>  Pr
>> > ogram &lt;<br>(303)497-8644                                               
>    
>> > P.O. Box 3000 &lt;<br><a class="moz-txt-link-abbreviated" href="mailto:sup
> por
>> > address@hidden">address@hidden</a>                          
>    
>> >       Boulder, CO 80307 &lt;<br>------------------------------------------
> ---
>> > ------------------------------- &lt;<br>Unidata WWW Service               
>    
>> >       <a class="moz-txt-link-freetext" href="http://www.unidata.ucar.edu/";
> >ht
>> > tp://www.unidata.ucar.edu/</a>      &lt;<br>******************************
> ***
>> > ******************************************* &lt;<br></pre>
>> >      </blockquote>
>> >      <br>
>> >      </body>
>> >      </html>
>> >
>> >--------------000309000300070500030401--
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>>
>