<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">&lt;<a href="mailto:dave.allured@noaa.gov" target="_blank">dave.allured@noaa.gov</a>&gt;</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 = &quot;test8.bin&quot; </div><div>  str = &quot;abcdef&quot;</div><div>  ubytes  = toubyte (tochar (str))</div></span><div>  ushorts = (256H * ubytes(0::2)) + ubytes(1::2)</div><span class=""><div>  setfileoption (&quot;bin&quot;, &quot;WriteByteOrder&quot;, &quot;BigEndian&quot;)</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">&lt;<a href="mailto:dave.allured@noaa.gov" target="_blank">dave.allured@noaa.gov</a>&gt;</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 = &quot;test8.bin&quot; </div><div>  str = &quot;abcdef&quot;</div><div>  ubytes  = toubyte (tochar (str))</div><div>  ushorts = toushort (256 * ubytes(0::2) + ubytes(1::2))</div><div>  setfileoption (&quot;bin&quot;, &quot;WriteByteOrder&quot;, &quot;BigEndian&quot;)</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">&lt;<a href="mailto:shea@ucar.edu" target="_blank">shea@ucar.edu</a>&gt;</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">&lt;<a href="mailto:dave.allured@noaa.gov" target="_blank">dave.allured@noaa.gov</a>&gt;</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 = &quot;test7.bin&quot;  </div><div>  x1 = tochar (&quot;name7&quot;)</div><div>  x2 = tobyte (x1)</div><div>  x3 = toubyte (x1)</div><div>  setfileoption (&quot;bin&quot;, &quot;WriteByteOrder&quot;, &quot;BigEndian&quot;)</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">&lt;<a href="mailto:kay.shelton@gmail.com" target="_blank">kay.shelton@gmail.com</a>&gt;</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 &quot;setfileoption(&quot;bin&quot;,&quot;WriteByteOrder&quot;,&quot;BigEndian&quot;)&quot;. 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 = &quot;blah_de_blah_de_blah&quot;</div><div>words_char = new(strlen(words),character)</div><div>words_char = tochar(&quot; &quot;)</div><div>words_char(0:strlen(words)-1) = tochar(words)</div><div>outfil = &quot;temp.bin&quot;</div><div><br></div><div>if (.not.endianness) then</div><div>  print(&quot;Endianness is LittleEndian&quot;)</div><div><br></div><div>; run and look at results, then uncomment the next two lines and re-run</div><div>;  setfileoption(&quot;bin&quot;,&quot;ReadByteOrder&quot;,&quot;BigEndian&quot;)</div><div>;  setfileoption(&quot;bin&quot;,&quot;WriteByteOrder&quot;,&quot;BigEndian&quot;)</div><div><br></div><div>  if (fileexists(outfil)) then</div><div>    system(&quot;rm -f &quot;+outfil)</div><div>  end if</div><div>  fbinrecwrite (outfil,0, (/ words_char /))</div><div>  new_words = fbinrecread(outfil, 0, -1, &quot;character&quot;)</div><div>  print(&quot;WORDS (original): $$ &quot;+words+&quot; $$&quot;)</div><div>  print(&quot;WORDS (original, char to str): $$ &quot;+tostring(words_char)+&quot; $$&quot;)</div><div>  print(&quot;NEW_WORDS (char to str): $$ &quot;+tostring(new_words)+&quot; $$&quot;)</div><div>else</div><div>  print(&quot;Already BigEndian&quot;)</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>