Astropy: les images avec des vitesses et une représentation "unitaire" ne parviennent pas à convertir en cartésien

Créé le 23 déc. 2017  ·  3Commentaires  ·  Source: astropy/astropy

Certains des tests de cas de coin dans #6944 ont révélé un comportement problématique pour les trames qui ont des vitesses où la représentation réelle est UnitSpherical . Il s'avère que c'est vrai. Les cas ci-dessous illustrent le problème :

Notez également que si #6944 est fusionné, il dispose de quelques emplacements avec des solutions de contournement pour ce bogue. Si ce bogue est corrigé, ces solutions de contournement doivent être supprimées (recherchez dans le sous-package coordinates #7028 pour les trouver).

Cela marche:

>>> f = ICRS(1*u.deg, 2*u.deg)
>>> f.cartesian
<CartesianRepresentation (x, y, z) [dimensionless]
    ( 0.99923861,  0.01744177,  0.0348995)>

Mais ces deux cas ne le font pas :

>>> f = ICRS(1*u.deg, 2*u.deg,
          pm_dec=1*u.mas/u.yr, pm_ra_cosdec=2*u.mas/u.yr, radial_velocity=10*u.km/u.s)
>>> f.represent_as('cartesian', in_frame_units=True)
UnitConversionError: 'mas / (rad yr)' (frequency) and 'km / s' (speed) are not convertible
>>> f = ICRS(1*u.deg, 2*u.deg, 
                pm_dec=1*u.mas/u.yr, pm_ra_cosdec=2*u.mas/u.yr)
>>> g = f.transform_to(GCRS)
>>> g.cartesian
UnitConversionError: '1 / s' (frequency) and 'km / s' (speed) are not convertible

Il est probablement un indice utile que dans le second cas à défaut, f.cartesian fonctionne, mais quelque chose dans la transformation de GCRS est ce qui ne commencent. Il est possible qu'il s'agisse de problèmes subtilement différents, mais ils sont suffisamment proches pour qu'ils doivent probablement être résolus ensemble.

@adrn ou @mhvk , une idée de ce qui se passe ici ? On pourrait soutenir qu'au moins l'étape de transformation ci-dessus est quelque peu mal définie, mais on devrait toujours pouvoir sortir la représentation cartésienne même si les unités sont un peu étranges...

Bug coordinates

Tous les 3 commentaires

Salut @eteq ,

J'essayais de travailler sur ce problème. Mais dans le cas de l'exemple,


>>> f = ICRS(1*u.deg, 2*u.deg,
          pm_dec=1*u.mas/u.yr, pm_ra_cosdec=2*u.mas/u.yr, radial_velocity=10*u.km/u.s)
>>> f.represent_as('cartesian', in_frame_units=True)

L'exemple ne contient pas de distance , mais plutôt un radial_velocity . Je n'ai pas compris ce que cela signifie exactement. Aussi, si je mets un peu de distance dans le cadre, ça marche parfaitement !

Pouvez-vous s'il vous plaît me faire comprendre le problème, je suis confus.

@shreyasbapat Pourriez-vous s'il vous plaît essayer de voir si https://github.com/astropy/astropy/pull/9064 résout ce problème ? (Edit : ce n'est pas le cas)

9086 m'a rappelé ce problème. Pour les deux cas :

Pas de distance mais avec RV

>>> f = ICRS(1*u.deg, 2*u.deg,
          pm_dec=1*u.mas/u.yr, pm_ra_cosdec=2*u.mas/u.yr, radial_velocity=10*u.km/u.s)
>>> f.represent_as('cartesian', in_frame_units=True)
UnitConversionError: 'mas / (rad yr)' (frequency) and 'km / s' (speed) are not convertible

Je pense que celui-ci est insoluble : sans distance, on ne peut pas convertir un mouvement propre en vitesse spatiale, ou une vitesse spatiale en vitesse agulaire. Donc, je pense que pour ce cas, nous devons simplement nous assurer que le message d'erreur est plus clair (déclenché par un camping-car mais pas de distance).

RV introduit par transformation de coordonnées

>>> f = ICRS(1*u.deg, 2*u.deg, 
                pm_dec=1*u.mas/u.yr, pm_ra_cosdec=2*u.mas/u.yr)
>>> g = f.transform_to(GCRS)
>>> repr(g)
# error
>>> g.data
<CartesianRepresentation (x, y, z) [dimensionless]
    (0.99923901, 0.01742676, 0.03489572)
 (has differentials w.r.t.: 's')>
