This sounds similar to other problems with ifort 12.1 - I'll bet that if
you update to ifort 13 and rebuild this problem will go away.
On Thu, Sep 5, 2013 at 7:38 AM, Letitia Soulliard - NOAA Affiliate <
letitia.soulliard@xxxxxxxx> wrote:
> For clarification...
>
> ifort version 12.1.3 20120212
> netCDF version 4.2.1.1
>
> As for a test case, I was just creating a dummy variable that was just
> filled with 1's, in various sizes. When I created a variable that was
> 4,000,000 elements, regardless of it it was 1 dimension or 3 dimension it
> would always cause a core dump when it got to nf90_put_var. If the dataset
> was only 2,000,000 elements then it never had a problem.
>
> Tish Soulliard
>
> NOAA/NESDIS/STAR
>
> letitia.soulliard@xxxxxxxx
> 301-683-3538
>
> National Oceanic and Atmospheric Administration
> NESDIS/STAR/SMCD/OPDB
> Letitia Soulliard
> NCWCP (E/RA23)
> 5830 University Research Court
> Floor 2, Room 2686
> College Park, MD 20740-3818
>
>
>
>
> On Wed, Sep 4, 2013 at 1:54 PM, Jim Edwards <jedwards@xxxxxxxx> wrote:
>
>> It would be really helpful if you could clarify this by including the
>> version of ifort that you are using. And your conclusion that "this seems
>> to be a bug in the library only when compiled with ifort" could well be
>> misplaced as there may not be a problem with the netcdf library at all but
>> rather a problem with compiling with a certain compiler version (and
>> possibly when using a certain set of compiler flags on a particular piece
>> of hardware). Can you provide a test case that demonstrates the problem?
>>
>>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 11:46 AM, Letitia Soulliard - NOAA Affiliate <
>> letitia.soulliard@xxxxxxxx> wrote:
>>
>>> I have been having trouble with writing an array of size 6x3960x243 =
>>> 5,773,680 elements. I had no problems writing this same data when the
>>> array was only size 6x2024x243 = 2950992 elements. I have been playing
>>> around with various size/type variables, and have found that it was only a
>>> problem with integer values and not with real/double values, and it didn't
>>> matter if it was 1, 2, or 3 dimensions. It also seems to always been an
>>> issue with a large number of elements, and never an issue with small number
>>> of elements. The tipping point seems to be around 3,116,000 elements. At
>>> that number the write would sometimes fail and sometimes work. It seemed
>>> very random.
>>>
>>> After struggling with this for a while we decided to try compiling the
>>> code with gfortran instead of ifort. Once I did this, the problem went
>>> away. So this seems to be a bug in the library only when compiled with
>>> ifort.
>>>
>>> Anyway, just wanted to let others know in case they run into a similar
>>> issue.
>>>
>>> Tish Soulliard
>>>
>>> NOAA/NESDIS/STAR
>>>
>>> letitia.soulliard@xxxxxxxx
>>> 301-683-3538
>>>
>>> National Oceanic and Atmospheric Administration
>>> NESDIS/STAR/SMCD/OPDB
>>> Letitia Soulliard
>>> NCWCP (E/RA23)
>>> 5830 University Research Court
>>> Floor 2, Room 2686
>>> College Park, MD 20740-3818
>>>
>>>
>>>
>>> _______________________________________________
>>> netcdfgroup mailing list
>>> netcdfgroup@xxxxxxxxxxxxxxxx
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/mailing_lists/
>>>
>>
>>
>>
>> --
>> Jim Edwards
>>
>> CESM Software Engineering Group
>> National Center for Atmospheric Research
>> Boulder, CO
>> 303-497-1842
>>
>
>
--
Jim Edwards
CESM Software Engineering Group
National Center for Atmospheric Research
Boulder, CO
303-497-1842
