quoting Artsemi Syrakvash
While our experience with the library has been rather smooth, we have encountered one minor issue that is somewhat inconvenient. We need to keep track of particles' origins and in other packages one can do this with GADGET-like notation (0 - gas, 1 - halo, 2 - disk etc.). But NEMO's snapshots handle component differentiation only by keeping ranges of each component, and the information about particles' nature (halo, disk, etc) is lost - it can be recovered only if one remembers which range corresponds to which particle type. Our team runs multiple simulations with varying components and particle counts, so keeping track of particle types becomes quite burdensome.
A workaround I found was to store particle type-denoting digits using the 'Key' tag (reading and writing via the UNSIO library). But when I pass the resulting snapshot to gyrfalcON, the 'Key' tag gets lost and isn't present in the output file. So, the question is: Is there an intended way to store the information about particle types inside NEMO snapshots? Could workarounds like using the 'Key' tag work with gyrfalcON (perhaps by utilising the 'give' argument properly)?
quoting Artsemi Syrakvash
While our experience with the library has been rather smooth, we have encountered one minor issue that is somewhat inconvenient. We need to keep track of particles' origins and in other packages one can do this with GADGET-like notation (0 - gas, 1 - halo, 2 - disk etc.). But NEMO's snapshots handle component differentiation only by keeping ranges of each component, and the information about particles' nature (halo, disk, etc) is lost - it can be recovered only if one remembers which range corresponds to which particle type. Our team runs multiple simulations with varying components and particle counts, so keeping track of particle types becomes quite burdensome.
A workaround I found was to store particle type-denoting digits using the 'Key' tag (reading and writing via the UNSIO library). But when I pass the resulting snapshot to gyrfalcON, the 'Key' tag gets lost and isn't present in the output file. So, the question is: Is there an intended way to store the information about particle types inside NEMO snapshots? Could workarounds like using the 'Key' tag work with gyrfalcON (perhaps by utilising the 'give' argument properly)?