From mcbeth at broggs.org Wed Sep 2 09:06:52 2015 From: mcbeth at broggs.org (Jeffrey Brent McBeth) Date: Wed, 2 Sep 2015 09:06:52 -0400 Subject: [AstroPy] Confused by coordinate transforms ICRS/ITRS/GCRS In-Reply-To: <20150828121348.GH5880@broggs.org> References: <20150828121348.GH5880@broggs.org> Message-ID: <20150902130651.GR5880@broggs.org> Is there further information I could provide, or another place I could ask? Jeff On Fri, Aug 28, 2015 at 08:13:48AM -0400, Jeffrey Brent McBeth wrote: > I've been working on a personal project figuring out where stars are from the point of view of the ISS (after reading about the difficulty of the transform in a paper on the Hubble). > > So, I have a catalog in ICRS, and location of the ISS in ITRS. All fine and good, now I want calculate orientations, and take into account some of the weirdness like parallax and velocity aberration. > > I have some code below that shows some of the things I've tried and the various ways I see things going "wrong". I'm perfectly willing to admit the wrong is more likely to be me, but in that case I would like to be educated. > > Thanks for your time and patience, > Jeff > > #+name: confusingTransforms > #+begin_src: python > import astropy > import astropy.coordinates > import astropy.time > import astropy.units as u > > # For now, lets just talk about the center of the earth > # You may complain "this isn't in the sky", but I get similar results > # even when I'm well away from the earth, this keeps things simple, and since > # I'm ultimately trying for orientation transforms, doesn't matter > earth = astropy.coordinates.SkyCoord(x=0,y=0,z=0,frame='itrs',unit=u.m) > # And a spot one meter away > # This goes wrong with larger distances too, so it isn't simply precision > almostEarth = astropy.coordinates.SkyCoord(x=0,y=0,z=1,frame='itrs',unit=u.m) > > # I would expect _most_ prints below to be 1 meter > print 'ITRS/ITRS:',earth.separation_3d(almostEarth) > print 'ICRS/ITRS:',earth.icrs.separation_3d(almostEarth) > print 'ICRS/ICRS:',earth.icrs.separation_3d(almostEarth.icrs) > > print 'GCRS/ITRS:',earth.gcrs.separation_3d(almostEarth) > print 'GCRS/GCRS:',earth.gcrs.separation_3d(almostEarth.gcrs) > > now = astropy.time.Time.now() > later = now+1*u.second > > # A notional ISS, I have the real numbers, but this keeps it simple > platform = astropy.coordinates.GCRS(obsgeoloc=[0,0,400]*u.km,obsgeovel=[0,0,7.5]*u.km/u.s,obstime=now) > > platformLater = astropy.coordinates.GCRS(obsgeoloc=[0,0,400]*u.km,obsgeovel=[0,0,7.5]*u.km/u.s,obstime=later) > > print 'GCRS(Now )/GCRS(Now ):',earth.transform_to(platform).separation_3d(almostEarth.transform_to(platform)) > print 'GCRS(Later)/GCRS(Later):',earth.transform_to(platformLater).separation_3d(almostEarth.transform_to(platformLater)) > > # These two, due to earth motion should probably be around 30km > print 'GCRS(Now )/GCRS(Later):',earth.transform_to(platform).separation_3d(almostEarth.transform_to(platformLater)) > print 'GCRS(Later)/GCRS(Now ):',earth.transform_to(platformLater).separation_3d(almostEarth.transform_to(platform)) > #+end_src > -- > "The man who does not read good books has no advantage over > the man who cannot read them." > -- Mark Twain > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy -- "The man who does not read good books has no advantage over the man who cannot read them." -- Mark Twain From embray at stsci.edu Wed Sep 2 15:01:18 2015 From: embray at stsci.edu (Erik Bray) Date: Wed, 2 Sep 2015 15:01:18 -0400 Subject: [AstroPy] Confused by coordinate transforms ICRS/ITRS/GCRS In-Reply-To: <20150902130651.GR5880@broggs.org> References: <20150828121348.GH5880@broggs.org> <20150902130651.GR5880@broggs.org> Message-ID: <55E7477E.2040702@stsci.edu> Hi Jeff, On 09/02/2015 09:06 AM, Jeffrey Brent McBeth wrote: > > Is there further information I could provide, or another place I could ask? I think often with questions like this it helps to show what output you're getting (you wrote what you expected to get but not what you actually got). Sometimes seeing the output (without having to run the code one's self) can help in quickly seeing what's going wrong. I have very little knowledge of this code, but I can maybe offer a few hints below: > On Fri, Aug 28, 2015 at 08:13:48AM -0400, Jeffrey Brent McBeth wrote: >> # For now, lets just talk about the center of the earth >> # You may complain "this isn't in the sky", but I get similar results >> # even when I'm well away from the earth, this keeps things simple, and since >> # I'm ultimately trying for orientation transforms, doesn't matter >> earth = astropy.coordinates.SkyCoord(x=0,y=0,z=0,frame='itrs',unit=u.m) >> # And a spot one meter away >> # This goes wrong with larger distances too, so it isn't simply precision >> almostEarth = astropy.coordinates.SkyCoord(x=0,y=0,z=1,frame='itrs',unit=u.m) >> >> # I would expect _most_ prints below to be 1 meter >> print 'ITRS/ITRS:',earth.separation_3d(almostEarth) >> print 'ICRS/ITRS:',earth.icrs.separation_3d(almostEarth) >> print 'ICRS/ICRS:',earth.icrs.separation_3d(almostEarth.icrs) >> >> print 'GCRS/ITRS:',earth.gcrs.separation_3d(almostEarth) >> print 'GCRS/GCRS:',earth.gcrs.separation_3d(almostEarth.gcrs) For example, for ITRS->ICRS for both coordinates I get: >>> earth.icrs.separation_3d(almostEarth.icrs) I think this is a probably a bug, probably stemming from the fact that your "earth" coordinates are ill-defined when converting to spherical coordinates (which the code does). That's just my guess but it seems like a decent one. If I instead use: >>> almostEarth2 = astropy.coordinates.SkyCoord(x=1,y=1,z=1,frame='itrs',unit=u.m) >>> almostEarth3 = astropy.coordinates.SkyCoord(x=2,y=2,z=2,frame='itrs',unit=u.m) I get: >>> almostEarth2.separation_3d(almostEarth3) (== sqrt(3) as expected) and >>> almostEarth2.icrs.separation_3d(almostEarth3.icrs).to(u.m) So off by a little more than a meter--I don't know how much error to expect but that seems reasonable considering that this is converting from AU to m. The error seems to get worse the further out I go though, but still within the correct order of magnitude, at least. I'll note the transformation from ITRS to ICRS goes: ITRS -> CIRS -> ICRS. The problem seems to occur, unsurprisingly, in the CIRS -> ICRS step (the former doesn't have any problem). Erik From embray at stsci.edu Wed Sep 2 19:32:32 2015 From: embray at stsci.edu (Erik Bray) Date: Wed, 2 Sep 2015 19:32:32 -0400 Subject: [AstroPy] Fwd: Delivery delayed:Re: Confused by coordinate transforms ICRS/ITRS/GCRS In-Reply-To: <4096d7f2-ef35-4b16-aa6d-6261d79bcd7f@EXCHCAS1.stsci.edu> References: <4096d7f2-ef35-4b16-aa6d-6261d79bcd7f@EXCHCAS1.stsci.edu> Message-ID: <55E78710.80901@stsci.edu> Anyone have any idea about this? -------- Forwarded Message -------- Subject: Delivery delayed:Re: [AstroPy] Confused by coordinate transforms ICRS/ITRS/GCRS Date: Wed, 2 Sep 2015 19:06:11 -0400 From: Microsoft Outlook To: embray at stsci.edu *Delivery is delayed to these recipients or groups:* astropy at scipy.org Subject: Re: [AstroPy] Confused by coordinate transforms ICRS/ITRS/GCRS This message hasn't been delivered yet. Delivery will continue to be attempted. The server will keep trying to deliver this message for the next 1 days, 19 hours and 55 minutes. You'll be notified if the message can't be delivered by that time. -------------- next part -------------- A non-text attachment was scrubbed... Name: Attached Message Part Type: text/rfc822-headers Size: 2010 bytes Desc: not available URL: From mcbeth at broggs.org Thu Sep 3 10:29:31 2015 From: mcbeth at broggs.org (Jeffrey Brent McBeth) Date: Thu, 3 Sep 2015 10:29:31 -0400 Subject: [AstroPy] Confused by coordinate transforms ICRS/ITRS/GCRS In-Reply-To: <55E7477E.2040702@stsci.edu> References: <20150828121348.GH5880@broggs.org> <20150902130651.GR5880@broggs.org> <55E7477E.2040702@stsci.edu> Message-ID: <20150903142931.GT5880@broggs.org> On Wed, Sep 02, 2015 at 03:01:18PM -0400, Erik Bray wrote: > Hi Jeff, > > On 09/02/2015 09:06 AM, Jeffrey Brent McBeth wrote: > > > > Is there further information I could provide, or another place I could ask? > > I think often with questions like this it helps to show what output you're > getting (you wrote what you expected to get but not what you actually got). > Sometimes seeing the output (without having to run the code one's self) can help > in quickly seeing what's going wrong. You are right, I should have included the output, I am sorry. > I have very little knowledge of this code, but I can maybe offer a few hints below: > I think this is a probably a bug, probably stemming from the fact that your > "earth" coordinates are ill-defined when converting to spherical coordinates > (which the code does). That's just my guess but it seems like a decent one. If I weren't seeing the problem no matter where I am in near earth space (I'm simulating ISS and Hubble), I would definitely agree with you. I probably should have called out a more complicated example too. > >>> almostEarth2.icrs.separation_3d(almostEarth3.icrs).to(u.m) > > > So off by a little more than a meter--I don't know how much error to expect but > that seems reasonable considering that this is converting from AU to m. The > error seems to get worse the further out I go though, but still within the > correct order of magnitude, at least. And this is where my "fun little experiment" breaks down. The hubble WC3's, for example, each subtend .632x10^-6 radians. So, I need vector directions accurate below that to stand a chance of matching up. It looks like going anywhere near ICRS from ITRS or comparing two GCRS frames is downright dangerous. Which is a shame, I was hoping to be messing with aberration (hubble should be seeing ~200 pixels), and I can't get the coordinate transforms anywhere close to even that level of accuracy :( Thank you for your help. Unfortunately, this is pushing me toward having to code up these transforms on my own, which as we all know is fraught with peril. Jeff Below are the code and results if I change things to start 1000km above the ground #+name: confusingTransforms #+begin_src: python import astropy import astropy.coordinates import astropy.time import astropy.units as u # For now, lets just talk about the center of the earth # You may complain "this isn't in the sky", but I get similar results # even when I'm well away from the earth, this keeps things simple, and since # I'm ultimately trying for orientation transforms, doesn't matter earth = astropy.coordinates.SkyCoord(x=0,y=0,z=1000,frame='itrs',unit=u.km) # And a spot one meter away # This goes wrong with larger distances too, so it isn't simply precision almostEarth = astropy.coordinates.SkyCoord(x=0,y=0,z=2000,frame='itrs',unit=u.km) # I would expect _most_ prints below to be 1000 kilometer print 'ITRS/ITRS:',earth.separation_3d(almostEarth).to(u.km) print 'ICRS/ITRS:',earth.icrs.separation_3d(almostEarth).to(u.km) print 'ICRS/ICRS:',earth.icrs.separation_3d(almostEarth.icrs).to(u.km) print 'GCRS/ITRS:',earth.gcrs.separation_3d(almostEarth).to(u.km) print 'GCRS/GCRS:',earth.gcrs.separation_3d(almostEarth.gcrs).to(u.km) now = astropy.time.Time.now() later = now+1*u.second # A notional ISS, I have the real numbers, but this keeps it simple platform = astropy.coordinates.GCRS(obsgeoloc=[0,0,400]*u.km,obsgeovel=[0,0,7.5]*u.km/u.s,obstime=now) platformLater = astropy.coordinates.GCRS(obsgeoloc=[0,0,400]*u.km,obsgeovel=[0,0,7.5]*u.km/u.s,obstime=later) print 'GCRS(Now )/GCRS(Now ):',earth.transform_to(platform).separation_3d(almostEarth.transform_to(platform)).to(u.km) print 'GCRS(Later)/GCRS(Later):',earth.transform_to(platformLater).separation_3d(almostEarth.transform_to(platformLater)).to(u.km) # These two, due to earth motion should probably be around 1000+/-30km print 'GCRS(Now )/GCRS(Later):',earth.transform_to(platform).separation_3d(almostEarth.transform_to(platformLater)).to(u.km) print 'GCRS(Later)/GCRS(Now ):',earth.transform_to(platformLater).separation_3d(almostEarth.transform_to(platform)).to(u.km) #+end_src #+begin_example ITRS/ITRS: [ 1000.] km ICRS/ITRS: [ 2.44988467e+08] km ICRS/ICRS: [ 390.88978995] km GCRS/ITRS: [ 1000.] km GCRS/GCRS: [1000.] km GCRS(Now )/GCRS(Now ): [ 340.79708459] km GCRS(Later)/GCRS(Later): [ 340.79711114] km GCRS(Now )/GCRS(Later): [ 59479316.98264851] km GCRS(Later)/GCRS(Now ): [ 59479320.25267375] km #+end_example -- "The man who does not read good books has no advantage over the man who cannot read them." -- Mark Twain From astropy at liska.ath.cx Thu Sep 3 11:08:22 2015 From: astropy at liska.ath.cx (Ole Streicher) Date: Thu, 03 Sep 2015 17:08:22 +0200 Subject: [AstroPy] Trying to read Tycho-2 catalog Message-ID: <87lhcnpml5.fsf@donar.aip.de> from astropy.io import ascii Hi, I am trying to read the Tycho-2 data catalog from CDS [1] with astropy.io.ascii. First question is: The catalog is split into 20 data files tyc2.dat.00 ... tyc2.dat.19[.gz]; how can I read them in? ascii.read() wants to use a single file name only, not a list of file names. When I tried to read a single file according to the help: cat = ascii.read('tyc2.dat.00', readme='ReadMe') I get a TypeError: __init__() got an unexpected keyword argument 'readme'; did I misunderstand here something or is this a (known) bug (version 1.0.3)? I then tried reader = ascii.get_reader(ascii.Cds, readme='ReadMe') cat = reader.read('tyc2.dat.00') which leads to an InconsistentTableError: Can't find table tyc2.dat.00 in ReadMe. Is there a way to specify the actual name of the catalog so that I don't have to rename the file? Finally, if I rename the file to 'tyc2.dat' (or concatenate all data files into a file of this name): cat = reader.read('tyc2.dat') I get a ValueError: Column RAmdeg failed to convert. (The column seems to contain empty values: may this be the problem?) How should I proceed here pragmatically? Or did I something completely not understand? Best regards Ole [1] http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/259 From burtscher at mpe.mpg.de Thu Sep 3 11:38:43 2015 From: burtscher at mpe.mpg.de (Leonard Burtscher) Date: Thu, 3 Sep 2015 17:38:43 +0200 Subject: [AstroPy] Trying to read Tycho-2 catalog In-Reply-To: <87lhcnpml5.fsf@donar.aip.de> References: <87lhcnpml5.fsf@donar.aip.de> Message-ID: <16D02A30-FEC8-4578-9C5E-484F63678F51@mpe.mpg.de> Hi Ole, I would recommend using the astropy.Table class which makes it very easy to deal with tables. To read your table you can simply do from astropy.table import Table tyc = Table.read("tyc2.dat.00",format="ascii") I am not sure what the size restriction or performance of this is, but parsing 500 MB of text through Python will certainly take a while. If you're only interested in a subset of the catalog, I would recommend cutting out the required columns using bash tools. E.g. if you only need columns 1 and 2, you could do cat tyc2.dat.00 | awk -F "|" '{print $1 "|" $2}' > tyc2_12.dat.00 Best, Leonard > Am 03.09.2015 um 17:08 schrieb Ole Streicher : > > from astropy.io import ascii > > Hi, > > I am trying to read the Tycho-2 data catalog from CDS [1] with > astropy.io.ascii. First question is: The catalog is split into 20 data > files tyc2.dat.00 ... tyc2.dat.19[.gz]; how can I read them in? > ascii.read() wants to use a single file name only, not a list of file > names. > > When I tried to read a single file according to the help: > > cat = ascii.read('tyc2.dat.00', readme='ReadMe') > > I get a TypeError: __init__() got an unexpected keyword argument > 'readme'; did I misunderstand here something or is this a (known) bug > (version 1.0.3)? > > I then tried > > reader = ascii.get_reader(ascii.Cds, readme='ReadMe') > cat = reader.read('tyc2.dat.00') > > which leads to an InconsistentTableError: Can't find table tyc2.dat.00 > in ReadMe. Is there a way to specify the actual name of the catalog so > that I don't have to rename the file? > > Finally, if I rename the file to 'tyc2.dat' (or concatenate all data > files into a file of this name): > > cat = reader.read('tyc2.dat') > > I get a ValueError: Column RAmdeg failed to convert. (The column seems > to contain empty values: may this be the problem?) > > How should I proceed here pragmatically? Or did I something completely > not understand? > > Best regards > > Ole > > [1] http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/259 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From embray at stsci.edu Thu Sep 3 12:10:02 2015 From: embray at stsci.edu (Erik Bray) Date: Thu, 3 Sep 2015 12:10:02 -0400 Subject: [AstroPy] Confused by coordinate transforms ICRS/ITRS/GCRS In-Reply-To: <20150903142931.GT5880@broggs.org> References: <20150828121348.GH5880@broggs.org> <20150902130651.GR5880@broggs.org> <55E7477E.2040702@stsci.edu> <20150903142931.GT5880@broggs.org> Message-ID: <55E870DA.2070900@stsci.edu> On 09/03/2015 10:29 AM, Jeffrey Brent McBeth wrote: > And this is where my "fun little experiment" breaks down. The hubble WC3's, > for example, each subtend .632x10^-6 radians. So, I need vector directions > accurate below that to stand a chance of matching up. It looks like going > anywhere near ICRS from ITRS or comparing two GCRS frames is downright > dangerous. > > Which is a shame, I was hoping to be messing with aberration (hubble should > be seeing ~200 pixels), and I can't get the coordinate transforms anywhere > close to even that level of accuracy :( > > Thank you for your help. Unfortunately, this is pushing me toward having to > code up these transforms on my own, which as we all know is fraught with > peril. I think that's probably more likely to be a waste of time. I think there's a better way to do what you're trying to do, but I don't know what it is myself. Though I don't fully understand either I'm not sure why none of the experts haven't chimed in yet... Erik > Below are the code and results if I change things to start 1000km above the > ground > > #+name: confusingTransforms #+begin_src: python import astropy import > astropy.coordinates import astropy.time import astropy.units as u > > # For now, lets just talk about the center of the earth # You may complain > "this isn't in the sky", but I get similar results # even when I'm well away > from the earth, this keeps things simple, and since # I'm ultimately trying > for orientation transforms, doesn't matter earth = > astropy.coordinates.SkyCoord(x=0,y=0,z=1000,frame='itrs',unit=u.km) # And a > spot one meter away # This goes wrong with larger distances too, so it isn't > simply precision almostEarth = > astropy.coordinates.SkyCoord(x=0,y=0,z=2000,frame='itrs',unit=u.km) > > # I would expect _most_ prints below to be 1000 kilometer print > 'ITRS/ITRS:',earth.separation_3d(almostEarth).to(u.km) print > 'ICRS/ITRS:',earth.icrs.separation_3d(almostEarth).to(u.km) print > 'ICRS/ICRS:',earth.icrs.separation_3d(almostEarth.icrs).to(u.km) > > print 'GCRS/ITRS:',earth.gcrs.separation_3d(almostEarth).to(u.km) print > 'GCRS/GCRS:',earth.gcrs.separation_3d(almostEarth.gcrs).to(u.km) > > now = astropy.time.Time.now() later = now+1*u.second > > # A notional ISS, I have the real numbers, but this keeps it simple platform > = > astropy.coordinates.GCRS(obsgeoloc=[0,0,400]*u.km,obsgeovel=[0,0,7.5]*u.km/u.s,obstime=now) > > platformLater = > astropy.coordinates.GCRS(obsgeoloc=[0,0,400]*u.km,obsgeovel=[0,0,7.5]*u.km/u.s,obstime=later) > > print 'GCRS(Now )/GCRS(Now > ):',earth.transform_to(platform).separation_3d(almostEarth.transform_to(platform)).to(u.km) > > print 'GCRS(Later)/GCRS(Later):',earth.transform_to(platformLater).separation_3d(almostEarth.transform_to(platformLater)).to(u.km) > > # These two, due to earth motion should probably be around 1000+/-30km print > 'GCRS(Now > )/GCRS(Later):',earth.transform_to(platform).separation_3d(almostEarth.transform_to(platformLater)).to(u.km) > > print 'GCRS(Later)/GCRS(Now ):',earth.transform_to(platformLater).separation_3d(almostEarth.transform_to(platform)).to(u.km) > #+end_src > > #+begin_example ITRS/ITRS: [ 1000.] km ICRS/ITRS: [ 2.44988467e+08] km > ICRS/ICRS: [ 390.88978995] km GCRS/ITRS: [ 1000.] km GCRS/GCRS: [1000.] km > GCRS(Now )/GCRS(Now ): [ 340.79708459] km GCRS(Later)/GCRS(Later): [ > 340.79711114] km GCRS(Now )/GCRS(Later): [ 59479316.98264851] km > GCRS(Later)/GCRS(Now ): [ 59479320.25267375] km #+end_example > From aldcroft at head.cfa.harvard.edu Thu Sep 3 12:33:47 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Thu, 3 Sep 2015 12:33:47 -0400 Subject: [AstroPy] Trying to read Tycho-2 catalog In-Reply-To: <87lhcnpml5.fsf@donar.aip.de> References: <87lhcnpml5.fsf@donar.aip.de> Message-ID: Hi Ole, I copied tyc2.dat.00 to tyc2.dat and had success with the recommended use pattern of: >>> t = ascii.read('tyc2.dat', readme='ReadMe') This format is certainly tricky and there is room to improve the error handling. The issue with your first try was that the ReadMe has a list of possible data files and tyc2.dat.00 was not there. On Thu, Sep 3, 2015 at 11:08 AM, Ole Streicher wrote: > from astropy.io import ascii > > Hi, > > I am trying to read the Tycho-2 data catalog from CDS [1] with > astropy.io.ascii. First question is: The catalog is split into 20 data > files tyc2.dat.00 ... tyc2.dat.19[.gz]; how can I read them in? > ascii.read() wants to use a single file name only, not a list of file > names. > > When I tried to read a single file according to the help: > > cat = ascii.read('tyc2.dat.00', readme='ReadMe') > > I get a TypeError: __init__() got an unexpected keyword argument > 'readme'; did I misunderstand here something or is this a (known) bug > (version 1.0.3)? > This weird error is a result of the guessing process where it ends up trying formats that don't accept the readme arg. If you know in advance the format then you can specify the format along with guess=False in order to get the actual exception: >>> t = ascii.read('tyc2.dat.00', readme='ReadMe', format='cds', guess=False) ... InconsistentTableError: Can't find table tyc2.dat.00 in ReadMe > > I then tried > > reader = ascii.get_reader(ascii.Cds, readme='ReadMe') > cat = reader.read('tyc2.dat.00') > > which leads to an InconsistentTableError: Can't find table tyc2.dat.00 > in ReadMe. Is there a way to specify the actual name of the catalog so > that I don't have to rename the file? > The CDS format requires that the data files be named exactly as specified in the ReadMe. You could always change the ReadMe. > > Finally, if I rename the file to 'tyc2.dat' (or concatenate all data > files into a file of this name): > > cat = reader.read('tyc2.dat') > > I get a ValueError: Column RAmdeg failed to convert. (The column seems > to contain empty values: may this be the problem?) > > How should I proceed here pragmatically? Or did I something completely > not understand? > > Best regards > > Ole > > [1] http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/259 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Thu Sep 3 12:39:54 2015 From: embray at stsci.edu (Erik Bray) Date: Thu, 3 Sep 2015 12:39:54 -0400 Subject: [AstroPy] Trying to read Tycho-2 catalog In-Reply-To: References: <87lhcnpml5.fsf@donar.aip.de> Message-ID: <55E877DA.7080607@stsci.edu> On 09/03/2015 12:33 PM, Aldcroft, Thomas wrote: > >>> t = ascii.read('tyc2.dat.00', readme='ReadMe', format='cds', guess=False) > ... > InconsistentTableError: Can't find table tyc2.dat.00 in ReadMe > > > I then tried > > reader = ascii.get_reader(ascii.Cds, readme='ReadMe') > cat = reader.read('tyc2.dat.00') > > which leads to an InconsistentTableError: Can't find table tyc2.dat.00 > in ReadMe. Is there a way to specify the actual name of the catalog so > that I don't have to rename the file? > > > The CDS format requires that the data files be named exactly as specified in the > ReadMe. You could always change the ReadMe. It's strange that they would distribute the catalog data in a manner that isn't actually compatible with the CDS format. I can understand if tyc2.dat is large that they would want to break it into multiple files (but then how do you know which file you want?). Is this format some known extension to CDS? How does other software read this catalog? Erik From aldcroft at head.cfa.harvard.edu Thu Sep 3 13:02:29 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Thu, 3 Sep 2015 13:02:29 -0400 Subject: [AstroPy] Trying to read Tycho-2 catalog In-Reply-To: <55E877DA.7080607@stsci.edu> References: <87lhcnpml5.fsf@donar.aip.de> <55E877DA.7080607@stsci.edu> Message-ID: On Thu, Sep 3, 2015 at 12:39 PM, Erik Bray wrote: > On 09/03/2015 12:33 PM, Aldcroft, Thomas wrote: > > >>> t = ascii.read('tyc2.dat.00', readme='ReadMe', format='cds', > guess=False) > > ... > > InconsistentTableError: Can't find table tyc2.dat.00 in ReadMe > > > > > > I then tried > > > > reader = ascii.get_reader(ascii.Cds, readme='ReadMe') > > cat = reader.read('tyc2.dat.00') > > > > which leads to an InconsistentTableError: Can't find table > tyc2.dat.00 > > in ReadMe. Is there a way to specify the actual name of the catalog > so > > that I don't have to rename the file? > > > > > > The CDS format requires that the data files be named exactly as > specified in the > > ReadMe. You could always change the ReadMe. > > It's strange that they would distribute the catalog data in a manner that > isn't > actually compatible with the CDS format. I can understand if tyc2.dat is > large > that they would want to break it into multiple files (but then how do you > know > which file you want?). > > Is this format some known extension to CDS? How does other software read > this > catalog? > I can't find anything, though it doesn't help that google thinks CDS refers to those obsolete shiny platter thingies. BTW, there was a bug that I found related to this, see https://github.com/astropy/astropy/issues/4120. - Tom > > Erik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Thu Sep 3 13:05:53 2015 From: aldcroft at head.cfa.harvard.edu (Aldcroft, Thomas) Date: Thu, 3 Sep 2015 13:05:53 -0400 Subject: [AstroPy] Trying to read Tycho-2 catalog In-Reply-To: <55E877DA.7080607@stsci.edu> References: <87lhcnpml5.fsf@donar.aip.de> <55E877DA.7080607@stsci.edu> Message-ID: On Thu, Sep 3, 2015 at 12:39 PM, Erik Bray wrote: > On 09/03/2015 12:33 PM, Aldcroft, Thomas wrote: > > >>> t = ascii.read('tyc2.dat.00', readme='ReadMe', format='cds', > guess=False) > > ... > > InconsistentTableError: Can't find table tyc2.dat.00 in ReadMe > > > > > > I then tried > > > > reader = ascii.get_reader(ascii.Cds, readme='ReadMe') > > cat = reader.read('tyc2.dat.00') > > > > which leads to an InconsistentTableError: Can't find table > tyc2.dat.00 > > in ReadMe. Is there a way to specify the actual name of the catalog > so > > that I don't have to rename the file? > > > > > > The CDS format requires that the data files be named exactly as > specified in the > > ReadMe. You could always change the ReadMe. > > It's strange that they would distribute the catalog data in a manner that > isn't > actually compatible with the CDS format. I can understand if tyc2.dat is > large > that they would want to break it into multiple files (but then how do you > know > which file you want?). > > Is this format some known extension to CDS? How does other software read > this > catalog? > If anyone has some time and patience, there is a program tofits on the page http://vizier.u-strasbg.fr/doc/catstd.htx which might shed light on whether the data files can be split in accordance with the standard. - Tom > > Erik > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Thu Sep 3 13:13:07 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 03 Sep 2015 19:13:07 +0200 Subject: [AstroPy] Trying to read Tycho-2 catalog In-Reply-To: <87lhcnpml5.fsf@donar.aip.de> References: <87lhcnpml5.fsf@donar.aip.de> Message-ID: <55E87FA3.6050209@gmail.com> Hi Ole, Note that when using CDS, you can always choose to download the catalog as a FITS binary table which would be much simpler to read in. You can go to this page: http://vizier.u-strasbg.fr/viz-bin/VizieR?-source=I/259 select the catalog you want, and on the left in 'Preferences' select 'unlimited' and 'FITS (binary) table'. Cheers, Tom Ole Streicher wrote: > from astropy.io import ascii > > Hi, > > I am trying to read the Tycho-2 data catalog from CDS [1] with > astropy.io.ascii. First question is: The catalog is split into 20 data > files tyc2.dat.00 ... tyc2.dat.19[.gz]; how can I read them in? > ascii.read() wants to use a single file name only, not a list of file > names. > > When I tried to read a single file according to the help: > > cat = ascii.read('tyc2.dat.00', readme='ReadMe') > > I get a TypeError: __init__() got an unexpected keyword argument > 'readme'; did I misunderstand here something or is this a (known) bug > (version 1.0.3)? > > I then tried > > reader = ascii.get_reader(ascii.Cds, readme='ReadMe') > cat = reader.read('tyc2.dat.00') > > which leads to an InconsistentTableError: Can't find table tyc2.dat.00 > in ReadMe. Is there a way to specify the actual name of the catalog so > that I don't have to rename the file? > > Finally, if I rename the file to 'tyc2.dat' (or concatenate all data > files into a file of this name): > > cat = reader.read('tyc2.dat') > > I get a ValueError: Column RAmdeg failed to convert. (The column seems > to contain empty values: may this be the problem?) > > How should I proceed here pragmatically? Or did I something completely > not understand? > > Best regards > > Ole > > [1] http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/259 > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From astropy at liska.ath.cx Thu Sep 3 14:14:44 2015 From: astropy at liska.ath.cx (Ole Streicher) Date: Thu, 03 Sep 2015 20:14:44 +0200 Subject: [AstroPy] Trying to read Tycho-2 catalog References: <87lhcnpml5.fsf@donar.aip.de> <55E87FA3.6050209@gmail.com> Message-ID: <87d1xzpdyj.fsf@donar.aip.de> Thomas Robitaille writes: > Note that when using CDS, you can always choose to download the catalog > as a FITS binary table which would be much simpler to read in. Thanks, this probably solves my complete problem :-) I wanted to create a FITS table that can be read to build an astrometry.net index. I will just add my findings as issues to github... Cheers Ole From npkuin at gmail.com Thu Sep 3 16:33:13 2015 From: npkuin at gmail.com (Paul Kuin) Date: Thu, 3 Sep 2015 21:33:13 +0100 Subject: [AstroPy] Trying to read Tycho-2 catalog In-Reply-To: <87d1xzpdyj.fsf@donar.aip.de> References: <87lhcnpml5.fsf@donar.aip.de> <55E87FA3.6050209@gmail.com> <87d1xzpdyj.fsf@donar.aip.de> Message-ID: (1) it would be good to ask the CDS help desk about this. My vague recollection is that long ascii data tables are split up. Then a simple cat name.txt.?? > name.txt re creates the whole (2) tofits takes the readme file and ascii data files and converts that into a fits file, though I do no longer remember if you get one file or many. In this case I think one. Paul On Thu, Sep 3, 2015 at 7:14 PM, Ole Streicher wrote: > Thomas Robitaille writes: > > Note that when using CDS, you can always choose to download the catalog > > as a FITS binary table which would be much simpler to read in. > > Thanks, this probably solves my complete problem :-) I wanted to create > a FITS table that can be read to build an astrometry.net index. > > I will just add my findings as issues to github... > > Cheers > > Ole > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.robitaille at gmail.com Wed Sep 9 10:16:02 2015 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Wed, 9 Sep 2015 16:16:02 +0200 Subject: [AstroPy] Apply now for the Python in Astronomy 2016 conference! (21-25th March 2016) Message-ID: Dear colleagues, We are very pleased to inform you that applications are now open for the Python in Astronomy 2016 conference: Python in Astronomy University of Washington eScience Institute Seattle, WA, USA 21-25th March 2016 http://python-in-astronomy.github.io/2016/ This meeting aims to bring together researchers, Python developers, users, and educators, and will include presentations, tutorials, unconference sessions, and coding sprints. In addition to sharing information about state-of-the-art Python Astronomy packages, the workshop will also focus on improving interoperability between astronomical Python packages, providing training for new contributors, and developing educational materials for Python in Astronomy. The meeting is therefore aimed not only at current developers, but also users and educators who are interested in being involved in these efforts. Note that this meeting is not intended to be a Python 'boot camp', and we do expect participants to have already at least used Python for some of their projects, even if only at a beginner level. To apply, please go to the following page: http://python-in-astronomy.github.io/2016/ and follow the link to the application form. Applications should be submitted by 9th October 2015 at the latest, and we hope to let you know by mid- to late November whether you have been accepted. Contingent on sponsorship, we hope to offer financial support for travel for a few participants. If you would like to apply for financial support, please indicate this in the last section of the application form. Please forward this email to anyone who may be interested! Best regards, The organizing committee: Kelle Cruz Perry Greenfield Eric Jeschke Mario Juric Stuart Mumford Chanda Prescod-Weinstein Thomas Robitaille Megan Sosey Erik Tollerud Jake Vanderplas From arcjohns at ucsc.edu Thu Sep 10 14:05:06 2015 From: arcjohns at ucsc.edu (Christian Johnson) Date: Thu, 10 Sep 2015 11:05:06 -0700 Subject: [AstroPy] Help needed - Pix2Sky error Message-ID: Hi all, (if this is the wrong list to use for questions like this, please let me know!) I'm attempting to use astropy to get data out of a FITS file in the Aitoff projection, and was trying to use the astropy.modeling.projections.Pix2Sky_AIT class (that I found here: http://astropy.readthedocs.org/en/latest/modeling/index.html). However, when I try to use it, I get an error that there is no module of that name ("AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'"). I can successfully import astropy.modeling.projections.Projection or astropy.modeling.projections.Zenithal or a few others, but most throw this error. Is there something I'm doing wrong, or does some other package need to be installed for these modules to work correctly? Thanks in advance, Christian Johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: From dencheva at stsci.edu Thu Sep 10 14:37:09 2015 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Thu, 10 Sep 2015 18:37:09 +0000 Subject: [AstroPy] Help needed - Pix2Sky error In-Reply-To: References: Message-ID: <0153364C9F56D944B0A795780ECF88DF6780EF20@EXCHMAIL2.stsci.edu> Hi Christian, It' s best to import models like this: >>> from astropy.modeling import models >>> ait = models.Pix2Sky_AIT() >>> ait(1, 2) (1.0004603647362484, 2.000082499873663) >>> ait.inverse(1.0004603647362484, 2.000082499873663) (1.0, 2.0000000000000004) Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Christian Johnson [arcjohns at ucsc.edu] Sent: Thursday, September 10, 2015 2:05 PM To: astropy at scipy.org Subject: [AstroPy] Help needed - Pix2Sky error Hi all, (if this is the wrong list to use for questions like this, please let me know!) I'm attempting to use astropy to get data out of a FITS file in the Aitoff projection, and was trying to use the astropy.modeling.projections.Pix2Sky_AIT class (that I found here: http://astropy.readthedocs.org/en/latest/modeling/index.html). However, when I try to use it, I get an error that there is no module of that name ("AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'"). I can successfully import astropy.modeling.projections.Projection or astropy.modeling.projections.Zenithal or a few others, but most throw this error. Is there something I'm doing wrong, or does some other package need to be installed for these modules to work correctly? Thanks in advance, Christian Johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: From arcjohns at ucsc.edu Thu Sep 10 14:44:10 2015 From: arcjohns at ucsc.edu (Christian Johnson) Date: Thu, 10 Sep 2015 11:44:10 -0700 Subject: [AstroPy] Help needed - Pix2Sky error In-Reply-To: <0153364C9F56D944B0A795780ECF88DF6780EF20@EXCHMAIL2.stsci.edu> References: <0153364C9F56D944B0A795780ECF88DF6780EF20@EXCHMAIL2.stsci.edu> Message-ID: Nadia, Thanks for the reply! Unfortunately I get the same error with your syntax (AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'). I believe my projections.py file is out of date- there's no AIT class defined in it, when it should look like this ( https://github.com/astropy/astropy/blob/master/astropy/modeling/projections.py ). I'm using astropy version 1.04 which I believe is the current version, so I'm confused about why I don't have the updated code? Thanks, Christian On Thu, Sep 10, 2015 at 11:37 AM, Nadezhda Dencheva wrote: > Hi Christian, > > It' s best to import models like this: > > >>> from astropy.modeling import models > >>> ait = models.Pix2Sky_AIT() > >>> ait(1, 2) > (1.0004603647362484, 2.000082499873663) > >>> ait.inverse(1.0004603647362484, 2.000082499873663) > (1.0, 2.0000000000000004) > > Nadia > > ------------------------------ > *From:* astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf > of Christian Johnson [arcjohns at ucsc.edu] > *Sent:* Thursday, September 10, 2015 2:05 PM > *To:* astropy at scipy.org > *Subject:* [AstroPy] Help needed - Pix2Sky error > > Hi all, > > (if this is the wrong list to use for questions like this, please let me > know!) > > I'm attempting to use astropy to get data out of a FITS file in the Aitoff > projection, and was trying to use the > astropy.modeling.projections.Pix2Sky_AIT class (that I found here: > http://astropy.readthedocs.org/en/latest/modeling/index.html). However, > when I try to use it, I get an error that there is no module of that name ("AttributeError: > 'module' object has no attribute 'Pix2Sky_AIT'"). I can successfully import > astropy.modeling.projections.Projection or astropy.modeling.projections.Zenithal > or a few others, but most throw this error. > > Is there something I'm doing wrong, or does some other package need to be > installed for these modules to work correctly? > > Thanks in advance, > Christian Johnson > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dencheva at stsci.edu Thu Sep 10 14:48:33 2015 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Thu, 10 Sep 2015 18:48:33 +0000 Subject: [AstroPy] Help needed - Pix2Sky error In-Reply-To: References: <0153364C9F56D944B0A795780ECF88DF6780EF20@EXCHMAIL2.stsci.edu>, Message-ID: <0153364C9F56D944B0A795780ECF88DF6780EF35@EXCHMAIL2.stsci.edu> Christian, This is in master, I don't think it's been released yet. Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Christian Johnson [arcjohns at ucsc.edu] Sent: Thursday, September 10, 2015 2:44 PM To: Astronomical Python mailing list Subject: Re: [AstroPy] Help needed - Pix2Sky error Nadia, Thanks for the reply! Unfortunately I get the same error with your syntax (AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'). I believe my projections.py file is out of date- there's no AIT class defined in it, when it should look like this (https://github.com/astropy/astropy/blob/master/astropy/modeling/projections.py). I'm using astropy version 1.04 which I believe is the current version, so I'm confused about why I don't have the updated code? Thanks, Christian On Thu, Sep 10, 2015 at 11:37 AM, Nadezhda Dencheva > wrote: Hi Christian, It' s best to import models like this: >>> from astropy.modeling import models >>> ait = models.Pix2Sky_AIT() >>> ait(1, 2) (1.0004603647362484, 2.000082499873663) >>> ait.inverse(1.0004603647362484, 2.000082499873663) (1.0, 2.0000000000000004) Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Christian Johnson [arcjohns at ucsc.edu] Sent: Thursday, September 10, 2015 2:05 PM To: astropy at scipy.org Subject: [AstroPy] Help needed - Pix2Sky error Hi all, (if this is the wrong list to use for questions like this, please let me know!) I'm attempting to use astropy to get data out of a FITS file in the Aitoff projection, and was trying to use the astropy.modeling.projections.Pix2Sky_AIT class (that I found here: http://astropy.readthedocs.org/en/latest/modeling/index.html). However, when I try to use it, I get an error that there is no module of that name ("AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'"). I can successfully import astropy.modeling.projections.Projection or astropy.modeling.projections.Zenithal or a few others, but most throw this error. Is there something I'm doing wrong, or does some other package need to be installed for these modules to work correctly? Thanks in advance, Christian Johnson _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From arcjohns at ucsc.edu Thu Sep 10 15:43:50 2015 From: arcjohns at ucsc.edu (Christian Johnson) Date: Thu, 10 Sep 2015 12:43:50 -0700 Subject: [AstroPy] Help needed - Pix2Sky error In-Reply-To: <0153364C9F56D944B0A795780ECF88DF6780EF35@EXCHMAIL2.stsci.edu> References: <0153364C9F56D944B0A795780ECF88DF6780EF20@EXCHMAIL2.stsci.edu> <0153364C9F56D944B0A795780ECF88DF6780EF35@EXCHMAIL2.stsci.edu> Message-ID: Nadia, Do you know of a simple way to install the master version? I tried following the instructions here: http://astropy.readthedocs.org/en/stable/install.html#building-from-source to install the development version but I'm getting errors trying to install Thanks, Christian On Thu, Sep 10, 2015 at 11:48 AM, Nadezhda Dencheva wrote: > Christian, > > This is in master, I don't think it's been released yet. > > Nadia > ------------------------------ > *From:* astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf > of Christian Johnson [arcjohns at ucsc.edu] > *Sent:* Thursday, September 10, 2015 2:44 PM > *To:* Astronomical Python mailing list > *Subject:* Re: [AstroPy] Help needed - Pix2Sky error > > Nadia, > > Thanks for the reply! Unfortunately I get the same error with your syntax (AttributeError: > 'module' object has no attribute 'Pix2Sky_AIT'). I believe my > projections.py file is out of date- there's no AIT class defined in > it, when it should look like this ( > https://github.com/astropy/astropy/blob/master/astropy/modeling/projections.py > ). I'm using astropy version 1.04 which I believe is the current version, > so I'm confused about why I don't have the updated code? > > Thanks, > Christian > > On Thu, Sep 10, 2015 at 11:37 AM, Nadezhda Dencheva > wrote: > >> Hi Christian, >> >> It' s best to import models like this: >> >> >>> from astropy.modeling import models >> >>> ait = models.Pix2Sky_AIT() >> >>> ait(1, 2) >> (1.0004603647362484, 2.000082499873663) >> >>> ait.inverse(1.0004603647362484, 2.000082499873663) >> (1.0, 2.0000000000000004) >> >> Nadia >> >> ------------------------------ >> *From:* astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf >> of Christian Johnson [arcjohns at ucsc.edu] >> *Sent:* Thursday, September 10, 2015 2:05 PM >> *To:* astropy at scipy.org >> *Subject:* [AstroPy] Help needed - Pix2Sky error >> >> Hi all, >> >> (if this is the wrong list to use for questions like this, please let me >> know!) >> >> I'm attempting to use astropy to get data out of a FITS file in the >> Aitoff projection, and was trying to use the >> astropy.modeling.projections.Pix2Sky_AIT class (that I found here: >> http://astropy.readthedocs.org/en/latest/modeling/index.html). However, >> when I try to use it, I get an error that there is no module of that name ("AttributeError: >> 'module' object has no attribute 'Pix2Sky_AIT'"). I can successfully import >> astropy.modeling.projections.Projection or astropy.modeling.projections.Zenithal >> or a few others, but most throw this error. >> >> Is there something I'm doing wrong, or does some other package need to be >> installed for these modules to work correctly? >> >> Thanks in advance, >> Christian Johnson >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> http://mail.scipy.org/mailman/listinfo/astropy >> >> > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dencheva at stsci.edu Thu Sep 10 16:40:17 2015 From: dencheva at stsci.edu (Nadezhda Dencheva) Date: Thu, 10 Sep 2015 20:40:17 +0000 Subject: [AstroPy] Help needed - Pix2Sky error In-Reply-To: References: <0153364C9F56D944B0A795780ECF88DF6780EF20@EXCHMAIL2.stsci.edu> <0153364C9F56D944B0A795780ECF88DF6780EF35@EXCHMAIL2.stsci.edu>, Message-ID: <0153364C9F56D944B0A795780ECF88DF6780EF86@EXCHMAIL2.stsci.edu> What is the OS? Can you post the errors? Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Christian Johnson [arcjohns at ucsc.edu] Sent: Thursday, September 10, 2015 3:43 PM To: Astronomical Python mailing list Subject: Re: [AstroPy] Help needed - Pix2Sky error Nadia, Do you know of a simple way to install the master version? I tried following the instructions here: http://astropy.readthedocs.org/en/stable/install.html#building-from-source to install the development version but I'm getting errors trying to install Thanks, Christian On Thu, Sep 10, 2015 at 11:48 AM, Nadezhda Dencheva > wrote: Christian, This is in master, I don't think it's been released yet. Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Christian Johnson [arcjohns at ucsc.edu] Sent: Thursday, September 10, 2015 2:44 PM To: Astronomical Python mailing list Subject: Re: [AstroPy] Help needed - Pix2Sky error Nadia, Thanks for the reply! Unfortunately I get the same error with your syntax (AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'). I believe my projections.py file is out of date- there's no AIT class defined in it, when it should look like this (https://github.com/astropy/astropy/blob/master/astropy/modeling/projections.py). I'm using astropy version 1.04 which I believe is the current version, so I'm confused about why I don't have the updated code? Thanks, Christian On Thu, Sep 10, 2015 at 11:37 AM, Nadezhda Dencheva > wrote: Hi Christian, It' s best to import models like this: >>> from astropy.modeling import models >>> ait = models.Pix2Sky_AIT() >>> ait(1, 2) (1.0004603647362484, 2.000082499873663) >>> ait.inverse(1.0004603647362484, 2.000082499873663) (1.0, 2.0000000000000004) Nadia ________________________________ From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Christian Johnson [arcjohns at ucsc.edu] Sent: Thursday, September 10, 2015 2:05 PM To: astropy at scipy.org Subject: [AstroPy] Help needed - Pix2Sky error Hi all, (if this is the wrong list to use for questions like this, please let me know!) I'm attempting to use astropy to get data out of a FITS file in the Aitoff projection, and was trying to use the astropy.modeling.projections.Pix2Sky_AIT class (that I found here: http://astropy.readthedocs.org/en/latest/modeling/index.html). However, when I try to use it, I get an error that there is no module of that name ("AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'"). I can successfully import astropy.modeling.projections.Projection or astropy.modeling.projections.Zenithal or a few others, but most throw this error. Is there something I'm doing wrong, or does some other package need to be installed for these modules to work correctly? Thanks in advance, Christian Johnson _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy _______________________________________________ AstroPy mailing list AstroPy at scipy.org http://mail.scipy.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Thu Sep 10 17:21:40 2015 From: embray at stsci.edu (Erik Bray) Date: Thu, 10 Sep 2015 17:21:40 -0400 Subject: [AstroPy] Help needed - Pix2Sky error In-Reply-To: References: Message-ID: <55F1F464.7000504@stsci.edu> On 09/10/2015 02:05 PM, Christian Johnson wrote: > Hi all, > > (if this is the wrong list to use for questions like this, please let me know!) > > I'm attempting to use astropy to get data out of a FITS file in the Aitoff > projection, and was trying to use the astropy.modeling.projections.Pix2Sky_AIT > class (that I found here: > http://astropy.readthedocs.org/en/latest/modeling/index.html). However, when I For what it's worth, the docs labeled "latest" are documentation for the most recent development version. The most recent released version is at http://astropy.readthedocs.org/en/stable, which is also what you get if you go directly to http://docs.astropy.org You can see this difference also in the top-left corner where on "stable" it currently reads "Astropy v1.0.4", while on "latest" it reads "Astropy v1.1.dev13387". The more I think about it though the less happy I am with this nomenclature. I think it's non-obvious that "latest" should be distinct from "stable". I'd rather it were called "dev" or something like that. Unfortunately the name is given by readthedocs itself and doesn't seem changeable. I'll poke them to see if they'd be willing to make the "latest" docs be renameable. Might be an easy patch, even... Erik > try to use it, I get an error that there is no module of that name > ("AttributeError: 'module' object has no attribute 'Pix2Sky_AIT'"). I can > successfully import astropy.modeling.projections.Projection or > astropy.modeling.projections.Zenithal or a few others, but most throw this error. > > Is there something I'm doing wrong, or does some other package need to be > installed for these modules to work correctly? > > Thanks in advance, > Christian Johnson > > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > From jazmin.berlanga at gmail.com Fri Sep 11 14:07:40 2015 From: jazmin.berlanga at gmail.com (Jazmin Berlanga Medina) Date: Fri, 11 Sep 2015 18:07:40 +0000 Subject: [AstroPy] Astroplan v0.1 Announcement Message-ID: Hi all! Brett Morris and Jazmin Berlanga Medina, student programmers for Astropy and the Python Sofware foundation, would like to share our Google Summer of Code project with you. We're proud to announce v0.1 of Astroplan, an observation planning and scheduling toolbox for astronomers! Astroplan is an open-source Python package and is powered by Astropy. Features include: - Calculate rise/set/transit times, alt/az positions for targets at observatories anywhere on Earth - Built-in plotting functions (airmass, parallactic angle, sky maps) - Determine which targets are "observable" given a list of constraints like moon separation, "above" some airmass, and/or within an altitude range, etc. - Built-in site list, with ability for users to add more. - Did we mention we're powered by Astropy? For more information on Astroplan, check out: http://astroplan.readthedocs.org We're just starting out and invite any astronomers, observatories, programmers and other cool people to join us in making this a great package! We're envisioning scheduling algorithms, a graphical interface and much more! Feedback and feature contribution are welcome at: https://github.com/astropy/astroplan What's Google Summer of Code? Check out: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Thanks! Jazmin Berlanga Medina & Brett Morris -------------- next part -------------- An HTML attachment was scrubbed... URL: From jslavin at cfa.harvard.edu Tue Sep 15 13:33:12 2015 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Tue, 15 Sep 2015 13:33:12 -0400 Subject: [AstroPy] deprecation warning from ipython Message-ID: Hi all, I was curious why I've started getting a deprecation warning from ipython when I import astropy: /export/slavin/python/anaconda/lib/python2.7/site-packages/IPython/kernel/__init__.py:13: ShimWarning: The `IPython.kernel` package has been deprecated. You should import from ipykernel or jupyter_client instead. "You should import from ipykernel or jupyter_client instead.", ShimWarning) ?It looks like it's related to the "Big Split" between ipython and jupyter. Are there plans to change the relevant part(s) of the code? Or is it an ipython issue? Regards, Jon? -- ________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA ________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pebarrett at gmail.com Fri Sep 25 07:13:00 2015 From: pebarrett at gmail.com (Paul Barrett) Date: Fri, 25 Sep 2015 07:13:00 -0400 Subject: [AstroPy] Mail server test Message-ID: This is just a test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.p.singer at nasa.gov Mon Sep 28 22:17:00 2015 From: leo.p.singer at nasa.gov (Singer, Leo P. (GSFC-661.0)[OAK RIDGE ASSOCIATED UNIVERSITIES (ORAU)]) Date: Tue, 29 Sep 2015 02:17:00 +0000 Subject: [AstroPy] Temporary files leaked by long-running process that calls astropy.utils.data.download_file Message-ID: <24D94D6E-ECAB-45ED-B641-D37BD3012BF0@nasa.gov> Hi, I have a process that is meant to run for a few days to months at a time, that is leaking temporary files whenever I download files using the functions in astropy.utils.data. I found no leaks in my own code. Then I looked in astropy.utils.data.get_readable_fileobj, and I found that the temporary files that it creates always make their way into the delete_fds list, and could not be leaked. Then I finally thought to look in astropy.utils.data.download_file itself, and found that it is leaking the files?at least until the interpreter exits cleanly! if conf.delete_temporary_downloads_at_exit: global _tempfilestodel _tempfilestodel.append(local_path) I find the astropy.utils.data module very convenient, and I would like to continue to use it in this long-running process. Would the maintainers be open to a patch that adds an option to delete these temporary files immediately, instead of at cleanup? Thanks, Leo P. Singer NASA Postdoctoral Program Fellow Goddard Space Flight Center 8800 Greenbelt Rd., B34, Room S239 Greenbelt, MD 20771 From kylebarbary at gmail.com Tue Sep 29 00:08:57 2015 From: kylebarbary at gmail.com (Kyle Barbary) Date: Tue, 29 Sep 2015 00:08:57 -0400 Subject: [AstroPy] [ANN] Nestle: Nested sampling Message-ID: Hi all, I'm pleased to announce the initial release of Nestle, a small Python package for nested sampling. ("Nestle" rhymes with "wrestle".) Nested sampling is a statistical technique for parameter estimation and model comparison, commonly used in cosmology. We've been using it in the sncosmo package and have found it to be a robust global optimizer in addition to its more typically cited benefits. Nestle implements an algorithm similar to that used in the MultiNest software, but in an open-source (MIT) licensed and easy-to-install (pure Python) package. (It was written based only on the literature, not the MultiNest source code.) In addition to this algorithm, Nestle also implements the "classic" nested sampling algorithm and the "single ellipsoid" algorithm. Nestle depends on only numpy and (optionally) scipy and supports both Python 3 and Legacy Python (formerly known as Python 2). docs: http://kbarbary.github.io/nestle source: http://github.com/kbarbary/nestle I'd appreciate any feedback on this initial release, particularly about application to real-world problems and comparisons with results from MultiNest. Thanks! - Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From rolf.buehler at desy.de Tue Sep 29 04:16:30 2015 From: rolf.buehler at desy.de (Rolf Buehler) Date: Tue, 29 Sep 2015 10:16:30 +0200 Subject: [AstroPy] Sine1D with phase? Message-ID: <560A48DE.5050207@desy.de> Dear all, I would like to fit a Sine1D to a dataset, however, am I right that in the current implementation there is no phase parameter? (f(x) = A * sin(2 * pi * f * x + Phase) http://docs.astropy.org/en/stable/api/astropy.modeling.functional_models.Sine1D.html#astropy.modeling.functional_models.Sine1D I will create a custom_model to work around this, but maybe it would be better to add a phase to the model? Thank you and all the best, Rolf -- www.rolfbuehler.net From wkerzendorf at gmail.com Tue Sep 29 04:30:35 2015 From: wkerzendorf at gmail.com (Wolfgang Kerzendorf) Date: Tue, 29 Sep 2015 08:30:35 +0000 Subject: [AstroPy] [ANN] Nestle: Nested sampling In-Reply-To: References: Message-ID: HI Kyle, Very nice. I'll definitely have a look at that. Cheers, Wolfgang -- Dr. Wolfgang E Kerzendorf ESO Fellow European Southern Observatory Karl-Schwarzschild Str. 2, 85748 Garching bei Muenchen, Germany On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary wrote: > Hi all, > > I'm pleased to announce the initial release of Nestle, a small Python > package for nested sampling. ("Nestle" rhymes with "wrestle".) Nested > sampling is a statistical technique for parameter estimation and model > comparison, commonly used in cosmology. We've been using it in the sncosmo > package and have found it to be a robust global optimizer in addition to > its more typically cited benefits. > > Nestle implements an algorithm similar to that used in the MultiNest > software, but in an open-source (MIT) licensed and easy-to-install (pure > Python) package. (It was written based only on the literature, not the > MultiNest source code.) In addition to this algorithm, Nestle also > implements the "classic" nested sampling algorithm and the "single > ellipsoid" algorithm. > > Nestle depends on only numpy and (optionally) scipy and supports both > Python 3 and Legacy Python (formerly known as Python 2). > > docs: http://kbarbary.github.io/nestle > source: http://github.com/kbarbary/nestle > > I'd appreciate any feedback on this initial release, particularly about > application to real-world problems and comparisons with results from > MultiNest. Thanks! > > - Kyle > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > https://mail.scipy.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From embray at stsci.edu Tue Sep 29 09:02:57 2015 From: embray at stsci.edu (Erik Bray) Date: Tue, 29 Sep 2015 09:02:57 -0400 Subject: [AstroPy] Sine1D with phase? In-Reply-To: <560A48DE.5050207@desy.de> References: <560A48DE.5050207@desy.de> Message-ID: <560A8C01.5070408@stsci.edu> On 09/29/2015 04:16 AM, Rolf Buehler wrote: > Dear all, > I would like to fit a Sine1D to a dataset, however, am I right that in the > current implementation there is no phase parameter? (f(x) = A * sin(2 * pi * f * > x + Phase) > > http://docs.astropy.org/en/stable/api/astropy.modeling.functional_models.Sine1D.html#astropy.modeling.functional_models.Sine1D > > > I will create a custom_model to work around this, but maybe it would be better > to add a phase to the model? > > Thank you and all the best, > Rolf A phase parameter was already added in the development version and will be in the v1.1.0 release: http://docs.astropy.org/en/latest/api/astropy.modeling.functional_models.Sine1D.html Best, Erik From embray at stsci.edu Tue Sep 29 09:09:24 2015 From: embray at stsci.edu (Erik Bray) Date: Tue, 29 Sep 2015 09:09:24 -0400 Subject: [AstroPy] Temporary files leaked by long-running process that calls astropy.utils.data.download_file In-Reply-To: <24D94D6E-ECAB-45ED-B641-D37BD3012BF0@nasa.gov> References: <24D94D6E-ECAB-45ED-B641-D37BD3012BF0@nasa.gov> Message-ID: <560A8D84.7030403@stsci.edu> On 09/28/2015 10:17 PM, Singer, Leo P. (GSFC-661.0)[OAK RIDGE ASSOCIATED UNIVERSITIES (ORAU)] wrote: > Hi, > > I have a process that is meant to run for a few days to months at a time, > that is leaking temporary files whenever I download files using the functions > in astropy.utils.data. I found no leaks in my own code. Then I looked in > astropy.utils.data.get_readable_fileobj, and I found that the temporary files > that it creates always make their way into the delete_fds list, and could not > be leaked. Then I finally thought to look in astropy.utils.data.download_file > itself, and found that it is leaking the files?at least until the interpreter > exits cleanly! > > if conf.delete_temporary_downloads_at_exit: global _tempfilestodel > _tempfilestodel.append(local_path) > > I find the astropy.utils.data module very convenient, and I would like to > continue to use it in this long-running process. Would the maintainers be > open to a patch that adds an option to delete these temporary files > immediately, instead of at cleanup? Hi Leo, Thanks for investigating this. For what it's worth, discussion about development of the astropy package itself is usually better directed toward the astropy-dev mailing list: https://groups.google.com/forum/#!forum/astropy-dev Or directly to the issue tracker. But yes, why don't you open an issue for that. Depending on the context it may not always be easy to automatically delete files when they're "done" being used, and it would be up to the user to delete them. But there are other cases where this would make sense. Thanks, Erik From johann.cohentanugi at gmail.com Tue Sep 29 13:03:03 2015 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Tue, 29 Sep 2015 19:03:03 +0200 Subject: [AstroPy] [ANN] Nestle: Nested sampling In-Reply-To: References: Message-ID: <560AC447.1090700@gmail.com> likewise! Any prospect toward the polychord extension? See http://arxiv.org/abs/1506.00171v1 cheers, Johann On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote: > HI Kyle, > > Very nice. I'll definitely have a look at that. > > Cheers, > Wolfgang > -- > Dr. Wolfgang E Kerzendorf > ESO Fellow > European Southern Observatory > Karl-Schwarzschild Str. 2, 85748 > Garching bei Muenchen, Germany > > On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary > wrote: > > Hi all, > > I'm pleased to announce the initial release of Nestle, a small > Python package for nested sampling. ("Nestle" rhymes with > "wrestle".) Nested sampling is a statistical technique for > parameter estimation and model comparison, commonly used in > cosmology. We've been using it in the sncosmo package and have > found it to be a robust global optimizer in addition to its more > typically cited benefits. > > Nestle implements an algorithm similar to that used in the > MultiNest software, but in an open-source (MIT) licensed and > easy-to-install (pure Python) package. (It was written based only > on the literature, not the MultiNest source code.) In addition to > this algorithm, Nestle also implements the "classic" nested > sampling algorithm and the "single ellipsoid" algorithm. > > Nestle depends on only numpy and (optionally) scipy and supports > both Python 3 and Legacy Python (formerly known as Python 2). > > docs: http://kbarbary.github.io/nestle > source: http://github.com/kbarbary/nestle > > I'd appreciate any feedback on this initial release, particularly > about application to real-world problems and comparisons with > results from MultiNest. Thanks! > > - Kyle > _______________________________________________ > 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 kylebarbary at gmail.com Tue Sep 29 14:10:15 2015 From: kylebarbary at gmail.com (Kyle Barbary) Date: Tue, 29 Sep 2015 14:10:15 -0400 Subject: [AstroPy] [ANN] Nestle: Nested sampling In-Reply-To: <560AC447.1090700@gmail.com> References: <560AC447.1090700@gmail.com> Message-ID: Yes, possibly! Nestle currently implements the basic MultiNest method, but doesn't implement later improvements such as importance reweighting or polychord. I'm open to contributions and improvements. (But be mindful of reading the MultiNest source code due to licensing issues!) Best, -- Kyle On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi < johann.cohentanugi at gmail.com> wrote: > likewise! > Any prospect toward the polychord extension? See > http://arxiv.org/abs/1506.00171v1 > cheers, > Johann > > > On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote: > > HI Kyle, > > Very nice. I'll definitely have a look at that. > > Cheers, > Wolfgang > -- > Dr. Wolfgang E Kerzendorf > ESO Fellow > European Southern Observatory > Karl-Schwarzschild Str. 2, 85748 > Garching bei Muenchen, Germany > > On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary < > kylebarbary at gmail.com> wrote: > >> Hi all, >> >> I'm pleased to announce the initial release of Nestle, a small Python >> package for nested sampling. ("Nestle" rhymes with "wrestle".) Nested >> sampling is a statistical technique for parameter estimation and model >> comparison, commonly used in cosmology. We've been using it in the sncosmo >> package and have found it to be a robust global optimizer in addition to >> its more typically cited benefits. >> >> Nestle implements an algorithm similar to that used in the MultiNest >> software, but in an open-source (MIT) licensed and easy-to-install (pure >> Python) package. (It was written based only on the literature, not the >> MultiNest source code.) In addition to this algorithm, Nestle also >> implements the "classic" nested sampling algorithm and the "single >> ellipsoid" algorithm. >> >> Nestle depends on only numpy and (optionally) scipy and supports both >> Python 3 and Legacy Python (formerly known as Python 2). >> >> docs: http://kbarbary.github.io/nestle >> source: >> http://github.com/kbarbary/nestle >> >> I'd appreciate any feedback on this initial release, particularly about >> application to real-world problems and comparisons with results from >> MultiNest. Thanks! >> >> - Kyle >> _______________________________________________ >> AstroPy mailing list >> AstroPy at scipy.org >> https://mail.scipy.org/mailman/listinfo/astropy >> > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: