Howdy all, I've been working on getting writing code (http://hg.enzotools.org/gadget_infrastructure/summary) that will transform gadget snapshots into the newly-minted gridded data format (GDF: http://yt.enzotools.org/wiki/GridDataFormat). The last few days I've been writing a very skeletal GDF reader in yt, and I've come across a few problems. I pushed changes to yt a few hours ago, and so should be up on the hg repository - what I'm talking about is referring to files in /frontends/gadget/* .
1. When reading, say, an array of particle data like position_x of some grid, (shape is just N, the number of particles in that grid) I get array shape errors. It tries to multiply the array by a weight_data but that's an array of the same shape as active dimensions for the grid (which in my case is [2,2,2] since I'm doing an octree refinement) - so it cries when it tries to multiply an N array with a (3,2)-shape array. To make that shape make sense, it seems like I want not the data for that particular grid, but all of it's children's data. Or something, I'm a bit confused. Check out io.py.
2. Is there going to be a problem with having parent grids with no particle data - that are almost empty? The position_x array for such a grid won't exist, so I'm not sure what to do in the _read_data_set() method. I get grids like this when I subdivide a grid into another 8 child grids and then all of the particles particles belonging to the parent grid are shuffled into the appropriate child bins. The parent is then left with none.
3. What does _read_data_slice() mean when a field like 'position' is already scalar-ified as position_x? I thought the slice 'axis' would've picked out the 'x' axis in position, but you start off already asking for position_x.
I've included an example GDF data file here (http://dl.dropbox.com/u/206140/decay_100.gyt.hdf5 - not guaranteed to be alive forever) and a pastebin script (http://paste.enzotools.org/show/1145/) that highlights my first problem.
chris