Franta (Neděle 8. ledna 2017)  ⇑

ZH:asi tak nějak jsem si výstup pro Horizons představoval. Jen bych si asi nechal vypočítat celý rok :-), ale asi je to zbytečné.
Lišíme se asi parametrem
$mail_body .="R_T_S_ONLY = 'GEO'n";
který jsem tehdy převzal z vzorového příkladu. To TVH, které tam máte nastavené Vy, tedy: True visual horizon... vypadá dobře, to "Allows for horizon dip effect" působí jako více přiblížené reálné situaci
Moje všechny udaje tady byly pro parametr GEO.

TVH ... True visual horizon plane. The horizon seen by an observer on
the reference ellipsoid. Allows for horizon dip effect and
refraction, but not local topography.
GEO ... Geometric horizon plane. The horizon is defined by the plane
perpendicular to the reference ellipsoid local zenith (no
horizon dip). Refraction is allowed for.

Odpovědi jsem nechával posílat na gmail a obvykle přišly maily rychle, občas byly v doručení prodlevy

Franta (Neděle 8. ledna 2017)  ⇑

Byl jsem doteď mimo internet, takže jen stručně. Tabulky jsem dal prostě k sobě a zkontroloval, že na jednom řádku bylo stejné datum jak z Horizons, tak z Azora. První graf, který jsem namaloval byl takový, že jsem vynesl oboje vypočtené hodnoty. Jednak byly ty dvě čára hodně blízko sebe a pak se postupně od sebe vzdalovaly, a z jejich vzhledu jsem si myslel, že moc nevyjadřují to zrychlení v přísluní - koncen roku se ty křivky zase přibližovaly, a i vizuálně to vypadalo jako posunuté.
viz

ZH (Neděle 8. ledna 2017)  ⇑

Nakonec jsem udělal výstup z Azoru do Horizons pomocí mailu, jak navrhoval Franta.
Je to úplně dole v Celestial Sféře (po kliknutí na časový údaj určitého dne v hlavní tabulce Azoru). Snad je to zajištěné proti robotům.

Důležité jsou mailem obdržené řádky jako tento (někde v polovině mailu):
0530-Dec-19 05:33,*,r,19 27 12.61,-22 06 38.0, 121.7233, 0.1840......
kde tuším sedmý údaj je azimut.

Výsledek přijde okamžitě, ale na mé druhé adrese na centrum.cz se čeká třeba hodinu.

ZH (Neděle 8. ledna 2017)  ⇑

Franta: už jsem pronikl do emailového zadání, tak se tím nemusíte zabývat. Zatím mi tedy výsledek nepřišel, ale soudě podle latence zaslání informací to asi chvíli trvá.

ZH (Neděle 8. ledna 2017)  ⇑

Obávám se, že odchylky můžou být podstatně větší, myslím, že to není až tolik, jak psal Franta, mně vychází maximální odchylka 0.6° – viz – pro Istanbul v r. 530, pokud jsem ponechal převýšení v Azoru a v Horizons nastavil elevaci 0.34°.
Konkrétně 19.12.530 juliánského kalendáře (slunovrat) je dle Horizons východ Slunce (první paprsek) při elevaci obzoru 0.34° v azimutu 121.7°.
(0530-Dec-19 05:33,*,r,19 27 12.61,-22 06 38.0, 121.7233, 0.1848, ).
Azor ukazuje 121.28 pro 20.12. Celestial Sfere (integrovaná do Azoru) ukazuje 121.85°.

Bohužel s tím už nic nenadělám, leda, jak psal Franta, krom Celestial Sfery ještě udělat z Azoru vstup do Horizons.

Jan Cinert (Neděle 8. ledna 2017)  ⇑

Jako obvykle se ze známých důvodů do průběhu diskuze nemohu míchat.

S možným vlivem perihélia/afélia (sv. Lucie noci upije) mne to napadlo již po 16. 4. t.r., kdy jsme o záležitosti poprvé (myslím si) diskutovali. Tehdy jsme nějak došli k tomu, že vliv je minimální. Ale nějak laicky mi něco říká, že když tehdy právě nevěděli Keplerovy poznatky o oběhu po elipse, tak by možná mohli používat nějaký poznatek/pomůcku, díky níž by pak měli azimut větší/menší.

