I think it's in the ifort documentation. If you open up the help GUI,
then click on "Appendix A: Notes", and click on subheading "3: Features",
then click on "3.5: The annoying ones," check the dialog box "Include ones
that drive you mad," it will pop up a warning dialog. Click on "Sod off",
navigate to the "you blasted pile of junk" tab, and it mentions the
subject there, in a footnote towards the end of the page.
Regards,
--Dave
Thomas Green wrote:
> 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
>
>
-------------------------------------------------------------------
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
-------------------------------------------------------------------
