Recently I've been working with the HOP halo finder in yt 3.0. In particular I've been looking at star particles from Enzo simulations in halos of different sizes. I've been running into strange results with particle fields that are stored in the halo hdf5 files vs particle fields that have to be retrieved from the original simulation data. In particular, if I create a mask for star particles from a field saved to disk (creation_time prior to 3.0 or ParticleMassMsun now) then I get the correct values for other fields when I use this mask if they were also saved to disk (so particle positions or velocities) but not for fields that were retrieved from the simulation (such as dynamical time). Similarly, if I identify stars by creation_time in 3.0 (when it isn't saved in the hdf5 file) then I get the correct dynamical_times, but incorrect particle masses. I think I've identified the source of this problem. When the "particle_index" field is read from the halo hdf5 files, it is then sorted into ascending order. In particular, in __getitem__ in the LoadedHalo class there is the following (this is line ~867 in halo_objects in the 3.0 experimental branch): field_data = self._get_particle_data(self.id, self.fnames, self.size, key) if field_data is not None: if key == 'particle_index': field_data = field_data[field_data.argsort()] These sorted particle indices are then used when retrieving fields from the simulation data, so the fields end up being sorted in a different order than the ones that are retrieved directly from the halo hdf5 files. As a result, masks created from one set of fields don't work properly on the other set. I think that I can fix this, but before I do I want to make sure I'm not going to be breaking anything else in the process. Does anyone know why the particle_index field was being sorted? If so, do you happen to know whether it would make more sense to sort the other particle fields from disk or leave particle_index unsorted? Thanks in advance for any help. - Josh