From julien.montillaud at univ-fcomte.fr Wed Jul 1 11:16:14 2020 From: julien.montillaud at univ-fcomte.fr (julien.montillaud at univ-fcomte.fr) Date: Wed, 1 Jul 2020 17:16:14 +0200 (CEST) Subject: [AstroPy] Dependence on field order in astroquery In-Reply-To: References: Message-ID: <1128689177.93191691.1593616574172.JavaMail.zimbra@univ-fcomte.fr> Hi, I am using astroquery to query Gaia data as follows: from astroquery.vizier import Vizier import astropy.coordinates as coord import astropy.units as u v1 = Vizier(columns=['phot_g_mean_mag', 'parallax', 'a_g_val', 'phot_bp_mean_mag', 'phot_rp_mean_mag']) v1.ROW_LIMIT = -1 c_l, c_b = 298.1, -0.1 query_angle = 0.25 raw_los2 = v1.query_region(coord.SkyCoord(l=c_l, b=c_b, unit=(u.deg, u.deg), frame="galactic"), radius=query_angle*u.deg, catalog="I/345/gaia2") print(raw_los2) With this code, I get: > TableList with 1 tables: > '0:I/345/gaia2' with 5 column(s) and 69866 row(s) But if I invert the bp and rp bands in the "v1 = ..." line, I get this: > Empty TableList Of course I could just use the order that works, but it depends on the line of sight, so in a loop, sometimes it works, sometimes it does not, and I did not figure out the underlying logic. Am I doing something wrong or is there something weird here? Thanks ! Julien -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.g.ginsburg at gmail.com Wed Jul 1 11:31:03 2020 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Wed, 1 Jul 2020 11:31:03 -0400 Subject: [AstroPy] Dependence on field order in astroquery In-Reply-To: <1128689177.93191691.1593616574172.JavaMail.zimbra@univ-fcomte.fr> References: <1128689177.93191691.1593616574172.JavaMail.zimbra@univ-fcomte.fr> Message-ID: Hi Julien, Thanks for raising this issue and giving a complete minimum working example. It would be better posted as an issue on our issue tracker: https://github.com/astropy/astroquery/issues That said, I can't reproduce the problem - I get good results with either order. I suspect you may have a cached query that was bad. You can try clearing the cache with: https://docs.astropy.org/en/stable/api/astropy.utils.data.clear_download_cache.html or by removing files in ~/.astropy/cache/astroquery/Vizier/ (which is the default cache directory) On Wed, Jul 1, 2020 at 11:22 AM wrote: > Hi, > > I am using astroquery to query Gaia data as follows: > > from astroquery.vizier import Vizier > import astropy.coordinates as coord > import astropy.units as u > > v1 = Vizier(columns=['phot_g_mean_mag', 'parallax', 'a_g_val', > 'phot_bp_mean_mag', 'phot_rp_mean_mag']) > v1.ROW_LIMIT = -1 > > c_l, c_b = 298.1, -0.1 > query_angle = 0.25 > raw_los2 = v1.query_region(coord.SkyCoord(l=c_l, b=c_b, unit=(u.deg, > u.deg), frame="galactic"), radius=query_angle*u.deg, catalog="I/345/gaia2") > print(raw_los2) > > With this code, I get: > > TableList with 1 tables: > > '0:I/345/gaia2' with 5 column(s) and 69866 row(s) > > But if I invert the bp and rp bands in the "v1 = ..." line, I get this: > > Empty TableList > > Of course I could just use the order that works, but it depends on the > line of sight, so in a loop, sometimes it works, sometimes it does not, and > I did not figure out the underlying logic. > > Am I doing something wrong or is there something weird here? > > > Thanks ! > Julien > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adam Ginsburg Assistant Professor, Department of Astronomy University of Florida, Gainesville http://www.adamgginsburg.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.montillaud at univ-fcomte.fr Fri Jul 3 04:59:14 2020 From: julien.montillaud at univ-fcomte.fr (julien.montillaud at univ-fcomte.fr) Date: Fri, 3 Jul 2020 10:59:14 +0200 (CEST) Subject: [AstroPy] Dependence on field order in astroquery In-Reply-To: References: <1128689177.93191691.1593616574172.JavaMail.zimbra@univ-fcomte.fr> Message-ID: <1851875877.94645989.1593766754844.JavaMail.zimbra@univ-fcomte.fr> Hi Adam, Thanks, that was it! I have opened (and closed) an issue as you suggested, with the question, your answer, and the positive conclusion, in case someone else faces the same problem. Best, Julien ----- Le 1 Juil 20, ? 17:31, Adam Ginsburg a ?crit : Hi Julien, Thanks for raising this issue and giving a complete minimum working example. It would be better posted as an issue on our issue tracker: [ https://github.com/astropy/astroquery/issues/ | https://github.com/astropy/astroquery/issues ] That said, I can't reproduce the problem - I get good results with either order. I suspect you may have a cached query that was bad. You can try clearing the cache with: [ https://docs.astropy.org/en/stable/api/astropy.utils.data.clear_download_cache.html | https://docs.astropy.org/en/stable/api/astropy.utils.data.clear_download_cache.html ] or by removing files in ~/.astropy/cache/astroquery/Vizier/ (which is the default cache directory) _______________________________________________ AstroPy mailing list AstroPy at python.org https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdzwig at summaventures.com Thu Jul 9 12:22:44 2020 From: pdzwig at summaventures.com (Peter Dzwig) Date: Thu, 9 Jul 2020 17:22:44 +0100 Subject: [AstroPy] Specutils: use of Gaussians and estimators Message-ID: <4ae21feb-0ec9-6d15-2455-ae10928f7602@summaventures.com> I am running the "simple example" from specutils as a precursor to doing some line-fitting. The demo code is here: https://specutils.readthedocs.io/en/stable/fitting.html This runs and does pretty much what it says. However I want to use estimate_line_parameters to get an approximation to the parameters in the Gaussian, because I am interested in looking at a number of long spectra with a lot of lines in. So I modify the specutils.fitting import to from specutils.fitting import fit_lines, estimate_line_parameters and add in e1 = estimate_line_parameters(spectrum, models.Gaussian1D()) a = round(e1.amplitude.value,2) b = round(e1.fwhm.value,2) c = round(e1.stddev.value,2) This gives meaningful values and I replace the call to the Gaussian and the plot by: g_init = models.Gaussian1D(amplitude=a*u.Jy, mean=b*u.um, stddev=c*u.um) then g_fit = fit_lines(spectrum, g_init) y_fit = g_fit(x*u.um) The initial values are: initial amplitude= 3.35 initial fwhm = 2.41 initial stddev= 1.02 But on looking at the output parameters using g_fit.amplitude.value etc, I get: final amplitude= -0.24 Jy final fwhm = 0.0 um final stddev= 0.0 um for the output values!! Surely it should be possible to use estimators in this way. Am I mistaken? FWIW I am running matplotlib 3.2.2, specutils 1.0, pyspeckit 0.1.23, numpy 1.19, python 3.6 over Ubuntu 19.10 Anyone any thoughts? Peter Dzwig -- Dr. Peter Dzwig From J.Hatchell at exeter.ac.uk Tue Jul 14 08:33:51 2020 From: J.Hatchell at exeter.ac.uk (Hatchell, Jenny) Date: Tue, 14 Jul 2020 12:33:51 +0000 Subject: [AstroPy] Discrepancy between astropy.constants parsec and au values? Message-ID: <92F7E50D-40E0-4EE6-8C48-B714DBF18C56@exeter.ac.uk> A colleague of mine points out that the value of a parsec in astropy.constants/units differs from that calculated from astronomical units after the 10th decimal place. The IAU fixed the astronomical unit in 2012 (resolution B2) to 149 597 870 700 m exactly, https://www.iau.org/static/resolutions/IAU2012_English.pdf and the parsec follows from the au so should be exactly a factor 180 * 3600 / pi larger. Comparing the calculated value with the stored value in astropy.constants shows the discrepancy - # AU to pc check # AU copied from IAU 2012 resolution B2 AU = 149597870700 print(AU * 180*3600 / np.pi) print(const.au * 180*3600 / np.pi) print(const.pc.value) 3.085677581491367e+16 3.085677581491367e+16 m 3.0856775814671916e+16 astropy version 4.0.1.post1 None of those values have any uncertainties, and although np.pi has a limited precision it is available to more than 10 d.p. Of course, it?s unlikely that anyone needs this level of precision when astronomical distances are typically only known to a few %. Best wishes Jenny --- Dr. Jennifer Hatchell Senior Lecturer in Astrophysics University of Exeter +44 (0)1392 725516 Standard working pattern: Tue-Thu and Fri AM. Currently working from home. -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Tue Jul 14 09:43:45 2020 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Tue, 14 Jul 2020 15:43:45 +0200 Subject: [AstroPy] Discrepancy between astropy.constants parsec and au values? In-Reply-To: <92F7E50D-40E0-4EE6-8C48-B714DBF18C56@exeter.ac.uk> References: <92F7E50D-40E0-4EE6-8C48-B714DBF18C56@exeter.ac.uk> Message-ID: Hi Jenny, > > A colleague of mine points out that the value of a parsec in astropy.constants/units differs from that calculated from astronomical units after the 10th decimal place. > > The IAU fixed the astronomical unit in 2012 (resolution B2) to 149 597 870 700 m exactly, > https://www.iau.org/static/resolutions/IAU2012_English.pdf > and the parsec follows from the au so should be exactly a factor 180 * 3600 / pi larger. > > Comparing the calculated value with the stored value in astropy.constants shows the discrepancy - > > # AU to pc check > # AU copied from IAU 2012 resolution B2 > AU = 149597870700 > print(AU * 180*3600 / np.pi) > print(const.au * 180*3600 / np.pi) > print(const.pc.value) > > 3.085677581491367e+16 > 3.085677581491367e+16 m > 3.0856775814671916e+16 > > > astropy version 4.0.1.post1 > > None of those values have any uncertainties, and although np.pi has a limited precision it is available to more than 10 d.p. > > Of course, it?s unlikely that anyone needs this level of precision when astronomical distances are typically only known to a few %. > it appears that astropy.constants defines the parsec as the distance of a 1?-parallax source to the Sun. print(const.au / np.tan(np.pi / 180*3600)) 3.0856775814671916e+16 m accordingly reproduces the const.pc value (just to check on numpy's tangent builtin, I confirmed that this is also identical to the 2nd order expansion const.au / ((np.pi / 180*3600) + (np.pi / 180*3600)**3 / 3) within float64 precision. Probably because this definition conflicts with the how people will calculate and use distances for smaller parallaxes, IAU 2015 resolution B2 (which is in fact explicitly listed as the reference in iau2015.py) states that "4 The parsec is defined as exactly (648 000/?) au (e.g. Cox 2000, Binney & Tremaine 2008)." which is 30 856 775 814 913 673 m, 3 metres longer than the numbers you calculated (float64 precision ;-). Thanks for the bug report! Derek From J.Hatchell at exeter.ac.uk Thu Jul 16 05:17:31 2020 From: J.Hatchell at exeter.ac.uk (Hatchell, Jenny) Date: Thu, 16 Jul 2020 09:17:31 +0000 Subject: [AstroPy] AstroPy Digest, Vol 166, Issue 4 In-Reply-To: References: Message-ID: Derek, thanks for looking into this. I must admit I?ve never calculated a parallax using anything other than the small angle approx., so it?s good to be reminded that there could be a tangent in the calculation. The IAU parsec definition is buried in a note at the bottom of a resolution on a completely different topic (zero points for magnitude scales), so it's easy to miss. Best wishes Jenny --- Dr. Jennifer Hatchell Senior Lecturer in Astrophysics University of Exeter +44 (0)1392 725516 Standard working pattern: Tue-Thu and Fri AM. Currently working from home. On 14 Jul 2020, at 17:00, astropy-request at python.org wrote: CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Send AstroPy mailing list submissions to astropy at python.org To subscribe or unsubscribe via the World Wide Web, visit https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fastropy&data=02%7C01%7CJ.Hatchell%40exeter.ac.uk%7Cb1f8616e3b47499b478b08d8280f18c5%7C912a5d77fb984eeeaf321334d8f04a53%7C0%7C1%7C637303392592405338&sdata=ARuvgsFGnu4HE7Q2Y21gJTFeC04%2Bt7ptCc9MDymPNM8%3D&reserved=0 or, via email, send a message with subject or body 'help' to astropy-request at python.org You can reach the person managing the list at astropy-owner at python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of AstroPy digest..." Today's Topics: 1. Discrepancy between astropy.constants parsec and au values? (Hatchell, Jenny) 2. Re: Discrepancy between astropy.constants parsec and au values? (Derek Homeier) ---------------------------------------------------------------------- Message: 1 Date: Tue, 14 Jul 2020 12:33:51 +0000 From: "Hatchell, Jenny" > To: "astropy at python.org" > Subject: [AstroPy] Discrepancy between astropy.constants parsec and au values? Message-ID: <92F7E50D-40E0-4EE6-8C48-B714DBF18C56 at exeter.ac.uk> Content-Type: text/plain; charset="utf-8" A colleague of mine points out that the value of a parsec in astropy.constants/units differs from that calculated from astronomical units after the 10th decimal place. The IAU fixed the astronomical unit in 2012 (resolution B2) to 149 597 870 700 m exactly, https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iau.org%2Fstatic%2Fresolutions%2FIAU2012_English.pdf&data=02%7C01%7CJ.Hatchell%40exeter.ac.uk%7Cb1f8616e3b47499b478b08d8280f18c5%7C912a5d77fb984eeeaf321334d8f04a53%7C0%7C1%7C637303392592405338&sdata=Y3bPohKF9BRxAK%2BxwYT53pu1zfC5Dgs7q16qUpDPY2M%3D&reserved=0 and the parsec follows from the au so should be exactly a factor 180 * 3600 / pi larger. Comparing the calculated value with the stored value in astropy.constants shows the discrepancy - # AU to pc check # AU copied from IAU 2012 resolution B2 AU = 149597870700 print(AU * 180*3600 / np.pi) print(const.au * 180*3600 / np.pi) print(const.pc.value) 3.085677581491367e+16 3.085677581491367e+16 m 3.0856775814671916e+16 astropy version 4.0.1.post1 None of those values have any uncertainties, and although np.pi has a limited precision it is available to more than 10 d.p. Of course, it?s unlikely that anyone needs this level of precision when astronomical distances are typically only known to a few %. Best wishes Jenny --- Dr. Jennifer Hatchell Senior Lecturer in Astrophysics University of Exeter +44 (0)1392 725516 Standard working pattern: Tue-Thu and Fri AM. Currently working from home. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 14 Jul 2020 15:43:45 +0200 From: Derek Homeier To: Astronomical Python mailing list Subject: Re: [AstroPy] Discrepancy between astropy.constants parsec and au values? Message-ID: Content-Type: text/plain; charset=utf-8 Hi Jenny, A colleague of mine points out that the value of a parsec in astropy.constants/units differs from that calculated from astronomical units after the 10th decimal place. The IAU fixed the astronomical unit in 2012 (resolution B2) to 149 597 870 700 m exactly, https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iau.org%2Fstatic%2Fresolutions%2FIAU2012_English.pdf&data=02%7C01%7CJ.Hatchell%40exeter.ac.uk%7Cb1f8616e3b47499b478b08d8280f18c5%7C912a5d77fb984eeeaf321334d8f04a53%7C0%7C1%7C637303392592405338&sdata=Y3bPohKF9BRxAK%2BxwYT53pu1zfC5Dgs7q16qUpDPY2M%3D&reserved=0 and the parsec follows from the au so should be exactly a factor 180 * 3600 / pi larger. Comparing the calculated value with the stored value in astropy.constants shows the discrepancy - # AU to pc check # AU copied from IAU 2012 resolution B2 AU = 149597870700 print(AU * 180*3600 / np.pi) print(const.au * 180*3600 / np.pi) print(const.pc.value) 3.085677581491367e+16 3.085677581491367e+16 m 3.0856775814671916e+16 astropy version 4.0.1.post1 None of those values have any uncertainties, and although np.pi has a limited precision it is available to more than 10 d.p. Of course, it?s unlikely that anyone needs this level of precision when astronomical distances are typically only known to a few %. it appears that astropy.constants defines the parsec as the distance of a 1?-parallax source to the Sun. print(const.au / np.tan(np.pi / 180*3600)) 3.0856775814671916e+16 m accordingly reproduces the const.pc value (just to check on numpy's tangent builtin, I confirmed that this is also identical to the 2nd order expansion const.au / ((np.pi / 180*3600) + (np.pi / 180*3600)**3 / 3) within float64 precision. Probably because this definition conflicts with the how people will calculate and use distances for smaller parallaxes, IAU 2015 resolution B2 (which is in fact explicitly listed as the reference in iau2015.py) states that "4 The parsec is defined as exactly (648 000/?) au (e.g. Cox 2000, Binney & Tremaine 2008)." which is 30 856 775 814 913 673 m, 3 metres longer than the numbers you calculated (float64 precision ;-). Thanks for the bug report! Derek ------------------------------ Subject: Digest Footer _______________________________________________ AstroPy mailing list AstroPy at python.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fastropy&data=02%7C01%7CJ.Hatchell%40exeter.ac.uk%7Cb1f8616e3b47499b478b08d8280f18c5%7C912a5d77fb984eeeaf321334d8f04a53%7C0%7C1%7C637303392592405338&sdata=ARuvgsFGnu4HE7Q2Y21gJTFeC04%2Bt7ptCc9MDymPNM8%3D&reserved=0 ------------------------------ End of AstroPy Digest, Vol 166, Issue 4 *************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at astro.physik.uni-goettingen.de Thu Jul 16 08:25:32 2020 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Thu, 16 Jul 2020 14:25:32 +0200 Subject: [AstroPy] Discrepancy between astropy.constants parsec and au values? In-Reply-To: References: Message-ID: On 16 Jul 2020, at 11:17 am, Hatchell, Jenny wrote: > > Derek, thanks for looking into this. I must admit I?ve never calculated a parallax using anything other than the small angle approx., so it?s good to be reminded that there could be a tangent in the calculation. > > The IAU parsec definition is buried in a note at the bottom of a resolution on a completely different topic (zero points for magnitude scales), so it's easy to miss. > It is actually of course based on the definition of the AU from 2012 B2; I guess they did not realise they had not clarified the parallax method until the next GA, but since that is even quoted in the docstring, it is good to become consistent. Fixed for Astropy 4.0.2. As the difference runs up to ~1.6 AU on a kpc, which would be somewhat below the distance change between two consecutive parallax measurements for typical Galactic RVs, it is indeed unlikely to be noticed, but thanks again for the bug report! Cheers, Derek From derek at astro.physik.uni-goettingen.de Sat Jul 18 12:12:34 2020 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Sat, 18 Jul 2020 18:12:34 +0200 Subject: [AstroPy] [EXTERNAL] Help with negative-dex type unit In-Reply-To: <32A53D9C-8514-4092-A2C7-0B24AE5CBA9D@jpl.nasa.gov> References: <86A79BD0-B371-4F56-BB56-D06EF486C5B6@jpl.nasa.gov> <7093EB26-A835-4061-BC5D-D9CB92C68581@astro.physik.uni-goettingen.de> <32A53D9C-8514-4092-A2C7-0B24AE5CBA9D@jpl.nasa.gov> Message-ID: Hi Nathaniel, > On 30 Jun 2020, at 5:34 am, Livesey, Nathaniel J (US 3290) wrote: > > Many thanks indeed, that did exactly what I had in mind. Much appreciated! by way of a late follow-up, this topic just came up again amidst some more general discussion on logarithmic units. Summary: there is a 1-step recommended alternative zhPa = u.LogUnit(u.hPa, '-1 dex') More details on https://github.com/astropy/astropy/issues/10577 ? suggestions for how to better document this are very welcome. Cheers, Derek From arkay7777 at gmail.com Mon Jul 20 23:07:43 2020 From: arkay7777 at gmail.com (Ar Kay) Date: Mon, 20 Jul 2020 22:07:43 -0500 Subject: [AstroPy] Question about ecliptic coordinate calculations Message-ID: Hello, I am an amateur who is learning my way through basic astronomy. I was interested in learning how to calculate the position of the moon given a time and location. I would like to compare these results to those from JPL Horizons. to make sure that I am on the right track To that end, I ran the following code: import astropy.units as u from astropy.coordinates import GeocentricTrueEcliptic, EarthLocation, AltAz, GCRS, get_moon, HeliocentricTrueEcliptic from astropy.time import Time import pendulum as pnd # greenwich observatory observerTime = Time(pnd.datetime(2020,7,21,18,0,tz=pnd.timezone('UTC'))) # observerLoc = EarthLocation(lat=(51+28/60+38.6/3600)*u.deg, lon=0*u.deg, height=65.8*u.meter) observerLoc = EarthLocation(lat=51.4773207*u.deg, lon=0*u.deg, height=67.0693*u.meter) # print observer information print(observerTime) print(observerLoc) print(observerLoc.geodetic) print("="*40, sep="") # get moon coordinates in GCRS moon_greenwich = get_moon(time=observerTime, location=observerLoc) print(moon_greenwich) print("="*40, sep="") # transform to various frames print(moon_greenwich.transform_to(AltAz(obstime=observerTime, location=observerLoc, pressure=1010*u.mbar, temperature=15*u.deg_C, obswl=0.5*u.micrometer))) # (270.91328479, 24.99375504, 3.70873971e+08) print("="*40, sep="") print(moon_greenwich.transform_to(GeocentricTrueEcliptic(equinox='J2000'))) # (132.26275734, 3.59188144, 373604.2078838) print("="*40, sep="") print(moon_greenwich.transform_to(HeliocentricTrueEcliptic(equinox='J2000'))) # (299.10543868, 0.0123854, 1.51638686e+08) print("="*40, sep="") I am comparing the results with JPL Horizons, set up as follows: Ephemeris Type [change] : OBSERVER Target Body [change] : Moon [Luna] [301] Observer Location [change] : Greenwich [000] ( 0?00'00.0''E, 51?28'38.6''N, 65.8 m ) Time Span [change] : discrete time(s)=2020-07-21 18:00 Table Settings [change] : QUANTITIES=4,10,18,31; refraction model=REFRACTED Display/Output [change] : default (formatted HTML) which produces: ***************************************************************************************************** Date__(UT)__HR:MN:SC.fff Azi_(r-apprnt)_Elev Illu% hEcl-Lon hEcl-Lat r-ObsEcLon r-ObsEcLat ***************************************************************************************************** $$SOE 2020-Jul-21 18:00:00.000 *m 270.91314 24.99602 1.29926 299.1093 0.0110 132.1879950 2.8266398 $$EOE ***************************************************************************************************** The AltAz and HeliocentricTrueEcliptic results compare nicely with JPL Horizons, better than 10 arcsec. However, the GeocentricTrueEcliptic results diverge. I can see that we're calculating GeocentricTrueEcliptic and JPL Horizons is calculating the observer (topocentric) ecliptic. However, when I switch the observer to geocentric (Body = 500) in JPL Horizon the ecliptic longitude results are still not as accurate (>1000 arcsec) as I would have expected. Refraction does not make a difference, which makes sense to me. ***************************************************************************************************** Date__(UT)__HR:MN:SC.fff Azi_(r-apprnt)_Elev Illu% hEcl-Lon hEcl-Lat r-ObsEcLon r-ObsEcLat ***************************************************************************************************** $$SOE 2020-Jul-21 18:00:00.000 n.a. n.a. 1.41112 299.1093 0.0110 132.5498898 3.5949470 $$EOE ***************************************************************************************************** Which brings me to my questions: 1) Why is there an apparent discrepancy between Astropy and JPL Horizons when it comes to the ecliptic longitude only? 2) How do I transform the GeocentricTrueEcliptic coordinates into topocentric (observer) ecliptic coordinates? Thank you for making Astropy so awesome! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathaniel.j.livesey at jpl.nasa.gov Mon Jul 20 23:41:14 2020 From: nathaniel.j.livesey at jpl.nasa.gov (Livesey, Nathaniel J (US 3290)) Date: Tue, 21 Jul 2020 03:41:14 +0000 Subject: [AstroPy] [EXTERNAL] Help with negative-dex type unit In-Reply-To: References: <86A79BD0-B371-4F56-BB56-D06EF486C5B6@jpl.nasa.gov> <7093EB26-A835-4061-BC5D-D9CB92C68581@astro.physik.uni-goettingen.de> <32A53D9C-8514-4092-A2C7-0B24AE5CBA9D@jpl.nasa.gov> Message-ID: <468BDC4B-FA1C-49C0-B327-CF1E7F2334A1@jpl.nasa.gov> Hi Derek, Thanks for this pointer. I?m afraid, in the end, I opted not to follow your initially very helpful suggestion. While that approach (and the one below) did exactly what I'd been seeking, it also behaved more logarithmically than I?d bargained for. Specifically, in using it as a vertical coordinate, I wanted addition and other operators to work in an essentially linear sense. For example, given z=-3zhPa (1000hPa, Earth?s surface, more or less), I wanted to be able to add 1zhPa to it to get -2zhPa (100hPa, ~16km altitude). However, and completely correctly from a mathematical point of view, we actually get: >>> -3*zhPa + 1*zhPa (note the hPa-squared). However, all was far from lost, as astropy.unit?s equivalencies came to my aid. I instead defined: zUnit = units.def_unit("-log(p/hPa") zetaEquivalencies = [(pUnit, zUnit, lambda p: -np.log10(p), lambda z: 10.0**(-z))] This has worked fine for me thus far. Many thanks to you, and to all involved in putting together a really nicely put together toolset. Yours, Nathaniel Nathaniel Livesey Mail Stop 183-701, Jet Propulsion Laboratory 4800 Oak Grove Drive, Pasadena, California 91109. Phone: +1 818 354-4214 Fax: +1 818 393-5065 > On Jul 18, 2020, at 9:12 AM, Derek Homeier wrote: > > Hi Nathaniel, > >> On 30 Jun 2020, at 5:34 am, Livesey, Nathaniel J (US 3290) wrote: >> >> Many thanks indeed, that did exactly what I had in mind. Much appreciated! > > by way of a late follow-up, this topic just came up again amidst some more general discussion on logarithmic units. > > Summary: there is a 1-step recommended alternative > > zhPa = u.LogUnit(u.hPa, '-1 dex') > > More details on > https://github.com/astropy/astropy/issues/10577 > > ? suggestions for how to better document this are very welcome. > > Cheers, > Derek > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy From rspencercarr at gmail.com Tue Jul 21 10:30:26 2020 From: rspencercarr at gmail.com (Robert Carr) Date: Tue, 21 Jul 2020 10:30:26 -0400 Subject: [AstroPy] Astroquery Using Vizier: How Do I Retrieve SDSS Photo Object Attribute "flags"? Message-ID: I hope that this question is "in bounds," Astroquery being an Astropy affiliated package. I am querying the SDSS-12 catalog for photometric data using Vizier. The SDSS field "flags" would be ideal to help me assess the photometric quality of the SDSS measurements for each object: this field includes a hexadecimal code that captures issues with the photometry such as pixel saturation, etc. My query line is: targetobj = Vizier.query_region(STAR_NAME, radius=field_of_view * u.deg, catalog = 'SDSS12') The line in my code to collect 'flags' does not work (where targetobjresults is my results from querying SDSS): targetobjresults.append({'flags': targetobj[0]['flags'][0]}) I receive the following error message, which I have discovered is because Vizier returns only 23 columns of the SDSS data. Traceback (most recent call last): File "", line 32, in File "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ astropy\table\table.py", line 1222, in __getitem__ return self.columns[item] File "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ astropy\table\table.py", line 106, in __getitem__ return OrderedDict.__getitem__(self, item) KeyError: 'flags' Is there a way to query SDSS through Vizier to get the hexadecimal 'flags' for each object? Or is there another workaround? I appreciate guidance on how to make this happen. Thank you! Bob C Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.g.ginsburg at gmail.com Tue Jul 21 10:44:16 2020 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Tue, 21 Jul 2020 10:44:16 -0400 Subject: [AstroPy] Astroquery Using Vizier: How Do I Retrieve SDSS Photo Object Attribute "flags"? In-Reply-To: References: Message-ID: If you want to include additional columns in vizier queries, follow these instructions: https://astroquery.readthedocs.io/en/latest/vizier/vizier.html#specifying-keywords-output-columns-and-constraints-on-columns for example, to get *all* columns, you would do: Vizier(columns=["**"]).query_region(coordinates.SkyCoord(180*u.deg, 0*u.deg, frame='fk5'), radius=field_of_view * u.deg, catalog = 'SDSS12') note the double-asterisks On Tue, Jul 21, 2020 at 10:30 AM Robert Carr wrote: > I hope that this question is "in bounds," Astroquery being an Astropy affiliated > package. > > I am querying the SDSS-12 catalog for photometric data using Vizier. The > SDSS field "flags" would be ideal to help me assess the photometric quality > of the SDSS measurements for each object: this field includes a hexadecimal > code that captures issues with the photometry such as pixel saturation, > etc. > > My query line is: > targetobj = Vizier.query_region(STAR_NAME, radius=field_of_view * > u.deg, catalog = 'SDSS12') > > The line in my code to collect 'flags' does not work (where > targetobjresults is my results from querying SDSS): > > targetobjresults.append({'flags': targetobj[0]['flags'][0]}) > > > I receive the following error message, which I have discovered is because Vizier > returns only 23 columns of the SDSS data. > Traceback (most recent call last): > > File "", line 32, in > > File > "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ > astropy\table\table.py", line 1222, in __getitem__ > > return self.columns[item] > > File > "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ > astropy\table\table.py", line 106, in __getitem__ > > return OrderedDict.__getitem__(self, item) > > KeyError: 'flags' > > > Is there a way to query SDSS through Vizier to get the hexadecimal 'flags' > for each object? Or is there another workaround? I appreciate guidance on > how to make this happen. > > Thank you! > > Bob C > > > > Virus-free. > www.avast.com > > <#m_4046137496446091284_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adam Ginsburg Assistant Professor, Department of Astronomy University of Florida, Gainesville http://www.adamgginsburg.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bovy at astro.utoronto.ca Wed Jul 22 11:10:31 2020 From: bovy at astro.utoronto.ca (Jo Bovy) Date: Wed, 22 Jul 2020 11:10:31 -0400 Subject: [AstroPy] ANN: sphinx-astroref Message-ID: Hi all, I developed a small Sphinx extension to format bibliographic references in an astronomy-like style in Sphinx documents that may be of interest to people on this list: * Documentation: https://sphinx-astrorefs.readthedocs.io/ * Code: https://github.com/jobovy/sphinx-astrorefs * Install: pip install sphinx-astrorefs sphinxcontrib-bibtex Specifically, this extension allows you to: 1) Format references in the bibliography in a style similar to that used in astro journals using the 'astrostyle' pybtex style: alphabetically by author, ApJ-like formatting of the authors, and linking to the DOI, ADS, and arXiv entry (note that unlike journals, I do include the title, but that would be easy to turn off) 2) Reference as author (year), (author year), or author year (i.e., \citet, \citep, and \citealt in natbib) 3) Directly use ADS bibtex entries in the bibtex file (i.e., without having to replace the \apj etc. AAS macros). The formatting style in 1) could be easily changed by adding a pybtex style similar to 'astrostyle' included here. The syntax for getting 2) to work is a little hacky, but it works (but if anybody has a better suggestion, I'd be interested to hear it!). Currently the extension works for 'html' and 'latex' Sphinx builds and it also works on readthedocs. If you find any issues or for other feedback, please open an issue on the GitHub page. Best, Jo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rspencercarr at gmail.com Sat Jul 25 20:19:06 2020 From: rspencercarr at gmail.com (Robert Carr) Date: Sat, 25 Jul 2020 20:19:06 -0400 Subject: [AstroPy] Astroquery Using Vizier: How Do I Retrieve SDSS Photo Object Attribute "flags"? (Adam Ginsburg) Message-ID: Thank you, Prof Ginsburg. Your advice was very helpful. It was good to know that the flags were accessible. The tweak worked fine on a standalone basis but within my code perhaps it hit another constraint. When I run *calibrators = Vizier.query_region(coord.SkyCoord(ra=TRA, dec=TDEC, unit=(u.deg, u.deg),frame='icrs'), radius=field_of_view * u.deg, catalog = 'SDSS12')* I get 3361 calibrators for my parameters, which I subsequently whittle down When I run *calibrators = Vizier(columns=['**']).query_region(coord.SkyCoord(ra=TRA, dec=TDEC, unit=(u.deg, u.deg),frame='icrs'), radius=field_of_view * u.deg, catalog = 'SDSS12') * I get only 50 calibrators for my parameters, which leaves me with nothing to whittle! Am I running afoul of a constraint? Vizier pulls down 23 default columns and there are 140 or so total, so the cut seems a bit too dramatic. If I am hitting a constraint, I will need to specify each of my columns up front. Thanks again, Bob C. ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Jul 2020 10:44:16 -0400 From: Adam Ginsburg To: Astronomical Python mailing list Subject: Re: [AstroPy] Astroquery Using Vizier: How Do I Retrieve SDSS Photo Object Attribute "flags"? Message-ID: Content-Type: text/plain; charset="utf-8" If you want to include additional columns in vizier queries, follow these instructions: https://astroquery.readthedocs.io/en/latest/vizier/vizier.html#specifying-keywords-output-columns-and-constraints-on-columns for example, to get *all* columns, you would do: Vizier(columns=["**"]).query_region(coordinates.SkyCoord(180*u.deg, 0*u.deg, frame='fk5'), radius=field_of_view * u.deg, catalog = 'SDSS12') note the double-asterisks On Tue, Jul 21, 2020 at 10:30 AM Robert Carr wrote: > I hope that this question is "in bounds," Astroquery being an Astropy affiliated > package. > > I am querying the SDSS-12 catalog for photometric data using Vizier. The > SDSS field "flags" would be ideal to help me assess the photometric quality > of the SDSS measurements for each object: this field includes a hexadecimal > code that captures issues with the photometry such as pixel saturation, > etc. > > My query line is: > targetobj = Vizier.query_region(STAR_NAME, radius=field_of_view * > u.deg, catalog = 'SDSS12') > > The line in my code to collect 'flags' does not work (where > targetobjresults is my results from querying SDSS): > > targetobjresults.append({'flags': targetobj[0]['flags'][0]}) > > > I receive the following error message, which I have discovered is because Vizier > returns only 23 columns of the SDSS data. > Traceback (most recent call last): > > File "", line 32, in > > File > "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ > astropy\table\table.py", line 1222, in __getitem__ > > return self.columns[item] > > File > "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ > astropy\table\table.py", line 106, in __getitem__ > > return OrderedDict.__getitem__(self, item) > > KeyError: 'flags' > > > Is there a way to query SDSS through Vizier to get the hexadecimal 'flags' > for each object? Or is there another workaround? I appreciate guidance on > how to make this happen. > > Thank you! > > Bob C Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.g.ginsburg at gmail.com Sat Jul 25 22:11:59 2020 From: adam.g.ginsburg at gmail.com (Adam Ginsburg) Date: Sat, 25 Jul 2020 22:11:59 -0400 Subject: [AstroPy] Astroquery Using Vizier: How Do I Retrieve SDSS Photo Object Attribute "flags"? (Adam Ginsburg) In-Reply-To: References: Message-ID: Set vizier.ROW_LIMIT = 5000. You can also do `Vizier(row_limit=5000, columns=['**']).query...`, iirc. On Sat, Jul 25, 2020 at 8:19 PM Robert Carr wrote: > Thank you, Prof Ginsburg. Your advice was very helpful. It was good to > know that the flags were accessible. The tweak worked fine on a standalone > basis but within my code perhaps it hit another constraint. > > When I run *calibrators = Vizier.query_region(coord.SkyCoord(ra=TRA, > dec=TDEC, unit=(u.deg, u.deg),frame='icrs'), radius=field_of_view * u.deg, > catalog = 'SDSS12')* > I get 3361 calibrators for my parameters, which I subsequently whittle down > > When I run *calibrators = > Vizier(columns=['**']).query_region(coord.SkyCoord(ra=TRA, dec=TDEC, > unit=(u.deg, u.deg),frame='icrs'), radius=field_of_view * u.deg, catalog = > 'SDSS12') * > I get only 50 calibrators for my parameters, which leaves me with nothing > to whittle! > > Am I running afoul of a constraint? Vizier pulls down 23 default columns > and there are 140 or so total, so the cut seems a bit too dramatic. If I > am hitting a constraint, I will need to specify each of my columns up front. > > Thanks again, > > Bob C. > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2020 10:44:16 -0400 > From: Adam Ginsburg > To: Astronomical Python mailing list > Subject: Re: [AstroPy] Astroquery Using Vizier: How Do I Retrieve SDSS > Photo Object Attribute "flags"? > Message-ID: > BCfUV2+o6VOmwaAm_zCjaCRA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > If you want to include additional columns in vizier queries, follow these > instructions: > > https://astroquery.readthedocs.io/en/latest/vizier/vizier.html#specifying-keywords-output-columns-and-constraints-on-columns > > > for example, to get *all* columns, you would do: > Vizier(columns=["**"]).query_region(coordinates.SkyCoord(180*u.deg, > 0*u.deg, frame='fk5'), radius=field_of_view * u.deg, catalog = 'SDSS12') > note the double-asterisks > > On Tue, Jul 21, 2020 at 10:30 AM Robert Carr > wrote: > > > I hope that this question is "in bounds," Astroquery being an Astropy > affiliated > > package. > > > > I am querying the SDSS-12 catalog for photometric data using Vizier. The > > SDSS field "flags" would be ideal to help me assess the photometric > quality > > of the SDSS measurements for each object: this field includes a > hexadecimal > > code that captures issues with the photometry such as pixel saturation, > > etc. > > > > My query line is: > > targetobj = Vizier.query_region(STAR_NAME, radius=field_of_view * > > u.deg, catalog = 'SDSS12') > > > > The line in my code to collect 'flags' does not work (where > > targetobjresults is my results from querying SDSS): > > > > targetobjresults.append({'flags': targetobj[0]['flags'][0]}) > > > > > > I receive the following error message, which I have discovered is > because Vizier > > returns only 23 columns of the SDSS data. > > Traceback (most recent call last): > > > > File "", line 32, in > > > > File > > > "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ > > astropy\table\table.py", line 1222, in __getitem__ > > > > return self.columns[item] > > > > File > > > "C:\Users\mawgui\AppData\Local\Programs\Python\Python36\lib\site-packages\ > > astropy\table\table.py", line 106, in __getitem__ > > > > return OrderedDict.__getitem__(self, item) > > > > KeyError: 'flags' > > > > > > Is there a way to query SDSS through Vizier to get the hexadecimal > 'flags' > > for each object? Or is there another workaround? I appreciate guidance > on > > how to make this happen. > > > > Thank you! > > > > Bob C > > > Virus-free. > www.avast.com > > <#m_5004871713416873812_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -- Adam Ginsburg Assistant Professor, Department of Astronomy University of Florida, Gainesville http://www.adamgginsburg.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: