<div>I am all for binary, especially since storage is a big problem for some of the bigger simulations.</div><div> </div><div>I am just curious, though, which binary are the other simulation groups pushing for?  Is there a consistent way of storing binary data in YT?  I am asking because currently sometimes I pickle my own data or store them in hdf5 .h5 binary or in the .yt files, and I didn't realize the different binaries are not compatible until recently.  </div>
<div> </div><div>Are we looking for a universal YT way of storing binaries?  One big advantage would be everyone being able to read the binary if we all store them the same way, and I'm sure there's many other advantages.  But the headache is everyone agreeing to store them whichever way.<br>
</div><div>From</div><div>G.S.<br></div><div class="gmail_quote">On Mon, Aug 15, 2011 at 6:02 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
Hi Stephen and Geoffrey,<br>
<br>
I would prefer we stick with the longer IO output.  The reason is not<br>
as much that we believe that a halo truly does exist with that<br>
specified precision, but to do our very best to ensure that we<br>
communicate between sessions the precise location.  This may also come<br>
into play with very high precision runs.<br>
<br>
My personal preference would be to utilize an all-binary storage<br>
format as our *primary* storage format and then allow ASCII for<br>
secondary, caveat emptor purposes.  I believe that both the IRATE<br>
group and the Galacticus group are pushing forward with halo<br>
cataloging methods that will be binary.<br>
<br>
-Matt<br>
<div><div></div><div class="h5"><br>
On Sun, Aug 14, 2011 at 9:24 AM, Stephen Skory <<a href="mailto:s@skory.us">s@skory.us</a>> wrote:<br>
> Hi all,<br>
><br>
>> With the current setting, the halo attributes<br>
>> are outputted with 9 decimal points, but the ellipsoid parameters determined<br>
>> using the particle's position (when the data is 64 bit) has 16 decimals.<br>
><br>
> just to clarify, what I've done is to add the option to the<br>
> halos.write_out() function (that outputs the HopAnalysis.out file) to<br>
> add 5 or so extra columns for the ellipsoid information. So what<br>
> Geoffrey is thinking about is increasing the precision of all the<br>
> floats in that text file.<br>
><br>
> --<br>
> Stephen Skory<br>
> <a href="mailto:s@skory.us">s@skory.us</a><br>
> <a href="http://stephenskory.com/" target="_blank">http://stephenskory.com/</a><br>
> <a href="tel:510.621.3687" value="+15106213687">510.621.3687</a> (google voice)<br>
> _______________________________________________<br>
> Yt-dev mailing list<br>
> <a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
Yt-dev mailing list<br>
<a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br>