Hello
I think there is serious bug in Uranus moons data (code?). While Titania and Oberon positions seems to be accurate, then other 3 moons are in random place - especially Miranda is faar away from planet...
Look at attachement screenshot and photo taken by me at 14.09.2021 22:40 UT. For example stellarium shows correct data.

btw, I've updated debian package for Ubuntu/Debian


W dniu 14.09.2021 o?14:44, Martin Federspiel pisze:

--
?ukasz Sanocki

You can do things like:

Also thanks to all who contributed. Finally the downloads work again!

To successfully compile "with static linking on Apple using X11 libs from ports" I had to add "-lssl" to line 47 of the Makefile which read now reads
LIBS = $(XLIBS) $(LIBLIB) -lm -lssl.
Obviously, I also uncommented that section and commented out the previous one ("for linux and Apple OS X")

Best,
Randolf

Hi to everyone, who contributed to version 4.1.0, and a huge thank you! That updates XEphem significantly. The quality of the updated positions of the Galilean moons can be checked e.g. by comparing Christopher Go's series of images of a triple transit of Callisto, Ganymede, and Europa on Aug 15th, 2021 (see ) with XEphem. During the transit there was also an occultation of Europa by Ganymede and a partial eclipse of Europa by Ganymede a few minutes later. All that is well reproduced by XEphem 4.1.0, whereas earlier versions didn't get the mutual events well.

Since openssl support is now included in 4.1.0, I had to install libssl-dev on my Ubuntu 20.04 system to get 4.1.0 compiled.

Thanks again and best regards,

Martin Federspiel

开云体育

Yes, SSL and more was merged on 4.1 release ...
Serge.

Are you planning to merge SSL-patch in 4.1? At Github patch seems to be revied by rmathar
On Elwood old site the are some contributions

I think most of these should be included in official version

I think that catalogs should have separate repo

regards,

On Fri, 10 Sep 2021, Brandon Rhodes wrote:

But I suppose something should be done for folks who look for official releases rather than seeking out the latest version of the source code!
?1. As he's stated before on this list, Elwood has made his final release.
?2. I'll therefore this weekend go ahead and mark the most up-to-date version of the source as 4.1, since fixing the expired moon models seems like the kind of user-visible
??? improvement that would warrant a bump of the middle version number. That will let folks see it on GitHub as version "4.1" and download a ZIP file that's properly
??? labeled as "4.1".
?3. I'll improve the README to point out where releases are listed on GitHub so folks don't have to discover that themselves.
?4. In case anyone looks there, I can update the table of source releases on the GitHub copy of the web site at:
???
?5. But that leaves a gap: what about folks who look directly at the legacy XEphem page, which will forever list 4.0.1 as the most recent version at?clearskyinstitute.com’s
??? “Free Download” link? I’ll defer here to Elwood as to how and whether that might be remedied. An elegant solution for the moment might be to have the XEphem web site
??? frame load the page at its new GitHub URL when the user clicks “Free Download” — or, clearskyinstitute.com might redirect the old “download.html” to the GitHub one, so
??? that even folks who link directly to "download.html" and skip the front-page-frame see an updated page. Or, there are doubtless other approaches that I'm not thinking
??? of.

-- 
Serge Montagnac + GPG Key 0xDF083D7B + 
  Nature, Not Human Activity, Rules the Climate.

That's totally awesome! Thanks to everybody contributing!

Users! Done.

I notice ?has the link removed. Here is what mine looks like:

On Mon, Sep 13, 2021 at 10:13 AM, Brandon Rhodes wrote:

Though, alas, it looks like the #1 Google search result for "XEphem" is??which is not yet a redirect. I don't have any quick recommendation to make because I'm not sure of the historical difference between index.html and xephem.html there.

They now both refer to reader to github.

I've added:

• Execpt?for the "gsc/*" directory, because it's not only heavy megabyte-wise but because it contains so many individual files that version control slows to a crawl. Hopefully it's redundant and folks can use the big star catalog instead? If not, then maybe we could commit a .tar.gz of it to version control and at least avoid the number-of-files problem. Let me know which course would be best.

They are complementary, not redundant. gsc goes to about visual magnitude 15. That cutoff was made, in part, so it would fit on what was the core DVD. The two large supplement GSC sets start at this magnitude and go to about mag 20.

Are you planning to merge SSL-patch in 4.1? At Github patch seems to be revied by rmathar
On Elwood old site the are some contributions

I think most of these should be included in official version

I think that catalogs should have separate repo

regards,

--
?ukasz Sanocki
AP-Media

So cool Brandon !! Thanks.

For what it's worth: the xephem.man page in XEphem-4.0.2.tar.gz still calls itself version 3.7.

开云体育

Just an advice ....

Update your source is enough, there are not any file correction to do from github sources.
Serge.
?

Thanks to Maxime's identification of the moon files I took the following four steps locally on my own computer and it works.

I would be grateful if one of the experienced Git-hub users would place it into the repository, assuming you agree.

?- Bernie


I.
Obtain the the new *.2040 files from? and place them into XEphem's auxil/ directory.

