Hi Peter: what version netcdf-java? if no using latest 4.5, can you try with that and report? thanks > Hi John, > > I've tracked the problem down a little further, and found the the string "not > a valid cdfid" comes from the HDF JNI library and the error is _not_ related > to assertions: > > > Beanlet-Pro:test_case_1 phollema$ strings libjhdf.jnilib | grep "not a > > valid cdfid" > > %d is not a valid cdfid > > > > which is from my Mac, or similarly in Linux: > > > Beanlet-Pro:test_case_1 phollema$ strings libjhdf.so | grep "not a valid > > cdfid" > > %d is not a valid cdfid > > > > I've been able to reduce the code to just the essentials needed to recreate > the error on Mac, but on Linux I've not been able to reproduce using the same > code. Essentially, I do these steps in the attached code: > > Step 1) Use the Java NetCDF library to create and write a NetCDF 3 file > Step 2) Use the Java HDF object interface to check if the file created is HDF > 5 > Step 3) Use the Java NetCDF library to create and write a NetCDF 4 file > Step 4) Use the Java HDF object interface to check if the file created is HDF > 5 > > When I run on Mac, Step 3 never completes and my program exits with "netcdf: > 65536 is not a valid cdfid" just when I perform the create() call. > > Peter > -- > Peter Hollemans <address@hidden>, Terrenus Earth Sciences > Web: http://www.terrenus.ca Phone: +1 (778) 533-2896 > > > On Jan 9, 2015, at 12:39 PM, Unidata netCDF Java Support <address@hidden> > > wrote: > > > > hi peter: > > > > can you try it with 4.5.4 version of java-netcdf? > > if still persists, send me the file so i can try to reproduce. > > thanks > > John > > > >> Full Name: Peter Hollemans > >> Email Address: address@hidden > >> Organization: NOAA > >> Package Version: 4.5.3 > >> Operating System: Mac OS X 10.10.1 > >> Hardware: MacBook Pro 13" 2011 > >> Description of problem: Hello! > >> > >> I have an interesting problem which I think I've tracked down to > >> assertions. If I run my Java code with assertions enabled just for my > >> package (-ea:noaa.coastwatch...), I seem to have assertions enabled for > >> the NetCDF 4 library that's JNA mapped via Nc4Iosp as well. If I turn off > >> assertions (ie: I just run as normal), then my code runs to completion > >> (no errors thrown, but no assertions checked either). The message I'm > >> getting with assertions enabled looks like this (running from ant): > >> > >> [java] > >> [java] ***** class noaa.coastwatch.io.CFNCWriter ***** > >> [java] Testing writing of NetCDF version 3 format ... OK > >> [java] Testing writing of NetCDF version 4 format ... Netcdf > >> nc_inq_libvers='4.3.2 of Oct 20 2014 09:49:08 $' isProtected=false > >> [java] netcdf: 65536 is not a valid cdfid > >> [java] > >> [java] Java Result: 3 > >> > >> I can see the nc_inq_libvers message is coming from the Nc4Iosp class > >> after it runs the Native.loadLibrary() call, but I can't see anywhere in > >> the Java code that the "not a valid cdfid" is coming from, so I assume > >> it must be from the NetCDF 4 native layer. > >> > >> Any ideas on how to fix this aside from going into the NetCDF 4 source > >> and trying to determine why the assertion (if that's what it is) is > >> being tripped? I thought, maybe there's a way to tell the loadLibrary > >> call to not propagate the JVM assertion mode into the native layer, > >> but couldn't find any documentation on if that's possible. > >> > >> Peter > >> > >> > > > > > > Ticket Details > > =================== > > Ticket ID: YCN-767203 > > Department: Support netCDF Java > > Priority: Normal > > Status: Open > > > > > > > > Ticket Details =================== Ticket ID: YCN-767203 Department: Support netCDF Java Priority: Normal Status: Open
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.