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

20000119: datasize problem


Dave,

If you change LLMXGD, then you also need to increase the value of 
LLMDGG which is the memory needed to do calculations on grids.
Eg, if you do temperature advection, then you need TMPC, UWND and
VWND and the output grid at a minimum. In the default, there is enough
working room for about 23 grids.

These parameters are fortran array size declarations. The bigger you
make them, the bigger the compiled program size is. They are
statically allocated storage structures.

The message you have:
Fatal Error: Program datasize exceeds process datasize limit

indicates your datasize limit is too small for what you are trying to do.

You show:
datasize        131072 kbytes

while your hard limit is:
datasize        1048576 kbytes

To start, you probably need to up your datasize limit to
the hard limit and see if that allows you to launch the program.

The larger the array sizes that are defined, the larger the executable
programs will end up when compiled since they include their data
register space.

Steve Chiswell
Unidata User Support

On Wed, 19 Jan 2000, Dave wrote:

> If I set the LLMXGD back to the original value, no problem. If it is set 
> to 500000, then ... no dice:
> 
> 11677:/scidata/NAWIPS/bin/osf/garp: /sbin/loader: Fatal Error: Program 
> datasize exceeds process datasize limit.
> 
> Now, I really don't need garp to be able to handle 500000 grid points. I 
> need to use the decoders and low level programs on some model output that 
> needs a larger number of grid points. Having two separate builds is what 
> I would like to avoid, if possible.
> 
> So,
> 
> question 1) Even if I can get garp to deal with the higher grid size (not
> so far!) will that mean that it actually takes extra memory that it
> doesn't need to. Are all the arrays going to get allocated from the
> get-go, for this larger size grid anyway, or is it sensibly dynamic?
> 
> question 2) You asked me to look at limits. I would think the limits are 
> still ok, but maybe there are more gemprm.OSF1 variables to change, or 
> there is a real conflict. Let me know what you would try next...
> 
> 
> atmsci.msrc.sunysb.edu> limit -h
> cputime         unlimited
> filesize        unlimited
> datasize        1048576 kbytes
> stacksize       32768 kbytes
> coredumpsize    unlimited
> memoryuse       505832 kbytes
> descriptors     4096 files
> addressspace    1048576 kbytes
> 
> 
> atmsci.msrc.sunysb.edu> limit
> cputime         unlimited
> filesize        unlimited
> datasize        131072 kbytes
> stacksize       2048 kbytes
> coredumpsize    unlimited
> memoryuse       505832 kbytes
> descriptors     4096 files
> addressspace    1048576 kbytes
> 
> 
> thx
> 
> -david
> 
>