Dave,
Many thanks, I knew it had to be something I had done (or hadnt in this
case). It works now with ulimit -s unlimited. Is there a reference to
this in the netCDF docs or should it be something a coder knows? There
might be a better method writing a large array out but this will do for
now. This also solved a problem I was having with nf90_get_var when I
was adding some unpacking code to check my results.
Thanks again,
Tom
On Thu, 2008-04-17 at 09:44 -0700, David Pierce wrote:
> Just a guess, but could it be a problem with too big an array on the
> stack? Just how big is your int_packed_data array? Calling with a
> reference to the array accesses the data from the heap, but on most
> compilers (don't know about ifort specifically) doing int(array) will put
> a (type-converted) copy of that array on the stack. If the array is too
> big to be held on the stack, you'll get a segfault there. Have you set
> your stacksize to be "unlimited" (i.e., "limit stacksize unlimited" in
> tcsh)?
>
> Regards,
>
> --Dave
>
>
> Thomas Green wrote:
> > NetCDF users,
> >
> > I am developing a program to evaluate most of the new features in
> > netcdf4 and also the netcdf3 format with our current file format. I
> > have now implemented packing but I am currently getting a segmentation
> > fault when packing to a 32bit int (worked for a 16bit int).
> >
> > Using gdb I can see that it was due to nf_put_var_int (through the f90
> > interface nf90_put_var). I then used the nf_put_var_int directly for
> > the packing the 32 bit integers and I found the fault was caused due to
> > the elemental function int within the call to nf_put_var_int.
> >
> > e.g.
> >
> > Call netcdf_check(nf_put_var_int(ncid, i, int(int_packed_data(:,:,:,:))))
> >
> > replaced with
> >
> > Call netcdf_check(nf_put_var_int(ncid, i, int_packed_data(:,:,:,:)))
> >
> > fixes the problem.
> >
> > I am using this on Linux with the intel compiler (ifort (IFORT) 10.0
> > 20070426 and ifort (IFORT) 9.1 20060927).
> >
> > Since I have gotten it to work it isnt a major problem but obviously
> > would like to understand what is going on and whether there is something
> > I am doing or whether there might be a bug.
> >
> > Any help appreciated,
> >
> > Tom
> >
> > ---
> > Thomas Green Unified Model System Analyst
> > Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
> > E-mail: thomas.green@xxxxxxxxxxxxxxxx http://www.metoffice.gov.uk
> >
> > _______________________________________________
> > netcdfgroup mailing list
> > netcdfgroup@xxxxxxxxxxxxxxxx
> > For list information or to unsubscribe, visit:
> > http://www.unidata.ucar.edu/mailing_lists/
> >
>
>
> -------------------------------------------------------------------
> David W. Pierce
> Division of Climate, Atmospheric Science, and Physical Oceanography
> Scripps Institution of Oceanography
> (858) 534-8276 (voice) / (858) 534-8561 (fax) dpierce@xxxxxxxx
> -------------------------------------------------------------------
>
---
Thomas Green Unified Model System Analyst
Met Office FitzRoy Road Exeter EX1 3PB United Kingdom
Tel: +44 (0)1392 884258 Fax: +44 (0)1392 885681
E-mail: thomas.green@xxxxxxxxxxxxxxxx http://www.metoffice.gov.uk
