• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.
  • We, the systems administration staff, apologize for this unexpected outage of the boards. We have resolved the root cause of the problem and there should be no further disruptions.

Radial Velocity for stars

Hal

SOC-14 1K
Anyone know of a way to get the radial velocity of stars from say, the Hipparcos catalog?

I'm wondering if there is a correlation between star masses and radial velocity. I'd also like to see if I could find out what the average velocity of a star within our arm of the galaxy would be.

I'm wondering just how complicating a factor adding in the radial velocity of stars to navigational aspects in Traveller.
 
Anyone know of a way to get the radial velocity of stars from say, the Hipparcos catalog?
I've checked a few sources, but none have a consistent set of data for figuring that out. The problem is calculating the radial velocity is somewhat error prone, mostly due to accurate distance calculations. And with no good agreement on how to calculate it, adding it to various star catalogs creates more heat than light.

I'm wondering if there is a correlation between star masses and radial velocity.
From every source I've ever read, the answer is no.
I'd also like to see if I could find out what the average velocity of a star within our arm of the galaxy would be.
Most stars within our local group have relative velocities of between 10 km/s and 20km/s with a few higher.

I'm wondering just how complicating a factor adding in the radial velocity of stars to navigational aspects in Traveller.

For most practical purposes, none. The drive system has to compensate for velocities that high to achieve orbit around a planet. If you are using a lower TL YTU, or some fuel based alternative maneuver drive, it might pose an interesting navigation challenge to do a minimal fuel jump to the next system.

Across the Impeirum, perhaps 3 stars a year should move from one hex to another, based upon the slow relative change of motion being rounded to the an integer position.
 
Last edited:
By my calculations, a Star moving 20 miles per second would take roughly 24,206 years to move about 1 parsec in distance.

If you had one star moving due north (I know I know, 2 dimensional thinking versus the real 3 dimensional movement!) at 20 miles per second, and you have one star a parsec away moving at 30 miles per second due south - a ship moving jumping from Star 1 to Star 2, would have a relative velocity of what?

