Re: 19990312: mangled doubles, 3.4, NC_UNLIMITED first dim?

Phil,

>Date: Mon, 15 Mar 1999 11:15:52 -0700
>From: Phil S <address@hidden>
>Organization: SNL
>To: Steve Emmerson <address@hidden>
>Subject: Re: 19990312: mangled doubles, 3.4, NC_UNLIMITED first dim?
>Keywords: 199903122213.PAA00700

In the above message, you wrote:

> Thanks for the tips.
> 
> In fact, I am doing create/ncredef/../close/open/redef/.../close
> operations and doing multiple nc_redef()s in this case.
> 
> >From that standpoint I was hopeful that URL's would help fix things.
> I've tried two of the suggestions but without success. Namely, the patch
> to "posixio.c" and using nc__open() with an explicit 8192 chunksizehint
> specification and still get corrupted double data in the file.

Rats!

> Again, this is netCDF 3.4 under Solaris 2.6 (though the problem also
> occurred when I tried building under AIX 4.1.[?34]).
> 
> 
> I would like to be able to try the suggested workaround of not using
> nc_redef(), but its use is tied inextricably with a process of
> open/redef.../close in multiple routines, some in our library, so that
> just commenting out nc_redef() would not suffice. My feeble attempt to
> do this nc_open..nc_dim_def had a cow, as you might well expect. 
> 
> I'd be willing to investigate this option further if it would
> potentially solve my problem. I presume then that the record variables
> with an NC_UNLIMITED dimension could just be added to the open file as
> long there were more record variables to add?

Yes, they could.  You should realize, however, that the nc_refef()s that
you're doing copy the entire file to a temporary file which is then
renamed to the original on closing.  As a consequence, use of nc_redef()
is discouraged from an efficiency standpoint (as well as a portability
standpoint).

I was hoping that the URL-s would help you with your problem.
Apparently not.  I'm afraid you'll have to wait until the author of (and
expert on) the netCDF package returns from vacation next Monday.  I've
CC-ed him on this so he should contact you then.

--------
Steve Emmerson   <http://www.unidata.ucar.edu>