g.data.differentials
<CartesianDifferential (d_x, d_y, d_z) in 1 / s
    (6.07736084e-13, -1.85772092e-11, -8.12625661e-12)>

C'est un peu plus subtil. Sans mouvement propre, g est UnitSpherical , ce qui est logique, et ici ça devrait l'être aussi, donc il y a quelque chose qui ne va pas avec la transformation. Pour être complet, le représenter sur la sphère unité fonctionne :

g.represent_as('unitspherical')                                                               
Out[24]: 
<UnitSphericalRepresentation (lon, lat) in rad
    (0.01743826, 0.0349028)
 (has differentials w.r.t.: 's')>

In [25]: g.represent_as('unitspherical').differentials['s']                                            
Out[25]: 
<UnitSphericalDifferential (d_lon, d_lat) in rad / s
    (-1.85963079e-11, -8.13120751e-12)>

Mais même ainsi, g.cartesian devrait fonctionner aussi - ici, le problème est que les cadres décident pour l'utilisateur quelles unités sont sensibles, insistant sur le fait qu'une vitesse cartésienne est en km/s (bien sûr, cela remonte à ma plainte de longue date selon laquelle les unités de coordonnées dans la représentation sont décidées pour moi...) : https://github.com/astropy/astropy/blob/c3dc7b38303b3615945aa36a11ebf7bd31d5cc0a/astropy/coordinates/baseframe.py#L1744 -L1753

Les unités elles-mêmes sont obtenues à partir de :

g.representation_info
{astropy.coordinates.representation.CartesianRepresentation: {'names': ['x',
   'y',
   'z'],
  'units': [None, None, None]},
 astropy.coordinates.representation.UnitSphericalRepresentation: {'names': ('ra',
   'dec'),
  'units': (Unit("deg"), Unit("deg"))},
 astropy.coordinates.representation.RadialRepresentation: {'names': ['distance'],
  'units': [None]},
 astropy.coordinates.representation.SphericalRepresentation: {'names': ('ra',
   'dec',
   'distance'),
  'units': (Unit("deg"), Unit("deg"), None)},
 astropy.coordinates.representation.PhysicsSphericalRepresentation: {'names': ['phi',
   'theta',
   'r'],
  'units': [Unit("deg"), Unit("deg"), None]},
 astropy.coordinates.representation.CylindricalRepresentation: {'names': ['rho',
   'phi',
   'z'],
  'units': [None, Unit("deg"), None]},
 astropy.coordinates.representation.CartesianDifferential: {'names': ('v_x',
   'v_y',
   'v_z'),
  'units': (Unit("km / s"), Unit("km / s"), Unit("km / s"))},
 astropy.coordinates.representation.UnitSphericalDifferential: {'names': ('pm_ra',
   'pm_dec'),
  'units': (Unit("mas / yr"), Unit("mas / yr"))},
 astropy.coordinates.representation.SphericalDifferential: {'names': ('pm_ra',
   'pm_dec',
   'radial_velocity'),
  'units': (Unit("mas / yr"), Unit("mas / yr"), Unit("km / s"))},
 astropy.coordinates.representation.UnitSphericalCosLatDifferential: {'names': ('pm_ra_cosdec',
   'pm_dec'),
  'units': (Unit("mas / yr"), Unit("mas / yr"))},
 astropy.coordinates.representation.SphericalCosLatDifferential: {'names': ('pm_ra_cosdec',
   'pm_dec',
   'radial_velocity'),
  'units': (Unit("mas / yr"), Unit("mas / yr"), Unit("km / s"))},
 astropy.coordinates.representation.RadialDifferential: {'names': ['d_distance'],
  'units': [None]},
 astropy.coordinates.representation.PhysicsSphericalDifferential: {'names': ['d_phi',
   'd_theta',
   'd_r'],
  'units': [None, None, None]},
 astropy.coordinates.representation.CylindricalDifferential: {'names': ['d_rho',
   'd_phi',
   'd_z'],
  'units': [None, None, None]}}

On voit ici que CartesianDifferential est le seul qui est faux, c'est parce qu'il a des unités préférées définies du tout.

Ce qui signifie probablement que le correctif dans #9086 est OK avec une petite modification : il faut essayer d'aller aux unités demandées mais ne pas se soucier si cela échoue.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

pllim picture pllim  ·  3Commentaires

embray picture embray  ·  3Commentaires

funbaker picture funbaker  ·  3Commentaires

simontorres picture simontorres  ·  3Commentaires

JWDobken picture JWDobken  ·  3Commentaires