|
XEphem 4.0.2 installed here effortlessly. Many thanks.
The messages "No Mars model" and "No uranus model" occur still. Is that because the data are not current in the auxil/ subdirectory files? I am poking through documentation without any luck so far.
toggle quoted message
Show quoted text
On 6/24/21 4:46 AM, Brandon Rhodes wrote: I¡¯ve now returned from some early Summer travel and have finished giving a talk that I¡¯d promised to give at a recent (remote) conference. Now that I¡¯ll be online for the rest of the summer and able to respond to any breakages I cause, I¡¯ve been emboldened to try my hand at an XEphem release from the GitHub source repository.
<>
Thanks to all of you who have been sharing the tweaks and fixes that have gotten XEphem working for you locally, in particular removing the old |-lXp| compile flag and (for Linux users) switching away from the old Motif library bundled with XEphem¡¯s source code so that XEphem can use your distribution¡¯s own up-to-date Motif library compiled against its own X libraries.
I can confirm that XEphem 4.0.2 builds and runs just fine on Ubuntu versions from the old 14.04 all the way up to the current 21.04, with two simple commands:
|sudo apt install build-essential groff-base libmotif-dev libxext-dev libxmu-dev libxt-dev make|
A few questions for the list.
1.
Are there any Debian package maintainers among us? With its new license, XEphem can now qualify to be an official Debian and Ubuntu package for people to effortlessly |apt install|, but I would rather not go through all the steps to become a Debian maintainer myself as I have quite a few projects ongoing already.
2.
I will be happy for the install instructions to expand to cover all UNIX-like operating systems, though I only use Ubuntu myself. If you know of anything that should be added to this list of packages I¡¯ve created in the README <> and the updated compilation instructions in the INSTALL file <> (which currently focus only on Debian/Ubuntu and MacOS), let me know and I will be happy to update them.
3.
At least some MacOS users have been on GitHub discussing segfaults <> when they try compiling and running XEphem. I?do have an old Mac laptop here in the house, but might not have time this summer to try compiling and installing XEphem on it. If anyone knows how to resolve the various issues that have been reported, I¡¯ll be happy to update the repository with any fixes. I¡¯m not familiar enough with the MacOS ecosystem to know whether, for example, something like |brew| might provide the Motif libraries, or whether an XEphem recipe could be added to |brew| to make installing XEphem automatic for its users.
Thanks again to everyone for the helpful recent discussions. Hopefully we¡¯ll soon have XEphem running without snags for everyone who tries it on a modern operating system!
|
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
|
Thanks, Elwood,
Bernie
toggle quoted message
Show quoted text
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
|
BTW, don't be tempted to extend the date ranges of a model just to get something working again. These models are high-order polynomials and become wildly inaccurate even slightly outside their design date range.
Elwood
|
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.
toggle quoted message
Show quoted text
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
|
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
toggle quoted message
Show quoted text
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.
|
Yes! Those are the files! Thank you Maxime.
toggle quoted message
Show quoted text
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.
|
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
toggle quoted message
Show quoted text
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.
|
Just an advice ....
Update your source is enough, there are not any file correction to
do from github sources.
Serge.
?
On 10/09/2021 11:48, Bernie Walp wrote:
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.
|
On Fri, Sep 10, 2021 at 6:35 AM Serge Montagnac < obs.psr@...> wrote:
Just an advice ....
Update your source is enough, there are not any file correction to
do from github sources.
Serge.
Yes, those files and changes are available if you install from the source on GitHub. For example, you can download the zip file that can automatically be generated from the most recent commit:
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! - As he's stated before on this list, Elwood has made his final release.
- 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".
- I'll improve the README to point out where releases are listed on GitHub so folks don't have to discover that themselves.
- In case anyone looks there, I can update the table of source releases on the GitHub copy of the web site at:
- 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?¡¯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, 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.
|
just refers the user straight over to . I thought this was better than having two independent copies of the site on the web.
?
But now I wonder about catalogs. Are they on github somewhere, including the two large GSC kits? Maybe I'm just missing them but if not, folks will still need access to at least that much of my old web site. If catalogs are not yet on github but you want them to be, I would suggest breaking out the smaller ones from my XEphem-3.7.7-disk1.tgz rather than just posting that file as-is.
?
|
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.
toggle quoted message
Show quoted text
On 9/10/21 2:27 AM, Brandon Rhodes wrote: On Fri, Sep 10, 2021 at 6:35 AM Serge Montagnac <obs.psr@... <mailto:obs.psr@...>> wrote:
Just an advice ....
Update your source is enough, there are not any file correction to do from github sources.
Serge.
Yes, those files and changes are available if you install from the source on GitHub. For example, you can download the zip file that can automatically be generated from the most recent commit:
<>
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.
|
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,
toggle quoted message
Show quoted text
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.
--
?ukasz Sanocki
AP-Media
|
just refers the user straight over to . I thought this was better than having two independent copies of the site on the web.
Nice, that's a solid solution and will hopefully prevent some confused users. (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.)
But now I wonder about catalogs. Are they on github somewhere, including the two large GSC kits? Maybe I'm just missing them but if not, folks will still need access to at least that much of my old web site. If catalogs are not yet on github but you want them to be, I would suggest breaking out the smaller ones from my XEphem-3.7.7-disk1.tgz rather than just posting that file as-is.
Oh ¡ª the catalogs! Thanks for thinking of that. I have created a new repository for them, so that all those huge binaries don't affect folks who just want to download and work on the main source code:
I've added: - The big GSC2201?star catalog from the supplementary install CDs XEphem-3.7-disk2.tgz and XEphem-3.7-disk3.tgz.
- All the catalogs from the official install CD?XEphem-3.7.7-disk1.tgz.
- 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.
- I welcome any guidance on what to do with big directories like "xephem/lo/img/" and "xephem/gallery/" which are not catalogs, but are indeed binary resources. Would a third repository be appropriate? I'd welcome guidance here.
I suppose at some point there will need to be documentation telling folks how to get those resources and install them locally. Let me know if anyone is interested in writing something up!
|
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.
I welcome any guidance on what to do with big directories like "xephem/lo/img/" and "xephem/gallery/" which are not catalogs, but are indeed binary resources. Would a third repository be appropriate? I'd welcome guidance here.
Perhaps the catalog repository could be renamed? Supplementary then GSC and these could all go there? FYI: lo/img are the lunar images keyed to location in the View -> Moon dialog. galley is a misc collection of deep sky images accessed via File -> Gallery. See section 3.2 in the manual.
|
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??¡
They now both refer to reader to github.
I hit reload and now see the new link! Thanks.
I wonder if those two links, instead of pointing at the GitHub list of files, should instead point to:
I have recently read accounts of users who are completely lost upon seeing a GitHub repository front page, and after clicking a few links in dismay they close the page, without ever discovering that if they scroll down they can see a rendered README full of information ¡ª the act of scrolling down to see the README is so natural to many developers that they forget that most folks won't know that trick who simply want to run a piece of software.
So a link to the "Site/" page, where we can control the content instead of GitHub controlling the content, might let us provide a gentler welcome and introduction to users?
|
Users! Done.
I notice ?has the link removed. Here is what mine looks like:
|
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.
(More than a month later, I've found time to sit down and learn more about the Field Stars options!)
The documentation describes GSC 2.2 as going from magnitudes 10¨C20, not 15¨C20; and thus, it claims, GSC 2.2 works well in conjunction with Hipparcos. When I select GSC 2.2 and "Hipparcos?+ Tycho2" is auto-selected with it, I seem to get a fairly complete starfield. Which would be a happy state of affairs: it would mean that the files already in the Catalogs repository are enough for a full display of stars, even without the files beneath "gsc/".
XEphem is not letting me select both GSC 2.2 and "gsc/" at the same time, so I can't verify whether they'll work together to show more stars than I see with simply Hipparcos?+ Tycho2?+ GSC 2.2.
(If I turn off Hipparcos?+ Tycho2 and only use GSC 2.2, then I do see a gap: very bright stars and very dim ones, with several empty magnitudes in between.)
For anyone curious:?experimenting with field star catalogs involves lots of zooming in the Skyview, and I've quickly become fatigued with locating and manipulating the "zoom bar" on the left side of the window, so I've attempted an experiment. Even though I'm not a Motif programmer, I've made a try at activating the mouse scroll wheel as a simple zoom mechanism for the Skyview ¡ª here¡¯s my diff:
I think this change is safe, as the mouse wheel didn't seem to have a previous function that I would be interrupting, but, anyone, feel free to let me know if this interferes with XEphem's function in some way that's not evident to me yet. Thanks! (To try the feature out before the next release, you'll need to compile yourself from the latest source on GitHub.)
|
