Subhalo values not being populated in mock when using SubhaloPhaseSpace
nvanalfen opened this issue · comments
When making and populating a model_instance, then looking at model_instance.mock.galaxy_table, all of the halo values for the satellite galaxies are that of their host halos. I'm using SubhaloPhaseSpace, so the satellite galaxies themselves are getting their positions and velocities from their subhalo, but the values in the table (halo_x, halo_y, etc.) refer to their host halos (other than halo_id, which properly references the subhalo; This is how I've been able to get the proper information so far).
This also means when I try to align with the halo, it aligns to the host halo. To get around this, I've made a new alignment model called SubhaloAlignment that overwrites the halo columns with the correct subhalo information, but I thought this might be something we want to fix farther upstream.
As such, I do have some code to replace these host halo values with the subhalo values from the halocat, if that would help resolve this issue.
Thanks!
Adding on some more information. I found that this also affects features like RadialSatelliteAlignmentStrength. In RadialSatelliteAlignmentStrength, the alignment strength is calculated using the distance between the satellite galaxy and the host halo.
If I use the fix I mentioned in the previous comment (Overwriting the satellite galaxy halo information with their subhalos using SubhaloAlignment model) this overwrites the halo_x, halo_y, and halo_z with the values of the subhalo the satellite galaxy resides in rather than the values for the host halo. This causes issues when using RadialSatelliteAlignmentStrength as all the distances are now calculated to be zero.
So I think either we should fix this upstream and fix the RadialSatelliteAlignmentStrength model to account for that (I also have some notes on the form of the equation used there I think we should change), or if keeping the host halo information in the galaxy_table is preferable, we need to make sure the models intended to align with subhalos have the halocat information and properly reference that.
Hmm, ok, thanks for following up. We should probably find a time to have some discussion of this then.