As best as I can tell, the ship would retain the velocity of Star 1's motion, plus what ever built up velocity the ship had while in Star 1's system (in this case, about 20 miles per second due North relative to the Star 2's system). Ship leaving system 2 for System one would have a built up velocity of star System 2 (plus what ever built up velocity it had while in Star system 2) and would have a relative built up velocity of 30 miles per second due south once it exits into Star System 1.

Note that I'm not saying what the built up velocity of the ship in Star System is - because it can be ANYTHING.

The goal then, is to figure out what the rule effects would be requiring that there be a database made of some 600 star systems plus in say, the Spinward Marches that contains the built up velocity of the stars themselves. Having a direction of movement, and a magnitude of velocity - would be all that is required to record a star's relative motion.
 
If you had one star moving due north (I know I know, 2 dimensional thinking versus the real 3 dimensional movement!) at 20 miles per second, and you have one star a parsec away moving at 30 miles per second due south - a ship moving jumping from Star 1 to Star 2, would have a relative velocity of what?

As best as I can tell, the ship would retain the velocity of Star 1's motion, plus what ever built up velocity the ship had while in Star 1's system (in this case, about 20 miles per second due North relative to the Star 2's system). Ship leaving system 2 for System one would have a built up velocity of star System 2 (plus what ever built up velocity it had while in Star system 2) and would have a relative built up velocity of 30 miles per second due south once it exits into Star System 1.

A ship at rest relative to star 1 which jumps to star 2 comes out with a relative velocity of 50 miles/second northward.

50 mi/s = 264000 ft/sec, 1 G = 32 f/s/s. So canceling that velocity (or achieving it in system 1) takes about 2.3 hours at 1G.

Given how long it takes to fly to the 100D limit, altering the velocity at the 100D limit to be at rest relative to the target system is a relatively trivial exercise in real space navigation.
 
Most stars within our local group have relative velocities of between 10 km/s and 20km/s with a few higher.

If this is the case, then it helps explain while relative system velocities simply don't come in to much play regarding interstellar travel.

On the one hand, it's fair to hand wave it away and mechanical minutia. But on the other, notably in TNE, where ships have reaction mass, if the delta were dramatic enough, it could turn in to a real issue with ships not having enough fuel to compensate upon entry. Not a real issue with generic M-Drives, but certainly a potential one with fuel limited ships.

But, again, if the stars are mostly stable relative to each other, it's not really much of an issue at all.
 
As well as radial velocity, the other component of a star's relative motion is transverse velocity derived from "proper motion", without which you only have half the information you need (the towards/away component but not the "across" line of sight; and at large enough distances you need celerity or proper velocity too.
 
As well as radial velocity, the other component of a star's relative motion is transverse velocity derived from "proper motion", without which you only have half the information you need (the towards/away component but not the "across" line of sight; and at large enough distances you need celerity or proper velocity too.

For what it is worth, a 3-D simulation of the universe is not something I can write code for at this point in time. Simply having a velocity for the star, and the direction of the star's motion in a 2D environment will suffice.

At present - I've been working on coding Vector movement rules for use with what amounts to a virtual table top mapping environment. Center of galactic mass is zero, zero and each star can be located as a Theta/Rho style polar co-ordinate. Each Star would then have its built up velocity listed as a Theta/Rho style co-ordinate such that the GM could have stars move within the campaign if that were desirable.

I've been working on a project on and off, and phase I seems to have been completed successfully. Phase II will be as follows:

Center of Mass for the star system will be deemed zero,zero. Planets that move will be measured in miles distant from the center of mass for the star system. Consequently, ALL planets can be listed such that they have a movement rate in degrees per 20 minute turn (obviously a decimal value unless the planet has a year that measures less than 360 days). From there, planets can move just as starships, space ships, and missiles can move in the Traveller Universe.

For vector movement involving ships, the process is:

A) Determine current location of ship
B) determine built up vector of ship, and add the vector to current location.
C) Add Acceleration vectors as listed below:
1) Ship acceleration in values of 0 to 6 G's.
2) Ship acceleration due to nearby planetary mass (if any)
3) Ship acceleration due to star's mass
D) Determine new built up vector by determining the distance from the old "Current location" to the New Current Location after steps B & C. This becomes the new built up vector for the next turn.


Step A determines what the ship's current X/Y value is. Step B requires that the vector of the built up velocity be added to the ship's current location to reach a new "final location" sans any acceleration effects. Step C requires that all applicable acceleration vectors be added to the built up velocity vector, to determine the final location of the ship at the end of that turn.

Why am I bothering with this? My goal is to - time permitting and INTEREST permitting (ie, do I feel like working on it at any given moment), to code software that will permit a GM to keep track of things in motion within a star system. These things might be:

A) Planets
B) Ships
C) Missiles

The program would track how close any given "thing" is to any other "thing". This would permit a referee to run a fog of war style combat between ships in a Traveller Universe. Being able to list all "participant" ships in a Datagridview and track their location in 20 minute turns would permit all of that to be done. Best of all, it would permit a GM to use the software coding (It would be in VB.NET) to run their own battles whether using CT, MT, MgT,T4, T5, T20, and GT).

Eventually, for my own use, I would code it for use with GURPS TRAVELLER as far as the sensor rules would come into play, and perhaps include coding for ship to ship combat with the weapons involved.

But that's just a pipe dream of Vaporware at the moment. I don't have anyone to use this software with. If I had someone who wanted to participate in something like this, I'd have to start devoting more time to coding - but then I'd be motivated to do so. A win/win in my book.
 
Radial velocity would be one-dimensional though, the approach or recession vector would need the product of a transverse vector to make it two-dimensional. The resultant third vector would give the true direction of a star's relative velocity in the second dimension, though there's nothing wrong with a "range band" one-dimensional approach if the speed is right.

After all, we don't tend to worry about the angle of the plane of the ecliptic when jumping to a new system, and I've only seen rules about a planet's position around its orbit in the DGP Starship Operator's Manual, so one dimension is as commonly used as two.
 
Back
Top