VReijs

By the way, the improved page of Larry Bogan (at least according to my knowledge) is here: http://www.archaeocosmology.org/eng/vislimit-Bogan-vr.htm <it coefficient="" wrongly="" that="" astronomical="" an="" does="" behave="" have="" error="" not="" the="" extinction="" makes="">.</it> On Wed, 27 Jan 2021 at 21:28, Andrey Nakin andreynado@users.sourceforge.net wrote: Hello Georg. Please execuse my long silence, I was trying to find the articles mentioned. I only managed to find a poor quality copy...

Hello Andrey, Swiss Ephemeris is an open source program indeed. But it is a C library, so no nice GUI as Stellarium. All the best, Victor On Thu, 28 Jan 2021 at 00:19, Andrey Nakin andreynado@users.sourceforge.net wrote: Hello Victor! It would be great to have a copy of the 2000 year article. I've send you a message (via SF messenger) with my private e-mail. Thanks a lot! BTW is Swiss Ephemeris an open-source project? Formulas for a limiting apparent magnitude https://sourceforge.net/p/stellarium/discussion/278769/thread/af0ceb4a2f/?limit=25#1416/5d4a/cc70/9df2...

Hello Andrey, The 2000 article is the best (according to Schaefer himself also). But it has (still) some errors in it (as I discussed these with Brad Schaefer): http://www.archaeocosmology.org/eng/archxv.htm ) http://www.archaeocosmology.org/eng/archxv.htm S&T code en Bogan javascript have gotten a new error (IMHO) between 2002 and 2016 (compared to Schaefer 2000): KA=KAMath.pow((1-.32/Math.log(RH/100.0)),1.33)(1+SLMath.sin(RA)); which should be (according also to Schaefer): KA=KAMath.pow((1-.32/Math.log(RH/100.0)),1.33)(1+0.33SL*Math.sin(RA));...

Hello Georg I am interested to help (I gave a year ago some feedback on the Stellarium code, I think). But if wanted I am willing to help (but coding in C [or a larger programming environment] is not something I want to do;-) I can check code and give constructive feedback on results, etc. All the best, Victor On Sun, 24 Jan 2021 at 13:23, gzotti gzotti@users.sourceforge.net wrote: Ah, thanks. I agree there are some typos/unclear differences/bugs between the 1993 and other of his works, and also...

I think his latest article is better (Schaefer's texts and code can have some small bugs): Schaefer, B.E. New methods and techniques for historical astronomy and archaeoastronomy Archaeoastronomy, Volume XV [2000], pages 121-135 <see <span="" my="" comments="">[and checked with Schaefer] here: http://www.archaeocosmology.org/eng/archxv.htm ></see> All the best, Victor On Sat, 23 Jan 2021 at 22:49, gzotti gzotti@users.sourceforge.net wrote: Most relevant may be this: @Article{Schaefer:Limits, author...

Don;t look at the date, look at the Julian day number! What do you see then? Or only use proleptic Gregorian calendar. I can't imagine there is an error, so I hope it is related to the date... (and not the Julian day number). All the best, Victor On Tue, 3 Nov 2020 at 10:27, "Victoriano Canales Cerdá" nanocanales@users.sourceforge.net wrote: Hi, The problem is not in the date. If you put the date of the autumn equinox of 1582 and 1583, you will see that at sunrise there is a difference between the...

Did you use julian date, as you also close the change over from Julian to Grgorian calendar. Using the Julian Day Number input is perhaps better. Using the proleptic Gregorian calendar would keep the equinox day around 21 september, otherwise in the Julian calendar the autumnal equinox will be on another day (that is why they introduce the gregorian calendar;-). Check the declination of the Sun (should be zero on equinox day). All the best, Victro On Tue, 3 Nov 2020 at 01:46, "Victoriano Canales...

I am glad you now recognised it. Indeed the proleptic gregorian calendar is perhaps a month out from the proleptic julian calendar. It is always a discussion about what to use in the past (as no calendar is correct as it is unknown what they used back then;-). Best is perhaps using the Julian Day Number... In some way the proleptic Gerogorian calendar is the nicest (as it keeps the solstice/equinox more or less in sink (but of course not fully over long periods of time). But using that needs a decision...