We are searching data for your request:
Upon completion, a link will appear to access the found materials.
I'm trying to parse stellar data in the GAIA 2 release to galactic coordinates and am struggling with the velocity component. I've tried following online documentation and papers, but end up with velocity results with strange biases that indicate I'm probably doing something wrong. Sources I've used are: http://adsabs.harvard.edu/full/1987AJ… 93… 864J
The GAIA 2 dataset has these relevant variables per star:
- ra (from 0-360)
- dec (from -90 to 90)
And this is the code I have (C#) to try to obtain the velocity components. Done by first converting pmra and pmdec to cartesian velocities based on the stars position, and then rotating that location to galactic coordinates.
double RA = ra * Math.PI / 180.0; double DEC = (dec + 90) * Math.PI / 90.0; Microsoft.Xna.Framework.Matrix positionrotation = new Microsoft.Xna.Framework.Matrix(); positionrotation.M11 = (float)(Math.Cos(RA) * Math.Cos(DEC)); positionrotation.M12 = (float)-Math.Sin(RA); positionrotation.M13 = (float)-(Math.Cos(RA) * Math.Sin(DEC)); positionrotation.M21 = (float)(Math.Sin(RA) * Math.Cos(DEC)); positionrotation.M22 = (float)Math.Cos(RA); positionrotation.M23 = (float)-(Math.Sin(RA) * Math.Sin(DEC)); positionrotation.M31 = (float)(Math.Sin(DEC)); positionrotation.M32 = 0; positionrotation.M33 = (float)(Math.Cos(DEC)); Microsoft.Xna.Framework.Vector3 vector = new Microsoft.Xna.Framework.Vector3((float)(radial_velocity), (float)(pmra / parallax), (float)(pmdec/ parallax)); vector = Microsoft.Xna.Framework.Vector3.Transform(vector, positionrotation); Microsoft.Xna.Framework.Matrix galacticrotation = new Microsoft.Xna.Framework.Matrix(); galacticrotation.M11 = -0.054876f; galacticrotation.M12 = -0.87347f; galacticrotation.M13 = -0.483835f; galacticrotation.M21 = 0.494109f; galacticrotation.M22 = -0.444830f; galacticrotation.M23 = 0.746982f; galacticrotation.M31 = -0.867666f; galacticrotation.M32 = -0.198076f; galacticrotation.M33 = 0.455984f; vector = Microsoft.Xna.Framework.Vector3.Transform(vector, galacticrotation);
DECconversion in the question is incorrect. Try this:
double DEC = dec * Math.PI / 180.0;
positionrotationlooks like a composition of two rotations bringing (1, 0, 0) to the RA and DEC of interest. It seems correct, but something like this would be easier to verify:
using Microsoft.Xna.Framework.Matrix; Matrix positionrotation = Matrix.CreateRotationZ((float) RA) * Matrix.CreateRotationY((float) -DEC);
The units in
vectorare mixed up. According to these Gaia DR2 docs,
radial_velocityis in km/s.
pmdecare in mas/yr; dividing (*) them by
parallaxin mas (1 au baseline) gives results in au/yr. Try this:
using Microsoft.Xna.Framework.Vector3; // conversion to km/s double au_yr = 1.49598e+8 / 3.15576e+7; Vector3 velocity = new Vector3( (float) radial_velocity, // km/s (float) pmra / parallax * au_yr, (float) pmdec / parallax * au_yr); Vector3 vel_icrs = Vector3.Transform(velocity, positionrotation);
galacticrotationis from equation 3.61 in these Gaia DR2 docs,
// Matrix galacticrotation as above except galacticrotation.M12 = -0.873437f; Vector3 vel_gal = Vector3.transform(vel_ircs, galacticrotation);
(*) Actual distance in parsecs may differ from the reciprocal of measured parallax in arcseconds, which may be zero or negative.
RA & DEC Epoch conversion
I need to convert the RA & DEC from Epoch J2000 to the current date in a Visual Basic .net program I already have written.
I found how to do this from B1950 to J2000 but it is hard coded for that conversion.
Does anyone know where I can find the formulas to do this that will allow me to input the epochs?
Here is the web page that shows the B1950 to J2000 conversion. http://www.stargazin. pler/b1950.html
Check out this site, and play around with the utility.. It converts every which way, including J2000 to current date.
And then read the text at the bottom. He is willing to share his code. It is downloadable.
#3 Wm Rison
I was hoping to just find the math to do it. Translating someones code is not my favorite thing to do.
Have found many times in the past that what can be done in a few lines of code someone will take tens of lines to do and make it a lot more complicated that it really is.
To reduce from the mean equinox of B1950.0 + T0 to that of B1950.0 + T0 + T, your program
Xx = 1 - 10 -8 [(29696 + 26 T0) T 2 - 13 T 3 ]
Yx = -Xy = -10 -8 [(2234941 + 1355 T0)T - 676 T 2 + 221 T 3 ]
Zx = -Xz = -10 -8 [(971690 - 414 T0)T +207 T 2 + 96 T 3 ]
Yy = 1 - 10 -8 [(24975 + 30 T0)T 2 - 15 T 3 ]
Yz = Zy = -10 -8 [10858 + 2 T0)T 2 ]
Zz = 1 - 10 -8 [(4721 - 4 T0)T 2 ]
and T0 and T are in tropical centuries (36524.219878 days).
Source: The Explanatory Supplement to the Ephemeris (HMSO, 1977), p.34.
Although it is not explicitly stated in the book, from the definitions find that
T0 = (JD0 - 2433282.423)/36524.219878 tropical centuries since B1950.0
T = (JD - JD0)/36524.219878 tropical centuries from starting epoch to ending epoch
As a check, try to predict the elements in your original matrix from the starting epoch
B1950.0 (JD0 = 2433282.423) to the ending epoch J2000.0 (JD = 2451545.0).
Then, since you want to start at J2000.0, input JD0 = 2451545.0 to find the new starting T0.
Input the current JD to find T and the new matrix.
Edited by catalogman, 29 December 2016 - 04:27 PM.
Find a copy of "Practical Astronomy With Your Calculator". I would type the formulae in for you but its not easy on my keyboard.
Probably a free e-book by now.
#6 Wm Rison
I found out there are formulas in Astronomical Algorithms by Jean Meeus that I can get right away from a friend. Chapter 20 Precession has two methods to do the calculations.
Meeus does not use rectangular coordinates, so you would have to write an entirely new program.
Also, Meeus does not give the inverse conversion at all, whereas in the matrix method it is obvious
(just take the transpose of the matrix).
Duffett-Smith (1979 edition) gives only the low-accuracy method, which should be used only if the
two epochs are not widely separated and if the object is not too close to a pole. Again, the OP
would have to write a brand new program from scratch.
Astronomy on the Personal Computer by Montenbruck and Pfleger (Springer-Verlag)
Near the bottom op the page, download 'Pascal source codes'.
The procedures PMATECL, PMATEQU and PRECART may be what you need.
#9 Wm Rison
The Meeus book I have is published by Willmann-Bell and is the 1991 edition.
The chapter on Precession has two methods for the calculation.
Low accuracy and Rigorous method. I was looking at using the Rigorous method.
I looked at the Pascal routines and can easily create the matrix but would need to figure out how to use them.
Are you saying the Meeus Rigorous method is not good enough?
What I want to do is adjust the RA & DEC from MegaStar that uses epoch J2000.0 to the current JD.
So I am not going very long at all. I.E. 17 years.
The elementary expressions in Duffett-Smith are derived from differentials, so they are accurate only for
very short time intervals (only a year or so!)
The IAUSOFA routines in F77 and 'C', and AstroPy are other possibly good sources. However, the OP is
Attached is a sample PowerBASIC program using the OP's method of rectangular coordinates. The input
uses NGC 3172 as a test, which is very close to the pole. According to HYPERLEDA, the coordinates are
B1950.0: 11 38 24.96 +89 22 15.1
J2000.0: 11 47 11.89 +89 05 35.9
The OP's method in the attached PowerBASIC program gives
PowerBASIC: 11 47 12.18 +89 05 35.6
The "rigorous method" of Meeus (written in Decimal BASIC) is off by somewhat more:
DecimalBASIC: 11 47 12.23 +89 05 35.5
And the Pascal routines (Post #8) look very much like they came from Meeus.
One explanation for the discrepancies is that both the Meeus expressions and the power
series for the rectangular coordinate transformations are somewhat old. In this 1994 paper
the numerical constants on page 665 are noticeably different from page 126 of Meeus.
Edited by catalogman, 30 December 2016 - 06:24 PM.
For the southern hemisphere, let's try NGC 2573 (B1950.0 = 02 42 48.65 -89 34 13.3):
HYPERLEDA: 01 41 35.71 -89 20 04.7
PowerBASIC (Rect): 01 41 36.02 -89 20 05.0
DecimalBASIC (Meeus): 01 41 36.19 -89 20 05.0
Edited by catalogman, 30 December 2016 - 06:44 PM.
#12 Wm Rison
I'll give OP's method a try. The Meeus one I am working on is directly from the book published in 1991.
I was putting it into my own program from formulas in the book.
The source of the Meeus "rigorous method" (1991 ed., p. 126) is probably this paper from 1977:
#14 Wm Rison
I got the Power Basic code to work with my program fine.
Glad to hear that you have a working version.
Here's a revised version of my first program. Instead of the time series,
the attached PowerBASIC program writes the Meeus angles to the transformation matrix (see Equations (6) and (7) of this paper):
The matrix in Equation (13) should look familiar -- it's the same matrix
The results of the attached program are almost the same:
NGC 3172: 11 47 12.24 +89 05 35.6
NGC 2573: 01 41 36.19 -89 20 05.0
Edited by catalogman, 30 December 2016 - 10:01 PM.
At the bottom of my webpage http://www.hnsky.org/software.htm there is an Excel table with both the rigorous (Montenbruck, Pfleger) and approximation method in visual basic, so the accuracy around the poles is optimum. I made it long time ago in 2002. My first and last activity in visual basic.
To be correct, your trying to correct the equinox from B1950 to J2000. So precession, the slow shift of the Earth axis and ecliptic. The epoch is something different. That's the error due to the object own motion. So a DSS image of 1974 has an epoch of 1974. The coordinates could be J2000 but to calculate the star position in the year 2000 you have to apply 26 year of star proper motion.That epoch error is very minor compared with the equinox error.
The new Gaia star database has an Celestial Reference Frame (ICRF) which is more or less J2000 and an epoch 2015.0 since the position was observed in 2015 and no proper motion was (yet) taken into account.
The measurements we will work with are physical quantities, which means that they have two parts, a value and a unit. For example, the coordinate (30^
Until recently, most scientific computation was done with values only units were left out of the program altogether, often with catastrophic results.
Astropy provides tools for including units explicitly in computations, which makes it possible to detect errors before they cause disasters.
To use Astropy units, we import them like this:
u is an object that contains most common units and all SI units.
You can use dir to list them, but you should also read the documentation.
To create a quantity, we multiply a value by a unit.
The result is a Quantity object. Jupyter knows how to display Quantities like this:
Quantities provide a method called to that converts to other units. For example, we can compute the number of arcminutes in angle :
If you add quantities, Astropy converts them to compatible units, if possible:
If the units are not compatible, you get an error. For example:
causes a UnitConversionError .
Create a quantity that represents 5 arcminutes and assign it to a variable called radius .
Then convert it to degrees.
Jprecess : Precess celestial positions from B1950.0 (FK4) to J2000.0.
Calculates the mean place of a celestial object at J2000.0 on the FK5 system from the mean place at B1950.0 on the FK4 system. Use the function bprecess for precession in the other direction from J2000 to B1950.
The algorithm is taken from the Explanatory Supplement to the Astronomical Almanac 1992, page 186. Also see Aoki et al (1983).
BPRECESS distinguishes between the following two cases: (1) The proper motion is known and non-zero and (2) the proper motion is unknown or known to be exactly zero (i.e. extragalactic radio sources). In the latter case, the reverse of the algorithm in Appendix 2 of Aoki et al. (1983) is used to ensure that the output proper motion is exactly zero. Better precision can be achieved in this case by inputting the EPOCH of the original observations.
Convert sexagesimal coordinate string into degrees.
The coordinate string. Valid formats are, e.g., “00 05 08.83239 +67 50 24.0135” or “00:05:08.83239 -67:50:24.0135”. Spaces or colons are allowed as separators for the individual components of the coordinates.
fullOut : boolean, optional
If True, two additional tuples holding the individual components of the right ascension and declination specification will be returned. The default is False.
Right ascension and declination in degrees.
hms, dms : tuples of three floats
If fullOut is True, two tuples of three numbers each will be returned, which hold the individual constituents making up the right ascension (hms) and declination (dms) specifiers in sexagesimal representation.
Convert right ascension and declination from degrees into sexagesimal representation.
Right ascension in degrees.
dec : float
asString : boolean, optional
If True (default), the result will be a string formatted according to the rules specified by fmt .
fmt : tuple of strings, optional
The output format used to create the output string (first ra, second dec). Only used if asString is True (default).
If asString is True (default), a string holding the coordinates is returned, which is formatted according to the rules specified by the fmt parameter. If False, a tuple of two tuples is returned, of which the first holds three numbers representing the right ascension (hms) and the second three numbers representing the declination (dms, sign).
Convert hour-minute-second specification into degrees.
The corresponding angle in degrees.
Convert degrees into time units (hours-minutes-seconds)
Hours, minutes, and seconds
Convert degree-arcminute-arcsecond specification into degrees.
esign : int, optional,
Explicit sign with -1 representing negative sign, +1 representing positive sign, and 0 indicating no explicit sign specification. The explicit sign is necessary if negative southern coordinates are specified but d is 0 and, thus, cannot carry the sign.
The corresponding angle in degrees.
Convert degrees into arc units (degrees, (arc)minutes, (arc)seconds)
Degrees, (arc)minutes, and (arc)seconds. Note that only the degree number is signed. The sign (+1/-1) is also returned to yield a complete result if the value of degree (d) is zero.
Download an image¶
Now that we have a SkyCoord object, we can try to use it to access data from the Sloan Digitial Sky Survey (SDSS). Let’s start by trying to get a picture using the SDSS image cutout service to make sure HCG 7 is in the SDSS footprint and has good image quality.
This requires an internet connection, but if it fails, don’t worry: the file is included in the repository so you can just let it use the local file 'HCG7_SDSS_cutout.jpg' , defined at the top of the cell.
FK5 equinox and epoch J2000.0, to topocentric observed¶
Topocentric observed azimuth and elevation (and zenith distance) for an observer at the default location (KPNO) is calculated for 2010/1/1 mid-day. The final state i.e., apparent topocentric Az & El, is 19 .
For midnight 2010/1/1 this object is below the horizon and hence the refraction calculations are not reliable. So we use mid-day for the following example.
To calculate the observed hour angle and declination the v6_app vector obtained above can be used as input. We don’t need to go back to the FK5 equinox and epoch J2000.0 values. The input state is now 19 and the output, i.e., topocentric observed HA & Dec, is 20 .
To calculate the observed RA we need to find the LAST, since TPM only provides apparent RA. The observed RA can be found by subtracting hour angle from LAST. This is one situation where we need to access the underlying TPM machinery provided in pytpm.tpm .
The same calculation with SLALIB, using sla_aop produces results that agree with PyTPM.
The hour angle, declination and right ascension are:
See Comparison of PyTPM with SLALIB for a more detailed comparison between PyTPM and SLALIB.
A question about ra and Dec coordinates for objects.
I believe the measurement is at the time of the Spring Equinox.
Which will occur at a specific time on March whatever, 20th this year, varies from 19th to 21st, but precise time I am unaware of.
Spring Equinox 2019 in Northern Hemisphere will be at 21:58 on Wednesday, 20 March
So at 21:58 on March 20 GMT/UTC measurements will be made. At least it allows astronomers in the UK to measure objects. Likely too light in the US for visual measurements.
I am not sure if Sidereal of 00:00 comes into it, cannot really see why it should but they may take measurements then relate all back to some datum.
Try explaining RA+Dec to a person, really takes some thinking.
As you can see by the time the sun breaking the horizon is not relevant.
At a weekly outreach that has a nice big RA display - the values being Hour, Minutes, Seconds and decimal seconds I get asked it about 5 times a night. What is that clock showing?
And I am still not sure I am correct, well fully.
From what I can tell, at the equinox, 21:58 on March 20 if a star/object is on your meridian then that object has that Longitude. Then that longitude is converted back to a time.
Now whether that time is then measured from 00:00 UTC or 0 longitude I am unsure. In effect convert to Time and subtract 21:58. Half suspect not, but .
What gets me is every week people always ask. I would like the display turned off - life would be easier. But as usually someone hangs on the end of the scope and so it moves it has to be on to recenter the scope.
Actually with the time this year of the equinox I wonder if anyone at the university will be making a measurement of the records.
The easy explanation is that it is the Longitude of the object converted fron longitude to time by 1 hour = 15 degrees East or West. The longitude measurement being made at the date and time of the equinox. By that stage most are suitably confused. Forget if it is then related to 00:00 or 0 Longitude, that just add confusion.
I have never heard of the Longitude/Time being referenced back to anything.
#6 Michael Covington
Right ascension and declination rotate with the sky -- they do not change with time of day.
They do change slightly from year to year, which is why you will see epoch 1950, epoch 2000, and epoch of current date. But the change over those periods is well under a degree.
The whole sky rotates around the earth (or seems to, because the earth is turning). The right ascension of the point directly overhead is called the sidereal time.
When you think about it it is the sort of once a year event where "citizen science" could come in to use. The possible problem being the time has to be precise and the meridian location has to be precise.
But otherwise just think of the potentially available measurements. However I suspect the required accuracy would be the downfall. Shame.
Let's neglect precession and proper motion for the moment. They are not significant over periods of a few years. The declination (Dec.) and right ascension (R.A.) coordinates are fixed values for any given star or deep sky object. For instance, the star Pollux is always at approximately 07:46:29 R.A. and +27º 58' 43" Dec. These coordinates are analogous to latitude and longitude coordinates for the sky. Solar system objects have varying right ascension and declination coordinates, since they move against the background of "fixed stars".
The R.A. of an object gives you the sidereal time that the object crosses the meridian. Sidereal time is a local time based on your longitude and the position of the stars in the sky. Thus Pollux will always cross the meridian at sidereal time 07:46:29.
Note that sidereal time units differ slightly from normal time units. There are 24 sidereal hours in a sidereal day, but that sidereal day is roughly four minutes shorter than a solar day.
Edited by ascii, 24 February 2019 - 09:15 PM.
This site has a nice overview star chart set that shows right ascension and declination scales, plus the dates of the Sun's position along the ecliptic. It can help in visualizing things.
Is that supposed to be the object's location in the sky when sidereal time is 00:00?
Don't make it unnecessarily complicated. RA and DEC is absolute just like latitude an longitude. The "zero-zero" location is utterly arbitrary and utterly irrelevant. Each place on Earth has a unique latitude and longitude. Each point in he sky "dome" above Earth likewise has a unique "latitude and longitude" (called "RA" and "Dec").
The German equatorial mount is a simple geometric design optimized to take advantage of the equatorial celestial grid system. The grid uses the earths poles projected to infinity. You align the axial pole of the mount with the axial pole of earth and sky relative to earth by setting the mount's altitude to negate your own latitude. That is the pole of the mount becomes parallel to the rotational pole of earth and sky. Once you have that your two mount axes, perpendicular to one another, are perfectly orthogonal to the celestial grid system.
Put a target of known RA and Dec in your eyepiece. Set RA and Dec analog setting circles to match the catalog or atlas coordinates of that object, and the sky is yours using the setting circles on a GEM. Where and why the "zero hour" was placed where it was placed on the grid isn't necessary to being able to use the system to find targets.
Edited by jrbarnett, 02 March 2019 - 10:15 PM.
Here is an analog. Declination (Dec) is latitude, while Right Ascension (RA) is longitude. It does change as there is 1950 and 2000 epoch, but is not much.
Edited by Ptarmigan, 03 March 2019 - 12:55 PM.
#14 Michael Covington
I think the part of this that people find hard is right ascension.
Declination is easy. It's latitude in the sky, relative to the earth's equator. Stars whose declination equals your latitude are able to pass overhead at your location.
Right ascension is longitude in the same set of coordinates. It is measured in hours rather than degrees, for reasons we'll get to.
But with a rotating and orbiting earth, right ascension does not stay fixed relative to your position. If the earth only rotated, and didn't orbit the sun, the whole cycle of right ascension, from 0 to 23:59 and back to 0, would go around you every 24 hours, and "sidereal time" (the right ascension of the point directly overhead) would be the same as time measured the ordinary way (with some fixed offset to match your time zone).
As it is, the orbit of the earth around the sun throws this off slightly, so a "sidereal day" (the time taken for a star to come back to the same position in your sky) is about 23 hours and 56 minutes. That discrepancy allows the constellations to rotate through the seasons, so you don't see the same stars at midnight in the summer as in the winter. (The physical reason for this is that we've orbited around to the opposite side of the sun.)
It is also why a sidereal clock, and a sidereal telescope drive, do not run at the same speed as an ordinary clock. Back in the 1960s many of us were acutely aware that it's hard to build a sidereal telescope drive from parts intended for electric clocks and timers we settled for solar-rate drives. Now that it's easy to control the speed of a motor electronically, all telescope drives are capable of sidereal rate. (And solar rate, for people observing the sun, and an approximate lunar rate for people who want to try to keep up with the moon as it orbits the earth.)
A.2. Positions in the Milky Way¶
To describe the dynamics of the Milky Way, we require various coordinate frames. The basic coordinate frame that astronomical measurements are reported in is the equatorial system, which is a spherical coordinate system centered in the Earth with a longitudinal angle called right ascension (RA) and a latitudinal angle called declination (Dec). The radial direction is the distance from Earth, but note that for the purpose of Galactic astronomy the difference between distances measured from the Sun and the Earth is negligible.
A more convenient coordinate system for studying the Milky Way is that of Galactic coordinates. This is simply a rotation of the equatorial system, such that the resulting system is aligned with the Milky Way. Specifically, Galactic coordinates are still centered on the Earth and the radial direction remains distance. The latitudinal angle ( (b) ) is such that an angle of zero is the (approximate position of the) Galactic midplane as seen from Earth and the longitudinal angle ( (l) ) is such that an angle of zero at latitude zero points towards the (approximate position of the) Galactic center. Note that we do not follow the convention for spherical coordinates agreed to above here, because (b=0) at the midplane rather than the pole (welcome to astronomy!). We won’t go into detail of how to transform from equatorial coordinates to Galactic coordinates take a look at these notes for a detailed discussion of the definition of the equatorial and Galactic coordinate systems and how to transform coordinates between them. In practice, if you are given coordinates in the equatorial coordinate system, you can transform them to Galactic coordinates using astropy. For example, to transform (RA,Dec) = ((120^circ,30^circ)) to Galactic coordinates ((l,b)) we setup a SkyCoord object for the given (RA,Dec) and ask for this position in Galactic coordinates (the SkyCoord class does the transformation internally):
There have been various definitions of equatorial coordinates over the last few decades, but unless you are told otherwise, coordinates that you are handed are probably in the ICRS frame. RA and Dec can be specified in a large variety of ways (no, not just in degrees as would be handy, but in things like “hours, minutes, seconds” and such) astropy can deal with most of these. SkyCoord also works for array, so this works for example
The cartesian frame associated with Galactic coordinates has coordinates ((X,Y,Z)) and velocities traditionally given as ((U,V,W)) . The coordinates are simply computed as
where (D) is the distance. Because (l = 0) corresponds to the Galactic center, (X) is positive going towards the Galactic center and negative going away from it. Confusingly, ((X,Y,Z)) is a left-handed coordinate system (Y) is positive in the direction of Galactic rotation (which is perpendicular to the Sun–Galactic center line). (Z) is positive towards the North Galactic Pole (NGP). We discuss velocities further below. astropy can also compute these cartesian coordinates. To do this, you also need to specify the distance in the SkyCoord instantiation and then ask for the output in cartesian Galactic coordinates:
Galactic coordinates are useful only when we study the structure (in position, velocity, or chemistry) of the solar neighborhood. When we investigate the Milky Way on a global scale, we use Galactocentric coordinates that have the Galactic center as their zero point. Specifically, we will define Galactocentric coordinates as the left-handed coordinate system that has the Galactic center at its center, with (x) increasing in the disk midplane towards the location of the Sun, (y) increasing in the disk midplane perpendicular to (x) in the direction of Galactic rotation at the Sun’s position, and (z) increasing towards the direction of the North Galactic Pole. To convert from Galactic coordinates to these Galactocentric coordinates, we need to know the Sun’s position with respect to the Galactic center and with respect to the Galactic midplane. Neither of these quantities are perfectly known at the present time and they are uncertain enough (especially the distance to the center) that the uncertainty affects our interpretation of Galactic dynamics. Roughly, the Sun is located about (z_odot = 25) pc above the Galactic midplane and about (R_0 = 8.1) kpc from the Galactic center. Note that because the Sun is not located in the Galactic midplane (although see Bovy (2017)), the (b=0) plane does not exactly line up with the Galactic midplane and a slight rotation (through an angle that is approximate equal to (z_odot/R_0) ) is necessary to go between the two coordinate systems (see here for some additional explanation of this). Again, we can use astropy ’s coordinate-transformation utilities to convert positions to the Galactocentric coordinate frame. One subtlety is that astropy uses a right-handed coordinate system instead of the left-handed, where the Sun is located at negative (x) and (x) increases away from the Sun. This means that the (x) coordinate is flipped with respect to the left-handed frame. For the ((R_0,z_odot)) pair given in this paragraph, we can then transform to the right-handed Galactocentric frame as (using the same example as we have been using throughout this section):
and the position in the left-handed Galactocentric frame is the same, except that the sign of (x) is flipped (and is therefore (x=9.34605497) kpc in this example. To get the cylindrical Galactocentric coordinates, we set the representation to be cylindrical:
Here the angle is again in the right-handed coordinate system. (180^circ-) this angle gives the angle in the left-handed coordinate system.
Of course, we could also start from Galactic coordinates (starting from Galactic coordinates approximately equal to those above):
StarData: proper motion of a star in HelioCoordinates
I am not an astronomer, but am trying to calculate the trajectory of an interstellar space probe, for example to Proxima Centauri. The HelioCoordinates seem appropriate, as typically used within the solar system. (I am assuming HelioCoordinates is an ecliptic Cartesian coordinate system centered on the Sun. Unfortunately StarData "Definition" is missing for "HelioCoordinates" and all the other properties I have checked.) But I am having difficulty with characterizing the proper motion of Proxima in these coordinates. As a check, I used a nearby star Hadar for comparison -- since it is much farther away, its proper motion is small. This is confirmed:
Now I try to calculate the same motion in heliocoordinates. The results don't agree with the reported proper motion, and further are almost identical for the two stars:
I conclude that there are two things going on: (a) StarData in HelioCoordates does not take into account the proper motion of the star (it just uses data from an epoch, even though it seems to accept a date) and (b) what I am seeing is a change in star position due to the rotational motion of the solar system. Or in other words, in HelioCoordinates the far star field is moving slowly due to a rotational motion of the solar system ecliptic plane. Is my interpretation correct? If so, what is the best way to characterize the position of Proxima Centauri in HelioCoordinates that does take the star's proper motion into account? Or perhaps I should be using a different coordinate system from the get-go?
Addition: After further investigation it seems clear that the variation in star positions I am seeing is not due to proper motion but rather due to the precession/nutation of the heliocentric coordinate system in question. I have therefore decided to do all my space probe trajectory calculations in the heliocentric coordinates, so at least they are consistent. Then I will have to characterize the star proper motion separately from that. I would criticize Wolfram for not properly documenting what database they are using or its limitations. No wonder nobody has answered my question.