Closed nvanalfen closed 3 years ago
This is useful to know. Halotools just directly uses the publicly available Rockstar subhalo catalogs, so these outlier halos are inherited from the upstream data. I'm not sure what failure mode this would signify. One innocuous explanation would be that these halos are perfect spheres. What are their values of b/a and c/a?
Regardless, probably the simplest treatment is as you say: to just mask out the outlier halos before proceeding with any further preprocessing.
For these 39 halos, the 'halo_b_to_a' and 'halo_c_to_a' values are all zero.
Hmm, ok, thanks for checking. I would have guessed that if these were perfect spheres then c/a and b/a would be unity, not zero. But of course it's possible that when Rockstar encounters such a rare edge case, it just uses zero for the fill value instead of unity. It's good that you raised this issue in case other people encounter it and go poking around for whether it has been noticed before. But since this is such a tiny fraction of objects, presumably throwing these subhalos out will not impact a cosmological analysis, so I think we should close this issue for now until we find that this is creating some downstream problem.
When generating a CachedHaloCatalog using the following:
halocat = CachedHaloCatalog(simname='bolshoi', halo_finder='rockstar', redshift=0, version_name='halotools_v0p4')
there are 39 entries that have a value of 0 for halo_axisA_x, halo_axisA_y, and halo_axisA_z. This introduces NaN values when trying to use these halo orientations to align galaxies within them.
It's a relatively small number in comparison to all the halos available, and I can mask them out when generating a mock, but it seemed major enough to bring to someone's attention in case it has slipped under the radar so far.