Hi James and Dennis, I discovered an apparent bug in the latest beta snapshot concerning nccopy. I have two builds of netcdf, and I executed the following commands and obtained different results: USING LATEST BUILD (latest beta referenced in previous email) ezaron$ ~/opt/bin/nccopy http://omglnx1.meas.ncsu.edu:8080/thredds/dodsC/gomexppp/2010_June/avg/N N.nc USING AN OLDER BUILD: ezaron$ /opt/local/bin/nccopy http://omglnx1.meas.ncsu.edu:8080/thredds/dodsC/gomexppp/2010_June/avg/N N.nc The latest build fails to copy all the variables correctly. For some reason the file it creates discards all the time variability of the 3-dimensional fields (u,v, temp, and salt). I have attached the output of ncdump -h for the files. I can post the entire files if needed, they are about 1GB. Please see below the nc-config information for both netcdf builds. Here's the config info on the LATEST BUILD: ezaron$ ~/opt/bin/nc-config --all This netCDF 4.1.2-beta2-snapshot2011011022 has been built with the following features: --cc -> cc --cflags -> -I/Users/ezaron/opt/include -I/opt/local/include -I/opt/local/include -I/opt/local/include --libs -> -L/Users/ezaron/opt/lib -lnetcdf -L/opt/local/lib -lhdf5_hl -lhdf5 -L/opt/local/lib -lz -L/opt/local/lib -lcurl -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lidn -lssl -lcrypto -lssl -lcrypto -lz -lz -lz --cxx -> g++ --has-c++ -> yes --fc -> g95 --fflags -> -g -O2 /Users/ezaron/opt/include --flibs -> -L/Users/ezaron/opt/lib -lnetcdff -lnetcdf --has-f77 -> no --has-f90 -> no --has-dap -> yes --has-nc2 -> yes --has-nc4 -> yes --has-hdf5 -> yes --has-hdf4 -> no --has-pnetcdf-> no --has-szlib -> no --prefix -> /Users/ezaron/opt --includedir-> /Users/ezaron/opt/include --version -> netCDF 4.1.2-beta2-snapshot2011011022 Here's the config info on the working OLDER BUILD: ezaron$ /opt/local/bin/nc-config --all This netCDF 4.1.1 has been built with the following features: --cc -> /opt/local/bin/gcc-mp-4.3 --cflags -> -I/opt/local/include --libs -> -L/opt/local/lib -lnetcdf --cxx -> /opt/local/bin/g++-mp-4.3 --has-c++ -> yes --fc -> /opt/local/bin/gfortran-mp-4.3 --fflags -> -O2 -m64 -I/opt/local/include --flibs -> -L/opt/local/lib -lnetcdff -lnetcdf --has-f77 -> yes --has-f90 -> yes --has-dap -> yes --has-nc2 -> yes --has-nc4 -> yes --has-hdf5 -> yes --has-hdf4 -> no --has-szlib -> yes --prefix -> /opt/local --includedir-> /opt/local/include --version -> netCDF 4.1.1 Please forgive me if this is not the right place to post a bug report. All the best, -Ed
Attachment:
ncdump_NEW_BUILD_BROKEN.log
Description: Binary data
Attachment:
ncdump_OLD_BUILD_WORKING.log
Description: Binary data
On Jan 10, 2011, at 4:21 PM, Dennis Heimbigner wrote: > The netcdf snapshot > (ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz) > available TOMORROW (Tuesday) > now supports the ability to access opendap data stored in files. > > If you have a file called, say, dataset.dods, it is expected that > it contains the on-the-wire data for a request to an opendap server. > Such a file can be created using, for example, wget or a web browser. > Similarly, one can save .das and .dds data in files. > > Suppose you have such a file at absolute path /home/abc/dapdata.dods. > You should now be able to access it using, for example the command: > ncdump file:///home/abs/dapdata > You could also use nccopy instead of ncdump. > NOTE: the final .dods is left off. > > There are some things to note: > 1. You must have at least a .dods file (e.g. dataset.dods). > > 2. If there is also a /home/abs/dapdata.das, > it will be used to obtain attributes. > > 3. If there is a /home/abs/dapdata.dds > it will be used. If this does not exist, > then the dds part of the .dods file will be used. > > If you are in a position to try this out, please do so > and let me know if there are any problems. > > =Dennis Heimbigner (dmh@xxxxxxxx) > Unidata
netcdfgroup archives: