[gradsusr] big/little endian bug in OpenGrads v2.0.a9.oga.1 for 2-byte integers files

[Jennifer Adams]

I will take a look at this bug as soon as I can. Thanks for all the  
helpful diagnostic material. Although it doesn't say it explicitly in  
the documentation, I don't think the 'special format' codes in the  
units field of the variable declaration for non-standard binary data  
were ever intended to be used on a per-variable basis. When looking at  
this bug, I will make sure that is the case and update the  
documentation as appropriate. If you want to write out variables of  
different binary formats in the same file, I think netCDF is probably  
the better format for that. GrADS will handle a variety of data types  
in the same file automatically without any fuss or muss. --Jennifer

On May 20, 2011, at 11:06 AM, David Lorenz wrote:

> I've run into the same problem in the GrADS binary for Mac. I sent a  
> message to these forums a while back and didn't get a response.
>
> There's also a problem when you mix two-byte and four-byte variables  
> together in the same file. GrADS get confused and acts like all  
> variables are the same size as the variable you are trying to display.
>
>
> -Dave
>
> On 05/19/11, Henrique Barbosa   wrote:
>> Dear all,
>>
>> 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:
>>
>>
>>
>> (...)
>> options big_endian
>> (...)
>> myvar 0 -1,40,2,-1 ** my variable
>> (...)
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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:
>>
>>
>>
>>
>>
>> <http://www.fap.if.usp.br/~hbarbosa/file_format.tgz>
>>
>>
>>
>> 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.
>>
>> Sincerely,
>> Henrique
>>
>>
>>
>>
>> _______________________________________________
>> gradsusr mailing list
>> gradsusr at gradsusr.org
>> http://gradsusr.org/mailman/listinfo/gradsusr
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jma at cola.iges.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20110520/da68d65d/attachment-0003.html