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

Re: 20010105: 20010103: garp - surface data problem

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: Re: 20010105: 20010103: garp - surface data problem
  • Date: Mon, 8 Jan 2001 16:32:49 -0700 (MST)
stacksize limit was set to 8192kbytes.
raised limit to 65536kbytes, still does not work.


The plot thickens.....


> From address@hidden  Mon Jan  8 15:52:36 2001
> Delivered-To: address@hidden
> To: "Bryan G. White" <address@hidden>
> Cc: address@hidden, address@hidden
> Subject: 20010105: 20010103: garp - surface data problem 
> Date: Mon, 08 Jan 2001 15:52:34 -0700
> From: Unidata Support <address@hidden>
> 
> 
> Bryan,
> 
> The output below shows that the program dies on line 67 of
> $GARPHOME/gempak/psurf.f which is trying to execute
> the command:
>       read ( msize, '(f5.1)' ) size
> 
> msize passed to the routine is the string "1.0", and size is a real
> defined in the psurf.f routine.
> 
> In itself, there is nothing that should be wrong with this statement.
> The code profiler does not show any memory being steped on when
> I run the program under solaris here.
> 
> However, the size declaration does come following some real arrays
> of size (LLSTFL) (eg 29,700 in the $GARPHOME/include definitions).
> Its possible that these arrays are too large for the stack that your account 
> is using, and creating a situation where the variables are getting clobbered.
> 
> Do you have any limits assigned to your work area? The "limit" command
> from your shell should show what your workspace is allowed to use.
> I increased LLSTFL from 9800 to 29700 from GEMPAK 5.4 to 5.6 since
> many sites wanted to use larger numbers of station ids. It might be that
> this value is too large for your work environment.
> 
> Steve Chiswell
> Unidata User Support
> 
> 
> 
> 
>