<div dir="ltr">Stuart,<div><br></div><div>Wow, a parallel gdf writer? I was planning to add that sometime next week or so. I'd like to know how you approached it. I was simply thinking of having a flag to only write a data-only "sidecar" file that would use HDF5 links in the master file for grids on other cores. Please let me know if I can help integrate what you've done into this framework.</div>
<div><br></div><div>Jeff</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 11:09 AM, Stuart Mumford <span dir="ltr"><<a href="mailto:stuart@mumford.me.uk" target="_blank">stuart@mumford.me.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interesting!!<br>
<br>
I will have a look over this, I wrote a parallel compatible version of<br>
this code a while back I will try and get it working within your<br>
module.<br>
<span class="HOEnZb"><font color="#888888"><br>
Stuart<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 29 January 2014 22:22, j s oishi <<a href="mailto:jsoishi@gmail.com">jsoishi@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I've adapted yt's gdf_writer.py into a standalone class called pygdf<br>
> (<a href="https://bitbucket.org/jsoishi/pygdf" target="_blank">https://bitbucket.org/jsoishi/pygdf</a>). I've done this so that any python<br>
> code can now save data in the gdf format.<br>
><br>
> While doing this, I came across something in the yt gdf frontend that I'm<br>
> not quite sure I understand. In the grid metadata, yt expects<br>
> /grid_particle_count to be a 2-D array, but the gdf standard clearly states<br>
> this should be a 1-D (int64, N) array, where N is the number of grids.<br>
> Further complicating the issue is the fact that if I create a 1-D array for<br>
> /grid_particle_count, the failure point in the following script<br>
><br>
> from yt.mods import *<br>
> pf = load("/tmp/blah.gdf")<br>
><br>
> sp = SlicePlot(pf, 2, "Density")<br>
><br>
> is actually in data_objects/grid_patch.py, not in the gdf frontend itself.<br>
> The file /tmp/blah.gdf can be generated by running the test.py script in<br>
> pygdf.<br>
><br>
> The obvious workaround is to simply make /grid_particle_count a 2D array<br>
> (this is especially so since I'm not actually using particles at the<br>
> moment), but I'm not sure why this should be so. The total count of<br>
> particles in N grids seems to be better fit in a 1-D array to me. However,<br>
> I'd like to understand better what's going on. Any pointers or clarification<br>
> would be very helpful.<br>
><br>
> Also, any feedback on pygdf would be most welcome!<br>
><br>
> thanks,<br>
><br>
> j<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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></div>