<div dir="ltr">Thanks very much for the simple workaround, Dave. It seems to work just fine.<div><br></div><div>Kay</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 July 2016 at 00:20, Dave Allured - NOAA Affiliate <span dir="ltr"><<a href="mailto:dave.allured@noaa.gov" target="_blank">dave.allured@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry, there is a bug in the code that I just posted. Please use this version instead, for correct handling of 8-bit character sets.<div><br></div><div><span class=""><div> f = "test8.bin" </div><div> str = "abcdef"</div><div> ubytes = toubyte (tochar (str))</div></span><div> ushorts = (256H * ubytes(0::2)) + ubytes(1::2)</div><span class=""><div> setfileoption ("bin", "WriteByteOrder", "BigEndian")</div><div> fbinrecwrite (f, 0, ushorts) </div></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>--Dave</div></font></span><div><div class="h5"><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 8, 2016 at 4:41 PM, Dave Allured - NOAA Affiliate <span dir="ltr"><<a href="mailto:dave.allured@noaa.gov" target="_blank">dave.allured@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks, Dennis.<div><br></div><div>Kay, here is a workaround to write characters in big endian mode. This uses unsigned shorts to circumvent the current problem with single-byte data types.</div><div><br></div><div><div> f = "test8.bin" </div><div> str = "abcdef"</div><div> ubytes = toubyte (tochar (str))</div><div> ushorts = toushort (256 * ubytes(0::2) + ubytes(1::2))</div><div> setfileoption ("bin", "WriteByteOrder", "BigEndian")</div><div> fbinrecwrite (f, 0, ushorts) </div><div><br></div><div>This trick requires an even number of characters in the string to be written. HTH.</div><div><br></div><div>--Dave</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 8, 2016 at 4:08 PM, Dennis Shea <span dir="ltr"><<a href="mailto:shea@ucar.edu" target="_blank">shea@ucar.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">FYI: A JIRA ticket has been opened: NCL_2462<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 8, 2016 at 3:10 PM, Dave Allured - NOAA Affiliate <span dir="ltr"><<a href="mailto:dave.allured@noaa.gov" target="_blank">dave.allured@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Kay and NCL,</div><div><br></div><div>I can confirm that fbinrecwrite fails to correctly write an array of characters in big endian mode. I also found the same failure for types byte and ubyte. So I think this is a bug in NCL that needs fixing.<br></div><div><br></div><div>Here is a reduced test case. Use any of x1, x2, or x3 in the write statement. I get valid little-endian output files when the setfileoption statement is commented out. I get the same good and bad results on both Linux and Mac systems; both are little-endian X86 type systems.</div><div><br></div><div><div> f = "test7.bin" </div><div> x1 = tochar ("name7")</div><div> x2 = tobyte (x1)</div><div> x3 = toubyte (x1)</div><div> setfileoption ("bin", "WriteByteOrder", "BigEndian")</div><div> fbinrecwrite (f, 0, x1)</div></div><span><font color="#888888"><div><br></div><div>--Dave</div><div><br></div></font></span><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Jul 7, 2016 at 4:31 AM, Kay Shelton <span dir="ltr"><<a href="mailto:kay.shelton@gmail.com" target="_blank">kay.shelton@gmail.com</a>></span> wrote:<br></span><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello ncl-talkers,<div><br></div><div>I have a little bit of a conundrum with trying to write a binary file for a colleague that is destined to be used in TELEMAC-2D. The binary file that I am trying to write needs to include characters, integers and floats, and will be used on a machine that is Big Endian. I am creating the file on a Linux machine that is Little Endian, hence when I write the binary file I am using "setfileoption("bin","WriteByteOrder","BigEndian")". This all works fine for integers and floats, but the characters are not correctly represented in the output binary.</div><div><br></div><div>I have written a short piece of code that demonstrates the problem succinctly:</div><div><br></div><div>--------------------------------------------------------</div><div><div>begin</div><div><br></div><div>endianness = isbigendian()</div><div>words = "blah_de_blah_de_blah"</div><div>words_char = new(strlen(words),character)</div><div>words_char = tochar(" ")</div><div>words_char(0:strlen(words)-1) = tochar(words)</div><div>outfil = "temp.bin"</div><div><br></div><div>if (.not.endianness) then</div><div> print("Endianness is LittleEndian")</div><div><br></div><div>; run and look at results, then uncomment the next two lines and re-run</div><div>; setfileoption("bin","ReadByteOrder","BigEndian")</div><div>; setfileoption("bin","WriteByteOrder","BigEndian")</div><div><br></div><div> if (fileexists(outfil)) then</div><div> system("rm -f "+outfil)</div><div> end if</div><div> fbinrecwrite (outfil,0, (/ words_char /))</div><div> new_words = fbinrecread(outfil, 0, -1, "character")</div><div> print("WORDS (original): $$ "+words+" $$")</div><div> print("WORDS (original, char to str): $$ "+tostring(words_char)+" $$")</div><div> print("NEW_WORDS (char to str): $$ "+tostring(new_words)+" $$")</div><div>else</div><div> print("Already BigEndian")</div><div>end if</div><div><br></div><div>end</div></div><div><div>--------------------------------------------------------</div><div><br></div><div>I have tested this on two completely different Linux machines running NCL 6.3.0 (both 64-bit Ubuntu) and also on one of them using NCL 6.2.1. All give the same result.</div><div><br></div><div>Running the script first time with the two setfileoption lines commented out (i.e. native LittleEndian binary):</div><div><div>(0) Endianness is LittleEndian</div><div>(0) WORDS (original): $$ blah_de_blah_de_blah $$</div><div>(0) WORDS (original, char to str): $$ blah_de_blah_de_blah $$</div><div>(0) NEW_WORDS (char to str): $$ blah_de_blah_de_blah $$</div></div><div><br></div><div>Running with the two setfileoption lines un-commented:</div><div><div>(0) Endianness is LittleEndian</div><div>(0) WORDS (original): $$ blah_de_blah_de_blah $$</div><div>(0) WORDS (original, char to str): $$ blah_de_blah_de_blah $$</div><div>(0) NEW_WORDS (char to str): $$ $$</div></div><div><br></div><div>As you can see with the BigEndian option the characters are not correctly written to the file.</div><div><br></div><div>Is this correct behaviour? Have I missed something I should have included to get this to work? (This is entirely possible and I apologise for wasting your time if this is a simple user-error.)</div><div><br></div><div>I have searched the ncl-talk archives and have not found this problem encountered by others, so it may well be an issue exclusive to my machines. If it is, I can work around it by wrapping in some fortran to handle the reading and writing of the binary correctly. I would prefer to avoid such a work around as the size of the arrays in the binary files I have to read and write will vary, and I would prefer not to have to hard-code the array sizes when NCL makes calls to the fortran code.<br></div><div><br></div><div><div>[Note: on the machine running NCL 6.2.1 I also get the following warning message on both attempts:</div><div>warning:fbinrecwrite: end of file reached before record number, writing record as last record in file]</div></div><div><br></div><div>Many thanks for your help,</div><div>Kay</div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>