From geert.barentsen at gmail.com Sun Jan 8 13:57:02 2017 From: geert.barentsen at gmail.com (Geert Barentsen) Date: Sun, 8 Jan 2017 12:57:02 -0600 Subject: [AstroPy] Python 3.6 appears to be faster than 2.7/3.4/3.5 Message-ID: Dear All, At yesterday's AAS Hack Day (cf. #hackaas on Twitter), I decided to compare the performance of AstroPy between different versions of Python. I thought you may all be interested to see the results, which are shown here: https://twitter.com/GeertHub/status/817857735484198912 Bottom line: the newly-released Python 3.6 appears to triumph over previous versions. I used AstroPy's existing benchmarks located at https://github.com/astropy/astropy-benchmarks, and so these results are only really applicable to the limited set of features being benchmarked there. Another caveat is that I only ran the benchmarks on Linux. It is reasonable to expect the best performance from 3.6 however, given how much effort has gone into performance improvements (e.g. CompactDict). The script used to create the graph is here: https://gist.github.com/barentsen/bd10e5ec13b97171c202e7e5747fa163 Best wishes, Geert -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.f.evans at keele.ac.uk Mon Jan 9 08:11:31 2017 From: d.f.evans at keele.ac.uk (Daniel Evans) Date: Mon, 9 Jan 2017 13:11:31 +0000 Subject: [AstroPy] Offset coordinate by distance and position angle Message-ID: Dear all, I have a set of (RA, Dec) positions of objects, which have companion objects with positions specified by separation (arcsec) and position angle (degrees E of N). I would like to calculate the (RA, Dec) positions of the companion objects from this data. Is there a way to calculate these (RA, Dec) positions within the AstroPy SkyCoord framework (or any other part of AstroPy)? I can find functions to calculate separations from two sets of (RA, Dec) coordinates, or to offset if (deltaRA, deltaDec) are known, but not for separation and P.A.. Regards, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.gallardo.lopez at gmail.com Sat Jan 14 15:33:03 2017 From: f.gallardo.lopez at gmail.com (=?UTF-8?Q?Francisco_Gallardo_l=C3=B3pez?=) Date: Sat, 14 Jan 2017 21:33:03 +0100 Subject: [AstroPy] astropy.vo.client conesearch radius problem? Message-ID: Hi all! I looked in the Internet but I did not find references to this problem, so maybe I'm making something wrong. So I'm using the conesearch from astropy.vo.client to query some catalogs (indeed all the catalogs that are returned by conesearch.list_catalogs() ). The thing is, I'm using a radius of 0.2 seconds of arc and it seems like when querying some catalogs the results seem to be out of that requested radius. For instance, two sources returned by the query were, one at ra=5.602814 deg and another one @ ra=5.536589 deg. That does not happen with the 'Guide Star Catalog v2 1' which seems to work properly, it happens when requesting the The PMM USNO-A1.0 Catalogue (Monet 1997) 1'. Am I missing something or making something wrong or is it a known bug? Thanks a lot! BR Fran Gallardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.gallardo.lopez at gmail.com Mon Jan 16 02:23:37 2017 From: f.gallardo.lopez at gmail.com (=?UTF-8?Q?Francisco_Gallardo_l=C3=B3pez?=) Date: Mon, 16 Jan 2017 08:23:37 +0100 Subject: [AstroPy] astropy.vo.client conesearch radius problem? Message-ID: Hi all! I looked in the Internet but I did not find references to this problem, so maybe I'm making something wrong. So I'm using the conesearch from astropy.vo.client to query some catalogs (indeed all the catalogs that are returned by conesearch.list_catalogs() ). The thing is, I'm using a radius of 0.2 seconds of arc and it seems like when querying some catalogs the results seem to be out of that requested radius. For instance, two sources returned by the query were, one at ra=5.602814 deg and another one @ ra=5.536589 deg. That does not happen with the 'Guide Star Catalog v2 1' which seems to work properly, it happens when requesting the The PMM USNO-A1.0 Catalogue (Monet 1997) 1'. Am I missing something or making something wrong or is it a known bug? Thanks a lot! BR Fran Gallardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From evert.rol at gmail.com Mon Jan 16 02:46:21 2017 From: evert.rol at gmail.com (Evert Rol) Date: Mon, 16 Jan 2017 18:46:21 +1100 Subject: [AstroPy] astropy.vo.client conesearch radius problem? In-Reply-To: References: Message-ID: <59B5781C-63DF-4E4B-9B2C-E85C5A5527AA@gmail.com> Hi Francisco, Could you send a short working code example around that shows the actual problem? Possibly for both the GSC (ok) and the USNO catalogs (not ok). Evert > Hi all! > > I looked in the Internet but I did not find references to this problem, so maybe I'm making something wrong. > > So I'm using the conesearch from astropy.vo.client to query some catalogs (indeed all the catalogs that are returned by conesearch.list_catalogs() ). > > The thing is, I'm using a radius of 0.2 seconds of arc and it seems like when querying some catalogs the results seem to be out of that requested radius. For instance, two sources returned by the query were, one at ra=5.602814 deg and another one @ ra=5.536589 deg. > > That does not happen with the 'Guide Star Catalog v2 1' which seems to work properly, it happens when requesting the The PMM USNO-A1.0 Catalogue (Monet 1997) 1'. > > Am I missing something or making something wrong or is it a known bug? > > Thanks a lot! > BR > Fran Gallardo > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy From f.gallardo.lopez at gmail.com Mon Jan 16 14:57:52 2017 From: f.gallardo.lopez at gmail.com (=?UTF-8?Q?Francisco_Gallardo_l=C3=B3pez?=) Date: Mon, 16 Jan 2017 20:57:52 +0100 Subject: [AstroPy] astropy.vo.client conesearch radius problem? In-Reply-To: <59B5781C-63DF-4E4B-9B2C-E85C5A5527AA@gmail.com> References: <59B5781C-63DF-4E4B-9B2C-E85C5A5527AA@gmail.com> Message-ID: Hi Evert! Thanks a lot for answering. I would say it only happens with the USNO catalogs, both 'The PMM USNO-A1.0 Catalogue (Monet 1997) 1' and 'The USNO-A2.0 Catalogue (Monet+ 1998) 1'. I created a small code to show the thing (please find it attached to this email). It iterates through all the available catalogs and breaks into the debugger as soon as the query returns some sources (with the AR,DEC hard-coded in the program, only USNO catalogs will return sources). It stores the result in the ?temp? variable. No big deal. For instance, with the second catalog (*'The USNO-A2.0 Catalogue (Monet+ 1998) 1')* and the sky position (ra=159*.31*5075782, dec=-27.6515145412): _r USNO-A2.0 RAJ2000 DEJ2000 ... Bmag Rmag Epoch deg deg deg ... mag mag yr float64 str13 float64 float64 ... float32 float32 float64 ---------- ------------- ---------- ---------- ... ------- ------- -------- 0.041089 0600-13508332 159.269631 -27.643284 ... 19.3 17.9 1981.701 0.039111 0600-13508442 159.271653 -27.644431 ... 20.2 17.9 1981.701 0.038170 0600-13508467 159.272078 -27.654039 ... 20.6 17.5 1981.701 0.039771 0600-13508743 159.277409 -27.629875 ... 19.8 17.9 1981.701 0.031614 0600-13508894 159.280334 -27.644278 ... 19.8 17.9 1981.701 0.037095 0600-13509081 159.283342 -27.675723 ... 16.1 15.6 1981.701 ... ... ... ... ... ... ... ... 0.040114 0600-13512624 159.348720 -27.678370 ... 15.9 15.4 1981.701 ========================================================= I would say it is not paying attention to the requested radius. (Again, this does not happen with other catalogs, only with the USNO catalogs) Thanks a lot! BR Fran 2017-01-16 8:46 GMT+01:00 Evert Rol : > Hi Francisco, > > Could you send a short working code example around that shows the actual > problem? > Possibly for both the GSC (ok) and the USNO catalogs (not ok). > > Evert > > > > > Hi all! > > > > I looked in the Internet but I did not find references to this problem, > so maybe I'm making something wrong. > > > > So I'm using the conesearch from astropy.vo.client to query some > catalogs (indeed all the catalogs that are returned by > conesearch.list_catalogs() ). > > > > The thing is, I'm using a radius of 0.2 seconds of arc and it seems like > when querying some catalogs the results seem to be out of that requested > radius. For instance, two sources returned by the query were, one at > ra=5.602814 deg and another one @ ra=5.536589 deg. > > > > That does not happen with the 'Guide Star Catalog v2 1' which seems to > work properly, it happens when requesting the The PMM USNO-A1.0 Catalogue > (Monet 1997) 1'. > > > > Am I missing something or making something wrong or is it a known bug? > > > > Thanks a lot! > > BR > > Fran Gallardo > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > https://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sample.py Type: text/x-script.phyton Size: 492 bytes Desc: not available URL: From d.f.evans at keele.ac.uk Mon Jan 16 15:18:51 2017 From: d.f.evans at keele.ac.uk (Daniel Evans) Date: Mon, 16 Jan 2017 20:18:51 +0000 Subject: [AstroPy] astropy.vo.client conesearch radius problem? In-Reply-To: References: <59B5781C-63DF-4E4B-9B2C-E85C5A5527AA@gmail.com> Message-ID: I'm not entirely sure what radius you're querying, as your quoted coordinates vary by much more than 0.2 arcsec, and the nearest object I can find in USNO-A2.0 is 26 arcsec away. It looks more like you've used 2 degrees? Running the code with 0.20 degrees as the search radius, the RA coordinate values do indeed differ by +-0.22 degrees. However, this is entirely correct, because a change of 0.2 degrees in RA coordinate does not equal an angular separation of 0.2 degrees between two objects (unless you're on the equator). The RA coordinate difference must be multiplied by cos(Dec), so because you're querying at Dec=-27.65, the angular distance along the RA axis is (0.22 degrees) * cos(-27.65) = 0.20 degrees. (If anything, it seems the USNO ought to be congratulated for seemingly being the only catalog providers to remember the cos(Dec) term!) Regards, Daniel On 16 January 2017 at 19:57, Francisco Gallardo l?pez < f.gallardo.lopez at gmail.com> wrote: > Hi Evert! > > Thanks a lot for answering. > > I would say it only happens with the USNO catalogs, both 'The PMM > USNO-A1.0 Catalogue (Monet 1997) 1' and 'The USNO-A2.0 Catalogue (Monet+ > 1998) 1'. > > I created a small code to show the thing (please find it attached to this > email). > > It iterates through all the available catalogs and breaks into the > debugger as soon as the query returns some sources (with the AR,DEC > hard-coded in the program, only USNO catalogs will return sources). It > stores the result in the ?temp? variable. No big deal. > > For instance, with the second catalog (*'The USNO-A2.0 Catalogue (Monet+ > 1998) 1')* and the sky position (ra=159*.31*5075782, dec=-27.6515145412 > <(651)%20514-5412>): > > >
> _r USNO-A2.0 RAJ2000 DEJ2000 ... Bmag Rmag Epoch > deg deg deg ... mag mag yr > float64 str13 float64 float64 ... float32 float32 float64 > ---------- ------------- ---------- ---------- ... ------- ------- -------- > 0.041089 0600-13508332 159.269631 -27.643284 ... 19.3 17.9 > 1981.701 > 0.039111 0600-13508442 159.271653 -27.644431 ... 20.2 17.9 1981.701 > 0.038170 0600-13508467 159.272078 -27.654039 ... 20.6 17.5 1981.701 > 0.039771 0600-13508743 159.277409 -27.629875 ... 19.8 17.9 1981.701 > 0.031614 0600-13508894 159.280334 -27.644278 ... 19.8 17.9 1981.701 > 0.037095 0600-13509081 159.283342 -27.675723 ... 16.1 15.6 1981.701 > ... ... ... ... ... ... ... ... > 0.040114 0600-13512624 159.348720 -27.678370 ... 15.9 15.4 > 1981.701 > > ========================================================= > > > I would say it is not paying attention to the requested radius. (Again, > this does not happen with other catalogs, only with the USNO catalogs) > > Thanks a lot! > BR > Fran > > 2017-01-16 8:46 GMT+01:00 Evert Rol : > >> Hi Francisco, >> >> Could you send a short working code example around that shows the actual >> problem? >> Possibly for both the GSC (ok) and the USNO catalogs (not ok). >> >> Evert >> >> >> >> > Hi all! >> > >> > I looked in the Internet but I did not find references to this problem, >> so maybe I'm making something wrong. >> > >> > So I'm using the conesearch from astropy.vo.client to query some >> catalogs (indeed all the catalogs that are returned by >> conesearch.list_catalogs() ). >> > >> > The thing is, I'm using a radius of 0.2 seconds of arc and it seems >> like when querying some catalogs the results seem to be out of that >> requested radius. For instance, two sources returned by the query were, one >> at ra=5.602814 deg and another one @ ra=5.536589 deg. >> > >> > That does not happen with the 'Guide Star Catalog v2 1' which seems to >> work properly, it happens when requesting the The PMM USNO-A1.0 Catalogue >> (Monet 1997) 1'. >> > >> > Am I missing something or making something wrong or is it a known bug? >> > >> > Thanks a lot! >> > BR >> > Fran Gallardo >> > _______________________________________________ >> > AstroPy mailing list >> > AstroPy at scipy.org >> > https://mail.scipy.org/mailman/listinfo/astropy >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.gallardo.lopez at gmail.com Mon Jan 16 16:20:21 2017 From: f.gallardo.lopez at gmail.com (=?UTF-8?Q?Francisco_Gallardo_l=C3=B3pez?=) Date: Mon, 16 Jan 2017 22:20:21 +0100 Subject: [AstroPy] astropy.vo.client conesearch radius problem? In-Reply-To: References: <59B5781C-63DF-4E4B-9B2C-E85C5A5527AA@gmail.com> Message-ID: Hi Daniel! Thanks a lot for replying. I'm afraid It seems like the attached file was not included (sorry!). Thanks for raising the Cos(dec) term issue. Nonetheless, the code of the example can be found below. As you can see the cone search is as follows: conesearch.conesearch(a,*0.2*u.arcsec* ,catalog_db=k) The radius is 0.2 arcsec (or I may be missing something). As you point out the list I was showing in my last email differs by much more than 0.2 arcsec. That is exactly the problem. Moreover the rest of the catalogs don't show this behavior. If the radius is not wrongly set (please refer to the conesearch, I think it is fine, according to the documentation ), then by no means the resulting list of sources could be so far from the center. If the radius is properly set, I don't think the Cos(dec) term could explain the resulting list with the USNO. Please find below the example code. Do you see something not properly set?. According to what I saw no other catalog is showing this behavior apart of those from USNO. Nonetheless I could be missing something. The rest of the catalogs return only one source (note I'm using a large list of sky positions. For this particular position the only catalogs showing results are the USNO catalogs and it may be due to this problem with the radius as, as you are pointing out, the closer source in USNO catalogs seems to be 26 arcsec away) Thanks a lot! BR Fran ============== #!/usr/bin/python import pdb from astropy.vo.client import conesearch from astropy.coordinates import ICRS from astropy import units as u from astropy.coordinates import SkyCoord def main(): ra=159.315075782 dec=-27.6515145412 a=SkyCoord(ra=float(ra)*u.deg,dec=float(dec)*u.deg,frame='icrs') for k in conesearch.list_catalogs(): try: temp=conesearch.conesearch(a,*0.2*u.arcsec*,catalog_db=k) pdb.set_trace() except: print "Nothing found." if __name__=="__main__": main() 2017-01-16 21:18 GMT+01:00 Daniel Evans : > I'm not entirely sure what radius you're querying, as your quoted > coordinates vary by much more than 0.2 arcsec, and the nearest object I can > find in USNO-A2.0 is 26 arcsec away. It looks more like you've used 2 > degrees? > > Running the code with 0.20 degrees as the search radius, the RA coordinate > values do indeed differ by +-0.22 degrees. However, this is entirely > correct, because a change of 0.2 degrees in RA coordinate does not equal an > angular separation of 0.2 degrees between two objects (unless you're on the > equator). The RA coordinate difference must be multiplied by cos(Dec), so > because you're querying at Dec=-27.65, the angular distance along the RA > axis is (0.22 degrees) * cos(-27.65) = 0.20 degrees. > > (If anything, it seems the USNO ought to be congratulated for seemingly > being the only catalog providers to remember the cos(Dec) term!) > > Regards, > Daniel > > On 16 January 2017 at 19:57, Francisco Gallardo l?pez < > f.gallardo.lopez at gmail.com> wrote: > >> Hi Evert! >> >> Thanks a lot for answering. >> >> I would say it only happens with the USNO catalogs, both 'The PMM >> USNO-A1.0 Catalogue (Monet 1997) 1' and 'The USNO-A2.0 Catalogue (Monet+ >> 1998) 1'. >> >> I created a small code to show the thing (please find it attached to this >> email). >> >> It iterates through all the available catalogs and breaks into the >> debugger as soon as the query returns some sources (with the AR,DEC >> hard-coded in the program, only USNO catalogs will return sources). It >> stores the result in the ?temp? variable. No big deal. >> >> For instance, with the second catalog (*'The USNO-A2.0 Catalogue (Monet+ >> 1998) 1')* and the sky position (ra=159*.31*5075782, dec=-27.6515145412 >> <(651)%20514-5412>): >> >> >>
>> _r USNO-A2.0 RAJ2000 DEJ2000 ... Bmag Rmag >> Epoch >> deg deg deg ... mag mag >> yr >> float64 str13 float64 float64 ... float32 float32 >> float64 >> ---------- ------------- ---------- ---------- ... ------- ------- >> -------- >> 0.041089 0600-13508332 159.269631 -27.643284 ... 19.3 17.9 >> 1981.701 >> 0.039111 0600-13508442 159.271653 -27.644431 ... 20.2 17.9 >> 1981.701 >> 0.038170 0600-13508467 159.272078 -27.654039 ... 20.6 17.5 >> 1981.701 >> 0.039771 0600-13508743 159.277409 -27.629875 ... 19.8 17.9 >> 1981.701 >> 0.031614 0600-13508894 159.280334 -27.644278 ... 19.8 17.9 >> 1981.701 >> 0.037095 0600-13509081 159.283342 -27.675723 ... 16.1 15.6 >> 1981.701 >> ... ... ... ... ... ... ... >> ... >> 0.040114 0600-13512624 159.348720 -27.678370 ... 15.9 15.4 >> 1981.701 >> >> ========================================================= >> >> >> I would say it is not paying attention to the requested radius. (Again, >> this does not happen with other catalogs, only with the USNO catalogs) >> >> Thanks a lot! >> BR >> Fran >> >> 2017-01-16 8:46 GMT+01:00 Evert Rol : >> >>> Hi Francisco, >>> >>> Could you send a short working code example around that shows the actual >>> problem? >>> Possibly for both the GSC (ok) and the USNO catalogs (not ok). >>> >>> Evert >>> >>> >>> >>> > Hi all! >>> > >>> > I looked in the Internet but I did not find references to this >>> problem, so maybe I'm making something wrong. >>> > >>> > So I'm using the conesearch from astropy.vo.client to query some >>> catalogs (indeed all the catalogs that are returned by >>> conesearch.list_catalogs() ). >>> > >>> > The thing is, I'm using a radius of 0.2 seconds of arc and it seems >>> like when querying some catalogs the results seem to be out of that >>> requested radius. For instance, two sources returned by the query were, one >>> at ra=5.602814 deg and another one @ ra=5.536589 deg. >>> > >>> > That does not happen with the 'Guide Star Catalog v2 1' which seems to >>> work properly, it happens when requesting the The PMM USNO-A1.0 Catalogue >>> (Monet 1997) 1'. >>> > >>> > Am I missing something or making something wrong or is it a known bug? >>> > >>> > Thanks a lot! >>> > BR >>> > Fran Gallardo >>> > _______________________________________________ >>> > AstroPy mailing list >>> > AstroPy at scipy.org >>> > https://mail.scipy.org/mailman/listinfo/astropy >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >>> >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.f.evans at keele.ac.uk Mon Jan 16 17:07:48 2017 From: d.f.evans at keele.ac.uk (Daniel Evans) Date: Mon, 16 Jan 2017 22:07:48 +0000 Subject: [AstroPy] astropy.vo.client conesearch radius problem? In-Reply-To: References: <59B5781C-63DF-4E4B-9B2C-E85C5A5527AA@gmail.com> Message-ID: Playing around again, I do now see your problem! I think I hadn't got the output showing correctly before I played with the arcsec/degrees part. After a lot of poking around on the CDS (which is what Astropy is querying for the USNO catalogs), it appears to be a problem with parsing Astropy's preferred format for cone radius. Whilst the CDS allows radius in degrees, arcmin, or arcsec, Astropy is querying with a very small degree value in scientific notation - 5.55...6e-5. For some reason, the CDS parses this scientific notation as "0.000056/0.", which it then interprets as being equal 7.5 arcmin (the VO results returned in your script are truncated at the 50 closest entries). The same incorrect results are returned via the web interface with either "5.5555556e-5" or "0.000056/0.", with units of degrees. Now, whether Astropy is sending queries to the CDS in an unsupported format (with the CDS handling this very strangely), or instead this being a bug with the parser at the CDS, I don't know. Daniel On 16 January 2017 at 21:20, Francisco Gallardo l?pez < f.gallardo.lopez at gmail.com> wrote: > Hi Daniel! > > Thanks a lot for replying. > > I'm afraid It seems like the attached file was not included (sorry!). > > Thanks for raising the Cos(dec) term issue. > > Nonetheless, the code of the example can be found below. As you can see > the cone search is as follows: conesearch.conesearch(a,*0.2*u.arcsec* > ,catalog_db=k) > > The radius is 0.2 arcsec (or I may be missing something). As you point out > the list I was showing in my last email differs by much more than 0.2 > arcsec. That is exactly the problem. Moreover the rest of the catalogs > don't show this behavior. > > If the radius is not wrongly set (please refer to the conesearch, I think > it is fine, according to the documentation > ), > then by no means the resulting list of sources could be so far from the > center. If the radius is properly set, I don't think the Cos(dec) term > could explain the resulting list with the USNO. > > Please find below the example code. Do you see something not properly set?. > According to what I saw no other catalog is showing this behavior apart of > those from USNO. Nonetheless I could be missing something. The rest of the > catalogs return only one source (note I'm using a large list of sky > positions. For this particular position the only catalogs showing results > are the USNO catalogs and it may be due to this problem with the radius as, > as you are pointing out, the closer source in USNO catalogs seems to be 26 > arcsec away) > > > Thanks a lot! > BR > Fran > > > > ============== > > > #!/usr/bin/python > > import pdb > from astropy.vo.client import conesearch > from astropy.coordinates import ICRS > from astropy import units as u > from astropy.coordinates import SkyCoord > > def main(): > ra=159.315075782 > dec=-27.6515145412 <(651)%20514-5412> > a=SkyCoord(ra=float(ra)*u.deg,dec=float(dec)*u.deg,frame='icrs') > for k in conesearch.list_catalogs(): > try: > temp=conesearch.conesearch(a,*0.2*u.arcsec*,catalog_db=k) > pdb.set_trace() > except: > print "Nothing found." > > > > if __name__=="__main__": > main() > > > 2017-01-16 21:18 GMT+01:00 Daniel Evans : > >> I'm not entirely sure what radius you're querying, as your quoted >> coordinates vary by much more than 0.2 arcsec, and the nearest object I can >> find in USNO-A2.0 is 26 arcsec away. It looks more like you've used 2 >> degrees? >> >> Running the code with 0.20 degrees as the search radius, the RA >> coordinate values do indeed differ by +-0.22 degrees. However, this is >> entirely correct, because a change of 0.2 degrees in RA coordinate does not >> equal an angular separation of 0.2 degrees between two objects (unless >> you're on the equator). The RA coordinate difference must be multiplied by >> cos(Dec), so because you're querying at Dec=-27.65, the angular distance >> along the RA axis is (0.22 degrees) * cos(-27.65) = 0.20 degrees. >> >> (If anything, it seems the USNO ought to be congratulated for seemingly >> being the only catalog providers to remember the cos(Dec) term!) >> >> Regards, >> Daniel >> >> On 16 January 2017 at 19:57, Francisco Gallardo l?pez < >> f.gallardo.lopez at gmail.com> wrote: >> >>> Hi Evert! >>> >>> Thanks a lot for answering. >>> >>> I would say it only happens with the USNO catalogs, both 'The PMM >>> USNO-A1.0 Catalogue (Monet 1997) 1' and 'The USNO-A2.0 Catalogue (Monet+ >>> 1998) 1'. >>> >>> I created a small code to show the thing (please find it attached to >>> this email). >>> >>> It iterates through all the available catalogs and breaks into the >>> debugger as soon as the query returns some sources (with the AR,DEC >>> hard-coded in the program, only USNO catalogs will return sources). It >>> stores the result in the ?temp? variable. No big deal. >>> >>> For instance, with the second catalog (*'The USNO-A2.0 Catalogue >>> (Monet+ 1998) 1')* and the sky position (ra=159*.31*5075782, dec=-27. >>> 6515145412 <(651)%20514-5412>): >>> >>> >>>
>>> _r USNO-A2.0 RAJ2000 DEJ2000 ... Bmag Rmag >>> Epoch >>> deg deg deg ... mag mag >>> yr >>> float64 str13 float64 float64 ... float32 float32 >>> float64 >>> ---------- ------------- ---------- ---------- ... ------- ------- >>> -------- >>> 0.041089 0600-13508332 159.269631 -27.643284 ... 19.3 17.9 >>> 1981.701 >>> 0.039111 0600-13508442 159.271653 -27.644431 ... 20.2 17.9 >>> 1981.701 >>> 0.038170 0600-13508467 159.272078 -27.654039 ... 20.6 17.5 >>> 1981.701 >>> 0.039771 0600-13508743 159.277409 -27.629875 ... 19.8 17.9 >>> 1981.701 >>> 0.031614 0600-13508894 159.280334 -27.644278 ... 19.8 17.9 >>> 1981.701 >>> 0.037095 0600-13509081 159.283342 -27.675723 ... 16.1 15.6 >>> 1981.701 >>> ... ... ... ... ... ... ... >>> ... >>> 0.040114 0600-13512624 159.348720 -27.678370 ... 15.9 15.4 >>> 1981.701 >>> >>> ========================================================= >>> >>> >>> I would say it is not paying attention to the requested radius. (Again, >>> this does not happen with other catalogs, only with the USNO catalogs) >>> >>> Thanks a lot! >>> BR >>> Fran >>> >>> 2017-01-16 8:46 GMT+01:00 Evert Rol : >>> >>>> Hi Francisco, >>>> >>>> Could you send a short working code example around that shows the >>>> actual problem? >>>> Possibly for both the GSC (ok) and the USNO catalogs (not ok). >>>> >>>> Evert >>>> >>>> >>>> >>>> > Hi all! >>>> > >>>> > I looked in the Internet but I did not find references to this >>>> problem, so maybe I'm making something wrong. >>>> > >>>> > So I'm using the conesearch from astropy.vo.client to query some >>>> catalogs (indeed all the catalogs that are returned by >>>> conesearch.list_catalogs() ). >>>> > >>>> > The thing is, I'm using a radius of 0.2 seconds of arc and it seems >>>> like when querying some catalogs the results seem to be out of that >>>> requested radius. For instance, two sources returned by the query were, one >>>> at ra=5.602814 deg and another one @ ra=5.536589 deg. >>>> > >>>> > That does not happen with the 'Guide Star Catalog v2 1' which seems >>>> to work properly, it happens when requesting the The PMM USNO-A1.0 >>>> Catalogue (Monet 1997) 1'. >>>> > >>>> > Am I missing something or making something wrong or is it a known bug? >>>> > >>>> > Thanks a lot! >>>> > BR >>>> > Fran Gallardo >>>> > _______________________________________________ >>>> > AstroPy mailing list >>>> > AstroPy at scipy.org >>>> > https://mail.scipy.org/mailman/listinfo/astropy >>>> >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> https://mail.scipy.org/mailman/listinfo/astropy >>>> >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >>> >>> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p3y1i4n at gmail.com Tue Jan 17 16:50:13 2017 From: p3y1i4n at gmail.com (Pey Lian Lim) Date: Tue, 17 Jan 2017 16:50:13 -0500 Subject: [AstroPy] astropy.vo.client conesearch radius problem? Message-ID: Hi, Indeed, I can reproduce the problem reported as well. It does not matter if I set the search radius as you did, convert it to degree first, or manually type out "0.00005555555555556" for those services affected. The fact that the same query works for some services but not the others indicate the problem probably lies with the external service providers (perhaps their search algorithm has some radius min/max limits), which is beyond the control of Astropy. For instance, using the PMM catalog but changing search radius to 0.005 degrees, it correctly says that there is no match. It is best if you raise this issue with the affected service providers. Hope this helps, Pey-Lian (conesearch subpackage maintainer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjw at as.arizona.edu Tue Jan 17 19:40:12 2017 From: bjw at as.arizona.edu (Benjamin Weiner) Date: Tue, 17 Jan 2017 17:40:12 -0700 Subject: [AstroPy] astropy.vo.client conesearch radius problem? Message-ID: ?Hi, I can't speak about the inner workings of either the astropy VO search or the catalog search parsers, but I have a couple of suggestions, the first related to the science goal. 1. The astrometric accuracy of GSC is about 0.2-0.3 arcsec rms and the astrometric accuracy of USNO-B is about 0.2 arcsec (not sure if rms; numbers are from the catalog papers). In general, it's probably not useful to use a matching radius less than 2-3 times the rms accuracy of the catalog, unless you have a specialized application. 2. Doing an astrometric difference of coordinates at less than 1 arcsec or so can underflow a single precision floating point number. So if somewhere in this processing chain is single precision, it risks getting erroneous results. The actual problem here could be something as simple as the CDS parser, but it would be useful to know if the error persists with a larger search radius. Ben > > Message: 1 > Date: Mon, 16 Jan 2017 22:07:48 +0000 > From: Daniel Evans > To: Astronomical Python mailing list > Subject: Re: [AstroPy] astropy.vo.client conesearch radius problem? > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Playing around again, I do now see your problem! I think I hadn't got the > output showing correctly before I played with the arcsec/degrees part. > > After a lot of poking around on the CDS (which is what Astropy is querying > for the USNO catalogs), it appears to be a problem with parsing Astropy's > preferred format for cone radius. Whilst the CDS allows radius in degrees, > arcmin, or arcsec, Astropy is querying with a very small degree value in > scientific notation - 5.55...6e-5. For some reason, the CDS parses this > scientific notation as "0.000056/0.", which it then interprets as being > equal 7.5 arcmin (the VO results returned in your script are truncated at > the 50 closest entries). The same incorrect results are returned via the > web interface with either "5.5555556e-5" or "0.000056/0.", with units of > degrees. > > Now, whether Astropy is sending queries to the CDS in an unsupported format > (with the CDS handling this very strangely), or instead this being a bug > with the parser at the CDS, I don't know. > > Daniel > > On 16 January 2017 at 21:20, Francisco Gallardo l?pez < > f.gallardo.lopez at gmail.com> wrote: > > > Hi Daniel! > > > > Thanks a lot for replying. > > > > I'm afraid It seems like the attached file was not included (sorry!). > > > > Thanks for raising the Cos(dec) term issue. > > > > Nonetheless, the code of the example can be found below. As you can see > > the cone search is as follows: conesearch.conesearch(a,*0.2*u.arcsec* > > ,catalog_db=k) > > > > The radius is 0.2 arcsec (or I may be missing something). As you point > out > > the list I was showing in my last email differs by much more than 0.2 > > arcsec. That is exactly the problem. Moreover the rest of the catalogs > > don't show this behavior. > > > > If the radius is not wrongly set (please refer to the conesearch, I think > > it is fine, according to the documentation > > conesearch.conesearch.html>), > > then by no means the resulting list of sources could be so far from the > > center. If the radius is properly set, I don't think the Cos(dec) term > > could explain the resulting list with the USNO. > > > > Please find below the example code. Do you see something not properly > set?. > > According to what I saw no other catalog is showing this behavior apart > of > > those from USNO. Nonetheless I could be missing something. The rest of > the > > catalogs return only one source (note I'm using a large list of sky > > positions. For this particular position the only catalogs showing results > > are the USNO catalogs and it may be due to this problem with the radius > as, > > as you are pointing out, the closer source in USNO catalogs seems to be > 26 > > arcsec away) > > > > > > Thanks a lot! > > BR > > Fran > > > > > -- Benjamin Weiner Associate Astronomer, Steward Observatory bjw at as.arizona.edu http://mingus.as.arizona.edu/~bjw/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deleenm at nku.edu Tue Jan 24 12:45:45 2017 From: deleenm at nku.edu (Nathan De Lee) Date: Tue, 24 Jan 2017 12:45:45 -0500 Subject: [AstroPy] astropy.modeling.fitting Using Weights in 2d Fits Message-ID: Hi Everyone, I am trying to fit a 2d Gaussian with weights for each data point using the astropy.modeling.fitting in astropy version 1.3. When I try this using a 1d Gaussian model everything seems to work fine, but I am encountering a shape error when I try to do it in the 2d case. The weights have the same shape (21,21) as everything else. The code I used and the error is below. Am I doing something wrong, or is there a bug that I am running into? Thanks for any help you can give, Nathan Code: from astropy.modeling import models,fitting import numpy as np def gaussian(height, center_x, center_y, width_x, width_y): """Returns a gaussian function with the given parameters""" width_x = float(width_x) width_y = float(width_y) return lambda x,y: height*np.exp( -(((center_x-x)/width_x)**2+((center_y-y)/width_y)**2)/2) Xin, Yin = np.mgrid[0:21, 0:21] y = gaussian(10, 10, 9, 2, 3)(Xin, Yin) #Add gaussian noise to the function with a random sigma between 0.1 and 1.1 ysig = 1*np.random.rand(Xin.shape[0],Xin.shape[1]) + 0.1 y = y + np.random.normal(0., ysig, Xin.shape) #Fit the data gauss2d_init = models.Gaussian2D(amplitude=15, x_mean=5, y_mean=5, x_stddev=1, y_stddev=1, theta=0) fit_gauss2d = fitting.LevMarLSQFitter() gmod = fit_gauss2d(gauss2d_init, Xin, Yin, y,weights=1.0/ysig) Error: --------------------------------------------------------------------------- ValueError Traceback (most recent call last) in() 12 print(y.shape)13 fit_gauss2d = fitting.LevMarLSQFitter()---> 14gmod = fit_gauss2d(gauss2d_init, Xin, Yin, y,weights=1.0/ysig)15 print(fit_gauss2d.fit_info.keys())16 print("{} {} {} {} {} {}".format(*gmod.param_names))/home/deleenm/anaconda2/lib/python2.7/site-packages/astropy/modeling/fitting.pyc in __call__(self, model, x, y, z, weights, maxiter, acc, epsilon, estimate_jacobian) 558 self.objective_function, init_values, args=farg, Dfun=dfunc,559 col_deriv=model_copy.col_fit_deriv, maxfev=maxiter, epsfcn=epsilon,--> 560xtol=acc, full_output=True) 561 _fitter_to_model_params(model_copy, fitparams)562 self.fit_info.update(dinfo)/home/deleenm/anaconda2/lib/python2.7/site-packages/scipy/optimize/minpack.pyc in leastsq(func, x0, args, Dfun, full_output, col_deriv, ftol, xtol, gtol, maxfev, epsfcn, factor, diag) 388 else:389 if col_deriv:--> 390_check_func('leastsq', 'Dfun', Dfun, x0, args, n, (n, m))391 else:392 _check_func('leastsq', 'Dfun', Dfun, x0, args, n, (m, n))/home/deleenm/anaconda2/lib/python2.7/site-packages/scipy/optimize/minpack.pyc in _check_func(checker, argname, thefunc, x0, args, numinputs, output_shape) 24 def _check_func(checker, argname, thefunc, x0, args, numinputs, 25 output_shape=None): ---> 26res = atleast_1d(thefunc(*((x0[:numinputs],) + args)))27 if (output_shape is not None) and (shape(res) != output_shape):28 if (output_shape[0] != 1):/home/deleenm/anaconda2/lib/python2.7/site-packages/astropy/modeling/fitting.pyc in _wrap_deriv(params, model, weights, x, y, z) 620 return [np.ravel(_) for _ in np.ravel(weights) * np.array(model.fit_deriv(x, *params))]621 else:--> 622return [np.ravel(_) for _ in (np.ravel(weights) * np.array(model.fit_deriv(x, y, *params)).T).T]623 624 ValueError: operands could not be broadcast together with shapes (441,) (21,21,6) -- Dr. Nathan De Lee Assistant Professor of Astronomy and Physics Northern Kentucky University 151 Science Center 1 Nunn Drive Highland Heights, KY 41099 Tel: 859-572-5492 Fax: 859-572-6092 www.nku.edu/~deleen1 deleenm at nku.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dencheva at stsci.edu Wed Jan 25 10:18:03 2017 From: dencheva at stsci.edu (Nadia Dencheva) Date: Wed, 25 Jan 2017 15:18:03 +0000 Subject: [AstroPy] astropy.modeling.fitting Using Weights in 2d Fits In-Reply-To: References: Message-ID: <0153364C9F56D944B0A795780ECF88DF68DC82AB@EXCHMAIL2.stsci.edu> Hi Natan, This looks like a bug. Could you file an issue on github https://github.com/astropy/astropy/issueshttps://github.com/astropy/astropy/issues Thanks, Nadia ________________________________ From: AstroPy [astropy-bounces at scipy.org] on behalf of Nathan De Lee [deleenm at nku.edu] Sent: Tuesday, January 24, 2017 12:45 PM To: astropy at scipy.org Subject: [AstroPy] astropy.modeling.fitting Using Weights in 2d Fits Hi Everyone, I am trying to fit a 2d Gaussian with weights for each data point using the astropy.modeling.fitting in astropy version 1.3. When I try this using a 1d Gaussian model everything seems to work fine, but I am encountering a shape error when I try to do it in the 2d case. The weights have the same shape (21,21) as everything else. The code I used and the error is below. Am I doing something wrong, or is there a bug that I am running into? Thanks for any help you can give, Nathan Code: from astropy.modeling import models,fitting import numpy as np def gaussian(height, center_x, center_y, width_x, width_y): """Returns a gaussian function with the given parameters""" width_x = float(width_x) width_y = float(width_y) return lambda x,y: height*np.exp( -(((center_x-x)/width_x)**2+((center_y-y)/width_y)**2)/2) Xin, Yin = np.mgrid[0:21, 0:21] y = gaussian(10, 10, 9, 2, 3)(Xin, Yin) #Add gaussian noise to the function with a random sigma between 0.1 and 1.1 ysig = 1*np.random.rand(Xin.shape[0],Xin.shape[1]) + 0.1 y = y + np.random.normal(0., ysig, Xin.shape) #Fit the data gauss2d_init = models.Gaussian2D(amplitude=15, x_mean=5, y_mean=5, x_stddev=1, y_stddev=1, theta=0) fit_gauss2d = fitting.LevMarLSQFitter() gmod = fit_gauss2d(gauss2d_init, Xin, Yin, y,weights=1.0/ysig) Error: --------------------------------------------------------------------------- ValueError Traceback (most recent call last) in () 12 print(y.shape) 13 fit_gauss2d = fitting.LevMarLSQFitter() ---> 14 gmod = fit_gauss2d(gauss2d_init, Xin, Yin, y,weights=1.0/ysig) 15 print(fit_gauss2d.fit_info.keys()) 16 print("{} {} {} {} {} {}".format(*gmod.param_names)) /home/deleenm/anaconda2/lib/python2.7/site-packages/astropy/modeling/fitting.pyc in __call__(self, model, x, y, z, weights, maxiter, acc, epsilon, estimate_jacobian) 558 self.objective_function, init_values, args=farg, Dfun=dfunc, 559 col_deriv=model_copy.col_fit_deriv, maxfev=maxiter, epsfcn=epsilon, --> 560 xtol=acc, full_output=True) 561 _fitter_to_model_params(model_copy, fitparams) 562 self.fit_info.update(dinfo) /home/deleenm/anaconda2/lib/python2.7/site-packages/scipy/optimize/minpack.pyc in leastsq(func, x0, args, Dfun, full_output, col_deriv, ftol, xtol, gtol, maxfev, epsfcn, factor, diag) 388 else: 389 if col_deriv: --> 390 _check_func('leastsq', 'Dfun', Dfun, x0, args, n, (n, m)) 391 else: 392 _check_func('leastsq', 'Dfun', Dfun, x0, args, n, (m, n)) /home/deleenm/anaconda2/lib/python2.7/site-packages/scipy/optimize/minpack.pyc in _check_func(checker, argname, thefunc, x0, args, numinputs, output_shape) 24 def _check_func(checker, argname, thefunc, x0, args, numinputs, 25 output_shape=None): ---> 26 res = atleast_1d(thefunc(*((x0[:numinputs],) + args))) 27 if (output_shape is not None) and (shape(res) != output_shape): 28 if (output_shape[0] != 1): /home/deleenm/anaconda2/lib/python2.7/site-packages/astropy/modeling/fitting.pyc in _wrap_deriv(params, model, weights, x, y, z) 620 return [np.ravel(_) for _ in np.ravel(weights) * np.array(model.fit_deriv(x, *params))] 621 else: --> 622 return [np.ravel(_) for _ in (np.ravel(weights) * np.array(model.fit_deriv(x, y, *params)).T).T] 623 624 ValueError: operands could not be broadcast together with shapes (441,) (21,21,6) -- Dr. Nathan De Lee Assistant Professor of Astronomy and Physics Northern Kentucky University 151 Science Center 1 Nunn Drive Highland Heights, KY 41099 Tel: 859-572-5492 Fax: 859-572-6092 www.nku.edu/~deleen1 deleenm at nku.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From masato.onodera at gmail.com Wed Jan 25 22:00:16 2017 From: masato.onodera at gmail.com (Masato Onodera) Date: Wed, 25 Jan 2017 17:00:16 -1000 Subject: [AstroPy] Fail to build documentation for astropy 1.3 Message-ID: Hello,? I'd like to build a documentation of astropy-1.3 to look at it when I'm not connected to the internet. ?I followed the instruction (http://docs.astropy.org/en/stable/install.html#building-documentation), but either ways do not work for me producing the following error message (this is for the case of "python setup.py build_docs"). ?I also tried both python 2.7 and 3.5 and got the same error. ? Are there any ideas how to fix this? Best regards, Masato Onodera Running Sphinx v1.5.1 loading pickled environment... not yet created loading intersphinx inventory from http://docs.python.org/2/objects.inv... intersphinx inventory has moved: http://docs.python.org/2/objects.inv -> https://docs.python.org/2/objects.inv loading intersphinx inventory from http://matplotlib.org/objects.inv... loading intersphinx inventory from http://pandas.pydata.org/pandas-docs/stable/objects.inv... loading intersphinx inventory from http://ipython.readthedocs.io/en/stable/objects.inv... loading intersphinx inventory from http://docs.scipy.org/doc/scipy/reference/objects.inv... intersphinx inventory has moved: http://docs.scipy.org/doc/scipy/reference/objects.inv -> https://docs.scipy.org/doc/scipy/reference/objects.inv loading intersphinx inventory from http://pytest.org/latest/objects.inv... intersphinx inventory has moved: http://pytest.org/latest/objects.inv -> http://docs.pytest.org/en/latest/objects.inv loading intersphinx inventory from http://docs.h5py.org/en/latest/objects.inv... loading intersphinx inventory from http://docs.scipy.org/doc/numpy/objects.inv... intersphinx inventory has moved: http://docs.scipy.org/doc/numpy/objects.inv -> https://docs.scipy.org/doc/numpy/objects.inv loading intersphinx inventory from /Users/monodera/packages/astropy-1.3/astropy_helpers/astropy_helpers/sphinx/local/python2_local_links.inv... [autosummary] generating autosummary for: analytic_functions/index.rst, changelog.rst, config/config_0_4_transition.rst, config/index.rst, constants/index.rst, convolution/index.rst, convolution/kernels.rst, convolution/using.rst, coordinates/angles.rst, coordinates/definitions.rst, ..., wcs/relax.rst, whatsnew/0.1.rst, whatsnew/0.2.rst, whatsnew/0.3.rst, whatsnew/0.4.rst, whatsnew/1.0.rst, whatsnew/1.1.rst, whatsnew/1.2.rst, whatsnew/1.3.rst, whatsnew/index.rst [automodsumm] vo/conesearch/index.rst: found 27 automodsumm entries to generate [automodsumm] time/index.rst: found 30 automodsumm entries to generate [automodsumm] io/ascii/index.rst: found 55 automodsumm entries to generate [automodsumm] convolution/index.rst: found 22 automodsumm entries to generate [automodsumm] stats/index.rst: found 34 automodsumm entries to generate [automodsumm] vo/samp/index.rst: found 11 automodsumm entries to generate [automodsumm] constants/index.rst: found 2 automodsumm entries to generate [automodsumm] nddata/utils.rst: found 9 automodsumm entries to generate [automodsumm] units/index.rst: found 86 automodsumm entries to generate [automodsumm] logging.rst: found 3 automodsumm entries to generate [automodsumm] cosmology/index.rst: found 11 automodsumm entries to generate [automodsumm] visualization/wcsaxes/index.rst: found 10 automodsumm entries to generate [automodsumm] io/votable/index.rst: found 33 automodsumm entries to generate [automodsumm] config/index.rst: found 10 automodsumm entries to generate [automodsumm] io/misc.rst: found 9 automodsumm entries to generate [automodsumm] utils/index.rst: found 91 automodsumm entries to generate [automodsumm] io/registry.rst: found 11 automodsumm entries to generate [automodsumm] testhelpers.rst: found 13 automodsumm entries to generate [automodsumm] wcs/index.rst: found 30 automodsumm entries to generate [automodsumm] table/index.rst: found 22 automodsumm entries to generate [automodsumm] visualization/index.rst: found 27 automodsumm entries to generate [automodsumm] coordinates/index.rst: found 69 automodsumm entries to generate [automodsumm] modeling/index.rst: found 189 automodsumm entries to generate [automodsumm] nddata/index.rst: found 33 automodsumm entries to generate [automodsumm] analytic_functions/index.rst: found 2 automodsumm entries to generate ________________________________________________________________________________ Example directory ../examples does not have a README.txt file Skipping this directory ________________________________________________________________________________ Traceback (most recent call last): ? File "", line 39, in NameError: name 'self' is not defined Sphinx Documentation subprocess failed with return code 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Deil at mpi-hd.mpg.de Thu Jan 26 02:42:15 2017 From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil) Date: Thu, 26 Jan 2017 08:42:15 +0100 Subject: [AstroPy] Fail to build documentation for astropy 1.3 In-Reply-To: References: Message-ID: <9F75A0B0-279B-4A4C-B4F6-946806466C7B@mpi-hd.mpg.de> > On 26 Jan 2017, at 04:00, Masato Onodera wrote: > > Hello, > > I'd like to build a documentation of astropy-1.3 to look at it when I'm not connected to the internet. I followed the instruction (http://docs.astropy.org/en/stable/install.html#building-documentation ), but either ways do not work for me producing the following error message (this is for the case of "python setup.py build_docs"). I also tried both python 2.7 and 3.5 and got the same error. Are there any ideas how to fix this? > > Best regards, > Masato Onodera > > > Running Sphinx v1.5.1 > loading pickled environment... not yet created > loading intersphinx inventory from http://docs.python.org/2/objects.inv ... > intersphinx inventory has moved: http://docs.python.org/2/objects.inv -> https://docs.python.org/2/objects.inv > loading intersphinx inventory from http://matplotlib.org/objects.inv ... > loading intersphinx inventory from http://pandas.pydata.org/pandas-docs/stable/objects.inv ... > loading intersphinx inventory from http://ipython.readthedocs.io/en/stable/objects.inv ... > loading intersphinx inventory from http://docs.scipy.org/doc/scipy/reference/objects.inv ... > intersphinx inventory has moved: http://docs.scipy.org/doc/scipy/reference/objects.inv -> https://docs.scipy.org/doc/scipy/reference/objects.inv > loading intersphinx inventory from http://pytest.org/latest/objects.inv ... > intersphinx inventory has moved: http://pytest.org/latest/objects.inv -> http://docs.pytest.org/en/latest/objects.inv > loading intersphinx inventory from http://docs.h5py.org/en/latest/objects.inv ... > loading intersphinx inventory from http://docs.scipy.org/doc/numpy/objects.inv ... > intersphinx inventory has moved: http://docs.scipy.org/doc/numpy/objects.inv -> https://docs.scipy.org/doc/numpy/objects.inv > loading intersphinx inventory from /Users/monodera/packages/astropy-1.3/astropy_helpers/astropy_helpers/sphinx/local/python2_local_links.inv... > [autosummary] generating autosummary for: analytic_functions/index.rst, changelog.rst, config/config_0_4_transition.rst, config/index.rst, constants/index.rst, convolution/index.rst, convolution/kernels.rst, convolution/using.rst, coordinates/angles.rst, coordinates/definitions.rst, ..., wcs/relax.rst, whatsnew/0.1.rst, whatsnew/0.2.rst, whatsnew/0.3.rst, whatsnew/0.4.rst, whatsnew/1.0.rst, whatsnew/1.1.rst, whatsnew/1.2.rst, whatsnew/1.3.rst, whatsnew/index.rst > [automodsumm] vo/conesearch/index.rst: found 27 automodsumm entries to generate > [automodsumm] time/index.rst: found 30 automodsumm entries to generate > [automodsumm] io/ascii/index.rst: found 55 automodsumm entries to generate > [automodsumm] convolution/index.rst: found 22 automodsumm entries to generate > [automodsumm] stats/index.rst: found 34 automodsumm entries to generate > [automodsumm] vo/samp/index.rst: found 11 automodsumm entries to generate > [automodsumm] constants/index.rst: found 2 automodsumm entries to generate > [automodsumm] nddata/utils.rst: found 9 automodsumm entries to generate > [automodsumm] units/index.rst: found 86 automodsumm entries to generate > [automodsumm] logging.rst: found 3 automodsumm entries to generate > [automodsumm] cosmology/index.rst: found 11 automodsumm entries to generate > [automodsumm] visualization/wcsaxes/index.rst: found 10 automodsumm entries to generate > [automodsumm] io/votable/index.rst: found 33 automodsumm entries to generate > [automodsumm] config/index.rst: found 10 automodsumm entries to generate > [automodsumm] io/misc.rst: found 9 automodsumm entries to generate > [automodsumm] utils/index.rst: found 91 automodsumm entries to generate > [automodsumm] io/registry.rst: found 11 automodsumm entries to generate > [automodsumm] testhelpers.rst: found 13 automodsumm entries to generate > [automodsumm] wcs/index.rst: found 30 automodsumm entries to generate > [automodsumm] table/index.rst: found 22 automodsumm entries to generate > [automodsumm] visualization/index.rst: found 27 automodsumm entries to generate > [automodsumm] coordinates/index.rst: found 69 automodsumm entries to generate > [automodsumm] modeling/index.rst: found 189 automodsumm entries to generate > [automodsumm] nddata/index.rst: found 33 automodsumm entries to generate > [automodsumm] analytic_functions/index.rst: found 2 automodsumm entries to generate > ________________________________________________________________________________ > Example directory ../examples does not have a README.txt file > Skipping this directory > ________________________________________________________________________________ > Traceback (most recent call last): > File "", line 39, in > NameError: name 'self' is not defined > Sphinx Documentation subprocess failed with return code 1 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy Hi Masato, that?s a weird error message, with the traceback not mentioning a filename. Could you please try again from a fresh Astropy 1.3 version to make sure you don?t have any accidental local file edits or something like that. This should work: Go to https://pypi.python.org/pypi/astropy/1.3 and click on astropy-1.3.tar.gz tar zxf astropy-1.3.tar.gz cd astropy-1.3 python setup.py build_docs # runs for ~ 10 minutes open docs/_build/html/index.html It does work for me. Here?s my full build log: https://gist.github.com/cdeil/b0c0774b45966ecf05f04bde3d0a88a4 If it still doesn?t work for you, maybe you could post your full build log also. It might contain a clue like another warning or error about what?s wrong. Good luck! Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at sconseil.fr Thu Jan 26 04:17:54 2017 From: simon at sconseil.fr (Simon Conseil) Date: Thu, 26 Jan 2017 10:17:54 +0100 Subject: [AstroPy] Fail to build documentation for astropy 1.3 In-Reply-To: <9F75A0B0-279B-4A4C-B4F6-946806466C7B@mpi-hd.mpg.de> References: <9F75A0B0-279B-4A4C-B4F6-946806466C7B@mpi-hd.mpg.de> Message-ID: Hi, I can reproduce on a fresh environment, and I found that pyyaml and matplotlib are now hard requirements to build the docs: pyyaml for the astropy.io.misc.yaml module, and matplotlib for astropy.visualization.wcsaxes. Once you install both it should build ! You may also want to install sphinx-gallery to build the examples, but this one is correctly mentioned in the install doc page. Cheers, Simon Le 26/01/2017 ? 08:42, Christoph Deil a ?crit : > >> On 26 Jan 2017, at 04:00, Masato Onodera > > wrote: >> >> Hello, >> >> I'd like to build a documentation of astropy-1.3 to look at it when >> I'm not connected to the internet. I followed the instruction >> (http://docs.astropy.org/en/stable/install.html#building-documentation), >> but either ways do not work for me producing the following error >> message (this is for the case of "python setup.py build_docs"). I >> also tried both python 2.7 and 3.5 and got the same error. Are >> there any ideas how to fix this? >> >> Best regards, >> Masato Onodera >> >> >> Running Sphinx v1.5.1 >> loading pickled environment... not yet created >> loading intersphinx inventory fromhttp://docs.python.org/2/objects.inv... >> intersphinx inventory has >> moved:http://docs.python.org/2/objects.inv->https://docs.python.org/2/objects.inv >> loading intersphinx inventory fromhttp://matplotlib.org/objects.inv... >> loading intersphinx inventory >> fromhttp://pandas.pydata.org/pandas-docs/stable/objects.inv... >> loading intersphinx inventory >> fromhttp://ipython.readthedocs.io/en/stable/objects.inv... >> loading intersphinx inventory >> fromhttp://docs.scipy.org/doc/scipy/reference/objects.inv... >> intersphinx inventory has >> moved:http://docs.scipy.org/doc/scipy/reference/objects.inv->https://docs.scipy.org/doc/scipy/reference/objects.inv >> loading intersphinx inventory fromhttp://pytest.org/latest/objects.inv... >> intersphinx inventory has >> moved:http://pytest.org/latest/objects.inv->http://docs.pytest.org/en/latest/objects.inv >> loading intersphinx inventory >> fromhttp://docs.h5py.org/en/latest/objects.inv... >> loading intersphinx inventory >> fromhttp://docs.scipy.org/doc/numpy/objects.inv... >> intersphinx inventory has >> moved:http://docs.scipy.org/doc/numpy/objects.inv->https://docs.scipy.org/doc/numpy/objects.inv >> loading intersphinx inventory from >> /Users/monodera/packages/astropy-1.3/astropy_helpers/astropy_helpers/sphinx/local/python2_local_links.inv... >> [autosummary] generating autosummary for: >> analytic_functions/index.rst, changelog.rst, >> config/config_0_4_transition.rst, config/index.rst, >> constants/index.rst, convolution/index.rst, convolution/kernels.rst, >> convolution/using.rst, coordinates/angles.rst, >> coordinates/definitions.rst, ..., wcs/relax.rst, whatsnew/0.1.rst, >> whatsnew/0.2.rst, whatsnew/0.3.rst, whatsnew/0.4.rst, >> whatsnew/1.0.rst, whatsnew/1.1.rst, whatsnew/1.2.rst, >> whatsnew/1.3.rst, whatsnew/index.rst >> [automodsumm] vo/conesearch/index.rst: found 27 automodsumm entries >> to generate >> [automodsumm] time/index.rst: found 30 automodsumm entries to generate >> [automodsumm] io/ascii/index.rst: found 55 automodsumm entries to >> generate >> [automodsumm] convolution/index.rst: found 22 automodsumm entries to >> generate >> [automodsumm] stats/index.rst: found 34 automodsumm entries to generate >> [automodsumm] vo/samp/index.rst: found 11 automodsumm entries to generate >> [automodsumm] constants/index.rst: found 2 automodsumm entries to >> generate >> [automodsumm] nddata/utils.rst: found 9 automodsumm entries to generate >> [automodsumm] units/index.rst: found 86 automodsumm entries to generate >> [automodsumm] logging.rst: found 3 automodsumm entries to generate >> [automodsumm] cosmology/index.rst: found 11 automodsumm entries to >> generate >> [automodsumm] visualization/wcsaxes/index.rst: found 10 automodsumm >> entries to generate >> [automodsumm] io/votable/index.rst: found 33 automodsumm entries to >> generate >> [automodsumm] config/index.rst: found 10 automodsumm entries to generate >> [automodsumm] io/misc.rst: found 9 automodsumm entries to generate >> [automodsumm] utils/index.rst: found 91 automodsumm entries to generate >> [automodsumm] io/registry.rst: found 11 automodsumm entries to generate >> [automodsumm] testhelpers.rst: found 13 automodsumm entries to generate >> [automodsumm] wcs/index.rst: found 30 automodsumm entries to generate >> [automodsumm] table/index.rst: found 22 automodsumm entries to generate >> [automodsumm] visualization/index.rst: found 27 automodsumm entries >> to generate >> [automodsumm] coordinates/index.rst: found 69 automodsumm entries to >> generate >> [automodsumm] modeling/index.rst: found 189 automodsumm entries to >> generate >> [automodsumm] nddata/index.rst: found 33 automodsumm entries to generate >> [automodsumm] analytic_functions/index.rst: found 2 automodsumm >> entries to generate >> ________________________________________________________________________________ >> Example directory ../examples does not have a README.txt file >> Skipping this directory >> ________________________________________________________________________________ >> Traceback (most recent call last): >> File "", line 39, in >> NameError: name 'self' is not defined >> Sphinx Documentation subprocess failed with return code 1 >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy > > > Hi Masato, > > that?s a weird error message, with the traceback not mentioning a > filename. > > Could you please try again from a fresh Astropy 1.3 version to make > sure you don?t have any accidental local file edits or something like > that. > > This should work: > > Go to https://pypi.python.org/pypi/astropy/1.3 and click > on astropy-1.3.tar.gz > tar zxf astropy-1.3.tar.gz > cd astropy-1.3 > python setup.py build_docs > # runs for ~ 10 minutes > open docs/_build/html/index.html > > It does work for me. Here?s my full build log: > https://gist.github.com/cdeil/b0c0774b45966ecf05f04bde3d0a88a4 > > If it still doesn?t work for you, maybe you could post your full build > log also. > It might contain a clue like another warning or error about what?s wrong. > > Good luck! > Christoph > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Deil at mpi-hd.mpg.de Thu Jan 26 04:44:05 2017 From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil) Date: Thu, 26 Jan 2017 10:44:05 +0100 Subject: [AstroPy] Fail to build documentation for astropy 1.3 In-Reply-To: References: <9F75A0B0-279B-4A4C-B4F6-946806466C7B@mpi-hd.mpg.de> Message-ID: <7B40E2F7-795C-4246-BEE3-632A431279CF@mpi-hd.mpg.de> One more thing: if you just want to have the Astropy docs for offline reading, you don?t need to build them yourself. At http://docs.astropy.org/en/stable/ in the lower right corner there?s a little black box. If you click it, it will expand and there?s a link to download a PDF, HTML and EPUB version of the docs. Christoph > On 26 Jan 2017, at 10:17, Simon Conseil wrote: > > Hi, > > I can reproduce on a fresh environment, and I found that pyyaml and matplotlib are now hard requirements to build the docs: pyyaml for the astropy.io.misc.yaml module, and matplotlib for astropy.visualization.wcsaxes. Once you install both it should build ! > You may also want to install sphinx-gallery to build the examples, but this one is correctly mentioned in the install doc page. > > Cheers, > Simon > > > Le 26/01/2017 ? 08:42, Christoph Deil a ?crit : >> >>> On 26 Jan 2017, at 04:00, Masato Onodera > wrote: >>> >>> Hello, >>> >>> I'd like to build a documentation of astropy-1.3 to look at it when I'm not connected to the internet. I followed the instruction (http://docs.astropy.org/en/stable/install.html#building-documentation ), but either ways do not work for me producing the following error message (this is for the case of "python setup.py build_docs"). I also tried both python 2.7 and 3.5 and got the same error. Are there any ideas how to fix this? >>> >>> Best regards, >>> Masato Onodera >>> >>> >>> Running Sphinx v1.5.1 >>> loading pickled environment... not yet created >>> loading intersphinx inventory from http://docs.python.org/2/objects.inv ... >>> intersphinx inventory has moved: http://docs.python.org/2/objects.inv -> https://docs.python.org/2/objects.inv >>> loading intersphinx inventory from http://matplotlib.org/objects.inv ... >>> loading intersphinx inventory from http://pandas.pydata.org/pandas-docs/stable/objects.inv ... >>> loading intersphinx inventory from http://ipython.readthedocs.io/en/stable/objects.inv ... >>> loading intersphinx inventory from http://docs.scipy.org/doc/scipy/reference/objects.inv ... >>> intersphinx inventory has moved: http://docs.scipy.org/doc/scipy/reference/objects.inv -> https://docs.scipy.org/doc/scipy/reference/objects.inv >>> loading intersphinx inventory from http://pytest.org/latest/objects.inv ... >>> intersphinx inventory has moved: http://pytest.org/latest/objects.inv -> http://docs.pytest.org/en/latest/objects.inv >>> loading intersphinx inventory from http://docs.h5py.org/en/latest/objects.inv ... >>> loading intersphinx inventory from http://docs.scipy.org/doc/numpy/objects.inv ... >>> intersphinx inventory has moved: http://docs.scipy.org/doc/numpy/objects.inv -> https://docs.scipy.org/doc/numpy/objects.inv >>> loading intersphinx inventory from /Users/monodera/packages/astropy-1.3/astropy_helpers/astropy_helpers/sphinx/local/python2_local_links.inv... >>> [autosummary] generating autosummary for: analytic_functions/index.rst, changelog.rst, config/config_0_4_transition.rst, config/index.rst, constants/index.rst, convolution/index.rst, convolution/kernels.rst, convolution/using.rst, coordinates/angles.rst, coordinates/definitions.rst, ..., wcs/relax.rst, whatsnew/0.1.rst, whatsnew/0.2.rst, whatsnew/0.3.rst, whatsnew/0.4.rst, whatsnew/1.0.rst, whatsnew/1.1.rst, whatsnew/1.2.rst, whatsnew/1.3.rst, whatsnew/index.rst >>> [automodsumm] vo/conesearch/index.rst: found 27 automodsumm entries to generate >>> [automodsumm] time/index.rst: found 30 automodsumm entries to generate >>> [automodsumm] io/ascii/index.rst: found 55 automodsumm entries to generate >>> [automodsumm] convolution/index.rst: found 22 automodsumm entries to generate >>> [automodsumm] stats/index.rst: found 34 automodsumm entries to generate >>> [automodsumm] vo/samp/index.rst: found 11 automodsumm entries to generate >>> [automodsumm] constants/index.rst: found 2 automodsumm entries to generate >>> [automodsumm] nddata/utils.rst: found 9 automodsumm entries to generate >>> [automodsumm] units/index.rst: found 86 automodsumm entries to generate >>> [automodsumm] logging.rst: found 3 automodsumm entries to generate >>> [automodsumm] cosmology/index.rst: found 11 automodsumm entries to generate >>> [automodsumm] visualization/wcsaxes/index.rst: found 10 automodsumm entries to generate >>> [automodsumm] io/votable/index.rst: found 33 automodsumm entries to generate >>> [automodsumm] config/index.rst: found 10 automodsumm entries to generate >>> [automodsumm] io/misc.rst: found 9 automodsumm entries to generate >>> [automodsumm] utils/index.rst: found 91 automodsumm entries to generate >>> [automodsumm] io/registry.rst: found 11 automodsumm entries to generate >>> [automodsumm] testhelpers.rst: found 13 automodsumm entries to generate >>> [automodsumm] wcs/index.rst: found 30 automodsumm entries to generate >>> [automodsumm] table/index.rst: found 22 automodsumm entries to generate >>> [automodsumm] visualization/index.rst: found 27 automodsumm entries to generate >>> [automodsumm] coordinates/index.rst: found 69 automodsumm entries to generate >>> [automodsumm] modeling/index.rst: found 189 automodsumm entries to generate >>> [automodsumm] nddata/index.rst: found 33 automodsumm entries to generate >>> [automodsumm] analytic_functions/index.rst: found 2 automodsumm entries to generate >>> ________________________________________________________________________________ >>> Example directory ../examples does not have a README.txt file >>> Skipping this directory >>> ________________________________________________________________________________ >>> Traceback (most recent call last): >>> File "", line 39, in >>> NameError: name 'self' is not defined >>> Sphinx Documentation subprocess failed with return code 1 >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >> >> Hi Masato, >> >> that?s a weird error message, with the traceback not mentioning a filename. >> >> Could you please try again from a fresh Astropy 1.3 version to make sure you don?t have any accidental local file edits or something like that. >> >> This should work: >> >> Go to https://pypi.python.org/pypi/astropy/1.3 and click on astropy-1.3.tar.gz >> tar zxf astropy-1.3.tar.gz >> cd astropy-1.3 >> python setup.py build_docs >> # runs for ~ 10 minutes >> open docs/_build/html/index.html >> >> It does work for me. Here?s my full build log: >> https://gist.github.com/cdeil/b0c0774b45966ecf05f04bde3d0a88a4 >> >> If it still doesn?t work for you, maybe you could post your full build log also. >> It might contain a clue like another warning or error about what?s wrong. >> >> Good luck! >> Christoph >> >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From yannick.roehlly at gmail.com Thu Jan 26 04:50:21 2017 From: yannick.roehlly at gmail.com (Yannick Roehlly) Date: Thu, 26 Jan 2017 09:50:21 +0000 Subject: [AstroPy] Fail to build documentation for astropy 1.3 In-Reply-To: <7B40E2F7-795C-4246-BEE3-632A431279CF@mpi-hd.mpg.de> References: <7B40E2F7-795C-4246-BEE3-632A431279CF@mpi-hd.mpg.de> Message-ID: <4221758.YjpPgixZGU@galactica> Le jeudi 26 janvier 2017, 10:44:05 GMT Christoph Deil a ?crit : > One more thing: if you just want to have the Astropy docs for offline > reading, you don?t need to build them yourself. Also, thanks to Simon it's available on Zeal[1]/Dash[2]. Yannick [1] https://zealdocs.org/ [2] https://kapeli.com/dash -- Exercise caution in your daily affairs. From bsipocz at gmail.com Thu Jan 26 07:50:16 2017 From: bsipocz at gmail.com (Brigitta Sipocz) Date: Thu, 26 Jan 2017 12:50:16 +0000 Subject: [AstroPy] Fail to build documentation for astropy 1.3 In-Reply-To: <7B40E2F7-795C-4246-BEE3-632A431279CF@mpi-hd.mpg.de> References: <9F75A0B0-279B-4A4C-B4F6-946806466C7B@mpi-hd.mpg.de> <7B40E2F7-795C-4246-BEE3-632A431279CF@mpi-hd.mpg.de> Message-ID: I believe we don't have the downloadables for the latest releases on the main docs page, see the discussion here https://github.com/astropy/astropy/issues/5677 Brigitta On 26 January 2017 at 09:44, Christoph Deil wrote: > One more thing: if you just want to have the Astropy docs for offline > reading, you don?t need to build them yourself. > > At http://docs.astropy.org/en/stable/ in the lower right corner there?s a > little black box. > If you click it, it will expand and there?s a link to download a PDF, HTML > and EPUB version of the docs. > > Christoph > > > On 26 Jan 2017, at 10:17, Simon Conseil wrote: > > Hi, > > I can reproduce on a fresh environment, and I found that pyyaml and > matplotlib are now hard requirements to build the docs: pyyaml for the > astropy.io.misc.yaml module, and matplotlib for > astropy.visualization.wcsaxes. Once you install both it should build ! > You may also want to install sphinx-gallery > to build the examples, but this > one is correctly mentioned in the install doc page. > > Cheers, > Simon > > Le 26/01/2017 ? 08:42, Christoph Deil a ?crit : > > > On 26 Jan 2017, at 04:00, Masato Onodera wrote: > > Hello, > > I'd like to build a documentation of astropy-1.3 to look at it when I'm > not connected to the internet. I followed the instruction ( > http://docs.astropy.org/en/stable/install.html#building-documentation), > but either ways do not work for me producing the following error message > (this is for the case of "python setup.py build_docs"). I also tried both > python 2.7 and 3.5 and got the same error. Are there any ideas how to fix > this? > > Best regards, > Masato Onodera > > > Running Sphinx v1.5.1 > loading pickled environment... not yet created > loading intersphinx inventory from http://docs.python.org/2/objects.inv... > intersphinx inventory has moved: http://docs.python.org/2/objects.inv -> > https://docs.python.org/2/objects.inv > loading intersphinx inventory from http://matplotlib.org/objects.inv... > loading intersphinx inventory from http://pandas.pydata.org/ > pandas-docs/stable/objects.inv... > loading intersphinx inventory from http://ipython. > readthedocs.io/en/stable/objects.inv... > loading intersphinx inventory from http://docs.scipy.org/ > doc/scipy/reference/objects.inv... > intersphinx inventory has moved: http://docs.scipy.org/ > doc/scipy/reference/objects.inv -> https://docs.scipy.org/ > doc/scipy/reference/objects.inv > loading intersphinx inventory from http://pytest.org/latest/objects.inv... > intersphinx inventory has moved: http://pytest.org/latest/objects.inv -> > http://docs.pytest.org/en/latest/objects.inv > loading intersphinx inventory from http://docs.h5py.org/en/ > latest/objects.inv... > loading intersphinx inventory from http://docs.scipy.org/ > doc/numpy/objects.inv... > intersphinx inventory has moved: http://docs.scipy.org/ > doc/numpy/objects.inv -> https://docs.scipy.org/doc/numpy/objects.inv > loading intersphinx inventory from /Users/monodera/packages/ > astropy-1.3/astropy_helpers/astropy_helpers/sphinx/local/ > python2_local_links.inv... > [autosummary] generating autosummary for: analytic_functions/index.rst, > changelog.rst, config/config_0_4_transition.rst, config/index.rst, > constants/index.rst, convolution/index.rst, convolution/kernels.rst, > convolution/using.rst, coordinates/angles.rst, coordinates/definitions.rst, > ..., wcs/relax.rst, whatsnew/0.1.rst, whatsnew/0.2.rst, whatsnew/0.3.rst, > whatsnew/0.4.rst, whatsnew/1.0.rst, whatsnew/1.1.rst, whatsnew/1.2.rst, > whatsnew/1.3.rst, whatsnew/index.rst > [automodsumm] vo/conesearch/index.rst: found 27 automodsumm entries to > generate > [automodsumm] time/index.rst: found 30 automodsumm entries to generate > [automodsumm] io/ascii/index.rst: found 55 automodsumm entries to generate > [automodsumm] convolution/index.rst: found 22 automodsumm entries to > generate > [automodsumm] stats/index.rst: found 34 automodsumm entries to generate > [automodsumm] vo/samp/index.rst: found 11 automodsumm entries to generate > [automodsumm] constants/index.rst: found 2 automodsumm entries to generate > [automodsumm] nddata/utils.rst: found 9 automodsumm entries to generate > [automodsumm] units/index.rst: found 86 automodsumm entries to generate > [automodsumm] logging.rst: found 3 automodsumm entries to generate > [automodsumm] cosmology/index.rst: found 11 automodsumm entries to generate > [automodsumm] visualization/wcsaxes/index.rst: found 10 automodsumm > entries to generate > [automodsumm] io/votable/index.rst: found 33 automodsumm entries to > generate > [automodsumm] config/index.rst: found 10 automodsumm entries to generate > [automodsumm] io/misc.rst: found 9 automodsumm entries to generate > [automodsumm] utils/index.rst: found 91 automodsumm entries to generate > [automodsumm] io/registry.rst: found 11 automodsumm entries to generate > [automodsumm] testhelpers.rst: found 13 automodsumm entries to generate > [automodsumm] wcs/index.rst: found 30 automodsumm entries to generate > [automodsumm] table/index.rst: found 22 automodsumm entries to generate > [automodsumm] visualization/index.rst: found 27 automodsumm entries to > generate > [automodsumm] coordinates/index.rst: found 69 automodsumm entries to > generate > [automodsumm] modeling/index.rst: found 189 automodsumm entries to generate > [automodsumm] nddata/index.rst: found 33 automodsumm entries to generate > [automodsumm] analytic_functions/index.rst: found 2 automodsumm entries to > generate > ____________________________________________________________ > ____________________ > Example directory ../examples does not have a README.txt file > Skipping this directory > ____________________________________________________________ > ____________________ > Traceback (most recent call last): > File "", line 39, in > NameError: name 'self' is not defined > Sphinx Documentation subprocess failed with return code 1 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > > > Hi Masato, > > that?s a weird error message, with the traceback not mentioning a filename. > > Could you please try again from a fresh Astropy 1.3 version to make sure > you don?t have any accidental local file edits or something like that. > > This should work: > > Go to https://pypi.python.org/pypi/astropy/1.3 and click > on astropy-1.3.tar.gz > tar zxf astropy-1.3.tar.gz > cd astropy-1.3 > python setup.py build_docs > # runs for ~ 10 minutes > open docs/_build/html/index.html > > It does work for me. Here?s my full build log: > https://gist.github.com/cdeil/b0c0774b45966ecf05f04bde3d0a88a4 > > If it still doesn?t work for you, maybe you could post your full build log > also. > It might contain a clue like another warning or error about what?s wrong. > > Good luck! > Christoph > > > _______________________________________________ > AstroPy mailing listAstroPy at scipy.orghttps://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masato.onodera at gmail.com Thu Jan 26 22:13:50 2017 From: masato.onodera at gmail.com (Masato Onodera) Date: Thu, 26 Jan 2017 17:13:50 -1000 Subject: [AstroPy] Fail to build documentation for astropy 1.3 In-Reply-To: References: <9F75A0B0-279B-4A4C-B4F6-946806466C7B@mpi-hd.mpg.de> Message-ID: Hi,? This is my full build log with a fresh astropy-1.3.tar.gz.? https://gist.github.com/monodera/4911502cfe70daaedd14c9c98d71a627 I found pyyaml and matplotlib is already installed (my python environment is basically astroconda). ?I also installed sphinx-gallery, but the result is identical.? As Brigitta pointed out, the latest documentation is not available through RtD, so I tried to do it by myself (actually the twitter post mentioned in the github issue is mine).? Cheers, Masato --? Masato Onodera Sent with Airmail On January 25, 2017 at 23:18:18, Simon Conseil (simon at sconseil.fr) wrote: Hi, I can reproduce on a fresh environment, and I found that pyyaml and matplotlib are now hard requirements to build the docs: pyyaml for the astropy.io.misc.yaml module, and matplotlib for astropy.visualization.wcsaxes. Once you install both it should build ! You may also want to install sphinx-gallery to build the examples, but this one is correctly mentioned in the install doc page. Cheers, Simon Le 26/01/2017 ? 08:42, Christoph Deil a ?crit?: On 26 Jan 2017, at 04:00, Masato Onodera wrote: Hello,? I'd like to build a documentation of astropy-1.3 to look at it when I'm not connected to the internet. ?I followed the instruction (http://docs.astropy.org/en/stable/install.html#building-documentation), but either ways do not work for me producing the following error message (this is for the case of "python setup.py build_docs"). ?I also tried both python 2.7 and 3.5 and got the same error. ? Are there any ideas how to fix this? Best regards, Masato Onodera Running Sphinx v1.5.1 loading pickled environment... not yet created loading intersphinx inventory from?http://docs.python.org/2/objects.inv... intersphinx inventory has moved:?http://docs.python.org/2/objects.inv?->?https://docs.python.org/2/objects.inv loading intersphinx inventory from?http://matplotlib.org/objects.inv... loading intersphinx inventory from?http://pandas.pydata.org/pandas-docs/stable/objects.inv... loading intersphinx inventory from?http://ipython.readthedocs.io/en/stable/objects.inv... loading intersphinx inventory from?http://docs.scipy.org/doc/scipy/reference/objects.inv... intersphinx inventory has moved:?http://docs.scipy.org/doc/scipy/reference/objects.inv?->?https://docs.scipy.org/doc/scipy/reference/objects.inv loading intersphinx inventory from?http://pytest.org/latest/objects.inv... intersphinx inventory has moved:?http://pytest.org/latest/objects.inv?->?http://docs.pytest.org/en/latest/objects.inv loading intersphinx inventory from?http://docs.h5py.org/en/latest/objects.inv... loading intersphinx inventory from?http://docs.scipy.org/doc/numpy/objects.inv... intersphinx inventory has moved:?http://docs.scipy.org/doc/numpy/objects.inv?->?https://docs.scipy.org/doc/numpy/objects.inv loading intersphinx inventory from /Users/monodera/packages/astropy-1.3/astropy_helpers/astropy_helpers/sphinx/local/python2_local_links.inv... [autosummary] generating autosummary for: analytic_functions/index.rst, changelog.rst, config/config_0_4_transition.rst, config/index.rst, constants/index.rst, convolution/index.rst, convolution/kernels.rst, convolution/using.rst, coordinates/angles.rst, coordinates/definitions.rst, ..., wcs/relax.rst, whatsnew/0.1.rst, whatsnew/0.2.rst, whatsnew/0.3.rst, whatsnew/0.4.rst, whatsnew/1.0.rst, whatsnew/1.1.rst, whatsnew/1.2.rst, whatsnew/1.3.rst, whatsnew/index.rst [automodsumm] vo/conesearch/index.rst: found 27 automodsumm entries to generate [automodsumm] time/index.rst: found 30 automodsumm entries to generate [automodsumm] io/ascii/index.rst: found 55 automodsumm entries to generate [automodsumm] convolution/index.rst: found 22 automodsumm entries to generate [automodsumm] stats/index.rst: found 34 automodsumm entries to generate [automodsumm] vo/samp/index.rst: found 11 automodsumm entries to generate [automodsumm] constants/index.rst: found 2 automodsumm entries to generate [automodsumm] nddata/utils.rst: found 9 automodsumm entries to generate [automodsumm] units/index.rst: found 86 automodsumm entries to generate [automodsumm] logging.rst: found 3 automodsumm entries to generate [automodsumm] cosmology/index.rst: found 11 automodsumm entries to generate [automodsumm] visualization/wcsaxes/index.rst: found 10 automodsumm entries to generate [automodsumm] io/votable/index.rst: found 33 automodsumm entries to generate [automodsumm] config/index.rst: found 10 automodsumm entries to generate [automodsumm] io/misc.rst: found 9 automodsumm entries to generate [automodsumm] utils/index.rst: found 91 automodsumm entries to generate [automodsumm] io/registry.rst: found 11 automodsumm entries to generate [automodsumm] testhelpers.rst: found 13 automodsumm entries to generate [automodsumm] wcs/index.rst: found 30 automodsumm entries to generate [automodsumm] table/index.rst: found 22 automodsumm entries to generate [automodsumm] visualization/index.rst: found 27 automodsumm entries to generate [automodsumm] coordinates/index.rst: found 69 automodsumm entries to generate [automodsumm] modeling/index.rst: found 189 automodsumm entries to generate [automodsumm] nddata/index.rst: found 33 automodsumm entries to generate [automodsumm] analytic_functions/index.rst: found 2 automodsumm entries to generate ________________________________________________________________________________ Example directory ../examples does not have a README.txt file Skipping this directory ________________________________________________________________________________ Traceback (most recent call last): ? File "", line 39, in NameError: name 'self' is not defined Sphinx Documentation subprocess failed with return code 1 _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy Hi Masato, that?s a weird error message, with the traceback not mentioning a filename. Could you please try again from a fresh Astropy 1.3 version to make sure you don?t have any accidental local file edits or something like that. This should work: Go to?https://pypi.python.org/pypi/astropy/1.3?and click on?astropy-1.3.tar.gz tar zxf astropy-1.3.tar.gz cd astropy-1.3 python setup.py build_docs # runs for ~ 10 minutes open docs/_build/html/index.html It does work for me. Here?s my full build log: https://gist.github.com/cdeil/b0c0774b45966ecf05f04bde3d0a88a4 If it still doesn?t work for you, maybe you could post your full build log also. It might contain a clue like another warning or error about what?s wrong. Good luck! Christoph _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Deil at mpi-hd.mpg.de Fri Jan 27 03:18:25 2017 From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil) Date: Fri, 27 Jan 2017 09:18:25 +0100 Subject: [AstroPy] Fail to build documentation for astropy 1.3 In-Reply-To: References: <9F75A0B0-279B-4A4C-B4F6-946806466C7B@mpi-hd.mpg.de> Message-ID: <49DCC403-44B4-488B-AC0C-39E38E387332@mpi-hd.mpg.de> Hi Masato, After installing sphinx-gallery, I now also get the same error. It looks to me like a bug, and there was already a related Github issue, so I?ve summarised the information from this mailing list thread here: https://github.com/astropy/astropy/issues/5019#issuecomment-275610995 Thanks for reporting this issue and posting the full build log! Christoph > On 27 Jan 2017, at 04:13, Masato Onodera wrote: > > Hi, > > This is my full build log with a fresh astropy-1.3.tar.gz. > https://gist.github.com/monodera/4911502cfe70daaedd14c9c98d71a627 > > I found pyyaml and matplotlib is already installed (my python environment is basically astroconda). I also installed sphinx-gallery, but the result is identical. > > As Brigitta pointed out, the latest documentation is not available through RtD, so I tried to do it by myself (actually the twitter post mentioned in the github issue is mine). > > Cheers, > Masato > > -- > Masato Onodera > Sent with Airmail > > On January 25, 2017 at 23:18:18, Simon Conseil (simon at sconseil.fr ) wrote: > >> Hi, >> >> I can reproduce on a fresh environment, and I found that pyyaml and matplotlib are now hard requirements to build the docs: pyyaml for the astropy.io.misc.yaml module, and matplotlib for astropy.visualization.wcsaxes. Once you install both it should build ! >> You may also want to install sphinx-gallery to build the examples, but this one is correctly mentioned in the install doc page. >> >> Cheers, >> Simon >> >> >> Le 26/01/2017 ? 08:42, Christoph Deil a ?crit : >>> >>>> On 26 Jan 2017, at 04:00, Masato Onodera > wrote: >>>> >>>> Hello, >>>> >>>> I'd like to build a documentation of astropy-1.3 to look at it when I'm not connected to the internet. I followed the instruction (http://docs.astropy.org/en/stable/install.html#building-documentation ), but either ways do not work for me producing the following error message (this is for the case of "python setup.py build_docs"). I also tried both python 2.7 and 3.5 and got the same error. Are there any ideas how to fix this? >>>> >>>> Best regards, >>>> Masato Onodera >>>> >>>> >>>> Running Sphinx v1.5.1 >>>> loading pickled environment... not yet created >>>> loading intersphinx inventory from http://docs.python.org/2/objects.inv ... >>>> intersphinx inventory has moved: http://docs.python.org/2/objects.inv -> https://docs.python.org/2/objects.inv >>>> loading intersphinx inventory from http://matplotlib.org/objects.inv ... >>>> loading intersphinx inventory from http://pandas.pydata.org/pandas-docs/stable/objects.inv ... >>>> loading intersphinx inventory from http://ipython.readthedocs.io/en/stable/objects.inv ... >>>> loading intersphinx inventory from http://docs.scipy.org/doc/scipy/reference/objects.inv ... >>>> intersphinx inventory has moved: http://docs.scipy.org/doc/scipy/reference/objects.inv -> https://docs.scipy.org/doc/scipy/reference/objects.inv >>>> loading intersphinx inventory from http://pytest.org/latest/objects.inv ... >>>> intersphinx inventory has moved: http://pytest.org/latest/objects.inv -> http://docs.pytest.org/en/latest/objects.inv >>>> loading intersphinx inventory from http://docs.h5py.org/en/latest/objects.inv ... >>>> loading intersphinx inventory from http://docs.scipy.org/doc/numpy/objects.inv ... >>>> intersphinx inventory has moved: http://docs.scipy.org/doc/numpy/objects.inv -> https://docs.scipy.org/doc/numpy/objects.inv >>>> loading intersphinx inventory from /Users/monodera/packages/astropy-1.3/astropy_helpers/astropy_helpers/sphinx/local/python2_local_links.inv... >>>> [autosummary] generating autosummary for: analytic_functions/index.rst, changelog.rst, config/config_0_4_transition.rst, config/index.rst, constants/index.rst, convolution/index.rst, convolution/kernels.rst, convolution/using.rst, coordinates/angles.rst, coordinates/definitions.rst, ..., wcs/relax.rst, whatsnew/0.1.rst, whatsnew/0.2.rst, whatsnew/0.3.rst, whatsnew/0.4.rst, whatsnew/1.0.rst, whatsnew/1.1.rst, whatsnew/1.2.rst, whatsnew/1.3.rst, whatsnew/index.rst >>>> [automodsumm] vo/conesearch/index.rst: found 27 automodsumm entries to generate >>>> [automodsumm] time/index.rst: found 30 automodsumm entries to generate >>>> [automodsumm] io/ascii/index.rst: found 55 automodsumm entries to generate >>>> [automodsumm] convolution/index.rst: found 22 automodsumm entries to generate >>>> [automodsumm] stats/index.rst: found 34 automodsumm entries to generate >>>> [automodsumm] vo/samp/index.rst: found 11 automodsumm entries to generate >>>> [automodsumm] constants/index.rst: found 2 automodsumm entries to generate >>>> [automodsumm] nddata/utils.rst: found 9 automodsumm entries to generate >>>> [automodsumm] units/index.rst: found 86 automodsumm entries to generate >>>> [automodsumm] logging.rst: found 3 automodsumm entries to generate >>>> [automodsumm] cosmology/index.rst: found 11 automodsumm entries to generate >>>> [automodsumm] visualization/wcsaxes/index.rst: found 10 automodsumm entries to generate >>>> [automodsumm] io/votable/index.rst: found 33 automodsumm entries to generate >>>> [automodsumm] config/index.rst: found 10 automodsumm entries to generate >>>> [automodsumm] io/misc.rst: found 9 automodsumm entries to generate >>>> [automodsumm] utils/index.rst: found 91 automodsumm entries to generate >>>> [automodsumm] io/registry.rst: found 11 automodsumm entries to generate >>>> [automodsumm] testhelpers.rst: found 13 automodsumm entries to generate >>>> [automodsumm] wcs/index.rst: found 30 automodsumm entries to generate >>>> [automodsumm] table/index.rst: found 22 automodsumm entries to generate >>>> [automodsumm] visualization/index.rst: found 27 automodsumm entries to generate >>>> [automodsumm] coordinates/index.rst: found 69 automodsumm entries to generate >>>> [automodsumm] modeling/index.rst: found 189 automodsumm entries to generate >>>> [automodsumm] nddata/index.rst: found 33 automodsumm entries to generate >>>> [automodsumm] analytic_functions/index.rst: found 2 automodsumm entries to generate >>>> ________________________________________________________________________________ >>>> Example directory ../examples does not have a README.txt file >>>> Skipping this directory >>>> ________________________________________________________________________________ >>>> Traceback (most recent call last): >>>> File "", line 39, in >>>> NameError: name 'self' is not defined >>>> Sphinx Documentation subprocess failed with return code 1 >>>> _______________________________________________ >>>> AstroPy mailing list >>>> AstroPy at scipy.org >>>> https://mail.scipy.org/mailman/listinfo/astropy >>> >>> Hi Masato, >>> >>> that?s a weird error message, with the traceback not mentioning a filename. >>> >>> Could you please try again from a fresh Astropy 1.3 version to make sure you don?t have any accidental local file edits or something like that. >>> >>> This should work: >>> >>> Go to https://pypi.python.org/pypi/astropy/1.3 and click on astropy-1.3.tar.gz >>> tar zxf astropy-1.3.tar.gz >>> cd astropy-1.3 >>> python setup.py build_docs >>> # runs for ~ 10 minutes >>> open docs/_build/html/index.html >>> >>> It does work for me. Here?s my full build log: >>> https://gist.github.com/cdeil/b0c0774b45966ecf05f04bde3d0a88a4 >>> >>> If it still doesn?t work for you, maybe you could post your full build log also. >>> It might contain a clue like another warning or error about what?s wrong. >>> >>> Good luck! >>> Christoph >>> >>> >>> _______________________________________________ >>> AstroPy mailing list >>> AstroPy at scipy.org >>> https://mail.scipy.org/mailman/listinfo/astropy >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Fri Jan 27 05:34:36 2017 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Fri, 27 Jan 2017 10:34:36 +0000 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle Message-ID: Hi I am given an hour angle and wish to calculate?alt/az or zenith angle/parallactic angle for a given SkyCoord and Location. After reading the documentation and many tries, I cannot see how to do this with the current Astropy Time/Angle classes. It is possible? Thanks, Tim --? Tim Cornwell Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.staley at physics.ox.ac.uk Fri Jan 27 05:51:34 2017 From: tim.staley at physics.ox.ac.uk (Tim Staley) Date: Fri, 27 Jan 2017 10:51:34 +0000 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: References: Message-ID: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Hi Tim, you want something like the following: from astropy.coordinates import SkyCoord, AltAz, EarthLocation from astropy.time import Time import astropy.units as u obs_time = Time('2017-01-01T18:00') sky_posn = SkyCoord(0 * u.deg, 30 * u.deg) earth_location = EarthLocation.from_geodetic(0*u.deg, 35*u.deg) altaz = sky_posn.transform_to( AltAz(obstime=obs_time, location=earth_location)) print(altaz.alt.deg, altaz.az.deg) Cheers, Tim On 27/01/17 10:34, Tim Cornwell wrote: > Hi > > I am given an hour angle and wish to calculate alt/az or zenith > angle/parallactic angle for a given SkyCoord and Location. After > reading the documentation and many tries, I cannot see how to do this > with the current Astropy Time/Angle classes. It is possible? > > Thanks, > Tim > > -- > Tim Cornwell > Sent with Airmail > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy From realtimcornwell at gmail.com Fri Jan 27 05:56:42 2017 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Fri, 27 Jan 2017 10:56:42 +0000 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> References: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Message-ID: Hi Tim, I can see how that works bit what I want is to be able to calculate from the local hour angle i.e. a relative time (LST-RA) instead of starting with an absolute time. For context, I?m writing some simulation code and don?t need to work with absolute time. From what I see, it?s not possible in astropy to start with hour angle instead of some form of absolute time. I can work around this but it seems to be a hole in either the package or more likely in the documentation. Thanks, Tim --? Tim Cornwell Sent with Airmail On 27 January 2017 at 10:51:42 am, Tim Staley (tim.staley at physics.ox.ac.uk) wrote: Hi Tim, you want something like the following: from astropy.coordinates import SkyCoord, AltAz, EarthLocation from astropy.time import Time import astropy.units as u obs_time = Time('2017-01-01T18:00') sky_posn = SkyCoord(0 * u.deg, 30 * u.deg) earth_location = EarthLocation.from_geodetic(0*u.deg, 35*u.deg) altaz = sky_posn.transform_to( AltAz(obstime=obs_time, location=earth_location)) print(altaz.alt.deg, altaz.az.deg) Cheers, Tim On 27/01/17 10:34, Tim Cornwell wrote: > Hi > > I am given an hour angle and wish to calculate alt/az or zenith > angle/parallactic angle for a given SkyCoord and Location. After > reading the documentation and many tries, I cannot see how to do this > with the current Astropy Time/Angle classes. It is possible? > > Thanks, > Tim > > -- > Tim Cornwell > Sent with Airmail > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.gallardo.lopez at gmail.com Fri Jan 27 06:07:36 2017 From: f.gallardo.lopez at gmail.com (=?UTF-8?Q?Francisco_Gallardo_l=C3=B3pez?=) Date: Fri, 27 Jan 2017 12:07:36 +0100 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: References: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Message-ID: We run into a similar problem with a project in SpaceApps. I think we discarded Skycoord due to the speed so we used PyEphem. Let me tell you in advance that I am not sure whether this works (I did not properly tested it nor had time to check it out properly). https://github.com/juanlu-sanz/neo-challege-2016/blob/master/spice/restapi.py Go to line 103: def conversion(ar,dec,times_list,lat,lon): [*AGAIN*: I am not sure whether this works properly as we did not have time to test it!!] (and as per the coding style and so on: We did the entire thing in a weekend so, please have some mercy :-P) obs.date=times_list[k] LST=math.degrees(obs.sidereal_time()) HA = ar[k] - LST x = math.cos(HA) * math.cos(dec[k]) y = math.sin(HA) * math.cos(dec[k]) z = math.sin(dec[k]) zhor = x * math.sin(90 - lat) + z * math.cos(90 - lat) alt.append(math.asin(zhor)) BR Fran Gallardo 2017-01-27 11:56 GMT+01:00 Tim Cornwell : > Hi Tim, > > I can see how that works bit what I want is to be able to calculate from > the local hour angle i.e. a relative time (LST-RA) instead of starting with > an absolute time. For context, I?m writing some simulation code and don?t > need to work with absolute time. From what I see, it?s not possible in > astropy to start with hour angle instead of some form of absolute time. I > can work around this but it seems to be a hole in either the package or > more likely in the documentation. > > Thanks, > Tim > > -- > Tim Cornwell > Sent with Airmail > > On 27 January 2017 at 10:51:42 am, Tim Staley (tim.staley at physics.ox.ac.uk) > wrote: > > Hi Tim, > > you want something like the following: > > from astropy.coordinates import SkyCoord, AltAz, EarthLocation > > from astropy.time import Time > import astropy.units as u > > obs_time = Time('2017-01-01T18:00') > > sky_posn = SkyCoord(0 * u.deg, 30 * u.deg) > earth_location = EarthLocation.from_geodetic(0*u.deg, 35*u.deg) > > altaz = sky_posn.transform_to( > AltAz(obstime=obs_time, > location=earth_location)) > > print(altaz.alt.deg, altaz.az.deg) > > > Cheers, > Tim > > On 27/01/17 10:34, Tim Cornwell wrote: > > Hi > > > > I am given an hour angle and wish to calculate alt/az or zenith > > angle/parallactic angle for a given SkyCoord and Location. After > > reading the documentation and many tries, I cannot see how to do this > > with the current Astropy Time/Angle classes. It is possible? > > > > Thanks, > > Tim > > > > -- > > Tim Cornwell > > Sent with Airmail > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > https://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Sun Jan 29 23:05:43 2017 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sun, 29 Jan 2017 23:05:43 -0500 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: References: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Message-ID: Tim (C), I don't quite understand what you mean here. You'd need to have *some* absolute time, because that's the only way to pin down the orientation of the Earth due to precession/nutation. Are you saying you want to specify an epoch to lock that down and then have as the remaining input just the hour angle? Or you want to specify an epoch for the precession/nutation and then additionally specify the hour angle and coordinate? The latter is nominally impossible, but there's probably some "good enough" solutions that you could implement with Astropy. --- Erik T On Fri, Jan 27, 2017 at 5:56 AM, Tim Cornwell wrote: > Hi Tim, > > I can see how that works bit what I want is to be able to calculate from > the local hour angle i.e. a relative time (LST-RA) instead of starting with > an absolute time. For context, I?m writing some simulation code and don?t > need to work with absolute time. From what I see, it?s not possible in > astropy to start with hour angle instead of some form of absolute time. I > can work around this but it seems to be a hole in either the package or > more likely in the documentation. > > Thanks, > Tim > > -- > Tim Cornwell > Sent with Airmail > > On 27 January 2017 at 10:51:42 am, Tim Staley (tim.staley at physics.ox.ac.uk) > wrote: > > Hi Tim, > > you want something like the following: > > from astropy.coordinates import SkyCoord, AltAz, EarthLocation > > from astropy.time import Time > import astropy.units as u > > obs_time = Time('2017-01-01T18:00') > > sky_posn = SkyCoord(0 * u.deg, 30 * u.deg) > earth_location = EarthLocation.from_geodetic(0*u.deg, 35*u.deg) > > altaz = sky_posn.transform_to( > AltAz(obstime=obs_time, > location=earth_location)) > > print(altaz.alt.deg, altaz.az.deg) > > > Cheers, > Tim > > On 27/01/17 10:34, Tim Cornwell wrote: > > Hi > > > > I am given an hour angle and wish to calculate alt/az or zenith > > angle/parallactic angle for a given SkyCoord and Location. After > > reading the documentation and many tries, I cannot see how to do this > > with the current Astropy Time/Angle classes. It is possible? > > > > Thanks, > > Tim > > > > -- > > Tim Cornwell > > Sent with Airmail > > > > > > _______________________________________________ > > AstroPy mailing list > > AstroPy at scipy.org > > https://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Sun Jan 29 23:08:04 2017 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sun, 29 Jan 2017 23:08:04 -0500 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: References: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Message-ID: Hi Francisco, > I think we discarded Skycoord due to the speed so we used PyEphem. Can you give a bit more on the specific use case that led you to this decision? SkyCoord has a fair amount of space for optimization, so it would be useful to know what kinds of use cases are coming out as "slow" so we can try to make them better. --- Erik T -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Mon Jan 30 04:33:46 2017 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Mon, 30 Jan 2017 09:33:46 +0000 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: References: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Message-ID: Hi Erik, Thanks for the reply. I?m writing a reference library for SKA (part of the Science Data Processor consortium work), and as part of that I need to do simulations of observations with SKA. The configuration of an interferometric array is a function of hour angle and the absolute time is not relevant for most observations. So most of the simulations can be done in hour angle without having a choose a notional time. The reasons for this are that we can observe day or night. This isn?t always true but it mostly is. Some effects are purely dependent on Az, El (e.g. power patten of an array fixed to the ground or an alt-az antenna). I can do this in other packages (such as casa) but astropy is lightweight but capable so I?d rather use it if at all possible. Regards, Tim --? Tim Cornwell Sent with Airmail On 30 January 2017 at 4:08:31 am, Erik Tollerud (erik.tollerud at gmail.com) wrote: Hi Francisco, > I think we discarded Skycoord due to the speed so we used PyEphem. Can you give a bit more on the specific use case that led you to this decision?? SkyCoord has a fair amount of space for optimization, so it would be useful to know what kinds of use cases are coming out as "slow" so we can try to make them better. --- Erik T _______________________________________________ AstroPy mailing list AstroPy at scipy.org https://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.gallardo.lopez at gmail.com Mon Jan 30 05:13:59 2017 From: f.gallardo.lopez at gmail.com (=?UTF-8?Q?Francisco_Gallardo_l=C3=B3pez?=) Date: Mon, 30 Jan 2017 11:13:59 +0100 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: References: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Message-ID: @Tim: You may want to take a look at the Apsynsim . It's a code in Python made by Ivan Mart? (Chalmers Univ.). It's a R. Astronomy interferometer simulator. The code is available and includes a GUI. It uses the Hour Angle for the calculations, so by looking at the "APSYNSIM.py" you may be able to implement what you want ( def _changeCoordinates ?). BTW: I read again my last email and realized that it should be HA = LST - ar[k] no the other way around. @Erik: We were trying to calculate the EL curves (during a long time span) for a large number of NEOs. We used JPL Spice to obtain the RA and DEC for those instants. It was a matter of translating that to the observer local Sky (the idea was to generate a friendly web-based user interface). It was quite slow and we thought it was due to this Issue: https://github.com/ astropy/astropy/issues/3323 BR Fran Gallardo 2017-01-30 10:33 GMT+01:00 Tim Cornwell : > Hi Erik, > > Thanks for the reply. I?m writing a reference library for SKA (part of the > Science Data Processor consortium work), and as part of that I need to do > simulations of observations with SKA. The configuration of an > interferometric array is a function of hour angle and the absolute time is > not relevant for most observations. So most of the simulations can be done > in hour angle without having a choose a notional time. The reasons for this > are that we can observe day or night. This isn?t always true but it mostly > is. Some effects are purely dependent on Az, El (e.g. power patten of an > array fixed to the ground or an alt-az antenna). > > I can do this in other packages (such as casa) but astropy is lightweight > but capable so I?d rather use it if at all possible. > > Regards, > > Tim > > -- > Tim Cornwell > Sent with Airmail > > On 30 January 2017 at 4:08:31 am, Erik Tollerud (erik.tollerud at gmail.com) > wrote: > > Hi Francisco, > > > > I think we discarded Skycoord due to the speed so we used PyEphem. > > Can you give a bit more on the specific use case that led you to this > decision? SkyCoord has a fair amount of space for optimization, so it > would be useful to know what kinds of use cases are coming out as "slow" so > we can try to make them better. > > > --- > Erik T > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From realtimcornwell at gmail.com Mon Jan 30 11:49:58 2017 From: realtimcornwell at gmail.com (Tim Cornwell) Date: Mon, 30 Jan 2017 08:49:58 -0800 Subject: [AstroPy] Calculating alt/az or zenith angle/parallactic angle In-Reply-To: References: <523c4cb0-13f7-b0c5-656a-cd8d09bc8228@physics.ox.ac.uk> Message-ID: Hi Fran, Thanks for the tip. I?ll take a look at it. BR, Tim -- Tim Cornwell Sent with Airmail On 30 January 2017 at 10:13:59 am, Francisco Gallardo l?pez ( f.gallardo.lopez at gmail.com) wrote: @Tim: You may want to take a look at the Apsynsim . It's a code in Python made by Ivan Mart? (Chalmers Univ.). It's a R. Astronomy interferometer simulator. The code is available and includes a GUI. It uses the Hour Angle for the calculations, so by looking at the "APSYNSIM.py" you may be able to implement what you want ( def _changeCoordinates ?). BTW: I read again my last email and realized that it should be HA = LST - ar[k] no the other way around. @Erik: We were trying to calculate the EL curves (during a long time span) for a large number of NEOs. We used JPL Spice to obtain the RA and DEC for those instants. It was a matter of translating that to the observer local Sky (the idea was to generate a friendly web-based user interface). It was quite slow and we thought it was due to this Issue: https://github.com/ astropy/astropy/issues/3323 BR Fran Gallardo 2017-01-30 10:33 GMT+01:00 Tim Cornwell : > Hi Erik, > > Thanks for the reply. I?m writing a reference library for SKA (part of the > Science Data Processor consortium work), and as part of that I need to do > simulations of observations with SKA. The configuration of an > interferometric array is a function of hour angle and the absolute time is > not relevant for most observations. So most of the simulations can be done > in hour angle without having a choose a notional time. The reasons for this > are that we can observe day or night. This isn?t always true but it mostly > is. Some effects are purely dependent on Az, El (e.g. power patten of an > array fixed to the ground or an alt-az antenna). > > I can do this in other packages (such as casa) but astropy is lightweight > but capable so I?d rather use it if at all possible. > > Regards, > > Tim > > -- > Tim Cornwell > Sent with Airmail > > On 30 January 2017 at 4:08:31 am, Erik Tollerud (erik.tollerud at gmail.com) > wrote: > > Hi Francisco, > > > > I think we discarded Skycoord due to the speed so we used PyEphem. > > Can you give a bit more on the specific use case that led you to this > decision? SkyCoord has a fair amount of space for optimization, so it > would be useful to know what kinds of use cases are coming out as "slow" so > we can try to make them better. > > > --- > Erik T > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wqp.gatech at gmail.com Tue Jan 31 10:37:10 2017 From: wqp.gatech at gmail.com (Qinpeng Wang) Date: Tue, 31 Jan 2017 09:37:10 -0600 Subject: [AstroPy] ascii read question Message-ID: Hi, all, I'm new to the AstroPy community, but I find the ascii read function very useful for ascii data import. However, I run into errors reading my table, probably due to the fact that I'm not quite familiar with all supported formats. I attach my table below, can somebody give me a hint how to read in all column names correctly? I have tried this when guessing failed: a = ascii.read("199808041.AHA", format = "basic", delimiter = " ", guess = False), but I don't know what to do with the "[ " in the header. Thanks! Qinpeng -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 199808041.AHA Type: application/octet-stream Size: 10285 bytes Desc: not available URL: From derek at astro.physik.uni-goettingen.de Tue Jan 31 11:51:23 2017 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Tue, 31 Jan 2017 17:51:23 +0100 Subject: [AstroPy] ascii read question In-Reply-To: References: Message-ID: <9BFEED0B-197E-4E55-BACF-01B5606C6AF9@astro.physik.uni-goettingen.de> Hi Qinpeng, > > I'm new to the AstroPy community, but I find the ascii read function very useful for ascii data import. However, I run into errors reading my table, probably due to the fact that I'm not quite familiar with all supported formats. > > I attach my table below, can somebody give me a hint how to read in all column names correctly? > > I have tried this when guessing failed: > a = ascii.read("199808041.AHA", format = "basic", delimiter = " ", guess = False), but I don't know what to do with the "[ " in the header. > the separate ?[ ? instances cause a mismatch between the header and data column numbers, so you?d need to get rid of either the blanks separating them from the actual names, or of the brackets altogether. The read() function does provide a ?header_Splitter? keyword for some custom pre- and postprocessing of the header lines - see http://docs.astropy.org/en/stable/api/astropy.io.ascii.BaseSplitter.html but it seems to use it you need to do a little Class exercise: class mysplitter(astropy.io.ascii.BaseSplitter): def __init__(self): self.process_line = lambda x: x.translate({ord('['):'', ord(']'):?}) Note that you have to remove the brackets from the header line before it is split by the whitespace. Then a = ascii.read("199808041.AHA", format = "basic", delimiter = " ", guess = False, header_Splitter = mysplitter) should work, but create column names entirely without the brackets. Don?t know if anyone has an idea how to do this in a more straightforward manner... HTH, Derek From derek at astro.physik.uni-goettingen.de Tue Jan 31 12:22:12 2017 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Tue, 31 Jan 2017 18:22:12 +0100 Subject: [AstroPy] ascii read question In-Reply-To: <9BFEED0B-197E-4E55-BACF-01B5606C6AF9@astro.physik.uni-goettingen.de> References: <9BFEED0B-197E-4E55-BACF-01B5606C6AF9@astro.physik.uni-goettingen.de> Message-ID: <4DB7C8B1-35FD-4BF9-98C0-D656DBF7968F@astro.physik.uni-goettingen.de> > On 31 Jan 2017, at 5:51 PM, Derek Homeier wrote: > >> I'm new to the AstroPy community, but I find the ascii read function very useful for ascii data import. However, I run into errors reading my table, probably due to the fact that I'm not quite familiar with all supported formats. >> >> I attach my table below, can somebody give me a hint how to read in all column names correctly? >> >> I have tried this when guessing failed: >> a = ascii.read("199808041.AHA", format = "basic", delimiter = " ", guess = False), but I don't know what to do with the "[ " in the header. >> > the separate ?[ ? instances cause a mismatch between the header and data column numbers, so you?d need > to get rid of either the blanks separating them from the actual names, or of the brackets altogether. > The read() function does provide a ?header_Splitter? keyword for some custom pre- and postprocessing of > the header lines - see http://docs.astropy.org/en/stable/api/astropy.io.ascii.BaseSplitter.html > but it seems to use it you need to do a little Class exercise: > > class mysplitter(astropy.io.ascii.BaseSplitter): > def __init__(self): > self.process_line = lambda x: x.translate({ord('['):'', ord(']'):?}) > Just a follow-up to self (no pun intended, but I am quite a dilettante when it comes to classes) - This may indeed be a slightly cleaner option since it should not override the parent class?s initialisation (and of course stripping the ?]? is entirely optional here and just for a cleaner look): class mysplitter(astropy.io.ascii.BaseSplitter): def process_line(self, line): return line.translate({ord('['):'', ord(']'):''}) > Note that you have to remove the brackets from the header line before it is split by the whitespace. Then > > a = ascii.read("199808041.AHA", format = "basic", delimiter = " ", guess = False, header_Splitter = mysplitter) > > should work, but create column names entirely without the brackets. > Don?t know if anyone has an idea how to do this in a more straightforward manner... Cheers, Derek