II.
IMPORTANT:? uranus.2040 seems to have a small problem in the line 1 header.? Missing are some spaces needed to separate several field entries.? Change line 1 from this:
????7 5??? 2?? 31?? 62?? 95?? 131? 2.4930? 1.5162? .7217? .4667? 4.4880 258.0242.0223.0206.0 41.0 309???? 2458849.500 2020
????????? to this instead:
????7 5??? 2?? 31?? 62?? 95?? 131? 2.4930? 1.5162? .7217? .4667? 4.4880 258. 242. 223. 206. 41. 309???? 2458849.500 2020

III.
Edit each of these 4 files: libastro/umoon.c libastro/jupmoon.c libastro/marsmoon.c libastro/satmoon.c
????- Modify the use_bdl() function to provide for a file named *.2040

IV.
Edit ./XEphem-4.0.2/libastro/bdl.c
????- Change the comment:? moon file locations are now




On 9/9/21 8:28 PM, Maxime GOMMEAUX wrote:

Dear friends of XEphem,

I can see files with names similar to those mentioned by Elwood in the following directory:



This includes, among others, jupiter.2040, mars.2040, saturne.2040 and uranus.2040.

Would they help?

Yours,
Maxime

Le 10/09/2021 à 08:15, Bernie Walp a écrit?:

It looks like those moon models came from the Bureau des Longitudes. The XEphem bdl.c code mentions an FTP site that isn't there any more. The Wiki Pedia says BDL's ephemeris functions have been taken over by Institut de Mécanique Céleste et de Calcul des ?phémérides but I can't get into imcce.fr by anonymous FTP to see whether they have a directory analogous to the one mentioned in the XEphem code.

Someone more knowledgeable than myself would have to look at this.? I haven't divined from the bdl.c code what all the various fields in the XEphem model files are.

-- 
Serge Montagnac + GPG Key 0xDF083D7B + 
  Nature, Not Human Activity, Rules the Climate.

开云体育

Hi sir,
I am a french amateur Astronomer who uses XEphem from the start ... and a bit surprised by your
somewhere nervous attitude ...??

The position of the IMCCE concerned official files are there:


I advise you that the stupidity of some people at Firefox and other browser to suppress the ftp sites access.
So you must use FileZilla or other tricks to pick-up these files there.

These files were generated specially for XEphem by Mr.Valery Lainey, the astronomer in charge of that work.
With Valery Lainey we carefuly calibrated the strict format of polynomials files named XXX.2040

We must be aware that the IMCCE professionals have no reason to help us, but their kindness for other
astronomers work like Elwood, Mr Lainey and others ... so I thank them again.

I did an XEphem fork to complete (about 10th lines of code extensions) to extend your access for 20 years more to the moons position.
Brandon Craig Rhodes very nicely took his time to verify my pull ... everything is now OK.

You can "git clone "
get to GUI/xephem , make ...
(I recommend to you to copy all the? .2040 files (as .9910 and? .1020) in your /usr/local/xephem/auxil/ directory.

We checked that with no heck on Ubuntu, Debian, Mageia linux distros on x86-32/64 and the Mac.

Best regards,
Serge.

It looks like those moon models came from the Bureau des Longitudes.? The XEphem bdl.c code mentions an FTP site that isn't there any more.? The Wiki Pedia says BDL's ephemeris functions have been taken over by Institut de Mécanique Céleste et de Calcul des ?phémérides but I can't get into imcce.fr by anonymous FTP to see whether they have a directory analogous to the one mentioned in the XEphem code.

Someone more knowledgeable than myself would have to look at this.? I haven't divined from the bdl.c code what all the various fields in the XEphem model files are.



On 9/9/21 5:53 PM, Elwood Downey wrote:

Those messages refer to the moons, not the planets. But yes, the last model I installed expired Jan 1 2021.

The models were generated by an observatory in France, the details escape me at the moment but there's another thread on here somewhere where someone was trying to track it down and get updates. There are separate files for moons of mars, jupiter, saturn and uranus named mars.1020 etc (where 1020 means the model is good from 2010 to 2020). Once you get the new model files in auxil, each instance of use_bdl() in the four corresponding *moon.c source code files also needs updating to accept the new date range of the models. Or better yet, continue with my file naming convention and change the code to infer the file name automatically, then no future code changes would be required.

Elwood

-- 
Serge Montagnac + GPG Key 0xDF083D7B + 
  Nature, Not Human Activity, Rules the Climate.

Thanks to Maxime's identification of the moon files I took the following four steps locally on my own computer and it works.

I would be grateful if one of the experienced Git-hub users would place it into the repository, assuming you agree.

- Bernie


I.
Obtain the the new *.2040 files from and place them into XEphem's auxil/ directory.

II.
IMPORTANT: uranus.2040 seems to have a small problem in the line 1 header. Missing are some spaces needed to separate several field entries. Change line 1 from this:
7 5 2 31 62 95 131 2.4930 1.5162 .7217 .4667 4.4880 258.0242.0223.0206.0 41.0 309 2458849.500 2020
to this instead:
7 5 2 31 62 95 131 2.4930 1.5162 .7217 .4667 4.4880 258. 242. 223. 206. 41. 309 2458849.500 2020

III.
Edit each of these 4 files: libastro/umoon.c libastro/jupmoon.c libastro/marsmoon.c libastro/satmoon.c
- Modify the use_bdl() function to provide for a file named *.2040

IV.
Edit ./XEphem-4.0.2/libastro/bdl.c
- Change the comment: moon file locations are now

Yes! Those are the files! Thank you Maxime.