¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Magnitude problem


Santiago Roland
 

Hi guys, i'm having an odd magnitude problem in XEphem. We own an
ordered copy of XEphem 3.7.1 (including the catalog CDs) and some faint
asteroids show as 2 or 3-ish magnitude. I updated the version of XEphem
packaged for Debian distros from this site
() and the error remains unchanged. I
attach a screenshot of my problem so you can help me out. I'm trying to
compile now the version following this tutorial
()

P.S: I compiled RC 3.7.7 and i have the same...

Any help would be great!

Cheers,

--
Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------


 

Like it says, your ephemerides are out of date, which means the location, and hence magnitudes, for your object are unreliable.

I just downloaded the latest elements from Lowell and 2010 OU100 is reported as being magnitude 21.7.


Santiago Roland
 

I downloaded the latest files from MPC (the links are shown in the
screenshot), maybe they were not updates properly? I also hit the
download button for Lowell and AstMPC_dim... will try again...

Best regards,


Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 12/11/14 a las 02:40, ecdowney@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:


Like it says, your ephemerides are out of date, which means the
location, and hence magnitudes, for your object are unreliable.


I just downloaded the latest elements from Lowell and 2010 OU100 is
reported as being magnitude 21.7.


Santiago Roland
 

Ok, i downloaded the Lowell dim catalog, but i still have the mag 3
asteroid thing using the Unusual from the MPC, maybe the address for
download is bad? I tried to download it again with no luck

Will appreciate any help.


Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 19/11/14 a las 19:46, Santiago Roland santiago@... [xephem]
±ð²õ³¦°ù¾±²ú¾±¨®:



I downloaded the latest files from MPC (the links are shown in the
screenshot), maybe they were not updates properly? I also hit the
download button for Lowell and AstMPC_dim... will try again...

Best regards,

Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 12/11/14 a las 02:40, ecdowney@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:


Like it says, your ephemerides are out of date, which means the
location, and hence magnitudes, for your object are unreliable.


I just downloaded the latest elements from Lowell and 2010 OU100 is
reported as being magnitude 21.7.


 

You do realize that Downloading just stores them on disk, right? You must still Load them using Data -> Files.



Santiago Roland
 

Yeah, i keep having the same problem. I downloaded the Lowell dim
catalog and magnitudes are fine, The issue is with the MPC files. I
downloaded them in the orbital elements page for planetarium programs,
fetched the link and entered in the download links in XEphem, deleted
all catalogs and reloaded them several times. I get for unusual,
magnitudes around 3 or 4. Any other ideas? Logs that i can post? I
deleted the .edb and generated them again. See object 2010 JT123, what
magnitude do you have for this object? I compiled the lastest version
and i'm running it on Debian, XEphem 3.7.6

Best Regards,


Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 21/11/14 a las 15:04, ecdowney@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:


You do realize that Downloading just stores them on disk, right? You
must still Load them using Data -> Files.




Santiago Roland
 

And also detected other problem that is maybe related to the magnitude
problem. It is in the numbering of the asteroids, see in the screen i
toggled high magnitude for a panorama view of bright asteroids and
notices the asteroid 1 Irene and 2 Amphitrite, they are 14 and 29
numbered, so maybe this issue is related with the magnitude one. Is
somebody having this problem? or just me? I compiled the latest version,
and i'm running Debian Wheezy 7.0 with backports repository.

See the screenshot.

Best regards,

Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 21/11/14 a las 15:04, ecdowney@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:


You do realize that Downloading just stores them on disk, right? You
must still Load them using Data -> Files.




 

Hey,

using xephem 3.7.7-RC3

I checked JPL and the MPC for the object 2010 JT123, for which
they show an updated name of 2014 FD7.

I don't find either name in the .edb files from Lowell or
the MPC bright, or dim, even after update.

MPC directly reports the mag as 23.2ish for now.

JPL sez the object has a heliocentric distance ~1.52e8km (1AU).

Can you send me the filename and line from your .edb file?

grep? '2014.*FD7' ?? *edb
and
grep? '2010.*JT123'?? *edb

I don't get any output for either query. check your install
base (mine is /usr/local/xephem/catalogs) and from
your ~/.xephem dir.

During this chase, I deleted? files from /usr/share/xephem/catalogs...
Reran the app.
Found MPC files in my ~/.xephem directory!
deleted those
reloaded


So, I asked the MPC for the single line for XEphem, and saved this
into a file in ~/.xephem/ast.edb and I can find, load, query, and
Sky Point the 2014*FD7 critter.

The mag reports fine.

# From MPO315289 (HACKED HERE, OK in ast.edb attached)
2014 FD7,e,15.4565,187.2564,138.8035
,1.203030,0.7469466,0.048986,50.8130,12/09.0/2014,2000,H21.5,0.15


