Go Down

Topic: Calcul éphéméride précis : lever et coucher de soleil (Read 4528 times) previous topic - next topic

Lancien

J'ai envisagé de faire un tracker solaire basé sur éphéméride. Je me suis donc intéressé à toute cette palanquée d'angles ..
J'ai résumé ce que j'en avais compris sur une feuille OpenOffice.calc.
Au vu de ce que vous avez fait, cette feuille est assez simpliste, mais si elle peut vous être utile.
(En l'ouvrant il faut accepter l'activation des macros)

68tjs

Tu t'es fait avoir par ce forum --> ils ne connaissent pas les fichiers normalisés ISO ils ne connaissent que les bouses microsofts.

Il faut ruser : tu zippe le fichier calc et il sera accepté.

Oui je sais OpenDocument est déjà zippé et zipper un fichier déjà zippé c'est idiot mais c'est comme cela que fonctionne le forum.
J'ai déjà demandé à ce que ce soit modifié : le webmestre semble être un trou noir.

manuetnini

Bonjour

Ce bout de code est mis à dispo pour un usage libre et sans engagement de ma part sur le résultat.
Bien sûr tu peux le modifier pour en faire ce que tu veux.

Ma seule demande est de partager ici avec la collectivité toute amélioration ou correction de ce code, mais ce n'est pas une obligation.

