Welcome to the NavList Message Boards.

NavList:

A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    Name or NavList Code:
    Email:
       
    Reply
    Re: Historical Lunars : take in account 'delta-T' or ignore it ?
    From: Paul Hirose
    Date: 2009 Dec 14, 21:10 -0800

    antoine.m.couette@club-internet.fr wrote:
    > For the SUN :
    > 
    > Coordinates error < 0.08", SD error < 0.005" and HP error < 0.0001"
    > 
    > For the MOON :
    > 
    > Coordinates error < 1.7", SD error < 0.1" and HP error < 0.35"
    > 
    > As a result, the Approximate Ephemeris I am computing are well under the NAL tolerances.
    
    Yes, I think your "approximate" values have more than enough accuracy.
    But note the strange "<" in the text I quoted. Are you posting via
    the Web? I know < is a "character entity" for the < symbol, but
    that's an HTML thing, and the header of the message does not say it's 
    HTML. (Later you did send one in HTML.)
    
    
    > Just one question here : I am not quite familiar with the definition of "refracted" semi-diameters.
    
    To compute refracted semidiameter, I use the unrefracted altitude of the
    body, its unrefracted semidiameter, and the desired position angle (0 =
    the 12 o'clock point on the limb). The algorithm is:
    
    1. Create a vector (in the horizontal coordinate system) to the center
    of the body. The azimuth doesn't matter, so I use 0.
    
    2. Create a second vector at the desired separation angle and position
    angle from the first vector. This is a vector to the unrefracted point
    on the limb where we want the semidiameter.
    
    3. Apply refraction to both vectors.
    
    4. Compute the separation angle between the vectors. This is the
    refracted semidiameter.
    
    The result is not strictly correct because the great circle between the
    unrefracted centers (e.g., of the Moon and Sun), and the great circle
    between the refracted centers, do not touch the same points on the
    limbs. However, the points are very close, and the refracted
    semidiameter is not sensitive to such a small change in the position
    angle, especially if you avoid low altitudes. I believe the semidiameter
    error is insignificant compared to the real world errors in altitude due
    to nonstandard refraction.
    
    When I was testing this routine, it precisely matched my hand
    computations for position angles 0 and 180, but at 90 and 270 the
    semidiameters were wrong by a tiny amount. After a lot of debugging, I
    realized the routine was smarter than the man who wrote it. There was no 
    bug. As explained by Meeus in "Astronomical Algorithms", refraction 
    reduces the semidiameter in every direction.
    
    
    > Also, I find the following Center to Center separation velocities :
    > 
    > GEOCENTRIC : .007664 d/minute (you specified .00767) and
    > 
    > TOPOCENTRIC : .007767 d/min (you specified .00492). Something is unclear 
    > to me here because apart from this specific topocentric result, all our 
    > other values match quite closely.
    
    I think my value is correct. At 1 minute later, the separation angle is
    .0049° greater. I used the HORIZONS az/el values and a calculator to
    check the separation angles.
    
    The angular rate from my program is not a precise value. It doesn't
    include refraction.
    
    
    > And finally, as regards the "exotic signs" you could read in [NavList 
    > 11087] these are essentially due to the fact that since I cannot get the 
    > degree symbol (°) with my laptop computer when directly typing a post on 
    > NavList (possible exception for the just preceeding degree symbol which 
    > I just copied and pasted from your own post), I have taken the habit to 
    > type everything on Word and then copy/paste onto Navlist. This is when 
    > the exotic signs ( • , o , � ) come to play.
    
    If you're running Windows, use the Character Map (in the Start menu) to
    copy special characters and past them into your message. That's what I
    do. (But I use the degree symbol enough that I can remember Alt+0176.)
    
    Your latest message (2009-12-14 15:49 UTC) arrived as HTML. I have a
    filter which deletes all messages with HTML (see my sig). But
    fortunately there was also a reply from Marcel on refraction. I didn't
    see the message that prompted his message, so I looked in my trash
    folder and found your email. But I would have noticed it anyway when I
    emptied my trash tomorrow. I'll have to keep an eye on the trash folder
    to catch your replies.
    
    In general I don't like HTML in messages, but in your case it's an
    improvement. When I replied to your non-HTML messages, each paragraph I
    quoted displayed as one very long line when I wrote the reply. There was
    no such problem when simply reading your messages, and the quoted text
    displayed OK when I got back a copy of my own message. So this is
    probably the fault of my email software.
    
    -- 
    
    
    -- 
    NavList message boards: www.fer3.com/arc
    Or post by email to: NavList@fer3.com
    To , email NavList+@fer3.com
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Get a NavList ID Code

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.

    Retrieve a NavList ID Code

    Enter the email address associated with your NavList messages. Your NavList code will be emailed to you immediately.
    Email:

    Email Settings

    NavList ID Code:

    Custom Index

    Subject:
    Author:
    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site