Attached is the hacked output from a JPL vector query
with object data from JPL and the hacked table
from the MPC direct query.

I realize you are not looking for these data exactly, but
trying to solve the XEphem .edb issue, but here is
the 'truth' from my two main sources for a baseline
for debugging.

I don't have a lot of time to dig into the code, but hope this
helps. Good first cup of coffee exercise for me this AM!





--Wayne



On Tue, Dec 9, 2014 at 5:37 AM, Santiago Roland santiago@... [xephem] <xephem@...> wrote:
?

Yeah, i keep having the same problem. I downloaded the Lowell dim
catalog and magnitudes are fine, The issue is with the MPC files. I
downloaded them in the orbital elements page for planetarium programs,
fetched the link and entered in the download links in XEphem, deleted
all catalogs and reloaded them several times. I get for unusual,
magnitudes around 3 or 4. Any other ideas? Logs that i can post? I
deleted the .edb and generated them again. See object 2010 JT123, what
magnitude do you have for this object? I compiled the lastest version
and i'm running it on Debian, XEphem 3.7.6

Best Regards,

Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 21/11/14 a las 15:04, ecdowney@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:
>
>
> You do realize that Downloading just stores them on disk, right? You
> must still Load them using Data -> Files.
>
>
>
>




--


-- Wayne


 



is one place; I checked for your asteroids they are there, maybe
with a different primary name?

--W


On Tue, Dec 9, 2014 at 9:17 AM, Wayne Green <dxwayne@...> wrote:
Hey,

using xephem 3.7.7-RC3

I checked JPL and the MPC for the object 2010 JT123, for which
they show an updated name of 2014 FD7.

I don't find either name in the .edb files from Lowell or
the MPC bright, or dim, even after update.

MPC directly reports the mag as 23.2ish for now.

JPL sez the object has a heliocentric distance ~1.52e8km (1AU).

Can you send me the filename and line from your .edb file?

grep? '2014.*FD7' ?? *edb
and
grep? '2010.*JT123'?? *edb

I don't get any output for either query. check your install
base (mine is /usr/local/xephem/catalogs) and from
your ~/.xephem dir.

During this chase, I deleted? files from /usr/share/xephem/catalogs...
Reran the app.
Found MPC files in my ~/.xephem directory!
deleted those
reloaded


So, I asked the MPC for the single line for XEphem, and saved this
into a file in ~/.xephem/ast.edb and I can find, load, query, and
Sky Point the 2014*FD7 critter.

The mag reports fine.

# From MPO315289 (HACKED HERE, OK in ast.edb attached)
2014 FD7,e,15.4565,187.2564,138.8035
,1.203030,0.7469466,0.048986,50.8130,12/09.0/2014,2000,H21.5,0.15


Attached is the hacked output from a JPL vector query
with object data from JPL and the hacked table
from the MPC direct query.

I realize you are not looking for these data exactly, but
trying to solve the XEphem .edb issue, but here is
the 'truth' from my two main sources for a baseline
for debugging.

I don't have a lot of time to dig into the code, but hope this
helps. Good first cup of coffee exercise for me this AM!





--Wayne



On Tue, Dec 9, 2014 at 5:37 AM, Santiago Roland santiago@... [xephem] <xephem@...> wrote:
?

Yeah, i keep having the same problem. I downloaded the Lowell dim
catalog and magnitudes are fine, The issue is with the MPC files. I
downloaded them in the orbital elements page for planetarium programs,
fetched the link and entered in the download links in XEphem, deleted
all catalogs and reloaded them several times. I get for unusual,
magnitudes around 3 or 4. Any other ideas? Logs that i can post? I
deleted the .edb and generated them again. See object 2010 JT123, what
magnitude do you have for this object? I compiled the lastest version
and i'm running it on Debian, XEphem 3.7.6

Best Regards,

Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 21/11/14 a las 15:04, ecdowney@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:
>
>
> You do realize that Downloading just stores them on disk, right? You
> must still Load them using Data -> Files.
>
>
>
>




--


-- Wayne



--


-- Wayne


Santiago Roland
 

So, is this page of any use?



Cheers,

Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 10/12/14 a las 22:04, Wayne Green dxwayne@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:




is one place; I checked for your asteroids they are there, maybe
with a different primary name?

--W


On Tue, Dec 9, 2014 at 9:17 AM, Wayne Green <dxwayne@...
<mailto:dxwayne@...>> wrote:

Hey,

using xephem 3.7.7-RC3

I checked JPL and the MPC for the object 2010 JT123, for which
they show an updated name of 2014 FD7.

I don't find either name in the .edb files from Lowell or
the MPC bright, or dim, even after update.

MPC directly reports the mag as 23.2ish for now.

JPL sez the object has a heliocentric distance ~1.52e8km (1AU).

