[yt-dev] Issue #1334: Yt misinterpretes gizmo binary files of type one (yt_analysis/yt)

[Christoph Bischko]

New issue 1334: Yt misinterpretes gizmo binary files of type one
https://bitbucket.org/yt_analysis/yt/issues/1334/yt-misinterpretes-gizmo-binary-files-of

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.