La partie calculs purs a été particulièrement étudiée.
Je serais surpris qu'elle puisse être significativement améliorée.
Par contre elle pourrait être étendue :
- aux calculs des divers aubes / crépuscules
- au paramétrage de la convention de calcul des levers et couchers du soleil. Là, j'ai suivi la convention française appliquée par l'imcce : les calculs sont basés sur l'instant où le centre du disque solaire franchit l'horizon. Dans la plupart des autres pays, il me semble que la convention est de considérer l'instant où le bord supérieur du disque solaire franchit l'horizon (plus naturel pour les calculs d'éclairement).

De plus, une encapsulation propre au sein d'une librairie ne serait pas du luxe.

a+

Salut et merci,
on peut effectivement faire "mieux" en prennant comme tu dis le haut du disque solaire etc etc ... mais franchement, on en est pas a la "minute" pres ! Le but est de connaitre (a mon avis) le décalage le matin, midi et soir, pour adapter une action/temps.
J'ai commencé a modifier ton code en améliorant deux trois trucs bateau, je vais faire une lib au final pour intégration dans mon projet et je posterai ici mes modifs, merci en tout cas.

standardUser

Merci Bricoleau pour ce code.


Pourrais-je connaître l'origine de vos formules.

Pour ma part, j'ai récupéré des formules sur ce site et ai créé le code correspondant en C#.
Mon code étant correct (je l'ai simplifié au maximum pour ne m'en tenir qu'aux formules), je constate une erreur de 12 minutes environ sur l'heure de lever du soleil à partir des formules de ce site.

J'ai trouvé d'autres formules, mais aucune ne donne l'heure correcte en mon lieu, sauf la vôtre !
Je vais donc intégrer certaines parties de votre code dans mon programme C#.

Cordialement.

bricoleau

Oups désolé pour cette réponse tardive

L'origine de mes formules, c'est un savant mélange de tout ce que j'ai trouvé sur le net  :D, que j'ai (à peu près) compris et réassemblé en gardant ce qui me semblait le plus précis.
Le site de Jean-Paul Cornec que tu indiques était effectivement dans mon périmètre d'analyse.

Enfin compris, c'est assez présomptueux. Quand on descend dans la théorie on se retrouve vite dépassé, sauf à avoir bac + xx (deux chiffres) d'études en astronomie, ce qui n'est pas mon cas.

Les diverses équations trouvées sur le net ne sont que des approximations des modèles théoriques (souvent en séries dérivées).

Par endroits, ma compréhension est venue de l'analyse des écarts entre mes résultats et ceux de l'IMCCE.
La mise au point était aussi très expérimentale. Le site de l'IMCCE m'a été très utile pour mesurer la précision des divers calculs.
Je me souviens avoir buté sur une analyse d'écarts pendant une semaine, jusqu'à réaliser qu'il y avait un bug sur le site de l'IMCCE. Pas dans leurs calculs évidemment, mais dans leur affichage des résultats (glissement de colonne).
J'ai même osé leur écrire pour leur signaler le problème. Ils m'ont répondu de manière très sympa et quelques mois plus tard j'ai pu constater que le bug était corrigé.

Pour finir, j'ai procédé à une optimisation purement informatique des calculs (factorisations + précalcul des constantes par le compilo). Ainsi par exemple l'équation du temps ou autre joyeuseté se trouve mélangée à la soupe, et n'apparaît plus clairement dans le code.

Donc on peut dire que c'est une recette 100% bricoleau.

J'y ai quand même passé quelques dizaines d'heures de boulot, la majeure partie dans Excel  :D

a+

bricoleau

Sur la démarche :

J'ai pris 10 points géographiques en référence, répartis sur le globe.
En évitant quand même les cercles polaires, où les équations peuvent ne pas avoir de solution du fait que le soleil ne s'y couche pas ou ne s'y lève pas. Les arduinistes esquimaux n'ont qu'à se débrouiller !

Pour chaque point, j'ai extrait du site de l'IMCCE les levers / méridiens / couchers sur deux ans = 730 jours consécutifs.
Cela me faisait donc une base exacte de plus de 7000 références, rangée dans Excel.

Puis j'ai commencé à tester les diverses formules trouvées en calculant automatiquement leur écart moyen par rapport aux 7000 références.

Le calcul du méridien est le premier élément à ajuster.
Pour le lever ou coucher, les erreurs d'approximation dues aux séries dérivées augmentent avec la valeur absolue de la latitude.
etc.

A la fin j'étais aussi confronté à l'imprécision de l'implémentation des calculs eux-mêmes, utilisant le type "double" en C.
Là en gros, l'imprécision des calculs binaires est du même ordre de grandeur que celle des formules utilisées.
Ainsi, le même programme exécuté sur mon PC ne donne pas strictement les mêmes résultats que sur arduino. La marge d'erreur entre les deux est la même qu'avec la référence IMCCE.

Je pense que pour être plus précis (sans utilité dans notre contexte d'utilisation), il ne serait pas suffisant d'augmenter la complexité des formules (pour prendre en compte le quart de poil de mollet de fourmi). Il serait aussi nécessaire de passer sur des codages de données plus longs. Et encore, en supposant qu'il n'y ait pas de déperdition dans les fonctions trigonométriques proposées en standard.
 

standardUser

Merci pour ces informations.
En tout cas très très beau travail ; le code est hyper-propre et intelligemment structuré.

Le code tel quel fonctionne sans problème sous Mac (environnement Xcode).
Mais je rencontre de gros problèmes de conversion lors du passage en C#. Je dois utiliser des passages en unsafe et pour le moment, les valeurs résultantes sont totalement fausses. Je persiste dans cette voie !

PS : réponse différée, suite à l'absence de réseau téléphonique pendant 5 jours due au passage de la tempête dans le Pas de Calais...

vinceducat

@bricoleau

merci pour cet algo

j'aurai aimeé avec un peu plus de detail notament sur les variable deja calculé...

m0
m1
l0
l1
c0
c1

etc ...

pourrais tu nous donner les hypothese de travail et de calcul de ces valeur, car je n arrive pas a recouper ces valeur avec ce que j'ai trouve dans les algo sur le net

merci d'avance

bricoleau

Bonjour

Il s'agit de ceci
Code: [Select]
  const double M_2PI = 2.0 * M_PI;
  const double degres = 180.0 / M_PI;
  const double radians = M_PI / 180.0;
  const double radians2 = M_PI / 90.0;
  const double m0 = 357.5291;
  const double m1 = 0.98560028;
  const double l0 = 280.4665;
  const double l1 = 0.98564736;
  const double c0 = 0.01671;
  const double c1 = degres * (2.0*c0 - c0*c0*c0/4.0);
  const double c2 = degres * c0*c0 * 5.0 / 4.0;
  const double c3 = degres * c0*c0*c0 * 13.0 / 12.0;
  const double r1 = 0.207447644182976; // = tan(23.43929 / 180.0 * M_PI / 2.0)
  const double r2 = r1*r1;
  const double d0 = 0.397777138139599; // = sin(23.43929 / 180.0 * M_PI)
  const double o0 = -0.0106463073113138; // = sin(-36.6 / 60.0 * M_PI / 180.0)



Je passe celles de conversion degrés / radians

Pour le nom des constantes, je me suis inspiré de leur nom usuel que l'on trouve dans les formules
m0/m1 famille M (anomalie)
l0/l1 famille L (longitude ecliptique)

Je pense que tu trouveras ton bonheur tout simplement en recherchant ces valeurs constantes sur google (par ex cherche 357.5291)

Pour te donner un aperçu de leur signification, voir par exemple le second post de ce topic d'un autre forum.

Pour les constantes issues d'une formule de calcul, au lieu de mettre la valeur en dur, j'ai préféré laisser le compilateur faire le calcul.
Cela revient au même code exécutable généré, mais c'est plus compréhensible en retro analyse.

Par contre le compilo ne sait pas évaluer les fonctions trigonométriques, donc pour celles-ci j'ai du mettre directement la valeur en dur, en prenant soin d'indiquer la formule utilisée en commentaire sur la ligne.

vinceducat

@bricoleau

merci pour ces infos le lien vers le post futura est ce que je cherchais....

une autre question ...

j adapte ce code pour une automate programmable siemens s7-400

peux tu me confirmer que fmod est bien le reste de la division ....

que l expression >>2 est bien un decalage vers la droite de 2 bit donc une division entiere par 4.

que la valeur lever coucher est une valeur entre -0.5 et 0.5 correspond a une valeur qui faudra utiliser pour calculer les heure de lever et coucher .

qu il faut suite effectue le calcul pour replacer cela en heure tenant compte du decalage horaire et de la gestion heure ete heure hiver


merci d avance...


vinceducat

@bricoleau

j ai trouve ta fonction afficherheure ....  :smiley-confuse:


pour la conversion d vers hh:mm:ss

vinceducat

@bricoleau

j'ai code tu algo dans mon api, mais j'ai un gros ecart entre les valeur que je calcule et les valeur recuperer sur le net pour controle que tout va bien environ 40 m d'ecart !!!!

pour mes calcul j'utilise des variable float qui sont sur 32 bits dans mon api

dans l'arduino le double est t il sur 32 ou 64 bits ? il semble que se soit 64bits.

penses tu que cela explique le decalage de 40min ???

Merci

vinceducat

@bricoleau

pour pouvoir confirmé pourrai tu me communiquer la valeur de lever et coucher pour le 19 08 2016

merci afin de voir s'il s'agit d'une erreur de precision ou autre

Cordialement

vinceducat

@bricoleau


j'ai trouvé mes erreur : la longitude en une longitude ouest il fallait donc que je paramete -2.xx et non 2.xxx

et j'avais egalement une erreur lors de la conversion en hh mm ss a cause d'une conversio  reel vers entier ou je faisait un arrondi plutot que recupere la partie entiere ....


je dois encore relire tout cela et nettoyer mon code ...

j'ai pour le 18 08 16 2 minute d'ecart pour le lever et 1 pour le coucher....

merci pour ce bel exemple


vinceducat

info ... pour les curieux


sur le site  http://www.ecy.wa.gov/programs/eap/models.html



vous trouverez un fichier excel avec macro ... et tous les algo ... pour calcul sunset sunrise ...etc ...

calcul excel complet .....

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy