This PR is a continuation from Benjamin Thompson's PR 1308.
The fields currently in yt with names like particle_spherical_position_radius return incorrect results. See #966. This PR ensures these fields return correct results.
Adds new particle_position_relative and particle_velocity_relative fields. This makes it possible to get particle positions and velocities in a rotated reference frame.
The naming system for particle and mesh vector fields has never been codified. In this PR I implement a proposed naming system.
Particle vector fields will be of the form:
particle_<vector field name>_coordinate
While mesh vector fields should have names following:
So the spherical radius particle position field becomes particle_position_spherical_radius. The main advantage is that this matches our current naming system for cartesian coordinates (e.g. particle_position_x, particle_velocity_y).
Where there are fields that are currently in yt that have names that do not match this naming convention, I've stubbed out their implementation and made them aliases for the fields with names following my proposed naming convention. I've also marked these stub fields as deprecated in their docstrings. In a few places (particularly in the fluid velocity fields), I've opted to leave the old fields behind without marking them as deprecated. There are mostly commonly used fields like radial_velocity, which is now just an alias for velocity_spherical_r.
Let me know if you disagree with any decisions I've made about field deprecation.
When no field already existed (e.g. the position fields in cylindrical coordinates), I've simply added the new fields following my proposed naming convention without adding fields that would immediately need to be deprecated.
Update: I've updated this so that all the index and gas velocity fields match the naming convention used for the particle fields.
Other than my highly tedious docstring complaints, I tried this out and it seems to work as advertised. Looks good to me.
All tests pass. Good job!
Just thinking, for a later PR (which I would be happy to work on). We could probably condense down the number of lines of code (especially after adding the relative fields) by calling again