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

19990524: Garp limits on number of satellite images

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.

  • Subject: 19990524: Garp limits on number of satellite images
  • Date: Tue, 25 May 1999 09:44:12 -0600
>From: David Ovens <address@hidden>
>Organization: .
>Keywords: 199905242142.PAA09785

>Hello,
>
>In attempting to run really long satellite loops (over 100 images) on
>our Sun Ultra-10s with Creator 3D graphics cards, I get the following
>error message as Garp v2.01 bombs out:
>
>GetNextPot: Out of PixmapObjects
>
>I started up garp from ntl in an attempt to save colormap space, but
>this did not help.  Is there anything I can do to fix this?  I seem to
>think that 100 images is about the limit, because I succeeded in
>getting 97 loaded, but 115 failed.
>
>Thanks for any help.
>
>David
>-- 
>
>David Ovens            e-mail: address@hidden
>(206) 685-8108
>Dept of Atmospheric Sciences, Box 351640
>University of Washington 
>Seattle, WA  98195
>

David,
The message you are getting is from $GARPHOME/object/pot.c where:

if( ! (*p) && i >= MAXPIXMAPOBJS ) {
                printf( "GetNextPot: Out of PixmapObjects.\n");
                return( (PixmapObjectType *) NULL );
        }

In include/winobj.h MAXPIXMAPOBJS is defined as 128 which may
include other frames besides your satellite loop frames.

It appears you can increase that compile time default and recompile
your Garp executable so long as you have enough system memory to
display the long loop. If you don't have enough memory, then allocation
of *p will fail and you could still get the above situation.

Steve Chiswell