These are chat archives for astropy/astropy

14th
Jul 2014
Thomas Robitaille
@astrofrog
Jul 14 2014 08:07
@Cadair - are you around?
Stuart Mumford
@Cadair
Jul 14 2014 08:28
hey @astrofrog
Thomas Robitaille
@astrofrog
Jul 14 2014 08:32
Hi @Cadair, was just looking at your example of reprojection
Stuart Mumford
@Cadair
Jul 14 2014 08:32
cool
Thomas Robitaille
@astrofrog
Jul 14 2014 08:32
I just updated astropy/astropy#2731 to rebase on my latest wcs changes
also fixed something with the units, so I think it's doing the right thing now
what would you expect the output to be?
i..e why is it wrong currently?
the coordinates are not the longitude/latitude on the surface of the sun, right? they are just on the sky, so the area of the image is < 1 degree across, so differences in projections won't be very big
Stuart Mumford
@Cadair
Jul 14 2014 08:34
hmmm
maybe I need to convert to HGS first
Thomas Robitaille
@astrofrog
Jul 14 2014 08:34
well you could keep the original image in HP
and then make the new header in HGS with CAR projection
I think that's what you want, right?
Stuart Mumford
@Cadair
Jul 14 2014 08:35
think so
Thomas Robitaille
@astrofrog
Jul 14 2014 08:35
make sure you update to the latest version of my branch
Thomas Robitaille
@astrofrog
Jul 14 2014 08:36
yep - I think the output WCS is wrong for now
out_ctype = ['HPLN-CAR', 'HPLT-CAR'] is not what you want
Stuart Mumford
@Cadair
Jul 14 2014 08:36
indeed
that means I need to get the HPC -> HGS coordinate transform working
Thomas Robitaille
@astrofrog
Jul 14 2014 08:36
ah, is that not working currently?
Stuart Mumford
@Cadair
Jul 14 2014 08:37
no
we know what the problem is now, which is a nice improvement
we have another issue though
we want to default the dateobs FrameAttribute to the time when the frame is created if no flag was specified
except we can't
Thomas Robitaille
@astrofrog
Jul 14 2014 08:37
huh, why not?
Stuart Mumford
@Cadair
Jul 14 2014 08:38
everything we try to override the behaviour of the BaseFrame constructor breaks something
Thomas Robitaille
@astrofrog
Jul 14 2014 08:38
hmm
Stuart Mumford
@Cadair
Jul 14 2014 08:38
we can't set it via the usual way in TimeFrameAttribute() because then the time is calculated at import not construct
so we tried intercepting the kwarg in the constructor and populating it if it wasn't specified
Thomas Robitaille
@astrofrog
Jul 14 2014 08:39
right, and overloading __init__ in your custom frame doesn't work?
Stuart Mumford
@Cadair
Jul 14 2014 08:40
but then SkyCoord breaks when you try and do a transform, because it remembers the FrameAttr from the frame you are converting from but then doesn't pass that value as a kwarg to the frame construtor, so it gets passed it twice
@astrofrog, we are trying to be clever in the constructor but it is breaking
Thomas Robitaille
@astrofrog
Jul 14 2014 08:42
so just to be clear, you have your custom frame, you are doing obstime = TimeFrameAttribute(default=None, secondary_attribute='equinox') and then you overload __init__ and you check if it's the default value and if it is, you reset it to the current time, and that doesn't work?
(ignore secondary_attribute='equinox' part)
Stuart Mumford
@Cadair
Jul 14 2014 08:44
@astrofrog
@astrofrog that works if you use the frame constructor it breaks SkyCoord tho
Thomas Robitaille
@astrofrog
Jul 14 2014 08:54
@Cadair - I see what you mean
I'm not sure if there is a way around it though
hmm
Stuart Mumford
@Cadair
Jul 14 2014 08:56
astrofrog, We tried manually setting the FrameAttribute value in the constructor
but then the super overwrote it as None
Thomas Robitaille
@astrofrog
Jul 14 2014 08:56
right, I was trying different things here
Stuart Mumford
@Cadair
Jul 14 2014 08:56
I suppose the only thing left to do is to override it after the super constructor call?
Thomas Robitaille
@astrofrog
Jul 14 2014 08:56
I think you should raise it as an issue and ask @eteq and @taldcroft
well another possibility
maybe it's too much magic for this to happen at the frame level
and maybe it's something you could more easily do with a custom SunCoord or SolarCoord class?
Stuart Mumford
@Cadair
Jul 14 2014 08:58
I really want to avoid that
Thomas Robitaille
@astrofrog
Jul 14 2014 08:58
ok
Stuart Mumford
@Cadair
Jul 14 2014 08:58
because WCSAxes and Ginga and stuff all use SkyCoord
Thomas Robitaille
@astrofrog
Jul 14 2014 08:58
ok
Stuart Mumford
@Cadair
Jul 14 2014 08:58
It feels like we will miss out on a lot of good stuff if we go that route
I am happy to wait for SkyCoord to support the sting parsing we want
it is not like we have that functionality at the moment
so
...
Thomas Robitaille
@astrofrog
Jul 14 2014 08:59
ok, other possibility, make it that TimeFrameAttribute understands default='now' and delays evaluation until the first 'get'
Stuart Mumford
@Cadair
Jul 14 2014 08:59
@astrofrog yeah that might work
Thomas Robitaille
@astrofrog
Jul 14 2014 09:00
it'd be a change you could submit to astropy core
but you could try overloading TimeFrameAttribute in Sunpy first
you could even have a mini-language
default='now-import'
default='now-get'
but maybe now is enough
brb
overloading TimeFramAttribute seems the cleanest approach
Stuart Mumford
@Cadair
Jul 14 2014 09:05
@astrofrog, manually setting it after the super constructor also works
Thomas Robitaille
@astrofrog
Jul 14 2014 09:11
@Cadair - just curious, why make that implicit assumption of defaulting the obstime rather than just having the user expliciltly say obstime=Time.now()?
it's not like it's that long to write, and wouldn't it be better for the user to make the assumption themselves?
Stuart Mumford
@Cadair
Jul 14 2014 09:11
@astrofrog, partly because it is the way it is done now
Thomas Robitaille
@astrofrog
Jul 14 2014 09:11
ok cool
Stuart Mumford
@Cadair
Jul 14 2014 09:12
it might be better
I think it is something we will discuss
Thomas Robitaille
@astrofrog
Jul 14 2014 09:13
ok, sounds good
Stuart Mumford
@Cadair
Jul 14 2014 09:14
there is another advantage to subclassing TimeFrameAttribute
we can use our awesome string parser :p
Thomas Robitaille
@astrofrog
Jul 14 2014 09:15
it might be worth doing that subclassing anyway since obstime='now' is easier than obstime=Time.now()
even if you don't set it as the default, it's still useful
Stuart Mumford
@Cadair
Jul 14 2014 09:17
@astrofrog it works!
Thomas Robitaille
@astrofrog
Jul 14 2014 09:24
awesome!
afk for a little, but back later
Stuart Mumford
@Cadair
Jul 14 2014 10:12
@astrofrog you back yet?
Thomas Robitaille
@astrofrog
Jul 14 2014 10:15
@Cadair - yes, back now
Stuart Mumford
@Cadair
Jul 14 2014 10:16
@astrofrog, when I create a SKyCoord with dateobs=... it is not getting propagated through the transform graph
Thomas Robitaille
@astrofrog
Jul 14 2014 10:17
you mean dateobs doesn't get propagated?
Stuart Mumford
@Cadair
Jul 14 2014 10:17
yeah
Thomas Robitaille
@astrofrog
Jul 14 2014 10:17
weird
Stuart Mumford
@Cadair
Jul 14 2014 10:17
so if I want to use it in the second link in a transform it's not there
Thomas Robitaille
@astrofrog
Jul 14 2014 10:18
hmm
sounds like a bug
I'd raise the issue
Stuart Mumford
@Cadair
Jul 14 2014 10:18
each Frame in the transform has a dateobs TimeFrameAttributeSunPy
and it seems to vanish
Thomas Robitaille
@astrofrog
Jul 14 2014 10:19
weird
Stuart Mumford
@Cadair
Jul 14 2014 10:20
@astrofrog, if I do the double hop manually it works
Thomas Robitaille
@astrofrog
Jul 14 2014 10:20
huh
that does sound like a bug
Stuart Mumford
@Cadair
Jul 14 2014 10:21
bug time
#2741
Stuart Mumford
@Cadair
Jul 14 2014 13:21
@taldcroft you about?
Erik Tollerud
@eteq
Jul 14 2014 14:29
@Cadair - is this about the SkyCoord issue you mentioned above?
Stuart Mumford
@Cadair
Jul 14 2014 14:29
yeah
though as I have commented on #2741 I fixed it
Erik Tollerud
@eteq
Jul 14 2014 14:29
ah, I see
Stuart Mumford
@Cadair
Jul 14 2014 14:29
I wonder if you agree that the way I fixed it is the best way of doing it?
Erik Tollerud
@eteq
Jul 14 2014 14:34
taking a look now
yeah, what you did in the fix is probably the cleaner way, although an alternative would be something like
kwargs = dict([(nm, getattr(hgcframe, nm)) for nm in hgcframe.get_frame_attr_names()])
return HelioGraphicCarrington(representation, **kwargs)
realize_frame is basically just shorthand for that
Erik Tollerud
@eteq
Jul 14 2014 14:40
I agree with @astrofrog’s comment that if you think this was not intuitive, it would help to add something about this in the docs (in theDefining Transformations section of docs/coords/frames.rst)
Stuart Mumford
@Cadair
Jul 14 2014 14:44
@eteq Yeah, I might add something to that, but I need to understand something better first
the second frame arg in the transform function, it is always instantiated, but can be empty right?
Stuart Mumford
@Cadair
Jul 14 2014 14:55
@eteq or anyone else
Once you have fitted a model to some data, is there a way to find the error on that fit?
some kind of good-ness of fit parameter?
Thomas Robitaille
@astrofrog
Jul 14 2014 14:57
@Cadair - it's a feature request: astropy/astropy#1055
Erik Tollerud
@eteq
Jul 14 2014 14:57
oh, missed there was a question in your last comment, @Cadair: the second argument is indeed always instantiated, but I think never has data (that may not be guaranteed, but it’s never intended to be treated like it has data)
Stuart Mumford
@Cadair
Jul 14 2014 14:59
right, ok but SkyCoord sets it's FrameAttributes
thanks @astrofrog that seems pretty important!!
Erik Tollerud
@eteq
Jul 14 2014 15:00
@Cadair for your second question - at least for the modeling.fitting.LevMarLSQFitter, you can get this directly:
x = np.arange(100)
y = 2*x+1+np.random.randn(100)/10
m=modeling.models.Linear1D(0,1)
f=modeling.fitting.LevMarLSQFitter()
f(m,x,y)
f.fit_info['param_cov’]
the last line will then give you the covariance matrix of the parameters

right, ok but SkyCoord sets it's FrameAttributes

That’s right, the intent is that you never even have to think about SkyCoord while writing frame transforms. That’s the whole separation-of-layers thing that APE5 was aiming for (if that turns out not to be true, I’d consider at a bug, most likey)

Stuart Mumford
@Cadair
Jul 14 2014 15:12
thanks on both counts @eteq