Pochopil jsem správně, že pro mne je zatím směrodatný praktický výsledek rozdíl mezi Azorem a Horizons je 0,015°?

ZH (Neděle 8. ledna 2017)  ⇑

PS: koukal jsem na dispozice k mailovému dotazu, to bych se asi hodně natrápil, kdybych to chtěl vyladit, Vy už to máte předpřipravené a máte představu, jak to zabudovat do Azoru (tj. pro každý den tlačítko RTS, pak by zadavatel zapsal svou adresu, automaticky by se tam vložila výška stanoviště a altituda?). Pokud mi to pošlete jako modul, tak by to pro mě asi nebyl problém.

ZH (Neděle 8. ledna 2017)  ⇑

Zpochybňování: já vím, že to tak nemyslíte a krom toho je to jen dobře, nakonec, i když mám náhodou pravdu, aspoň se trochu udržuju ve formě.
Je fakt, že jsem si toho tenkrát naložil moc najednou, jak astronomickou, tak počítačovou agendu a spoustu přídatků. Pustil jsem se do toho, protože jsem Vás nechtěl honit, když jsem tam chtěl nové funkce. Nelituju, protože jsem se při tom hodně naučil.
Všiml jsem si vaší sinusoidy s rozdíly H-A, teď jsem to zkoušel taky, ty výchylky jsou větší kolem rovnodennosti, kde Slunce po obzoru utíká rychlými kroky. V gregoriánském období jsou odchylky podstatně menší, napadlo mě, jestli jste zohlednil, že tabulka v Azoru v juliánském období začíná prvním lednem odpovídajícího gregoriánského data, tedy v r. 530 by se měla počítat až od 3. řádku, tedy prvního ledna juliánského kalendáře. Pak jsou rozdíly podstatně menší.
Pamatuju si několik nedodělků, které mohly z působit drobné odchylky do půl stupně na obzoru, ale je tam ta kontrola podle integrované Celestial sféry.

S tím mailem je to dobrý nápad, ale já jsem to nikdy nepoužil, tak o tom nic nevím. Ale jak se znám začne mi to vrtat hlavou, tak se na to možná kouknu. Otázka je, jestli výsledky budou všeobecně srozumitelné (vyběhne z toho změť čísel s anglickými zkratkami).

Franta (Sobota 7. ledna 2017)  ⇑

ZH: Možná by šlo dodělat do Azora export zadání pro Horizons. Myslím tím, že by se vygenerovalo emailové zadání a odeslal by se email pro výpočet v Horizons. Jediné, alespoň, co si myslím, by bylo potřeba domyslet jak se v Horizons posune obzor směrem nahoru - myslím to převýšení obzoru, které jsem v tom mém příkladě nahradil nulovou výškou stanoviště a nulovým převýšením obzoru. V zadání je parametr RTS elevation, který je standardně nastaven na RTS elevation : 0. degrees - tam by mělo být asi to převýšení skutečného obzoru, které Azor vypočítává. V zadání souřadnic je i výška stanoviště:
Center geodetic : 28.9800890,41.0083750,0.0000000{Elon(deg),Lat(deg),Alt(km)}
Když posílám emaily s dotazem na výpočet, používám na to celkem triviální PHP skript - nechtělo se mi zadávat údaje ručně takže jsem si našel to emailové zadání, ve kterém měním jenom souřadnice a těleso, kterého se to týká, tedy v mém případě Slunce a Měsíc, skript vygeneruje obsah emailu. Volám ho s jedním parametrem, kterým je rok pro který se to má vypočítat. Parametrů by se dalo zadávat samozřejmě mnohem víc, já ty ostatní parametry měním přímo ve zdrojovém kódu. Dělal jsem to pro roční výpočty poloh Měsíce v 19 letém cyklu, takže jsem obvykle zavolal 20x skript, kde jsem v adrese měnil jen parametr pro rok a přišlo mi 20 emailu s daty pro zvolené roky.

Myslím si, že snad jsou parametry, které jsem zadal v pořádku.

To zpochybňování , o kterém píšete je asi silné slovo. Ta má první verze se s Azorem nedá srovnat. Takže jako pomůcka je to asi velmi dobré. Jak jste přidával další vylepšení, přestal jsem držet s vývojem krok. Zpochybňovat, nebo hodnotit by to mohl nějaký astronom, můj názor, ale vždy byl, že pokud se výpočty mají použít jako seriozní podklad pro nějaké tvrzení bylo by dobré odvolat se nějakou uznávanou autoritu, kterou NASA bezpochyby je, bez ohledu na to jestli to Azor také počítá správně.

