minor astropy units + mass calc fixes

[jamesmlane]

• Passing rmin as astropy quantity to sphericaldf.sample() always fails the comparison with self._rmin_sampling, so parse to internal units first.
• Uncomment the try-except sequence in _make_cmf_interpolator() to allow galpy potentials that don't have vectorized mass calculations to work properly.
• Add use_physical=False to the mass normalization for self._rmin_sampling > 0 so it works properly when denspot has ro,vo set.

[jobovy]

Thanks! Looks like there's a typo in the code that needs to be fixed. Otherwise, two more comments:

• The self._rmin_sampling = conversion.parse_length(rmin, ro=self._ro) line should now just be self._rmin_sampling = rmin
• We'l probably need a test involving a potential that doesn't allow vectorized mass calculations. I think that code was commented out, because there was no potential that doesn't allow vectorized mass calculations that we were using, but it sounds like you must have hit upon one? So perhaps just a quick sampling test with that potential to verify that new code.

[jamesmlane]

Let me double check but I'm positive I uncommented the try-catch statement to fix something (one of the power law potentials I think) that was failing because it was passing into the numerical integration in Potential.mass()

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (4a4e6c1) 99.91% compared to head (3d5ed4d) 99.91%.

Additional details and impacted files

@@           Coverage Diff            @@
##             main     #577    +/-   ##
========================================
  Coverage   99.91%   99.91%            
========================================
  Files         196      198     +2     
  Lines       28955    29184   +229     
========================================
+ Hits        28931    29160   +229     
  Misses         24       24            

Impacted Files	Coverage Δ
galpy/df/sphericaldf.py	100.00% <100.00%> (ø)

... and 14 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jamesmlane]

Okay I confirmed that vectorized mass calculations fails for PowerSphericalPotential. Maybe the right approach here is to just address this in Potential.mass(). Adding list comprehension there should solve this issue while also preventing the issue arising for casual users of PowerSphericalPotential when calculating masses?

I could edit this PR then to go back to simple mass calculation without the try-catch sequence, and then work on the list comprehension in a different PR? Would this then still require a test if that PR would be accompanied by tests for vectorized mass calculations using forceint?

Reproducing mass failure for PowerSphericalPotential() w/ vector:

from galpy import potential
import numpy

pot = potential.PowerSphericalPotential()
rs = numpy.linspace(1,10,num=10)
mass = pot.mass(rs) # Fails -> TypeError during Gauss thm. integration

[jobovy]

I think we should just use the try/except clause in sample and add a quick sampling test using the PowerSphericalPotential potential. There is currently no guarantee that potential functions like mass (or evalautePotential, evaluateRforces, etc.) work with arrays and properly making this work is a bit of work (really should then be for all potential functions, maybe properly deal with multi-dimensional arrays [so difficult w/ list comprehesions]). So I think the best way forward is to just use the try/except clause and just make sure there's a test that hits it.

[jobovy]

Thanks!