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.
Brian, I'm not seeing the type of memory usage you see under Solaris. Did you modify any of the $NAWIPS/config/Makeinc.sol settings such as compiler optimizations flags? One thing that might lead to huge program set sizes is by specifying a high optimization which can lead to lots on code expansion and in-lining and bloat the memory requirements. Steve Chiswell Unidata User Support >From: Brian Colle <address@hidden> >Organization: . >Keywords: 199905181953.NAA18341 > >Steve, > >I have 800 Mb designated to swap for my 384 Mb RAM machine. The ldm >and decoding is running on this machine, which takes about 200 Mb >of swap. I fired up a garp session and I could not believe that it >reserves another 400 Mb of swap, so there is only 200 left. This is >probably why I can't fire up another one. But why do you think my garp is >taking so much, ie: After loading Garp with ntl >ldm>swap -s >total: 151520k bytes allocated + 407440k reserved = 558960k used, 263920k >available > >Before loading garp: >swap -s >total: 147384k bytes allocated + 31112k reserved = 178496k used, 644576k >available > >Thanks again, > >Brian > >On Tue, 18 May 1999, Unidata Support wrote: > >> >> Brian, >> >> There is nothing in the garp setup for multiple sessions. You >> should be able to run several garp sessions so long as you have the memory. >> >> Some checks to see if memory is a problem: >> 1) look for hung gplt sessions from other gempak programs >> 2) use the "swap -s" command to see how much available >> memory and swap space you have. If something like a dead >> gplt is hanging around, it can eat up your swap. Or it might be >> that yuou need to create an additional amount of swap space >> on your system using the "mkfile" command and then adding it >> to available swap with the "swap" command. >> >> If you have 64mb of ram, then you usually should have 128mb of swap- >> but if you are doing a lot of other stuff on the machine, then >> you might try increasing it to 196 or 256 Mb. >> >> If you need help with swap considerations, send me the output of the >> "swap -s" command so I can see what resources you have. >> >> Steve Chiswell >> Unidata User Support >> >> >From: Brian Colle <address@hidden> >> >Organization: . >> >Keywords: 199905181901.NAA17191 >> >> > >> >Dear Steve, >> > >> >Yes, I am using ntl, but when I press the Garp icon for another session >> >a new window does not come up, only the standard message: >> >Invoke ... /usr/local/ldm/NAWIPS-5.4/bin/sol/garp. If I try to get >> >another garp up using the command line, it just says "killed," which >> >sounds like the memory problem you were describing. I can load a Garp >> >and ntrans simultaneously, or two ntrans simultaneously. Is there >> >something in the GARP installation setup about multiple sessions? >> > >> >Thanks again, >> > >> >Brian >> > >> >____________________________________________________________ >> >Dr. Brian Colle INTERNET: address@hidden >> >(516)632-3174 >> >Institute for Terrestrial and Planetary Atmospheres >> >Marine Sciences Research Center >> >State University of New York at Stony Brook >> >Stony Brook, NY 11794-5000 >> > >> > >> >> >> >> Brian, >> >> >> >> Are you launching Garp from the "ntl" launching bar? >> >> Running ntl ensures that you have a common color table for all gempak >> >> programs- including garp - to access. If you are just running garp >> >> from the command line, then you will likely have trouble launching >> >> a second session since it will try to obtain a separate color map. >> >> With the shared color map, you should be able to launch several garp sess > ion >> > s. >> >> >> >> The NIDS data is handled between universities directly with WSI. >> >> Unidata negotiated the educational pricing, but the data is sent >> >> directly from WSI to you and they handle all contract and billing. >> >> >> >> Steve Chiswell >> >> ************************************************************************* > *** >> >> Unidata User Support UCAR Unidata Prog > ram >> >> (303)497-8644 P.O. Box 3 > 000 >> >> address@hidden Boulder, CO 80 > 307 >> >> ------------------------------------------------------------------------- > --- >> >> Unidata WWW Service http://www.unidata.ucar.edu/ > >> >> ************************************************************************* > *** >> >> >> > >> >> **************************************************************************** >> 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/ >> **************************************************************************** >> >