[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: <starship-design@lists.uoregon.edu>*Subject*: RE: starship-design: Massively Distributed Computing for SETI*From*: "L. Parker" <lparker@cacaphony.net>*Date*: Sun, 18 Mar 2001 08:41:38 -0600*Importance*: Normal*In-Reply-To*: <103.699201.27e5990d@aol.com>*Reply-To*: "L. Parker" <lparker@cacaphony.net>*Sender*: owner-starship-design@lists.uoregon.edu

> Given the relative positions of the stars haven't moved > visibly in thousands > of years. We can aim a fixed vector. The only problem is > earth orbit around > the sun. If beam array isn't a ring around the sun, I.E. if > its around a > point in orbit, the ship would have to follow the beam in a > helical course > around a direct vector from the sun, toward the target star. > > No serious math needed, or really possible. We can't aim the > beam because we > can't know where the ship is to aim it at. Actually, there is more to it than that. Lets start with the relative motion first. "Moved visibly" is not the same thing as haven't moved. All stars are in motion, they follow their own orbits about the center of the galaxy as I am sure you know. Our sun is in one such orbit, any target star is going to be in another orbit traveling at a different velocity. We cannot simply aim the beam at the star, the star will not be there when the beam arrives. We must aim the beam at where the star will be when the beam gets there. This is a non-trivial task considering that all distances to stars are currently _estimated_. Then you must add for the motion of the beam array in its orbit about Sol. As was stated by Kelly this induces a helical component, and if we are in orbit about Earth or some other planet, it induces another helical component. Although it is possible for the ship to correct its course for helical movement of the beam source, this involves tacking the sails to maintain a steady course on a continuous basis and involves an element of risk if we lose the beam entirely and it doesn't solve the other problem. That is actually the easiest problem to solve. The second problem involves Doppler drift. As the ship gains velocity, it begins to experience Doppler drift or "red shift". Unfortunately, the sail is composed of a material designed to reflect a particular wavelength of radiation. It may also reflect other wavelengths, but not with the same efficiency. Therefore the beam transmitter must be capable of tuning the output across a range of frequencies to keep the energy received by the sail at a constant frequency. This means we must know the exact speed, course and distance of the sail at all times, constantly update the targeting data for the sail, the beam source, and the sail's destination, all in four dimensions, one of which has at least one harmonic component if not two to compute a continually changing target solution and frequency solution for the beam. Any way we approach this, the solution is going to be compute intensive, and it involves many of the same types of calculations being done by the SETI team, which was why I found the article so interesting. Lee

**Follow-Ups**:**Re: starship-design: Massively Distributed Computing for SETI***From:*Ben Franchuk <bfranchuk@jetnet.ab.ca>

**References**:**Re: starship-design: Massively Distributed Computing for SETI***From:*KellySt@aol.com

- Prev by Date:
**Re: starship-design: Massively Distributed Computing for SETI** - Next by Date:
**RE: starship-design: Massively Distributed Computing for SETI** - Prev by thread:
**Re: starship-design: Massively Distributed Computing for SETI** - Next by thread:
**Re: starship-design: Massively Distributed Computing for SETI** - Index(es):