comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: NetCDF I/O problems
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: NetCDF I/O problems [message #34721] Tue, 15 April 2003 09:28 Go to previous message
Paul Van Delst[1] is currently offline  Paul Van Delst[1]
Messages: 1157
Registered: April 2002
Senior Member
Kenneth Bowman wrote:
>
> I want to warn everyone that I am finding what appears to be randomly
> corrupted data when reading from netCDF files in IDL 5.6 on Mac OS X. I
> identified the problem while trying to find the source of the floating
> point exceptions mentioned in a posting a few days ago. The problem
> does not seem to happen on our Linux and IRIX boxes. If you use a Mac
> and netCDF files, you may want to put some extra effort into assuring
> that your results are correct.
>
> If I run the same code on the same input files, the errors occur in
> different places (the program reads through about 10 GB of data). The
> data corruption generally does not generate any IDL error messages
> (other than floating point exceptions), so output files are corrupted
> (nearly) silently.
>
> I have no idea where the problem could be. It might be IDL; it might be
> the netCDF library; it might be OS-level libraries; it might even be a
> hardware problem.
>
> I am sending RSI a detailed description of the problem.
>
> If this is some blunder of my own, I'll confess as soon as I know. ;-)

Speaking of netCDF I/O blunders, one I came across the other day (in my Fortran90 code) in
reading attribute strings. If the attribute string was longer than the declared string
length (you lot know about type declarations, right? :o), the library I/O functions (the C
ones) kept reading the attribute string into memory past the end of the string...trouncing
memory and whatever was stored there - in my case an array index value that used to be 8
and then became 405693745. (My assumption was that the string would be truncated, which it
was on some platforms, but not on others).

Probably not the issue here since IDL would "create" the string of the required length
and, as you say, the error occurs in different places on the same input file, but just
so's ya know. I had the luxury of being able to use a debugger (and the collected wisdom
of the c.l.f newsgroup)...dunno how you'd track that sort of thing down in IDL.

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Ph: (301)763-8000 x7748
Fax:(301)763-8545
[Message index]
 
Read Message
Read Message
Previous Topic: Convert IDL code to HTML with color chromacoding for webpage / printing
Next Topic: Weighted triangulation

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 16:57:04 PDT 2025

Total time taken to generate the page: 0.00496 seconds