Calculateur de durée de transit d'exoplanète

Les valeurs non positives du demi-grand axe échouent avec invalid_input car elles ne définissent pas d'orbite fermée physique pour cette formule.

Ce que signifie la durée d'un transit central et ce que contient la réponse

La durée de transit est le temps qu'une planète passe devant son étoile vue par un observateur lointain, mesuré du premier au quatrième contact lorsque la corde stellaire complète est considérée sous le modèle géométrique simple. Pour une orbite circulaire avec un transit parfaitement central le paramètre d'impact est zéro, la trajectoire de la planète traverse le centre du disque stellaire et, lorsque le rayon planétaire est négligé par rapport à l'étoile, le demi-angle de corde se réduit à l'arcsin de R-star sur a. Multiplier cet angle par la période orbitale sur pi récupère la durée complète dans la même unité de temps que la période. Cette capacité prend la période en jours — l'unité de la plupart des catalogues d'exoplanètes — et multiplie la durée en jours par vingt-quatre afin que le champ principal duration_hours corresponde à la façon dont les observateurs citent les événements de Jupiter chauds et de super-Terres. La réponse renvoie les entrées nettoyées period, stellar_radius et semi_major_axis, signale radius_over_a pour des contrôles rapides et inclut duration_days et duration_minutes pour les feuilles qui préfèrent ces unités. Le champ small_angle_hours montre l'approximation linéaire obtenue en remplaçant arcsin de x par x, précise lorsque l'étoile est beaucoup plus petite que la séparation orbitale. Les chaînes method et formula documentent que le chemin est central_transit avec circular_orbit_b0_rp_neglected afin que les clients ne confondent pas cette estimation avec un ajustement complet de courbe de lumière Mandel–Agol. Il n'y a ni consultation réseau de catalogues stellaires ni tirage Monte Carlo de paramètres d'impact : soit les trois nombres définissent un transit central valide et le moteur renvoie des flottants déterministes, soit la requête échoue avec invalid_input en nommant la règle géométrique ou de positivité violée.

Contrat d'entrée, unités et comportement d'erreur

Les rayons solaires pour R-star et a sont courants lorsque vous convertissez a depuis des unités astronomiques via le rayon solaire en AU ; les mètres conviennent également si les deux champs sont en SI. Associez la réponse à vos propres corrections d'inclinaison ou de rayon planétaire si votre cas scientifique l'exige ; ce point de terminaison ne répond qu'à la réécriture centrale, circulaire et à Rp négligé. Envoyez par POST un corps JSON avec trois nombres finis obligatoires : period, la période orbitale en jours strictement supérieure à zéro ; stellar_radius, le rayon de l'étoile hôte dans l'unité de longueur de votre choix ; et semi_major_axis, le demi-grand axe orbital dans cette même unité. Chaque champ peut arriver comme nombre JSON ou comme chaîne numérique ; champs manquants, chaînes vides, NaN et Infinity échouent avec invalid_input. La règle produit à retenir est que semi_major_axis doit être positif : zéro et les négatifs sont rejetés avec un message clair indiquant qu'un demi-grand axe non positif n'est pas physique pour une géométrie de transit fermée, et ces échecs ne sont pas facturés. period et stellar_radius doivent aussi être positifs. Si stellar_radius est supérieur ou égal à semi_major_axis, le rapport R-star sur a quitte l'intervalle unitaire ouvert et l'arcsin n'est pas défini pour une corde centrale réelle, donc le gestionnaire rejette le cas au lieu de renvoyer NaN. Exemple : period égal à 3.5 jours, stellar_radius égal à 1 et semi_major_axis égal à 10 donne radius_over_a égal à 0.1 et une durée d'environ 2.68 heures, la référence à petit angle étant un peu plus courte comme prévu.

Où une API de durée de transit d'exoplanète apporte de la valeur

Les développeurs alimentent tests unitaires et vérifications de propriétés avec des valeurs déterministes de duration_hours afin que la CI échoue si quelqu'un remplace arcsin par un facteur linéaire par accident. Comme l'implémentation est parse pure de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant.