Dear all,<br><br>I was trying to read a single variable written as 2-byte signed integer in a big endian file. Plain binary file, i.e. stream, with no header. Should be really simple, but it was not. For handling this, I had my CTL as:<br>
<br>(...)<br>options big_endian<br>(...)<br>myvar 0 -1,40,2,-1 ** my variable<br>(...)<br><br>However, it did not work. The values were completely wrong. After a day trying to understand what as going on, I decided to force 'little_endian' on the CTL despite the file being big-endian... and it worked!! and I could read the data. <br>
<br>However, USGS claims gtopo30 to be big_endian. To make sure, I wrote a F90 program to read it. I could only get the correct data inside the program if I opened the file as big_endian. Therefore, as USGS and my program agree, I believe the data is big_endian.<br>
<br>Therefore the problem should be in grads. I made a series of tests, writing 1-byte, 2-byte and 4-byte integer binary files, and 4-byte float files, for both little and big endian types. The only problem I found was with 2-byte integers. I think that it is a bug in grads, actually, OpenGrads v2.0.a9.oga.1. The necessary data to reproduce the problem can be found here:<br>
<br><<a href="http://www.fap.if.usp.br/~hbarbosa/file_format.tgz">http://www.fap.if.usp.br/~hbarbosa/file_format.tgz</a>><br>
<br>Can some expert have a look in the source code? Arlindo? Jennifer? By the way, I am on x86-64 machine, runing ubuntu 64bits and using grads-2.0.a9.oga.1-bundle-x86_64-rhel5.5-linux-gnu.tar.gz.<br><br>Sincerely,<br>Henrique<br>