Can you send me the filename and line from your .edb file?

grep '2014.*FD7' *edb
and
grep '2010.*JT123' *edb

I don't get any output for either query. check your install
base (mine is /usr/local/xephem/catalogs) and from
your ~/.xephem dir.

During this chase, I deleted files from /usr/share/xephem/catalogs...
Reran the app.
Found MPC files in my ~/.xephem directory!
deleted those
reloaded


So, I asked the MPC for the single line for XEphem, and saved this
into a file in ~/.xephem/ast.edb and I can find, load, query, and
Sky Point the 2014*FD7 critter.

The mag reports fine.

# From MPO315289 (HACKED HERE, OK in ast.edb attached)
2014 FD7,e,15.4565,187.2564,138.8035
,1.203030,0.7469466,0.048986,50.8130,12/09.0/2014,2000,H21.5,0.15


Attached is the hacked output from a JPL vector query
with object data from JPL and the hacked table
from the MPC direct query.

I realize you are not looking for these data exactly, but
trying to solve the XEphem .edb issue, but here is
the 'truth' from my two main sources for a baseline
for debugging.

I don't have a lot of time to dig into the code, but hope this
helps. Good first cup of coffee exercise for me this AM!





--Wayne



On Tue, Dec 9, 2014 at 5:37 AM, Santiago Roland santiago@...
<mailto:santiago@...> [xephem] <xephem@...
<mailto:xephem@...>> wrote:

__


Yeah, i keep having the same problem. I downloaded the Lowell dim
catalog and magnitudes are fine, The issue is with the MPC files. I
downloaded them in the orbital elements page for planetarium
programs,
fetched the link and entered in the download links in XEphem,
deleted
all catalogs and reloaded them several times. I get for unusual,
magnitudes around 3 or 4. Any other ideas? Logs that i can post? I
deleted the .edb and generated them again. See object 2010
JT123, what
magnitude do you have for this object? I compiled the lastest
version
and i'm running it on Debian, XEphem 3.7.6

Best Regards,