ZH (Sobota 7. ledna 2017)  ⇑

Asi máte pravdu.
Ono je Sunrise definováno jako okamžik, kdy se v atmosférickém modelu dotkne horní okraj Slunce horizontu, tedy je v tomtéž časovém okamžiku i skutečná poloha Slunce v témže azimutu. Už jsem to pozapomněl (jednou jsme to už probírali a myslel jsem, že je to okamžik přechodu středu tělesa pro právě ten který model.

Opravdu se tedy Azor liší od Horizons, ty jsou jistě přesné.
Je to betaverze, ale s takovým odstupem s tím už asi nic nenadělám. Jak jsem dávno říkal, když to Franta právem zpochybňoval, všechno kontrolujte přes Horizons...

Franta (Sobota 7. ledna 2017)  ⇑

Já se na to koukám tak, že Horizons uvádí značku "r", tedy Rise, pro čas kdy Slunce uvidíme - tedy v modelu s atmosferou nebo bez atmosfery je to ve stejný čas. Jednomu času odpovídá jeden azimut. Slunce je fyzicky 0,7546 stupně pod horizontem. Atmosferu máme pořád a ta způsobí, že "vidíme za horizont". To nahlédnutí za horizont se ve výsledcích projeví tak, že se Slunce posune kolmo vzhuru na výšku -0,1499 stupně, tedy celá jeho dráha se posune, to v modelu s atmosférou. Protože má úhlovou šířku asi půl stupně, tedy průměr, a jeho střed je 0,15 stupně pod horizontem, tak z té poloviny, asi 0,25 stupně už něco vykukuje nad horizont. Refrakce deformuje i vlastní obraz slunečního kotouče. Samozřejmě je jeho dráha šikmá, ale refrakce způsobí při horizontu její nadzvednutí, a to je dle mého, kolmo vzhůru. Představuji si to tak, že u horizontu je dráha Slunce přímková šikmo vzhůru. Refrakce do urřité výšky od horizontu způsobí jakoby její vyboulení směrem vzůru.

Takže souhlasím s Vaším závěrem, že "když je střed Slunce v modelu bez atmosféry přesně na horizontu, je pro pozorovatele už dávno vyšlé", ale model bez atmosféry nelze prakticky použít, protože tam ta atmosféra pořád je. Tedy východ Slunce nemůže být v okamžiku, kdy je fyzicky střed Slunce přesně na horizontu. Horizons tvrdí, že je to tehdy když je SLunce fyzicky 0,7546 stupně pod horizontem. Podle toho Vašeho zadání. Při tom mém se výsledky trochu liší - mám 0,1356 stupně pod horizontem, kdežto Vámi uváděný příklad má -0,1499 stupně.

ZH (Sobota 7. ledna 2017)  ⇑

Možná nemám den, ale podle mě, když je střed Slunce v modelu bez atmosféry přesně na horizontu, je pro pozorovatele už dávno vyšlé, ovšem protože vychází šikmo, je v tu chvíli už v jiném azimutu.

Franta (Sobota 7. ledna 2017)  ⇑

Omlouvám se, nějak dlouho čekám na odezvu při klinutí na "Odeslat" a tak to někdy nevydržím a kliknu ještě jednou v domnění, že se to poprvé nepovedlo a pak jsou z toho příspěvky dva

Franat (Sobota 7. ledna 2017)  ⇑

ZH: myslím to tak, že Horizons nám udávají, kdy Slunce uvidíme. Když si zvolime model s atmosférou ukáží nám jeho výšku ovlivněnou atmosférou, model bez atmosféry nám ukáže neovlivněnou výšku.

Franta (Sobota 7. ledna 2017)  ⇑

ZH: Slunce je fyzicky 0,7545 stupně pod horizontem v azimutu 121.3135, kdybychom neměli atmosféru nebylo by vidět. Protože atmosféru máme je zdánlivě jen 0,1499 pod obzorem a vidět je. Protože se jedná o stejný okamžik, je stejný i azimut. V čem je tedy ten problém?