These are chat archives for astropy/astropy

30th
Mar 2016
Stuart Mumford
@Cadair
Mar 30 2016 08:54 UTC
hey olebole
Ole Streicher
@olebole
Mar 30 2016 08:55 UTC
Hey. So I arrived here :-)
Stuart Mumford
@Cadair
Mar 30 2016 08:55 UTC
yay
I have this logged in though by IRC bouncer now
David Pérez-Suárez
@dpshelio
Mar 30 2016 12:10 UTC
Thankd Cadair! I'm in
David Pérez-Suárez
@dpshelio
Mar 30 2016 12:16 UTC
Cadair do you get it like me, that it seems I'm connecting and disconencting once and again?
oh! to mention you here I have to call you @Cadair
Stuart Mumford
@Cadair
Mar 30 2016 12:34 UTC
hey dpshelio
David Pérez-Suárez
@dpshelio
Mar 30 2016 12:34 UTC
weechat notifies me anyway :)
Stuart Mumford
@Cadair
Mar 30 2016 12:34 UTC
to trigger a Gitter mention you have to use the @ but my irc client picks it up without
dpshelio, you are connecting and disconnecting?
Ole Streicher
@olebole
Mar 30 2016 12:57 UTC
@Cadair, I habe the same problem ... every half a minute or so
Stuart Mumford
@Cadair
Mar 30 2016 12:58 UTC
huh mine seems ok
though I have had that issue before
David Pérez-Suárez
@dpshelio
Mar 30 2016 12:59 UTC
Yes! I'm connecting/disconnecting every 30 seconds
Stuart Mumford
@Cadair
Mar 30 2016 13:09 UTC
well that's annoying
David Pérez-Suárez
@dpshelio
Mar 30 2016 13:16 UTC
that's very annoying when I get the screen full of 3-line messages with me going out/in
Stuart Mumford
@Cadair
Mar 30 2016 13:17 UTC
dpshelio, olebole have you both logged in through the web interface?
David Pérez-Suárez
@dpshelio
Mar 30 2016 13:17 UTC
yes
should I disconnect?
now from the web
wow, my message from the web does not appear in my irc client
Stuart Mumford
@Cadair
Mar 30 2016 13:18 UTC
yeah that's a thing
David Pérez-Suárez
@dpshelio
Mar 30 2016 13:18 UTC
what else I may be loosing
Stuart Mumford
@Cadair
Mar 30 2016 13:21 UTC
dpshelio, the irc bridge just does not forward your messages
it's a 'feature'
Erik Tollerud
@eteq
Mar 30 2016 16:06 UTC
@keflavich re: the ccache question: I’m confused why you need to do this - AFAIK ccache isn’t installed by ananconda so if you put it in /opt/local/bin it should still be found even after anaconda prepends its path
@keflavich @adrn re: “parameteric models”: I understand the point, but I don’t think we should rename the package to that. Right now the class heirarchy includes Model at the top, with ParametricModel below, so I think that would lead do confusion. Also astropy.parametric_model is pretty awkward to type.
So I’m inclined to say it should be left as astropy.model, but re-work the docs to always use the phrase “parametric model” or “physical model” or “mean model”, and avoid wherever possible using the word “model” without qualifiers
this is basically the approach taken in coordinates (where coordinate is a similarly overloaded term)
Adam Ginsburg
@keflavich
Mar 30 2016 16:18 UTC
@eteq: to get ccache working, I thought you had to replace gcc with ccache on your path using a symlink? conda puts its gcc ahead of system gcc
also, :+1: to leaving package name unchanged but making docs clearer
Erik Tollerud
@eteq
Mar 30 2016 16:22 UTC
Oh, gotcha, I thought you meant it was hiding the ccache executable
weird that it's different: for me this isn't a problem because there's no gcc or clang on the conda path
I have /opt/local/libexec/ccache in the front on my default path, and that has gcc/clang executables that conda is perfectly happy to work with
Adam Ginsburg
@keflavich
Mar 30 2016 16:24 UTC
oh… huh.
I must have conda install'd gcc
Erik Tollerud
@eteq
Mar 30 2016 16:24 UTC
oh, yeah, that would do it
Adam Ginsburg
@keflavich
Mar 30 2016 16:24 UTC
dang.
Erik Tollerud
@eteq
Mar 30 2016 16:24 UTC
so you could just uninstall that in conda, although it's unclear what the side effects would be
Adam Ginsburg
@keflavich
Mar 30 2016 16:24 UTC
yeah
it will probably be fine….
but this is not the time to test "probably"
Erik Tollerud
@eteq
Mar 30 2016 16:26 UTC
you could also just replace the gcc in the conda bin dir with a symlink to the ccache version
although that might have unintended consequences
another workaround is to do something like alias pyb="CC="ccache gcc" python setup.py build"
that worked for me on a different machine where I had done something really weird with the paths
Stuart Mumford
@Cadair
Mar 30 2016 16:46 UTC
hey @eteq @keflavich
Adam Ginsburg
@keflavich
Mar 30 2016 16:47 UTC
hey @cadair
eteq - thanks, I like the alias approach. But… pyb? what's that?
oh… wait, I see, nevermind
yeah, OK, forcing the path makes sense
Joseph Booker
@sargas
Mar 30 2016 19:18 UTC
Hello, I was wondering if there is a way to add more keywords to astropy.wcs.WCS or Wcsprm from parsing more of the keywords from a fits header. Specifically, the keywords describing a physical coordinate system by keywords like CDELT1P or CRVAL2L.
Erik Tollerud
@eteq
Mar 30 2016 19:19 UTC
@sargas - by add, you mean when constructing a WCS from scratch? Or actually implement them? (I’m not sure what those particular keywords do offhand…)
Joseph Booker
@sargas
Mar 30 2016 19:19 UTC
I think astropy.wcs is the right place for this, since the keywords are describing a transformation between coordinate systems, but currently I don't see how to access these keywords from a WCS object
Joseph Booker
@sargas
Mar 30 2016 19:24 UTC
@eteq I mean, add to the WCS class as part of a PR, to make these values accessible to code that could use it (kinda like det2im, although I'm not sure how det2im is supposed to work (or what headers it uses) since it's lacking a test case)
By "way to add more keywords," I guess I mean if someone knows of a commit that has done something like this before, or knows the right level to add this
Erik Tollerud
@eteq
Mar 30 2016 20:22 UTC
@sargas - can you clarify what you want those keywords to do? The thing that complicates almost everything with astropy.wcs is that most of the real work is done by the c library libwcs, which is based on the published WCS standards. So if libwcs is supposed to know about those keywords, it should already be accounted for.
oh, and they are accessible if you just want to read them - they are just FITS keywords so you can always read them directly (I’m pretty sure there’s a way to indirectly get at it from the WCS object, too, although I can’t remember offhand what the exact syntax is). The above comment is more for if you want to actually use them as part of the WCS transform.
Joseph Booker
@sargas
Mar 30 2016 20:35 UTC
@eteq I've been thinking about astropy/regions and https://github.com/astropy/pyregion/blob/master/pyregion/physical_coordinate.py , and how to incorporate the physical <-> image coordinate systems into astropy (or image <-> other systems from http://www.ucolick.org/~sla/fits/mosaic/lickwcs.html , for example)
Joseph Booker
@sargas
Mar 30 2016 20:44 UTC
It seems like a WCS object should be enough to transform between the various pixel-based coordinate systems without the original header. Are deviations from wcslib (=libwcs?) in astropy.wcs frowned on?
Erik Tollerud
@eteq
Mar 30 2016 20:52 UTC
yes, definitely
astropy.wcs is intended as a place for the code that is for the WCS standard
there are some deviations (i.e. the SIP distortion scheme, which wasn’t in wcslib initially but eventually got moved in), but not more major changes that are very different from the standard.
Although it’s true that what you are talking about are “extensions” rather than “changes"
it’s honestly a good question what the scope of that should be
my personal opinion is that wcs should stay fairly limited in scope to stuff defined in the FITS-WCS standard (which I thought did include physical<->image coordinates in some sense, although I could be wrong about that)
And new developements occur in parallel with a new wcs approach (e.g., https://github.com/spacetelescope/gwcs, or something else similar if that doesn’t gain traction)
Erik Tollerud
@eteq
Mar 30 2016 20:58 UTC
(that’s partly motivated by the fact that astropy.wcs is pretty tightly integrated with the C wcslib library, which makes it somewhat harder to hack on)
but it might be that others disagree on this
Joseph Booker
@sargas
Mar 30 2016 20:59 UTC
hmm, I'll take a look at gwcs
Erik Tollerud
@eteq
Mar 30 2016 21:02 UTC
@sargas - actually… aren’t CDELT1P taken care of as “alternate” WCSs? I.e., you can have a CDELT1a CDELT1b and so on? Or is the P a non-standard thing?
(For that matter, do you have an example of a file that does this?)
I've yet to find a place that documents that though
Erik Tollerud
@eteq
Mar 30 2016 21:06 UTC
Yeah, my hunch is that it’s completely non-standard - this is probably the form that ds9 was designed to deal with, right? Not clear to me where that’s documented/standardized beyond the ds9 manual (and maybe associated X-ray satellite data?)
Joseph Booker
@sargas
Mar 30 2016 21:08 UTC
Yea, I think this was only meant for ds9/ciao compatibility
Erik Tollerud
@eteq
Mar 30 2016 21:08 UTC
ah, gotcha
I guess now that I think about it it’s not clear why the physical coordinates should be special-cased - if they are just thought of as “another” WCS everything should work
so it might be that the path to this would be to provide special accessors that internally transform this into a more standards-compliant WCS. So that might make sense to include because it wouldn’t require any mucking about at the wcslib layer
Erik Tollerud
@eteq
Mar 30 2016 21:19 UTC
Oh, and det2im is about the distortion stuff from the WCS paper IV. So while the terminology seems similar, I think it’s not related to the ds9 physical/image terms
Joseph Booker
@sargas
Mar 30 2016 21:21 UTC
I actually think pyregion may have been doing it wrong, and the LTM/LTV keywords from IRAF are what define the coordinate system
Erik Tollerud
@eteq
Mar 30 2016 21:22 UTC
aha
here’s the trick: if you use http://docs.astropy.org/en/stable/api/astropy.wcs.find_all_wcs.html#astropy.wcs.find_all_wcs , it will get two WCS objects from that sample header
Joseph Booker
@sargas
Mar 30 2016 21:23 UTC
That header file defines both C....P keywords and LTM/LTV, and the former are probably redudant if they're defined like in http://iraf.noao.edu/projects/fitswcs/wcs-email.html ( although i guess keywords like CDELT1P are the standards-compliant way, as opposed to LTM/LTV)
Erik Tollerud
@eteq
Mar 30 2016 21:23 UTC
it looks like the first one is the “standard” WCS, and the second is the “P” one
Joseph Booker
@sargas
Mar 30 2016 21:23 UTC
hmm
Erik Tollerud
@eteq
Mar 30 2016 21:25 UTC
I can’t get it to load quite right, I think because that example header isn’t actually valid FITS, but I think that’s the key idea
Joseph Booker
@sargas
Mar 30 2016 21:27 UTC
I see. Then the .wcs.cdelt, .wcs.crpix, and .wcs.crval has the values for the physical coordinates
Erik Tollerud
@eteq
Mar 30 2016 21:28 UTC
yep
(of the second WCS)
Joseph Booker
@sargas
Mar 30 2016 21:30 UTC
Thanks, I think I can work with this for my PR
Erik Tollerud
@eteq
Mar 30 2016 21:30 UTC
:+1: