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

[Support #BPJ-806970]: netcdf-3.6.2 faild on ia64

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: [Support #BPJ-806970]: netcdf-3.6.2 faild on ia64
  • Date: Thu, 22 Mar 2007 16:34:30 -0600
Malte,

Thanks for sending the extra information, though it turns out it didn't help 
diagnose the problem.

We have not seen this error before on any other platform, as far as I can 
determine.  It may be an indication of an error in our tests or a problem with 
over-aggressive optimization by ifort.  You might be able to determine if it is 
an ifort problem by running the configure and "make check" again (after a "make 
distclean") without the "-O2" optimization flag in CFLAGS and FFLAGS, that is

 $ make distclean
 $ ./configure CFLAGS=-g FFLAGS=-g ...
 $ make check

If this works but using CFLAGS="-O2" doesn't work, that indicates a problem 
with ifort that you can report to the compiler vendor.  If it fails the same 
way, then I'm not sure how to explain it.

What is hapening in more detail in the test that fails (ncsync and nf_sync) is 
that a netCDF file is opened and written to, followed by a call to ncsync (but 
not to ncclose()), so that the file is still open but presumably the writes 
have been flushed to disk.  Then it is reopened (so it is now open twice, with 
two separate netCDF IDs), and read from the second ID.  The values it gets 
after the second open should agree with what was written, but they don't, 
indicating that ncsysnc either didn't flush the user buffers to disk or the 
second open didn't get the values from disk but perhaps from a cache somewhere 
that didn't agree with the values that should have been flushed to disk.

I may be able to get access to a similar platfomr with ifort to see if we can 
reproduce the problem here, but it will be a few days.

--Russ


Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: BPJ-806970
Department: Support netCDF
Priority: Normal
Status: Closed