Santiago Roland.-
---------------------------------
Jabber: santiago@... <mailto:santiago@...>
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 21/11/14 a las 15:04, ecdowney@...
<mailto:ecdowney@...> [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:
>
>
> You do realize that Downloading just stores them on disk,
right? You
> must still Load them using Data -> Files.
>
>
>
>




--


-- Wayne




--


-- Wayne


 

Hey,

If you want to proceed, lets take this offline.
dxwayne at . We can post summary
results later. To quiesce this particular thread...

I've just noticed some sort of disconnect between the
XEphem built-in Ast...edb files and the 'daily' type
of MPC orbit files. But!!! I am moving fast over this problem.

I downloaded the MPCORB.DAT.gz file and found
the asteroid you seek. However it would need to
be converted to .edb file. The XEphem user doc
describes the fields. The MPCORB.DAT file
is? a 'FORTRAN' like fixed column deal.

I deal with these types of files from Vizier all
the time, using python/editor as my choice approach
for the moment. There is a completely new
technique embedded in astropy for example, that allows
grabbing tabular data and converting to
ds9 tsv files pretty easy.

I downloaded the MPCORB.DAT file. It is big
(as in I don't want to hand edit it!) and appears
well formed.

The MPC states "At present MPCORB is not
available via anon-ftp on this site."

Not sure what the ramifications for XEphem might be.
I don't know the direct link between the XEphem
download files and this master file.

I took Ceres as an example, and could not match
the fields up between XEphem doc, edb, and Ceres'
line from MPCORB.

This is about as far as I can go with this, short of writing
a python script to convert the MPCORB to edb- several
hours at best. I don't have that time in my schedule. I
need to dig into the XEphem source code to understand
the real process. Someone might make a hack that takes the
file you get via the HTTP download and make the
files you need.


So, alas, this first cup of coffee exercise hit the bottom
of the cup before the bottom of the problem. Do I
get partial credit?




This page lets you enter asteroids, and will return
a .edb line for just your target(s) of interest. That
is how I got my little ast.edb file hacked together for
testing, and was able to spot the H issue. H is
in MPCORB.dat.



How well are your python skills?? I suggest to all to use
the Anaconda python package from Continuum.io site.
It is free, and well presented for general analytics
use on all platforms. I've used it under Mac and Linux,
astropy is there and completely integrated. There is
a trick to managing the PYTHONPATH etc to make
it sing. The 'Young Turks' of astronomy are migrating
to iPython (Anaconda is supporting this well)? from IDL.
For astronomy try to stick to the 2.7.6+, as the bulk
of existing stuff is there. Python 3.3.x is OK, but 2.7
seems to be the one for astronomy for now, seems to be
the base for os scripts too.


--W



On Wed, Dec 10, 2014 at 5:50 PM, Santiago Roland santiago@... [xephem] <xephem@...> wrote:
?

So, is this page of any use?



Cheers,

Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------

El 10/12/14 a las 22:04, Wayne Green dxwayne@... [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:
>
>
>
>
> is one place; I checked for your asteroids they are there, maybe
> with a different primary name?
>
> --W
>
>
> On Tue, Dec 9, 2014 at 9:17 AM, Wayne Green <dxwayne@...
> dxwayne@...>> wrote:
>
> Hey,
>
> using xephem 3.7.7-RC3
>
> I checked JPL and the MPC for the object 2010 JT123, for which
> they show an updated name of 2014 FD7.
>
> I don't find either name in the .edb files from Lowell or
> the MPC bright, or dim, even after update.
>
> MPC directly reports the mag as 23.2ish for now.
>
> JPL sez the object has a heliocentric distance ~1.52e8km (1AU).
>
> Can you send me the filename and line from your .edb file?
>
> grep '2014.*FD7' *edb
> and
> grep '2010.*JT123' *edb
>
> I don't get any output for either query. check your install
> base (mine is /usr/local/xephem/catalogs) and from
> your ~/.xephem dir.
>
> During this chase, I deleted files from /usr/share/xephem/catalogs...
> Reran the app.
> Found MPC files in my ~/.xephem directory!
> deleted those
> reloaded
>
>
> So, I asked the MPC for the single line for XEphem, and saved this
> into a file in ~/.xephem/ast.edb and I can find, load, query, and
> Sky Point the 2014*FD7 critter.
>
> The mag reports fine.
>
> # From MPO315289 (HACKED HERE, OK in ast.edb attached)
> 2014 FD7,e,15.4565,187.2564,138.8035
> ,1.203030,0.7469466,0.048986,50.8130,12/09.0/2014,2000,H21.5,0.15
>
>
> Attached is the hacked output from a JPL vector query
> with object data from JPL and the hacked table
> from the MPC direct query.
>
> I realize you are not looking for these data exactly, but
> trying to solve the XEphem .edb issue, but here is
> the 'truth' from my two main sources for a baseline
> for debugging.
>
> I don't have a lot of time to dig into the code, but hope this
> helps. Good first cup of coffee exercise for me this AM!
>
>
>
>
>
> --Wayne
>
>
>
> On Tue, Dec 9, 2014 at 5:37 AM, Santiago Roland santiago@...
> santiago@...> [xephem] <xephem@...
> xephem@...>> wrote:
>
> __
>
>
> Yeah, i keep having the same problem. I downloaded the Lowell dim
> catalog and magnitudes are fine, The issue is with the MPC files. I
> downloaded them in the orbital elements page for planetarium
> programs,
> fetched the link and entered in the download links in XEphem,
> deleted
> all catalogs and reloaded them several times. I get for unusual,
> magnitudes around 3 or 4. Any other ideas? Logs that i can post? I
> deleted the .edb and generated them again. See object 2010
> JT123, what
> magnitude do you have for this object? I compiled the lastest
> version
> and i'm running it on Debian, XEphem 3.7.6
>
> Best Regards,
>
> Santiago Roland.-
> ---------------------------------
> Jabber: santiago@... santiago@...>
> Diaspora*:
> Identi.ca:
> openPGP ID: 7BE512C5
> openPGP key:
> ---------------------------------
>
> El 21/11/14 a las 15:04, ecdowney@...
> ecdowney@...> [xephem] ±ð²õ³¦°ù¾±²ú¾±¨®:
> >
> >
> > You do realize that Downloading just stores them on disk,
> right? You
> > must still Load them using Data -> Files.
> >
> >
> >
> >
>
>
>
>
> --
>
>
> -- Wayne
>
>
>
>
> --
>
>
> -- Wayne
>
>




--


-- Wayne


 


Soft03Unusual contains a few objects of interest, but I don't want to see hundreds of those tiny small pebbles displayed as mag 3 objects when I've set the solar system mag. limit to 12 or 14.? As mentioned many (but not all) of the (newer?? e.g. 2010 ... ) entries have the letter H designation as the prefix flag for an absolute magnitude, but no numeric digits after the H, only the comma separator followed by the other "G" parameter.? So XEphem probably sets H=0 for these, and derives a current apparent mag. of 3 or so, just due to these being a few AU from Earth and/or the Sun.
Earlier in the thread it's mentioned that 21.5 is the correct H value for the particular object being discussed.? Briefly scanning the list for entries that do have a number after the H, it looks like it's typically about 20ish.?
So I just used vi in a terminal window to replace all occurrences of ",2000,H,"? with ",2000,H20.0,".? At least they don't fill the sky like locusts any more for any modest or auto. mag. limit.?