New issue 1334: Yt misinterpretes gizmo binary files of type one https://bitbucket.org/yt_analysis/yt/issues/1334/yt-misinterpretes-gizmo-bin... Christoph Bischko: [Gizmo](https://bitbucket.org/phopkins/gizmo) binary files of type 1 (oldest type, no hdf5, no 4 character block delimiters) are not read/recognized correctly by yt. Gizmo has introduced two additional integer-sized blocks (`CHILD_ID` and `GENERATION_ID`) for **all** particle types (gas, halo, disk, bulge, stars, boundary). So the order of blocks is: 1. Positions 2. Velocities 3. Particle IDs 4. **Child IDs** 5. **Generation IDs** 6. Masses 7. Internal Energy ... If the `LONGIDS` flag was set in Gizmo, the two new blocks have the size of a `long long` in C. Currently yt misinterpretes the `CHILD_ID` block as mass. A way to identify this is to skip the block that might be `CHILD_ID` or `MASS`, read the size of the next block and depending on that decide whether we have a Gizmo or Gadget file: - The block after `MASS` should be Internal energy therefore have `sizeof(float)` or `sizeof(double)`¹ times number of **gas** particles - The block after `CHILD_ID` should be `GENERATION_ID`, which has `sizeof(int)` or `sizeof(long long)` times the **total** number of particles Most people use HDF5 or at least snap format 2 with Gizmo, but there are a few legacy Gadget tools that require format 1. It should be recognized and read correctly in yt. ¹Depending on whether the Gizmo was compiled with the `OUTPUT_IN_DOUBLEPRECISION` flag.