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

[netCDF #SVH-828273]: nc_test failure in test_ncsync for netcdf4/HDF5 component only.



> Hi Netcdf,
> I am one of the luckless people who are trying to build netcdf-4  (version
> 4.1.3) for Windows (64 bit) .  I can get the code to compile and link without
> too many problems. However I do get a problem when I run the nc_tests 
> executable
> which is part of the build process. The code succeeds for the CLASSIC and 64 
> Bit
> OFFSET modes but fails (but still in control) for NETCDF-4/HDF5 in  function
> test_ncsync (line 74 driver.c).
> 
> I have stepped through the code with the Visual Studio debugger and I have
> tracked the problem to an inconsistency (in the version of code I have on my
> machine)  between function nc_def_var  (line 44 of var.c) and function 
> nvdims()
> (~line  45 of v2i.c) . Function nc_def_var seems to update a variable called
> ncp->vars each time we add a new variable.  Function nvdims looks at ncp->vars
> to get the variable info. The problem is that the NETCDF4 version (Windows 64
> bit) on my machine  does indeed update ncp->vars in CLASSIC and 64 Bit OFFSET
> mode but does not update the variable in NETCDF-4 mode.  In NETCDF-4 mode a
> HDF-5 group variable is updated and written to the HDF file but this 
> information
> is not being transmitted back to the ncp->vars variable.  This creates an 
> error
> when nvdims looks at ncp->vars as it thinks no variables have been created.
> 
> I have no doubt in my mind that nc_tests has successfully run on other
> platforms.  However this looks like a good 'ol bug where nvdims and nc_def_var
> are not playing together very well on a 64 bit Windows platform.  I'm not sure
> what I can ask given that you dont have much support for Windows . I guess one
> simple question is whether or not you know if NETCDF- 4.1.3 has passed all of
> the standard tests on 64 bit Windows with Visual Studio (2008/2009) or whether
> this is still  an unknown. This info would let me at least identify whether or
> not I have a configuration issue or a software bug.
> 
> My other question is how can I help you get a sensible CMAKE distribution for
> NETCDF-4.   Given that HDF-5 now distributes with CMAKE it makes sense that 
> you
> would support this method as well. I have had a look at the NETCDF autoconf
> files (configure.ac) and it does not look like a huge effort is required to 
> port
> from autoconf to CMAKE: it's basically a bunch of options variables and a few
> tests for compiler capabilities.  I think I would be willing to help get this
> going (say to a prototype/alpha/beta level). Let me know if you think this is 
> a
> worthwhile activity. I know everyone is pushed for time nowadays and I would 
> be
> glad to help.
> 
> Cheers
> Nick Lloyd
> University Of Saskatchewan.
> 
> 
> 

Howdy Nick!

I also am one of the luckless people trying to get 64-bit builds working, in my 
case under the mingw build system. ;-(

Can you send a simple test program that demonstrates the issue you are having?

It is extremely unlikely that the error is as you describe, because of the 
internal metadata store were not being updated correctly by the code, then this 
would fail on all platforms. What may be misleading you is that two different 
sets of code are used for classic and netCDF-4/HDF5 files. If you call 
nc_def_var on a netCDF-4 file, it calls a function in libsrc4/nc4var.c 
NC4_def_var(), but when you call nc_def_var on a classic format file, 
libsrc/var.c NC3_def_var() is called. 

Try uncommenting the two lines in netcdf.h and try again:

#include <io.h>
/*#define lseek _lseeki64                                                       
                                                                                
                                     
  #define off_t __int64*/

I would LOVE to have a cmake build system. But I despair and figuring out 
another one by myself, and doing all the other work I have signed up for. If 
you could help, that would be great. Ideally, you could give me the files, and 
I could add this to our nightly build/test system. 

To make things even easier, before the next release we are splitting off the 
fortran and C++ libraries into their own distributions. This makes a bunch of 
options and directories go away. It is the equivalent of --disable-fortran and 
--disable-cxx.

If you put together a working set, that would be terrific. 

You want to make sure you follow our work on jira:
https://www.unidata.ucar.edu/jira/browse/NCF

Also you want to start with the daily snapshot, and you want to stay current 
with it. We work hard around here and so it changes a lot. ;=)

That means if you grab a daily snapshot and spend 3 months creating a cmake 
build, you are likely to find some work to get it current. The daily snapshot 
is here: ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz.

Thanks,

Ed

Ticket Details
===================
Ticket ID: SVH-828273
Department: Support netCDF
Priority: Normal
Status: Closed