From npkuin at gmail.com  Fri May  1 03:34:19 2020
From: npkuin at gmail.com (Paul Kuin)
Date: Fri, 1 May 2020 08:34:19 +0100
Subject: [AstroPy] VOTable problems
In-Reply-To: <28E4842B-5C1A-4C75-87A1-759154E54D15@astro.physik.uni-goettingen.de>
References: <mailman.1456.1588173843.24659.astropy@python.org>
 <29869684-3272-4038-A85A-FE6FC14D34E2@astro.physik.uni-goettingen.de>
 <28E4842B-5C1A-4C75-87A1-759154E54D15@astro.physik.uni-goettingen.de>
Message-ID: <CANoQ6N3JiTmE1EwCCj+iKfGpUi1rb2iomTbjEYKrZF44n7he4w@mail.gmail.com>

Dear Derek,

On Thu, Apr 30, 2020 at 8:04 PM Derek Homeier
<derek at astro.physik.uni-goettingen.de> wrote:
>
> Hi Rick,
> >
> > astropy.units.core.UnitScaleError: The column 'mass' could not be stored in FITS format because it has a scale '(1.0)' that is not recognized by the FITS standard. Either scale the data or change the units.
> >
> > If one deletes the unit of the "mass" column, everything is ok.  If one uses a FITS-compatible unit like "solMass", everything is ok.  Thus, the problem is that the astropy implementation of converting a votable input into a FITS output won't accept non-FITS units.  The IVOA standard allows one to use any reasonable units and suggests that one follow the style of the FITS standard, but "jovMass" (Jovian masses, in the same syntax as "solMass" = Solar masses) isn't a FITS standard.  Generally, the IVOA standard should be the measure of things.  There are lots of tables that don't want to have to use wierd units like the FITS-acceptable "solMass/1047" or "1.8982e27*solMass?.
> >
> the IVOA standard actually allows the user to invent any kind of units, reasonable or not.
> Jovian or Jupiter masses, radii etc. per the VOUnit standard are not ?known? units either,
> but simply ?unrecognised units? that a parser is expected to accept.
> So transforming everything that the VOTable format would permit to FITS is a challenging task.
> For FITS, the measure of things is the official standard accepted and published by the IAU, and
> the principal philosophy of astropy?s fits module is to be forgiving on input, but strict with output: https://docs.astropy.org/en/latest/io/fits/usage/verification.html#verification
> Further down it also states that any of these verification rules can be changed to the ?warn? or ?silent?
> level if explicitly requested, but that admittedly does not make life much easier, since none of these
> options are accepted by the convenience functions for directly creating HDUs from tables.
> As long as one has identifiable units, the easier solution will probably still be converting to a
> standard-conforming unit as suggested in my first reply:
>
> > tab[col] = tab[col].to(tab[col].unit.to_system(u.si)[0].bases[0])
>
> Again, admittedly fairly awkward syntax (unless someone can suggest a more straightforward way
> to code this), but least you don?t need to treat every unit individually. Though you might of course
> prefer ?Mjup? to ?kg? in your example?
> And it would certainly be nice to have an option for making `table_to_hdu` take care of this automatically.
>
> > astropy should simply send a warning, saying that the FITS file created doesn't conform to the nominal FITS standard, but who cares, as long as the data has been stored.
> >
> > The problem Doug mentioned has to do with strings:  note that above I used a FIELD with the following syntax
> >
> >       <FIELD ID="astring" arraysize="16" datatype="char" name="astring" ucd="meta.id;src" unit="">
> >
> > Had I used the IVOA standard syntax
> >
> >       <FIELD ID="astring" arraysize="*" datatype="char" name="astring" ucd="meta.id;src" unit="">
> >
> > (i.e. strings of varying length), I would have gotten the problem with string objects mentioned by Doug.  The astropy implementation doesn't implement the standard IVOA syntax in a fashion that leads to a correct translation into FITS.
> >
> The astropy implementation should implement the standard in a way that is correctly reading VOTable files
> into functional astropy Tables. Translation into FITS format is quite a different thing, especially with the two
> following somewhat distinct standards. Acceptance of physical and nonphysical units is one example you?ve
> pointed out; variable-length or -width table entries another that I think is very hard to accommodate in FITS.
>
> > Yet another reason (other than the total lack of metadata storage) to work over the votable implementation.  A great task for a younger and better programmer than me....
>
> If you could file an issue on GitHub with the specific problems arising with your data, that would certainly
> help keeping it on the radar. Having someone able to devote a substantial part of their workforce to that
> task would of course help as well, but at least for the FITS side some familiarity with the over two decades
> of development history of PyFITS and astropy io.fits combined could probably also come in handy. ;-)
>
> Cheers,
>                                         Derek
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy



-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
N.P.M. Kuin   (n.kuin at ucl.ac.uk) -- phone +44-(0)1483 (prefix) -204111
(work) --  mobile +44(0)7908715953 --  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.

From npkuin at gmail.com  Fri May  1 03:58:37 2020
From: npkuin at gmail.com (Paul Kuin)
Date: Fri, 1 May 2020 08:58:37 +0100
Subject: [AstroPy] VOTable problems
In-Reply-To: <28E4842B-5C1A-4C75-87A1-759154E54D15@astro.physik.uni-goettingen.de>
References: <mailman.1456.1588173843.24659.astropy@python.org>
 <29869684-3272-4038-A85A-FE6FC14D34E2@astro.physik.uni-goettingen.de>
 <28E4842B-5C1A-4C75-87A1-759154E54D15@astro.physik.uni-goettingen.de>
Message-ID: <CANoQ6N245XOe5xgNy3Ymroma7ok4V9MkDj1eopYZaS734_okiA@mail.gmail.com>

Dear Derek,

see below : fits does allow

On Thu, Apr 30, 2020 at 8:04 PM Derek Homeier
<derek at astro.physik.uni-goettingen.de> wrote:
>
> Hi Rick,
> >
> > astropy.units.core.UnitScaleError: The column 'mass' could not be stored in FITS format because it has a scale '(1.0)' that is not recognized by the FITS standard. Either scale the data or change the units.
> >
> > If one deletes the unit of the "mass" column, everything is ok.  If one uses a FITS-compatible unit like "solMass", everything is ok.  Thus, the problem is that the astropy implementation of converting a votable input into a FITS output won't accept non-FITS units.  The IVOA standard allows one to use any reasonable units and suggests that one follow the style of the FITS standard, but "jovMass" (Jovian masses, in the same syntax as "solMass" = Solar masses) isn't a FITS standard.  Generally, the IVOA standard should be the measure of things.  There are lots of tables that don't want to have to use wierd units like the FITS-acceptable "solMass/1047" or "1.8982e27*solMass?.
> >
> the IVOA standard actually allows the user to invent any kind of units, reasonable or not.
> Jovian or Jupiter masses, radii etc. per the VOUnit standard are not ?known? units either,
> but simply ?unrecognised units? that a parser is expected to accept.
> So transforming everything that the VOTable format would permit to FITS is a challenging task.
> For FITS, the measure of things is the official standard accepted and published by the IAU, and
> the principal philosophy of astropy?s fits module is to be forgiving on input, but strict with output: https://docs.astropy.org/en/latest/io/fits/usage/verification.html#verification
> Further down it also states that any of these verification rules can be changed to the ?warn? or ?silent?
> level if explicitly requested, but that admittedly does not make life much easier, since none of these
> options are accepted by the convenience functions for directly creating HDUs from tables.
> As long as one has identifiable units, the easier solution will probably still be converting to a
> standard-conforming unit as suggested in my first reply:
>
> > tab[col] = tab[col].to(tab[col].unit.to_system(u.si)[0].bases[0])
>
> Again, admittedly fairly awkward syntax (unless someone can suggest a more straightforward way
> to code this), but least you don?t need to treat every unit individually. Though you might of course
> prefer ?Mjup? to ?kg? in your example?
> And it would certainly be nice to have an option for making `table_to_hdu` take care of this automatically.
>
> > astropy should simply send a warning, saying that the FITS file created doesn't conform to the nominal FITS standard, but who cares, as long as the data has been stored.
> >
> > The problem Doug mentioned has to do with strings:  note that above I used a FIELD with the following syntax
> >
> >       <FIELD ID="astring" arraysize="16" datatype="char" name="astring" ucd="meta.id;src" unit="">
> >
> > Had I used the IVOA standard syntax
> >
> >       <FIELD ID="astring" arraysize="*" datatype="char" name="astring" ucd="meta.id;src" unit="">
> >
> > (i.e. strings of varying length), I would have gotten the problem with string objects mentioned by Doug.  The astropy implementation doesn't implement the standard IVOA syntax in a fashion that leads to a correct translation into FITS.
> >
> The astropy implementation should implement the standard in a way that is correctly reading VOTable files
> into functional astropy Tables. Translation into FITS format is quite a different thing, especially with the two
> following somewhat distinct standards. Acceptance of physical and nonphysical units is one example you?ve
> pointed out; variable-length or -width table entries another that I think is very hard to accommodate in FITS.
>

I think that when we developed the FITS standard, we did not restrict
it to use only certain units. In fact, there were at the time at least
two different sets of units recommended, one by HEASARC, one by the
CDS. So FITS is 'flexible' on that. That is my understanding.  Astropy
seems to need more constraints, but the one with writing the units is
clearly not needed. The FITS standard v4.0 is clear on this: using IAU
units is a recommendation, the wording uses "should" not "must".

Variable length tables are more different to use, but section 2.7 of
the FITS standard V4.0 specified that it can be done in the binary
table environment.

Cheers,

   Paul

-- 

* * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * *
N.P.M. Kuin   (n.kuin at ucl.ac.uk) -- phone +44-(0)1483 (prefix) -204111
(work) --  mobile +44(0)7908715953 --  skype ID: npkuin
Mullard Space Science Laboratory  ? University College London  ?
Holmbury St Mary ? Dorking ? Surrey RH5 6NT?  U.K.

From Paolo.Tanga at oca.eu  Fri May  1 04:01:56 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Fri, 1 May 2020 10:01:56 +0200
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
Message-ID: <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/95540ed6/attachment-0001.html>

From Paolo.Tanga at oca.eu  Fri May  1 04:13:59 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Fri, 1 May 2020 10:13:59 +0200
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
Message-ID: <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>

Hi Michael - and the list

I noticed this:

On 29/04/2020 17:47, Michael Brewer wrote:
>
> Issue #3: This is a fairly minor quibble, but the functions atciqz() 
> and aticq() are calculating the gravitational light deflection from 
> the Sun incorrectly. The third argument of erfa.ld() should be the 
> time delayed heliocentric position vector of the target body. I do 
> realize that SOFA has this problem also. 

I suspect (hope) this has really a very minor impact (micro-as level?).

But there is another concern here. As far as I can understand from the 
source code of the functions that you mention (and the function they 
call) the gravitational light bending is ALWAYS computed for a source 
assumed to be "far" (=a star). This means that for a Solar System object 
(asteroid for intance) the result is wrong. It is easy to understand the 
physics: for a light beam that travels for a shorter distance in the 
gravity field of the Sun, bending is smaller.

For typical Main Belt asteroids, the difference is of the order of 50% 
of the stellar light bending in the same direction (a few mas), of 
course larger at small Solar elongations.

So, my questions are:

- Can you confirm that astropy does not use a "planetary" version of the 
light bending, but only its "stellar" version ?

- Would it be possible by having this feature corrected?

(I would really like to be a SOFA expert and be able to contribute 
myself...)

Paolo

-- 
---------------------------------------------------------------------
Paolo Tanga                              Astronomer
Deputy director of Laboratoire Langrange / UMR 7293
Observatoire de la C?te d'Azur           Tel  +33(0)492003042
Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
                                          https://twitter.com/ziggypao


From s.littlefair at sheffield.ac.uk  Fri May  1 05:00:35 2020
From: s.littlefair at sheffield.ac.uk (Stuart P Littlefair)
Date: Fri, 1 May 2020 10:00:35 +0100
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
 <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>
Message-ID: <CAOrDc--nG2g9=7inVTYKcoEdgvT2qvKtW8+gy+s4UeJUf_bv3w@mail.gmail.com>

Hi Paolo,

Your suspicion is correct; the light deflection from the Sun is calculated
assuming a distant source.

Fixing this is not trivial, from a quick look. It might be easy enough to
turn light deflection off for nearby bodies, but anything more
sophisticated than that will probably require a better model of light
deflection than is implemented in SOFA/ERFA.

Stuart

On Fri, 1 May 2020 at 09:14, Paolo Tanga <Paolo.Tanga at oca.eu> wrote:

> Hi Michael - and the list
>
> I noticed this:
>
> On 29/04/2020 17:47, Michael Brewer wrote:
> >
> > Issue #3: This is a fairly minor quibble, but the functions atciqz()
> > and aticq() are calculating the gravitational light deflection from
> > the Sun incorrectly. The third argument of erfa.ld() should be the
> > time delayed heliocentric position vector of the target body. I do
> > realize that SOFA has this problem also.
>
> I suspect (hope) this has really a very minor impact (micro-as level?).
>
> But there is another concern here. As far as I can understand from the
> source code of the functions that you mention (and the function they
> call) the gravitational light bending is ALWAYS computed for a source
> assumed to be "far" (=a star). This means that for a Solar System object
> (asteroid for intance) the result is wrong. It is easy to understand the
> physics: for a light beam that travels for a shorter distance in the
> gravity field of the Sun, bending is smaller.
>
> For typical Main Belt asteroids, the difference is of the order of 50%
> of the stellar light bending in the same direction (a few mas), of
> course larger at small Solar elongations.
>
> So, my questions are:
>
> - Can you confirm that astropy does not use a "planetary" version of the
> light bending, but only its "stellar" version ?
>
> - Would it be possible by having this feature corrected?
>
> (I would really like to be a SOFA expert and be able to contribute
> myself...)
>
> Paolo
>
> --
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
>                                           https://twitter.com/ziggypao
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Stuart Littlefair

-------------------------------------------------------

*I don't expect you to respond to my email outside your working hours. *

*At the University of Sheffield we value and encourage flexible working
patterns, so please be assured that I respect your working pattern and I am
looking forward to your response when you are next working. *

-------------------------------------------------------

Dept. of Physics & Astronomy,
Univ. of Sheffield, Sheffield, S3 7RH.

email: S.Littlefair at sheffield.ac.uk
phone: +44 114 2224525
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/04bf0a3a/attachment.html>

From Paolo.Tanga at oca.eu  Fri May  1 06:01:06 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Fri, 1 May 2020 12:01:06 +0200
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <CAOrDc--nG2g9=7inVTYKcoEdgvT2qvKtW8+gy+s4UeJUf_bv3w@mail.gmail.com>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
 <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>
 <CAOrDc--nG2g9=7inVTYKcoEdgvT2qvKtW8+gy+s4UeJUf_bv3w@mail.gmail.com>
Message-ID: <088dacac-301e-be53-d9d6-2ca442e1c364@oca.eu>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/13548cc0/attachment-0001.html>

From s.littlefair at sheffield.ac.uk  Fri May  1 06:07:16 2020
From: s.littlefair at sheffield.ac.uk (Stuart P Littlefair)
Date: Fri, 1 May 2020 11:07:16 +0100
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <088dacac-301e-be53-d9d6-2ca442e1c364@oca.eu>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
 <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>
 <CAOrDc--nG2g9=7inVTYKcoEdgvT2qvKtW8+gy+s4UeJUf_bv3w@mail.gmail.com>
 <088dacac-301e-be53-d9d6-2ca442e1c364@oca.eu>
Message-ID: <CAOrDc-9CbKC_weA_jF+fAKkNL-NNL3fuF76r9kOriW39X-_rrg@mail.gmail.com>

Please do!

If it is at all possible to provide some test data that would allow us to
check the implementation is correct along with the issue that would be
fantastic - although I appreciate this may depend upon implementation of
frames that do not currently exist in astropy.

Stuart

On Fri, 1 May 2020 at 11:01, Paolo Tanga <Paolo.Tanga at oca.eu> wrote:

> Hi Stuart
>
> I investigated a little further, and it turns out that SOFA already
> include that option! Provided that the iauLd function is exploited. Here is
> the description from the SOFA document:
>
> The function iauLd is quite general. The algorithm is based on Eq. (70)
> in Klioner (2003) and Eq. (7.63) in Urban & Seidelmann (2013), with some
> rearrangement to minimize the impact of machine precision. Its arguments
> include (among other things) the mass of the body and full details of the
> geometrical arrangement. The latter means the function is valid for
> solar-system targets as well as distant objects, which is not strictly true
> for either iauLdsun or iauLdn.
>
> So this implies that if one uses iauLd everywhere (with a possibility to
> fall back to iauLdsun or iauLdn for distant sources) the consistency is
> ensured!
>
> Should I rise an issue on this - maybe somebody is able to fix?
>
> Paolo
> On 01/05/2020 11:00, Stuart P Littlefair wrote:
>
> Hi Paolo,
>
> Your suspicion is correct; the light deflection from the Sun is calculated
> assuming a distant source.
>
> Fixing this is not trivial, from a quick look. It might be easy enough to
> turn light deflection off for nearby bodies, but anything more
> sophisticated than that will probably require a better model of light
> deflection than is implemented in SOFA/ERFA.
>
> Stuart
>
> On Fri, 1 May 2020 at 09:14, Paolo Tanga <Paolo.Tanga at oca.eu> wrote:
>
>> Hi Michael - and the list
>>
>> I noticed this:
>>
>> On 29/04/2020 17:47, Michael Brewer wrote:
>> >
>> > Issue #3: This is a fairly minor quibble, but the functions atciqz()
>> > and aticq() are calculating the gravitational light deflection from
>> > the Sun incorrectly. The third argument of erfa.ld() should be the
>> > time delayed heliocentric position vector of the target body. I do
>> > realize that SOFA has this problem also.
>>
>> I suspect (hope) this has really a very minor impact (micro-as level?).
>>
>> But there is another concern here. As far as I can understand from the
>> source code of the functions that you mention (and the function they
>> call) the gravitational light bending is ALWAYS computed for a source
>> assumed to be "far" (=a star). This means that for a Solar System object
>> (asteroid for intance) the result is wrong. It is easy to understand the
>> physics: for a light beam that travels for a shorter distance in the
>> gravity field of the Sun, bending is smaller.
>>
>> For typical Main Belt asteroids, the difference is of the order of 50%
>> of the stellar light bending in the same direction (a few mas), of
>> course larger at small Solar elongations.
>>
>> So, my questions are:
>>
>> - Can you confirm that astropy does not use a "planetary" version of the
>> light bending, but only its "stellar" version ?
>>
>> - Would it be possible by having this feature corrected?
>>
>> (I would really like to be a SOFA expert and be able to contribute
>> myself...)
>>
>> Paolo
>>
>> --
>> ---------------------------------------------------------------------
>> Paolo Tanga                              Astronomer
>> Deputy director of Laboratoire Langrange / UMR 7293
>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>> 06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
>>                                           https://twitter.com/ziggypao
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>>
>
>
> --
> Stuart Littlefair
>
> -------------------------------------------------------
>
> *I don't expect you to respond to my email outside your working hours. *
>
> *At the University of Sheffield we value and encourage flexible working
> patterns, so please be assured that I respect your working pattern and I am
> looking forward to your response when you are next working. *
>
> -------------------------------------------------------
>
> Dept. of Physics & Astronomy,
> Univ. of Sheffield, Sheffield, S3 7RH.
>
> email: S.Littlefair at sheffield.ac.uk
> phone: +44 114 2224525
>
> --
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
>                                          https://twitter.com/ziggypao
>
>

-- 
Stuart Littlefair

-------------------------------------------------------

*I don't expect you to respond to my email outside your working hours. *

*At the University of Sheffield we value and encourage flexible working
patterns, so please be assured that I respect your working pattern and I am
looking forward to your response when you are next working. *

-------------------------------------------------------

Dept. of Physics & Astronomy,
Univ. of Sheffield, Sheffield, S3 7RH.

email: S.Littlefair at sheffield.ac.uk
phone: +44 114 2224525
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/1ea4b617/attachment.html>

From Paolo.Tanga at oca.eu  Fri May  1 06:14:26 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Fri, 1 May 2020 12:14:26 +0200
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <CAOrDc-9CbKC_weA_jF+fAKkNL-NNL3fuF76r9kOriW39X-_rrg@mail.gmail.com>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
 <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>
 <CAOrDc--nG2g9=7inVTYKcoEdgvT2qvKtW8+gy+s4UeJUf_bv3w@mail.gmail.com>
 <088dacac-301e-be53-d9d6-2ca442e1c364@oca.eu>
 <CAOrDc-9CbKC_weA_jF+fAKkNL-NNL3fuF76r9kOriW39X-_rrg@mail.gmail.com>
Message-ID: <db6c6a47-639d-018a-e91f-f13825c05ebf@oca.eu>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/f8121ea7/attachment-0001.html>

From derek at astro.physik.uni-goettingen.de  Fri May  1 09:50:19 2020
From: derek at astro.physik.uni-goettingen.de (Derek Homeier)
Date: Fri, 1 May 2020 15:50:19 +0200
Subject: [AstroPy] VOTable problems
In-Reply-To: <CANoQ6N245XOe5xgNy3Ymroma7ok4V9MkDj1eopYZaS734_okiA@mail.gmail.com>
References: <mailman.1456.1588173843.24659.astropy@python.org>
 <29869684-3272-4038-A85A-FE6FC14D34E2@astro.physik.uni-goettingen.de>
 <28E4842B-5C1A-4C75-87A1-759154E54D15@astro.physik.uni-goettingen.de>
 <CANoQ6N245XOe5xgNy3Ymroma7ok4V9MkDj1eopYZaS734_okiA@mail.gmail.com>
Message-ID: <17420D0E-2C9D-4D3C-AA2B-2358BAB20660@astro.physik.uni-goettingen.de>

Dear Paul,

thanks for your comments!

> On 1 May 2020, at 9:58 am, Paul Kuin <npkuin at gmail.com> wrote:
> 
>>> (i.e. strings of varying length), I would have gotten the problem with string objects mentioned by Doug.  The astropy implementation doesn't implement the standard IVOA syntax in a fashion that leads to a correct translation into FITS.
>>> 
>> The astropy implementation should implement the standard in a way that is correctly reading VOTable files
>> into functional astropy Tables. Translation into FITS format is quite a different thing, especially with the two
>> following somewhat distinct standards. Acceptance of physical and nonphysical units is one example you?ve
>> pointed out; variable-length or -width table entries another that I think is very hard to accommodate in FITS.
>> 
> 
> I think that when we developed the FITS standard, we did not restrict
> it to use only certain units. In fact, there were at the time at least
> two different sets of units recommended, one by HEASARC, one by the
> CDS. So FITS is 'flexible' on that. That is my understanding.  Astropy
> seems to need more constraints, but the one with writing the units is
> clearly not needed. The FITS standard v4.0 is clear on this: using IAU
> units is a recommendation, the wording uses "should" not "must?.
> 
The ?should? actually refers to the even smaller subset of IAU-recommended units
(i.e. SI and derived units from Table 3 of the standard), but indeed my memory was
wrong in that it nowhere states that units ?shall? only be taken from the larger set of
accepted units in Tables 3+4. However Table 4 is captioned ?Additional allowed units?,
which could be read to imply that any other units are not ?allowed?.
I cannot speak for Astropy?s ?io.fits? developer team, but my understanding is that
they want to make files written with the software as standard-compliant as possible,
while allowing to read anything that can be sensibly interpreted - again, following the
philosophy of being ?tolerant with input and strict with output?. And they offer the option
to override the `verify()` defaults to allow writing any other units. But again, this is only
possible in the low-level HDU writing functions, so when working with table objects,
it is almost as good as non-existent. I?d agree it is a reasonable request to propagate
this option to the `Table.write` interface.

> Variable length tables are more different to use, but section 2.7 of
> the FITS standard V4.0 specified that it can be done in the binary
> table environment.

Yes, this is supported by astropy, although I don?t have much practical experience with
those. But in the present case the problem was the variable-width string columns given by
<FIELD ID="astring" arraysize=?*"
and for this there is, to my knowledge, no direct equivalent in the numpy data model
astropy table data are based on. Having anything that cannot be represented as one of
the standard numpy dtype arrays stored as an `object` array instead was a design choice
which I think has its benefits and disadvantages, but the conversion itself as suggested in
Doug Burke?s and my earlier posts - 

tab[col] = [str(n) for n in tab[col]]
or
tab[col] = tab[col].astype('str?)

is straightforward enough for anything that can be converted to ?str? or ?bytes?; but again
this could certainly be made more convenient for the user.

Cheers,
					Derek


From brewer at astro.umass.edu  Fri May  1 10:50:43 2020
From: brewer at astro.umass.edu (Michael Brewer)
Date: Fri, 1 May 2020 10:50:43 -0400
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <db6c6a47-639d-018a-e91f-f13825c05ebf@oca.eu>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
 <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>
 <CAOrDc--nG2g9=7inVTYKcoEdgvT2qvKtW8+gy+s4UeJUf_bv3w@mail.gmail.com>
 <088dacac-301e-be53-d9d6-2ca442e1c364@oca.eu>
 <CAOrDc-9CbKC_weA_jF+fAKkNL-NNL3fuF76r9kOriW39X-_rrg@mail.gmail.com>
 <db6c6a47-639d-018a-e91f-f13825c05ebf@oca.eu>
Message-ID: <1ebb6365-22a4-6cda-1736-c61c2b41a668@astro.umass.edu>

Paolo and Stuart,

void iauLd(double bm, double p[3], double q[3], double e[3],
            double em, double dlim, double p1[3])
**  Given:
**     bm     double     mass of the gravitating body (solar masses)
**     p      double[3]  direction from observer to source (unit vector)
**     q      double[3]  direction from body to source (unit vector)
**     e      double[3]  direction from body to observer (unit vector)
**     em     double     distance from body to observer (au)
**     dlim   double     deflection limiter (Note 4)

    The main issue here is that the functions atciqz() and aticq() that 
call ld() are treating the arguments p and q as identical (q = p). This 
is true for a source at infinity, but not for a source within the solar 
system. In that case, the argument q should be the appropriately light 
delayed position vector of the source as seen from the center of the Sun.

    Regards,

      Michael Brewer

On 05/01/2020 06:14 AM, Paolo Tanga wrote:
>
> Stuart
>
> ok thanks! I will do, and try to figure out a test for this case
>
> Paolo
>
> On 01/05/2020 12:07, Stuart P Littlefair wrote:
>> Please do!
>>
>> If it is at all possible to provide some test data that would allow 
>> us to check the implementation is correct along with the issue that 
>> would be fantastic - although I appreciate this may depend upon 
>> implementation of frames that do not currently exist in astropy.
>>
>> Stuart
>>
>> On Fri, 1 May 2020 at 11:01, Paolo Tanga <Paolo.Tanga at oca.eu 
>> <mailto:Paolo.Tanga at oca.eu>> wrote:
>>
>>     Hi Stuart
>>
>>     I investigated a little further, and it turns out that SOFA
>>     already include that option! Provided that the iauLd function is
>>     exploited. Here is the description from the SOFA document:
>>
>>>     The function iauLd is quite general. The algorithm is based on
>>>     Eq. (70) in Klioner (2003) and Eq. (7.63) in Urban & Seidelmann
>>>     (2013), with some rearrangement to minimize the impact of
>>>     machine precision. Its arguments include (among other things)
>>>     the mass of the body and full details of the geometrical
>>>     arrangement. The latter means the function is valid for
>>>     solar-system targets as well as distant objects, which is not
>>>     strictly true for either iauLdsun or iauLdn.
>>>
>>     So this implies that if one uses iauLd everywhere (with a
>>     possibility to fall back to iauLdsun or iauLdn for distant
>>     sources) the consistency is ensured!
>>
>>     Should I rise an issue on this - maybe somebody is able to fix?
>>
>>     Paolo
>>
>>     On 01/05/2020 11:00, Stuart P Littlefair wrote:
>>>     Hi Paolo,
>>>
>>>     Your suspicion is correct; the light deflection from the Sun is
>>>     calculated assuming a distant source.
>>>
>>>     Fixing this is not trivial, from a quick look. It might be easy
>>>     enough to turn light deflection off for nearby bodies, but
>>>     anything more sophisticated than that will probably require a
>>>     better model of light deflection than is implemented in SOFA/ERFA.
>>>
>>>     Stuart
>>>
>>>     On Fri, 1 May 2020 at 09:14, Paolo Tanga <Paolo.Tanga at oca.eu
>>>     <mailto:Paolo.Tanga at oca.eu>> wrote:
>>>
>>>         Hi Michael - and the list
>>>
>>>         I noticed this:
>>>
>>>         On 29/04/2020 17:47, Michael Brewer wrote:
>>>         >
>>>         > Issue #3: This is a fairly minor quibble, but the
>>>         functions atciqz()
>>>         > and aticq() are calculating the gravitational light
>>>         deflection from
>>>         > the Sun incorrectly. The third argument of erfa.ld()
>>>         should be the
>>>         > time delayed heliocentric position vector of the target
>>>         body. I do
>>>         > realize that SOFA has this problem also.
>>>
>>>         I suspect (hope) this has really a very minor impact
>>>         (micro-as level?).
>>>
>>>         But there is another concern here. As far as I can
>>>         understand from the
>>>         source code of the functions that you mention (and the
>>>         function they
>>>         call) the gravitational light bending is ALWAYS computed for
>>>         a source
>>>         assumed to be "far" (=a star). This means that for a Solar
>>>         System object
>>>         (asteroid for intance) the result is wrong. It is easy to
>>>         understand the
>>>         physics: for a light beam that travels for a shorter
>>>         distance in the
>>>         gravity field of the Sun, bending is smaller.
>>>
>>>         For typical Main Belt asteroids, the difference is of the
>>>         order of 50%
>>>         of the stellar light bending in the same direction (a few
>>>         mas), of
>>>         course larger at small Solar elongations.
>>>
>>>         So, my questions are:
>>>
>>>         - Can you confirm that astropy does not use a "planetary"
>>>         version of the
>>>         light bending, but only its "stellar" version ?
>>>
>>>         - Would it be possible by having this feature corrected?
>>>
>>>         (I would really like to be a SOFA expert and be able to
>>>         contribute
>>>         myself...)
>>>
>>>         Paolo
>>>
>>>         -- 
>>>         ---------------------------------------------------------------------
>>>         Paolo Tanga                              Astronomer
>>>         Deputy director of Laboratoire Langrange / UMR 7293
>>>         Observatoire de la C?te d'Azur           Tel +33(0)492003042
>>>         Bv de l'Observatoire - CS 34229          Fax +33(0)492003121
>>>         06304 Nice Cedex 4 - France http://www.oca.eu/tanga
>>>         https://twitter.com/ziggypao
>>>
>>>         _______________________________________________
>>>         AstroPy mailing list
>>>         AstroPy at python.org <mailto:AstroPy at python.org>
>>>         https://mail.python.org/mailman/listinfo/astropy
>>>
>>>
>>>
>>>     -- 
>>>     Stuart Littlefair
>>>
>>>     -------------------------------------------------------
>>>
>>>     */I don't expect you to respond to my email outside your working
>>>     hours. /*
>>>     /
>>>     /
>>>     /At the University of Sheffield we value and encourage flexible
>>>     working patterns, so please be assured that I respect your
>>>     working pattern and I am looking forward to your response when
>>>     you are next working. /
>>>     /
>>>     /
>>>     -------------------------------------------------------
>>>
>>>     Dept. of Physics & Astronomy,
>>>     Univ. of Sheffield, Sheffield, S3 7RH.
>>>
>>>     email: S.Littlefair at sheffield.ac.uk
>>>     <mailto:S.Littlefair at sheffield.ac.uk>
>>>     phone: +44 114 2224525
>>
>>     -- 
>>     ---------------------------------------------------------------------
>>     Paolo Tanga                              Astronomer
>>     Deputy director of Laboratoire Langrange / UMR 7293
>>     Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>     Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>     06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>                                               https://twitter.com/ziggypao
>>
>>
>>
>> -- 
>> Stuart Littlefair
>>
>> -------------------------------------------------------
>>
>> */I don't expect you to respond to my email outside your working 
>> hours. /*
>> /
>> /
>> /At the University of Sheffield we value and encourage flexible 
>> working patterns, so please be assured that I respect your working 
>> pattern and I am looking forward to your response when you are next 
>> working. /
>> /
>> /
>> -------------------------------------------------------
>>
>> Dept. of Physics & Astronomy,
>> Univ. of Sheffield, Sheffield, S3 7RH.
>>
>> email: S.Littlefair at sheffield.ac.uk 
>> <mailto:S.Littlefair at sheffield.ac.uk>
>> phone: +44 114 2224525
> -- 
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>                                           https://twitter.com/ziggypao
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/2d2b75bb/attachment-0001.html>

From s.littlefair at sheffield.ac.uk  Fri May  1 11:27:35 2020
From: s.littlefair at sheffield.ac.uk (Stuart P Littlefair)
Date: Fri, 1 May 2020 16:27:35 +0100
Subject: [AstroPy] Problems with solar system ephemerides
In-Reply-To: <1ebb6365-22a4-6cda-1736-c61c2b41a668@astro.umass.edu>
References: <92f5421d-d660-fd06-3a9b-54b127a46337.ref@astro.umass.edu>
 <92f5421d-d660-fd06-3a9b-54b127a46337@astro.umass.edu>
 <3de5d9ee-e0df-7aec-ef0d-391838c98545@oca.eu>
 <CAOrDc--nG2g9=7inVTYKcoEdgvT2qvKtW8+gy+s4UeJUf_bv3w@mail.gmail.com>
 <088dacac-301e-be53-d9d6-2ca442e1c364@oca.eu>
 <CAOrDc-9CbKC_weA_jF+fAKkNL-NNL3fuF76r9kOriW39X-_rrg@mail.gmail.com>
 <db6c6a47-639d-018a-e91f-f13825c05ebf@oca.eu>
 <1ebb6365-22a4-6cda-1736-c61c2b41a668@astro.umass.edu>
Message-ID: <CAOrDc-9i3Q=O8HhpZMRFRyOoMS0Pn+sEKiO_6yQtE3dUxk+2wg@mail.gmail.com>

Agreed - there's also another point of trouble which is that
the transformations strip out the distance before calling aticqz and
aticq so that needs to be changed as well.

We also ignore the objects space motion when calculating these
transformations which affects aberrations etc. When the 4.1 release is over
it is probably time to have a look at all of these issues.

On Fri, 1 May 2020 at 15:51, Michael Brewer <brewer at astro.umass.edu> wrote:

> Paolo and Stuart,
>
> void iauLd(double bm, double p[3], double q[3], double e[3],
>            double em, double dlim, double p1[3])
> **  Given:
> **     bm     double     mass of the gravitating body (solar masses)
> **     p      double[3]  direction from observer to source (unit vector)
> **     q      double[3]  direction from body to source (unit vector)
> **     e      double[3]  direction from body to observer (unit vector)
> **     em     double     distance from body to observer (au)
> **     dlim   double     deflection limiter (Note 4)
>
>    The main issue here is that the functions atciqz() and aticq() that
> call ld() are treating the arguments p and q as identical (q = p). This is
> true for a source at infinity, but not for a source within the solar
> system. In that case, the argument q should be the appropriately light
> delayed position vector of the source as seen from the center of the Sun.
>
>    Regards,
>
>      Michael Brewer
>
> On 05/01/2020 06:14 AM, Paolo Tanga wrote:
>
> Stuart
>
> ok thanks! I will do, and try to figure out a test for this case
>
> Paolo
> On 01/05/2020 12:07, Stuart P Littlefair wrote:
>
> Please do!
>
> If it is at all possible to provide some test data that would allow us to
> check the implementation is correct along with the issue that would be
> fantastic - although I appreciate this may depend upon implementation of
> frames that do not currently exist in astropy.
>
> Stuart
>
> On Fri, 1 May 2020 at 11:01, Paolo Tanga <Paolo.Tanga at oca.eu> wrote:
>
>> Hi Stuart
>>
>> I investigated a little further, and it turns out that SOFA already
>> include that option! Provided that the iauLd function is exploited. Here is
>> the description from the SOFA document:
>>
>> The function iauLd is quite general. The algorithm is based on Eq. (70)
>> in Klioner (2003) and Eq. (7.63) in Urban & Seidelmann (2013), with some
>> rearrangement to minimize the impact of machine precision. Its arguments
>> include (among other things) the mass of the body and full details of the
>> geometrical arrangement. The latter means the function is valid for
>> solar-system targets as well as distant objects, which is not strictly true
>> for either iauLdsun or iauLdn.
>>
>> So this implies that if one uses iauLd everywhere (with a possibility to
>> fall back to iauLdsun or iauLdn for distant sources) the consistency is
>> ensured!
>>
>> Should I rise an issue on this - maybe somebody is able to fix?
>>
>> Paolo
>> On 01/05/2020 11:00, Stuart P Littlefair wrote:
>>
>> Hi Paolo,
>>
>> Your suspicion is correct; the light deflection from the Sun is
>> calculated assuming a distant source.
>>
>> Fixing this is not trivial, from a quick look. It might be easy enough to
>> turn light deflection off for nearby bodies, but anything more
>> sophisticated than that will probably require a better model of light
>> deflection than is implemented in SOFA/ERFA.
>>
>> Stuart
>>
>> On Fri, 1 May 2020 at 09:14, Paolo Tanga <Paolo.Tanga at oca.eu> wrote:
>>
>>> Hi Michael - and the list
>>>
>>> I noticed this:
>>>
>>> On 29/04/2020 17:47, Michael Brewer wrote:
>>> >
>>> > Issue #3: This is a fairly minor quibble, but the functions atciqz()
>>> > and aticq() are calculating the gravitational light deflection from
>>> > the Sun incorrectly. The third argument of erfa.ld() should be the
>>> > time delayed heliocentric position vector of the target body. I do
>>> > realize that SOFA has this problem also.
>>>
>>> I suspect (hope) this has really a very minor impact (micro-as level?).
>>>
>>> But there is another concern here. As far as I can understand from the
>>> source code of the functions that you mention (and the function they
>>> call) the gravitational light bending is ALWAYS computed for a source
>>> assumed to be "far" (=a star). This means that for a Solar System object
>>> (asteroid for intance) the result is wrong. It is easy to understand the
>>> physics: for a light beam that travels for a shorter distance in the
>>> gravity field of the Sun, bending is smaller.
>>>
>>> For typical Main Belt asteroids, the difference is of the order of 50%
>>> of the stellar light bending in the same direction (a few mas), of
>>> course larger at small Solar elongations.
>>>
>>> So, my questions are:
>>>
>>> - Can you confirm that astropy does not use a "planetary" version of the
>>> light bending, but only its "stellar" version ?
>>>
>>> - Would it be possible by having this feature corrected?
>>>
>>> (I would really like to be a SOFA expert and be able to contribute
>>> myself...)
>>>
>>> Paolo
>>>
>>> --
>>> ---------------------------------------------------------------------
>>> Paolo Tanga                              Astronomer
>>> Deputy director of Laboratoire Langrange / UMR 7293
>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>> 06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
>>>                                           https://twitter.com/ziggypao
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org
>>> https://mail.python.org/mailman/listinfo/astropy
>>>
>>
>>
>> --
>> Stuart Littlefair
>>
>> -------------------------------------------------------
>>
>> *I don't expect you to respond to my email outside your working hours. *
>>
>> *At the University of Sheffield we value and encourage flexible working
>> patterns, so please be assured that I respect your working pattern and I am
>> looking forward to your response when you are next working. *
>>
>> -------------------------------------------------------
>>
>> Dept. of Physics & Astronomy,
>> Univ. of Sheffield, Sheffield, S3 7RH.
>>
>> email: S.Littlefair at sheffield.ac.uk
>> phone: +44 114 2224525
>>
>> --
>> ---------------------------------------------------------------------
>> Paolo Tanga                              Astronomer
>> Deputy director of Laboratoire Langrange / UMR 7293
>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>> 06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
>>                                          https://twitter.com/ziggypao
>>
>>
>
> --
> Stuart Littlefair
>
> -------------------------------------------------------
>
> *I don't expect you to respond to my email outside your working hours. *
>
> *At the University of Sheffield we value and encourage flexible working
> patterns, so please be assured that I respect your working pattern and I am
> looking forward to your response when you are next working. *
>
> -------------------------------------------------------
>
> Dept. of Physics & Astronomy,
> Univ. of Sheffield, Sheffield, S3 7RH.
>
> email: S.Littlefair at sheffield.ac.uk
> phone: +44 114 2224525
>
> --
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
>                                          https://twitter.com/ziggypao
>
>
>
> _______________________________________________
> AstroPy mailing listAstroPy at python.orghttps://mail.python.org/mailman/listinfo/astropy
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Stuart Littlefair

-------------------------------------------------------

*I don't expect you to respond to my email outside your working hours. *

*At the University of Sheffield we value and encourage flexible working
patterns, so please be assured that I respect your working pattern and I am
looking forward to your response when you are next working. *

-------------------------------------------------------

Dept. of Physics & Astronomy,
Univ. of Sheffield, Sheffield, S3 7RH.

email: S.Littlefair at sheffield.ac.uk
phone: +44 114 2224525
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/3817d88f/attachment-0001.html>

From brewer at astro.umass.edu  Fri May  1 17:20:36 2020
From: brewer at astro.umass.edu (Michael Brewer)
Date: Fri, 1 May 2020 17:20:36 -0400
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
Message-ID: <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>

Paolo,

I can tell you how to do this. First query JPL Horizons for your target 
body setting the observer location to the Earth's geocenter. This will 
return the astrometric position of the target body in the ICRF frame 
referred to the Earth's geocenter including the proper light time 
offset. Now you want these coordinates as an astropy SkyCoord object in 
astropy's ICRS frame. The problem here is that astropy always refers 
ICRS coordinates to the solar system barycenter. This will require you 
to add the solar system barycentric position of the Earth's geocenter. 
The way to do this is: First create a SkyCoord object using the 
coordinates that you got from your query, call get_body_barycentric() to 
get the Earth's position and then add these two together to get a proper 
astropy SkyCoord object. This looks like this:

from astropy.coordinates.solar_system import get_body_barycentric
my_object_ICRS = SkyCoord( SkyCoord( JPL geocentric astrometric 
coordinates ).cartesian + get_body_barycentric('earth', my_time) )

Now if you want to compare the result with JPL Horizons apparent place, 
you need to realize that JPL's apparent place is referenced to the true 
equator and equinox of date whereas astropy's CIRS frame is referenced 
to the Celestial Intermediate Origin. Fortunately, there is a function 
that converts GCRS coordinates to true apparent place:

from astropy.coordinates.solar_system import 
_apparent_position_in_true_coordinates
my_object_apparent = _apparent_position_in_true_coordinates( 
my_object_ICRS.transform_to('gcrs') )

The result should compare to JPL Horizons to 53 mas in RA. This 53 mas 
is a rather mysterious offset that I pointed out to the JPL Horizons 
people awhile ago. It took me awhile to convince them of this, but I'm 
happy to see that they have now accepted it and are making a note of it 
in their output files. There will be some small residual offsets due to 
the fact that JPL Horizons uses a slightly different set of earth 
orientation parameters than those used by astropy, but these are usually 
less than 1 mas.

I have raised an issue in this regard on github (Issue #10230) 
requesting two new built-in frames for converting to geocentric or 
topocentric astrometric place and true apparent place. If these ever get 
implemented, this process will become a lot easier.

    Best Regards,

     Michael Brewer



On 05/01/2020 04:01 AM, Paolo Tanga wrote:
>
> Hi Eric
>
> thank you for your other comments. Some answers below.y
>
> On 01/05/2020 05:09, Eric Jensen wrote:
>> Like Ben, I?m a little unclear on exactly what you are trying to 
>> achieve beyond what you?ve demonstrated already.  (I have learned 
>> from your example!)  You have shown that Horizons provides 
>> astrometric coordinates that are ICRS, and that these are 
>> straightforward to insert into a SkyCoord object as you show in your 
>> example.
>
> my whole point here is that this works *only* when you query Horizons 
> for astrometric coordinates with an observer at "@0" (= the Solar 
> System barycenter), and this is not explicitly explained in the 
> documentation. My other point is that I am not so expert in all 
> features in astropy, so I wanted to have a confirmation (which 
> essentially I got, I think). Eventually, somebody could be able to 
> define a "custom" frame that works for all output returned by Horizons.
>
>>
>> If for some reason you want to use the apparent coordinates instead, 
>> then you need to put them into a SkyCoord frame that precesses, which 
>> as I understand it is what the PrecessedGeocentric frame is for.  So 
>> with a slight modification of your example, you can do this:
>>
>> (...)Doing this, I get coordinates that differ by about 13 arcsec 
>> (mostly in RA) from the GCRS coords you create in the first part of 
>> your example using the ICRS coords at the barycenter.  I don?t know 
>> what the source of that difference is, but perhaps some of the 
>> various GR corrections.
>
> Thank you for this additional example, but in my view this shows that 
> even in this approach you do not get consistent results. 13 arcsec are 
> a huge discrepancy, not for most amateur use, but for today's 
> standard. In fact, probably the effect is due to annual aberration 
> (most of it) and light bending (a few mas). But what is the interest 
> of including relativistic corrections in astropy, if then you cannot 
> get an agreement at ~mas level, at least? For professional use in the 
> Gaia era, this is a requirement.
>
>> There are indeed subtleties in converting between various coordinates 
>> systems, as you note, but I would say that those subtleties are 
>> inherent to the topic in general, not to the astropy software in 
>> particular.
> True! And the whole topic is complex. But astropy already does a great 
> service to the user, by providing out of the box, accurate 
> transformations with all the bells and whistles. So, providing 
> information on how to use (at full accuracy!) astroquery.horizons (or 
> new reference frames to improve consistency!) I think goes in the same 
> direction. By the way, note that the issues in the other mail thread 
> by Michael Brewer also partially addresses the same problem.
>> That said, examples are quite helpful, so I?d encourage you to submit 
>> an example based on your work here for inclusion on the examples page 
>> at https://docs.astropy.org/en/stable/generated/examples/ .
>
> I will certainly do, including warnings about how NOT to use the 
> Horizons output with SkyCoords... ;-) ...!
>
> Cheers
>
> Paolo
>
>
>>
>>
>>> On Apr 29, 2020, at 11:23 AM, Paolo Tanga <Paolo.Tanga at oca.eu 
>>> <mailto:Paolo.Tanga at oca.eu>> wrote:
>>>
>>> Hi Ben
>>>
>>> thank you for taking your time to look into this question, and sorry 
>>> for the delay.
>>>
>>> I would say, all that I am trying to do is to use the astroquery 
>>> output in a SkyCoord object coherently. If one manages to do that, 
>>> than it is possible to take profit of all the SkyCoord methods of 
>>> course, to manipulate the coordinates (transform_to ) etc.
>>>
>>> As the SkyCoord is a fundamental part of the astropy suite, I would 
>>> expect that there should be a "easy" method (or at least, a 
>>> documented one!) to pass from an astroquery/JPL result to SkyCoord. 
>>> But it turns out that this is not the case.
>>>
>>> So, what we have learned so far, if I am correct, is that:
>>>
>>> - JPL apparent coordinates. Precession - you are totally right - 
>>> creates the difference between GCRS and the JPL apparent 
>>> coordinates. In the documentation I would explicitly write that 
>>> these cannot easily be used in a SkyCoord frame. In fact I tried 
>>> playing with different reference frames (including 
>>> GeocentricTrueEquator etc) but I see the same inconsistencies as 
>>> with GCRS. So, I suppose that if there is a method, it is not 
>>> straightforward (at least, not for me).
>>>
>>> - JPL astrometric coordinates. If computed with the observer at the 
>>> barycenter of the Solar System, they can fit a SkyCoord object in 
>>> ICRS. And this is the only possibility.
>>>
>>> I think that there could be other subtleties to check, but don't you 
>>> think that this should be documented somewhere?
>>>
>>> Note that in the case of the ephemeris of the major planets 
>>> (get_body()...) a SkyCoord object is directly returned, which is 
>>> very convenient.
>>>
>>> Cheers
>>>
>>> Paolo
>>>
>>>
>>> On 25/04/2020 10:43, Benjamin Weiner wrote:
>>>> Hello Paolo,
>>>>
>>>> I am not entirely sure what end result you wish to achieve, nor am 
>>>> I an expert on SkyCoord.  However, I have a suggestion to 
>>>> understand further these discrepancies (and thank you for including 
>>>> the notebook example). In your first example:
>>>> (a) JPL's barycentric coords to build ICRS at specified time, then 
>>>> transformed to GCRS at specified time.
>>>> (b) JPL's apparent coords to build GCRS at specified time.
>>>>
>>>> The separation of 16 arcmin between (a) and (b) is due to the 
>>>> precession of the Earth's axis from 2000 to 2020.  This can be seen 
>>>> if we substitute
>>>>  time = Time('2000-01-01T00:00:00', scale='utc')
>>>> in the line of your notebook that sets the time. At 2000-01-01, the 
>>>> separation reduces to 8 arcseconds, which you have identified as 
>>>> coming from the aberration of starlight.
>>>>
>>>> I think that the discrepancy is in building the GCRS coordinates 
>>>> from the apparent RA/Dec. The JPL apparent coordinates are 
>>>> referenced to the position of the Earth's axis at the specified 
>>>> time. But the axes of GCRS are non-rotating with respect to the 
>>>> axes of BCRS and ICRS - that is, GCRS is fixed to the Earth's 
>>>> center, but not to the Earth's axis, and does not precess.  I 
>>>> believe that this is correct - USNO circular 179 has more gory 
>>>> details on the definition of coordinate frames, see
>>>> https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> On Fri, Apr 24, 2020 at 9:01 AM <astropy-request at python.org 
>>>> <mailto:astropy-request at python.org>> wrote:
>>>>
>>>>
>>>>     Message: 1
>>>>     Date: Fri, 24 Apr 2020 15:00:22 +0200
>>>>     From: Paolo Tanga <Paolo.Tanga at oca.eu <mailto:Paolo.Tanga at oca.eu>>
>>>>     To: AstroPy at python.org <mailto:AstroPy at python.org>
>>>>     Subject: [AstroPy] consistency of reference frames between SkyCoord
>>>>             and JPL Horizons
>>>>     Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu
>>>>     <mailto:b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu>>
>>>>     Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>>
>>>>     Hi all
>>>>
>>>>     I am trying to plug the results by JPL Horizons into the
>>>>     appropriate
>>>>     reference system of a SkyCoord object, but it looks very trick.
>>>>     (bewore
>>>>     long message, I hope the explanation is clear for the
>>>>     specialists of
>>>>     reference systems)
>>>>
>>>>     The Horizons server returns two types of equatorial coordinates:
>>>>     "astrometric" (1) and (2) "apparent".
>>>>
>>>>     Their description is the following:
>>>>
>>>>     - (1): astrometric RA and Dec with respect to the observing site
>>>>     (coordinate origin) in the reference frame of
>>>>     the planetary ephemeris (ICRF). Compensated for down-leg
>>>>     light-time
>>>>     delay aberration.
>>>>
>>>>     - (2): Airless apparent RA and Dec of the target with respect
>>>>     to an
>>>>     instantaneous reference frame defined by the Earth equator of-date
>>>>     (z-axis) and meridian containing the Earth equinox of-date
>>>>     (x-axis,
>>>>     IAU76/80). Compensated for down-leg light-time delay,
>>>>     gravitational
>>>>     deflection of light, stellar aberration, precession & nutation.
>>>>     Note:
>>>>     equinox (RA origin) is offset -53 mas from the of-date frame
>>>>     defined by
>>>>     the IAU06/00a P & N system.
>>>>
>>>>     My guess is none of these two systems correspond to either ICRS
>>>>     or GCRS
>>>>     as defined in astropy. The simplest possibility for me, would
>>>>     have been
>>>>     to assimilate (1), computed for the Solar System barycenter, to
>>>>     ICRS.
>>>>     But definitely (2) is not GCRS and the test below easily proves
>>>>     that.
>>>>
>>>>     Verification (see the attached notebook if you want to play with) :
>>>>
>>>>     - I queried for Solar System barycentric coordinates (1) of an
>>>>     asteroid
>>>>     at one epoch. I inserted them in a SkyCoord object as ICRS and
>>>>     use the
>>>>     transform_to(GCRS) towards geocentric, at the given epoch.
>>>>
>>>>     - I queried again JPL Horizons for the apparent coordinates (2)
>>>>     from the
>>>>     geocenter, directly.
>>>>
>>>>     As expected, by comparing the results I get the patent
>>>>     confirmation that
>>>>     GCRS is not the frame of (2), with a discrepancy of 16 arcmin
>>>>     in my
>>>>     case. SO, IT DOES NOT WORK, AS EXPECTED. Let's put apparent
>>>>     coordinates
>>>>     (2) aside for the moment.
>>>>
>>>>     Second possibility (see notebook again).
>>>>
>>>>     I take coordinates (1), for the geocentric observer. I insert
>>>>     them as
>>>>     GCRS in a SkyCoord object. I trasform_to(ICRS) (barycentric
>>>>     observer)
>>>>     and compare the result to a query of (1) directly for the
>>>>     barycentric
>>>>     observer.
>>>>
>>>>     Again this SHOULD NOT WORK accurately. In fact the definition
>>>>     of (1)
>>>>     does not contain annual aberration and light deflection that
>>>>     are part of
>>>>     GCRS. A difference of several arcsec (mostly due to annual
>>>>     aberration)
>>>>     SHOULD show up. And in fact IT DOES, ~8 arcsec of difference.
>>>>
>>>>     The conclusions if that using SkyCoord with the output of JPL
>>>>     Horizons
>>>>     is far from obvious to the end user...
>>>>
>>>>     ----
>>>>
>>>>     So, my final questions/remarks are:
>>>>
>>>>     - How to get a fully accurate consistency between a SkyCoord
>>>>     frame and
>>>>     JPL Horizons output, in the case of a barycentric, geocentric or
>>>>     topocentric observer, for both "astrometric" and "apparent"
>>>>     coordinates
>>>>     as provided by JPL? Which reference SkyCoord should use and how?
>>>>
>>>>     - Does astropy implement GCRS correctly in the case of Solar
>>>>     System
>>>>     objects, by taking into account aberration and light deflection
>>>>     in the
>>>>     relativistic form, for an object at finite distance (different
>>>>     than for
>>>>     the stars!) ?
>>>>
>>>>     - ...or... Am I missing something fundamental in my interpretation?
>>>>
>>>>     - Eventually, this query to Horizons turns our to be tricky to
>>>>     manage as
>>>>     SkyCoord for the final user. I think it would be useful to
>>>>     provide the
>>>>     correct recipe and/or directly a SkyCoord as output of the query...
>>>>
>>>>     Best regards
>>>>
>>>>     Paolo
>>>>
>>>>
>>>> -- 
>>>> Benjamin Weiner
>>>> Staff Scientist / Associate Astronomer, MMT / Steward Observatory
>>>> bjw at as.arizona.edu <mailto:bjw at as.arizona.edu>
>>>> http://mingus.mmto.arizona.edu/~bjw/ 
>>>> <http://mingus.as.arizona.edu/%7Ebjw/>
>>>>
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at python.org
>>>> https://mail.python.org/mailman/listinfo/astropy
>>> -- 
>>> ---------------------------------------------------------------------
>>> Paolo Tanga                              Astronomer
>>> Deputy director of Laboratoire Langrange / UMR 7293
>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>>                                           https://twitter.com/ziggypao
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org <mailto:AstroPy at python.org>
>>> https://mail.python.org/mailman/listinfo/astropy
>>
> -- 
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>                                           https://twitter.com/ziggypao
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/763bf7e1/attachment-0001.html>

From brewer at astro.umass.edu  Fri May  1 18:09:29 2020
From: brewer at astro.umass.edu (Michael Brewer)
Date: Fri, 1 May 2020 18:09:29 -0400
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
 <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
Message-ID: <4542fe37-4936-406b-a1a3-90b793126c7e@astro.umass.edu>

Oh, I forgot. This accuracy assumes that you are using the same DE430 
ephemeris that JPL Horizon uses.

solar_system_ephemeris.set('de430')


On 05/01/2020 05:20 PM, Michael Brewer wrote:
> Paolo,
>
> I can tell you how to do this. First query JPL Horizons for your 
> target body setting the observer location to the Earth's geocenter. 
> This will return the astrometric position of the target body in the 
> ICRF frame referred to the Earth's geocenter including the proper 
> light time offset. Now you want these coordinates as an astropy 
> SkyCoord object in astropy's ICRS frame. The problem here is that 
> astropy always refers ICRS coordinates to the solar system barycenter. 
> This will require you to add the solar system barycentric position of 
> the Earth's geocenter. The way to do this is: First create a SkyCoord 
> object using the coordinates that you got from your query, call 
> get_body_barycentric() to get the Earth's position and then add these 
> two together to get a proper astropy SkyCoord object. This looks like 
> this:
>
> from astropy.coordinates.solar_system import get_body_barycentric
> my_object_ICRS = SkyCoord( SkyCoord( JPL geocentric astrometric 
> coordinates ).cartesian + get_body_barycentric('earth', my_time) )
>
> Now if you want to compare the result with JPL Horizons apparent 
> place, you need to realize that JPL's apparent place is referenced to 
> the true equator and equinox of date whereas astropy's CIRS frame is 
> referenced to the Celestial Intermediate Origin. Fortunately, there is 
> a function that converts GCRS coordinates to true apparent place:
>
> from astropy.coordinates.solar_system import 
> _apparent_position_in_true_coordinates
> my_object_apparent = _apparent_position_in_true_coordinates( 
> my_object_ICRS.transform_to('gcrs') )
>
> The result should compare to JPL Horizons to 53 mas in RA. This 53 mas 
> is a rather mysterious offset that I pointed out to the JPL Horizons 
> people awhile ago. It took me awhile to convince them of this, but I'm 
> happy to see that they have now accepted it and are making a note of 
> it in their output files. There will be some small residual offsets 
> due to the fact that JPL Horizons uses a slightly different set of 
> earth orientation parameters than those used by astropy, but these are 
> usually less than 1 mas.
>
> I have raised an issue in this regard on github (Issue #10230) 
> requesting two new built-in frames for converting to geocentric or 
> topocentric astrometric place and true apparent place. If these ever 
> get implemented, this process will become a lot easier.
>
>    Best Regards,
>
>     Michael Brewer
>
>
>
> On 05/01/2020 04:01 AM, Paolo Tanga wrote:
>>
>> Hi Eric
>>
>> thank you for your other comments. Some answers below.y
>>
>> On 01/05/2020 05:09, Eric Jensen wrote:
>>> Like Ben, I?m a little unclear on exactly what you are trying to 
>>> achieve beyond what you?ve demonstrated already.  (I have learned 
>>> from your example!)  You have shown that Horizons provides 
>>> astrometric coordinates that are ICRS, and that these are 
>>> straightforward to insert into a SkyCoord object as you show in your 
>>> example.
>>
>> my whole point here is that this works *only* when you query Horizons 
>> for astrometric coordinates with an observer at "@0" (= the Solar 
>> System barycenter), and this is not explicitly explained in the 
>> documentation. My other point is that I am not so expert in all 
>> features in astropy, so I wanted to have a confirmation (which 
>> essentially I got, I think). Eventually, somebody could be able to 
>> define a "custom" frame that works for all output returned by Horizons.
>>
>>>
>>> If for some reason you want to use the apparent coordinates instead, 
>>> then you need to put them into a SkyCoord frame that precesses, 
>>> which as I understand it is what the PrecessedGeocentric frame is 
>>> for.  So with a slight modification of your example, you can do this:
>>>
>>> (...)Doing this, I get coordinates that differ by about 13 arcsec 
>>> (mostly in RA) from the GCRS coords you create in the first part of 
>>> your example using the ICRS coords at the barycenter.  I don?t know 
>>> what the source of that difference is, but perhaps some of the 
>>> various GR corrections.
>>
>> Thank you for this additional example, but in my view this shows that 
>> even in this approach you do not get consistent results. 13 arcsec 
>> are a huge discrepancy, not for most amateur use, but for today's 
>> standard. In fact, probably the effect is due to annual aberration 
>> (most of it) and light bending (a few mas). But what is the interest 
>> of including relativistic corrections in astropy, if then you cannot 
>> get an agreement at ~mas level, at least? For professional use in the 
>> Gaia era, this is a requirement.
>>
>>> There are indeed subtleties in converting between various 
>>> coordinates systems, as you note, but I would say that those 
>>> subtleties are inherent to the topic in general, not to the astropy 
>>> software in particular.
>> True! And the whole topic is complex. But astropy already does a 
>> great service to the user, by providing out of the box, accurate 
>> transformations with all the bells and whistles. So, providing 
>> information on how to use (at full accuracy!) astroquery.horizons (or 
>> new reference frames to improve consistency!) I think goes in the 
>> same direction. By the way, note that the issues in the other mail 
>> thread by Michael Brewer also partially addresses the same problem.
>>> That said, examples are quite helpful, so I?d encourage you to 
>>> submit an example based on your work here for inclusion on the 
>>> examples page at 
>>> https://docs.astropy.org/en/stable/generated/examples/ .
>>
>> I will certainly do, including warnings about how NOT to use the 
>> Horizons output with SkyCoords... ;-) ...!
>>
>> Cheers
>>
>> Paolo
>>
>>
>>>
>>>
>>>> On Apr 29, 2020, at 11:23 AM, Paolo Tanga <Paolo.Tanga at oca.eu 
>>>> <mailto:Paolo.Tanga at oca.eu>> wrote:
>>>>
>>>> Hi Ben
>>>>
>>>> thank you for taking your time to look into this question, and 
>>>> sorry for the delay.
>>>>
>>>> I would say, all that I am trying to do is to use the astroquery 
>>>> output in a SkyCoord object coherently. If one manages to do that, 
>>>> than it is possible to take profit of all the SkyCoord methods of 
>>>> course, to manipulate the coordinates (transform_to ) etc.
>>>>
>>>> As the SkyCoord is a fundamental part of the astropy suite, I would 
>>>> expect that there should be a "easy" method (or at least, a 
>>>> documented one!) to pass from an astroquery/JPL result to SkyCoord. 
>>>> But it turns out that this is not the case.
>>>>
>>>> So, what we have learned so far, if I am correct, is that:
>>>>
>>>> - JPL apparent coordinates. Precession - you are totally right - 
>>>> creates the difference between GCRS and the JPL apparent 
>>>> coordinates. In the documentation I would explicitly write that 
>>>> these cannot easily be used in a SkyCoord frame. In fact I tried 
>>>> playing with different reference frames (including 
>>>> GeocentricTrueEquator etc) but I see the same inconsistencies as 
>>>> with GCRS. So, I suppose that if there is a method, it is not 
>>>> straightforward (at least, not for me).
>>>>
>>>> - JPL astrometric coordinates. If computed with the observer at the 
>>>> barycenter of the Solar System, they can fit a SkyCoord object in 
>>>> ICRS. And this is the only possibility.
>>>>
>>>> I think that there could be other subtleties to check, but don't 
>>>> you think that this should be documented somewhere?
>>>>
>>>> Note that in the case of the ephemeris of the major planets 
>>>> (get_body()...) a SkyCoord object is directly returned, which is 
>>>> very convenient.
>>>>
>>>> Cheers
>>>>
>>>> Paolo
>>>>
>>>>
>>>> On 25/04/2020 10:43, Benjamin Weiner wrote:
>>>>> Hello Paolo,
>>>>>
>>>>> I am not entirely sure what end result you wish to achieve, nor am 
>>>>> I an expert on SkyCoord.  However, I have a suggestion to 
>>>>> understand further these discrepancies (and thank you for 
>>>>> including the notebook example). In your first example:
>>>>> (a) JPL's barycentric coords to build ICRS at specified time, then 
>>>>> transformed to GCRS at specified time.
>>>>> (b) JPL's apparent coords to build GCRS at specified time.
>>>>>
>>>>> The separation of 16 arcmin between (a) and (b) is due to the 
>>>>> precession of the Earth's axis from 2000 to 2020.  This can be 
>>>>> seen if we substitute
>>>>>  time = Time('2000-01-01T00:00:00', scale='utc')
>>>>> in the line of your notebook that sets the time. At 2000-01-01, 
>>>>> the separation reduces to 8 arcseconds, which you have identified 
>>>>> as coming from the aberration of starlight.
>>>>>
>>>>> I think that the discrepancy is in building the GCRS coordinates 
>>>>> from the apparent RA/Dec.  The JPL apparent coordinates are 
>>>>> referenced to the position of the Earth's axis at the specified 
>>>>> time. But the axes of GCRS are non-rotating with respect to the 
>>>>> axes of BCRS and ICRS - that is, GCRS is fixed to the Earth's 
>>>>> center, but not to the Earth's axis, and does not precess.  I 
>>>>> believe that this is correct - USNO circular 179 has more gory 
>>>>> details on the definition of coordinate frames, see
>>>>> https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf
>>>>>
>>>>> Cheers,
>>>>> Ben
>>>>>
>>>>> On Fri, Apr 24, 2020 at 9:01 AM <astropy-request at python.org 
>>>>> <mailto:astropy-request at python.org>> wrote:
>>>>>
>>>>>
>>>>>     Message: 1
>>>>>     Date: Fri, 24 Apr 2020 15:00:22 +0200
>>>>>     From: Paolo Tanga <Paolo.Tanga at oca.eu <mailto:Paolo.Tanga at oca.eu>>
>>>>>     To: AstroPy at python.org <mailto:AstroPy at python.org>
>>>>>     Subject: [AstroPy] consistency of reference frames between
>>>>>     SkyCoord
>>>>>             and JPL Horizons
>>>>>     Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu
>>>>>     <mailto:b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu>>
>>>>>     Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>>>
>>>>>     Hi all
>>>>>
>>>>>     I am trying to plug the results by JPL Horizons into the
>>>>>     appropriate
>>>>>     reference system of a SkyCoord object, but it looks very
>>>>>     trick. (bewore
>>>>>     long message, I hope the explanation is clear for the
>>>>>     specialists of
>>>>>     reference systems)
>>>>>
>>>>>     The Horizons server returns two types of equatorial coordinates:
>>>>>     "astrometric" (1) and (2) "apparent".
>>>>>
>>>>>     Their description is the following:
>>>>>
>>>>>     - (1): astrometric RA and Dec with respect to the observing site
>>>>>     (coordinate origin) in the reference frame of
>>>>>     the planetary ephemeris (ICRF). Compensated for down-leg
>>>>>     light-time
>>>>>     delay aberration.
>>>>>
>>>>>     - (2): Airless apparent RA and Dec of the target with respect
>>>>>     to an
>>>>>     instantaneous reference frame defined by the Earth equator
>>>>>     of-date
>>>>>     (z-axis) and meridian containing the Earth equinox of-date
>>>>>     (x-axis,
>>>>>     IAU76/80). Compensated for down-leg light-time delay,
>>>>>     gravitational
>>>>>     deflection of light, stellar aberration, precession &
>>>>>     nutation. Note:
>>>>>     equinox (RA origin) is offset -53 mas from the of-date frame
>>>>>     defined by
>>>>>     the IAU06/00a P & N system.
>>>>>
>>>>>     My guess is none of these two systems correspond to either
>>>>>     ICRS or GCRS
>>>>>     as defined in astropy. The simplest possibility for me, would
>>>>>     have been
>>>>>     to assimilate (1), computed for the Solar System barycenter,
>>>>>     to ICRS.
>>>>>     But definitely (2) is not GCRS and the test below easily
>>>>>     proves that.
>>>>>
>>>>>     Verification (see the attached notebook if you want to play
>>>>>     with) :
>>>>>
>>>>>     - I queried for Solar System barycentric coordinates (1) of an
>>>>>     asteroid
>>>>>     at one epoch. I inserted them in a SkyCoord object as ICRS and
>>>>>     use the
>>>>>     transform_to(GCRS) towards geocentric, at the given epoch.
>>>>>
>>>>>     - I queried again JPL Horizons for the apparent coordinates
>>>>>     (2) from the
>>>>>     geocenter, directly.
>>>>>
>>>>>     As expected, by comparing the results I get the patent
>>>>>     confirmation that
>>>>>     GCRS is not the frame of (2), with a discrepancy of 16 arcmin
>>>>>     in my
>>>>>     case. SO, IT DOES NOT WORK, AS EXPECTED. Let's put apparent
>>>>>     coordinates
>>>>>     (2) aside for the moment.
>>>>>
>>>>>     Second possibility (see notebook again).
>>>>>
>>>>>     I take coordinates (1), for the geocentric observer. I insert
>>>>>     them as
>>>>>     GCRS in a SkyCoord object. I trasform_to(ICRS) (barycentric
>>>>>     observer)
>>>>>     and compare the result to a query of (1) directly for the
>>>>>     barycentric
>>>>>     observer.
>>>>>
>>>>>     Again this SHOULD NOT WORK accurately. In fact the definition
>>>>>     of (1)
>>>>>     does not contain annual aberration and light deflection that
>>>>>     are part of
>>>>>     GCRS. A difference of several arcsec (mostly due to annual
>>>>>     aberration)
>>>>>     SHOULD show up. And in fact IT DOES, ~8 arcsec of difference.
>>>>>
>>>>>     The conclusions if that using SkyCoord with the output of JPL
>>>>>     Horizons
>>>>>     is far from obvious to the end user...
>>>>>
>>>>>     ----
>>>>>
>>>>>     So, my final questions/remarks are:
>>>>>
>>>>>     - How to get a fully accurate consistency between a SkyCoord
>>>>>     frame and
>>>>>     JPL Horizons output, in the case of a barycentric, geocentric or
>>>>>     topocentric observer, for both "astrometric" and "apparent"
>>>>>     coordinates
>>>>>     as provided by JPL? Which reference SkyCoord should use and how?
>>>>>
>>>>>     - Does astropy implement GCRS correctly in the case of Solar
>>>>>     System
>>>>>     objects, by taking into account aberration and light
>>>>>     deflection in the
>>>>>     relativistic form, for an object at finite distance (different
>>>>>     than for
>>>>>     the stars!) ?
>>>>>
>>>>>     - ...or... Am I missing something fundamental in my
>>>>>     interpretation?
>>>>>
>>>>>     - Eventually, this query to Horizons turns our to be tricky to
>>>>>     manage as
>>>>>     SkyCoord for the final user. I think it would be useful to
>>>>>     provide the
>>>>>     correct recipe and/or directly a SkyCoord as output of the
>>>>>     query...
>>>>>
>>>>>     Best regards
>>>>>
>>>>>     Paolo
>>>>>
>>>>>
>>>>> -- 
>>>>> Benjamin Weiner
>>>>> Staff Scientist / Associate Astronomer, MMT / Steward Observatory
>>>>> bjw at as.arizona.edu <mailto:bjw at as.arizona.edu>
>>>>> http://mingus.mmto.arizona.edu/~bjw/ 
>>>>> <http://mingus.as.arizona.edu/%7Ebjw/>
>>>>>
>>>>> _______________________________________________
>>>>> AstroPy mailing list
>>>>> AstroPy at python.org
>>>>> https://mail.python.org/mailman/listinfo/astropy
>>>> -- 
>>>> ---------------------------------------------------------------------
>>>> Paolo Tanga                              Astronomer
>>>> Deputy director of Laboratoire Langrange / UMR 7293
>>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>>>                                           https://twitter.com/ziggypao
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at python.org <mailto:AstroPy at python.org>
>>>> https://mail.python.org/mailman/listinfo/astropy
>>>
>> -- 
>> ---------------------------------------------------------------------
>> Paolo Tanga                              Astronomer
>> Deputy director of Laboratoire Langrange / UMR 7293
>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>                                           https://twitter.com/ziggypao
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200501/80151e30/attachment-0001.html>

From Paolo.Tanga at oca.eu  Mon May  4 04:18:43 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Mon, 4 May 2020 10:18:43 +0200
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
 <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
Message-ID: <d26ebe77-ebae-ab78-f414-7cd3f730b160@oca.eu>

Hi Michael

thank you for this suggestion, very interesting. I will certainly try 
and make a test! I am currently using 
solar_system_ephemeris.set('de432s')... I suppose it does not make a 
different with respect to de430 but I confess I did not check.

best regards

Paolo


-- 
---------------------------------------------------------------------
Paolo Tanga                              Astronomer
Deputy director of Laboratoire Langrange / UMR 7293
Observatoire de la C?te d'Azur           Tel  +33(0)492003042
Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
06304 Nice Cedex 4 - France              http://www.oca.eu/tanga
                                          https://twitter.com/ziggypao


From Paolo.Tanga at oca.eu  Thu May  7 09:59:17 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Thu, 7 May 2020 15:59:17 +0200
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
 <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
Message-ID: <f663f629-73ba-33d9-6b76-9a45896de097@oca.eu>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200507/6952dc6c/attachment-0001.html>

From brewer at astro.umass.edu  Fri May  8 17:55:42 2020
From: brewer at astro.umass.edu (Michael Brewer)
Date: Fri, 8 May 2020 17:55:42 -0400
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <f663f629-73ba-33d9-6b76-9a45896de097@oca.eu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
 <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
 <f663f629-73ba-33d9-6b76-9a45896de097@oca.eu>
Message-ID: <9c8a6657-3c7f-6593-2043-5f8210b70857@astro.umass.edu>

Hi Paolo,

   I forgot about time.  You need to tell the GCRS frame the time of the 
observation. But you must have figured that out as you got good 
agreement in position, so the error in distance is odd. I tried an 
example with the following script:

from astropy.time import Time
from astropy.coordinates import get_body_barycentric, SkyCoord, GCRS
from astropy.coordinates.solar_system import 
_apparent_position_in_true_coordinates
import astropy.units as u

#Mars Geocentric JPL 2020-May-07 00:00:00     328.364842462 
-14.682567251 328.634953692 -14.587885357 1.18472191315873

my_time        = Time('2020-05-07T00:00:00')
my_astrometric = SkyCoord( 328.364842462*u.deg, -14.682567251*u.deg, 
1.18472191315873*u.au )
my_apparent    = SkyCoord( 328.634953692*u.deg, -14.587885357*u.deg, 
1.18472191315873*u.au )

print ('JPL ICRS', my_astrometric)

my_object_ICRS = SkyCoord( my_astrometric.cartesian + 
get_body_barycentric('earth', my_time) )

print ('ICRS', my_object_ICRS)

my_object_apparent = _apparent_position_in_true_coordinates( 
my_object_ICRS.transform_to(GCRS(obstime=my_time)))

print ('apparent', my_object_apparent)

print ('delta ra', (my_object_apparent.ra - my_apparent.ra).to(u.mas),
        'delta dec', (my_object_apparent.dec - my_apparent.dec).to(u.mas),
        'delta distance', (my_object_apparent.distance - 
my_apparent.distance).to(u.meter) )

And got this result:

JPL ICRS <SkyCoord (ICRS): (ra, dec, distance) in (deg, deg, AU)
     (328.36484246, -14.68256725, 1.18472191)>
ICRS <SkyCoord (ICRS): (ra, dec, distance) in (deg, deg, AU)
     (282.36772087, -24.4176493, 1.42516501)>
apparent <SkyCoord (GCRS: obstime=2020-05-07T00:00:00.000, 
obsgeoloc=(0., 0., 0.) m, obsgeovel=(0., 0., 0.) m / s): (ra, dec, 
distance) in (deg, deg, AU)
     (328.63496745, -14.58788562, 1.18472191)>
delta ra 49.5348mas delta dec -0.964467mas delta distance 
-6.643480019441483e-05 m

The positions are off a bit more than I'd like to see, but the distance 
is right on.

By the way, thanks to an example from Stuart Littlefair, I figured out 
how to do this using topocentric coordinates also. This is just a matter 
of setting up an EarthLocation my_loc and then doing:

earth_loc = get_body_barycentric('earth', my_time)
obsgeoloc, obsgeovel = my_loc.get_gcrs_posvel(my_time)
earth_loc += obsgeoloc

before adding earth_loc to your topocentric astrometric coordinates from 
Horizons and then you also need to tell the GCRS frame your location and 
velocity:

my_object_apparent = _apparent_position_in_true_coordinates( 
my_object_ICRS.transform_to(
                       GCRS(obsgeoloc=obsgeoloc, obsgeovel=obsgeovel, 
obstime=my_time)))


    Regards,

       Michael Brewer


On 05/07/2020 09:59 AM, Paolo Tanga wrote:
>
> Hi Micheal
>
> I did the test following your instructions and I correctly found the 
> result that you indicate: 52.5 mas of discrepancty in RA, and 
> negligible in Dec (0.01 mas).
>
> However, I notice something strange. At the first step:
>
> my_object_ICRS = SkyCoord( SkyCoord( JPL geocentric astrometric 
> coordinates ).cartesian + get_body_barycentric('earth', my_time) )
>
> I give as "JPL geocentric astrometric coordinates" ra, dec and 
> distance. I chose first the geocentric distance (delta, in my case 
> 2.0958388  au).
>
> Then I get
>
> my_object_ICRS.distance = 3.816102 au.
>
> Formally, this may be correct, as this is the result of the addition 
> of barycenter-to-Earth vector. But then, even if I am now in 
> geocentric ICRS, it does not represent the geocentric distance.
>
> At the end of the process, after transformation to GCRS and then to 
> apparent coordinates (by _apparent_position_in_true_coordinates) I find:
>
> my_object_apparent.distance = 2.962877... au, which is off the JPL 
> value for delta given above by ~0.9 au.
>
> If at the beginning I give 'r' (heliocentric distance = 2.95757466, 
> instead of 'delta'), I still get:
>
> my_object_ICRS.distance = 3.810857 but now my_object_apparent.distance
>
> but then:
>
> my_object_apparent.distance =2.957567
>
> which is much closer to the geocentric distance.... So, whatever the 
> choice, it looks like the distance goes completely wrong and there is 
> no way to obtain the correct value directly from the transformations. 
> As ra and dec are correct, the only solution seems to apply a 
> correction to the distance at the end of the computation.
>
> Is this behavior consistent with what you would expect ?
>
> best regards
>
> Paolo
>
>
>
>
> On 01/05/2020 23:20, Michael Brewer wrote:
>> Paolo,
>>
>> I can tell you how to do this. First query JPL Horizons for your 
>> target body setting the observer location to the Earth's geocenter. 
>> This will return the astrometric position of the target body in the 
>> ICRF frame referred to the Earth's geocenter including the proper 
>> light time offset. Now you want these coordinates as an astropy 
>> SkyCoord object in astropy's ICRS frame. The problem here is that 
>> astropy always refers ICRS coordinates to the solar system 
>> barycenter. This will require you to add the solar system barycentric 
>> position of the Earth's geocenter. The way to do this is: First 
>> create a SkyCoord object using the coordinates that you got from your 
>> query, call get_body_barycentric() to get the Earth's position and 
>> then add these two together to get a proper astropy SkyCoord object. 
>> This looks like this:
>>
>> from astropy.coordinates.solar_system import get_body_barycentric
>> my_object_ICRS = SkyCoord( SkyCoord( JPL geocentric astrometric 
>> coordinates ).cartesian + get_body_barycentric('earth', my_time) )
>>
>> Now if you want to compare the result with JPL Horizons apparent 
>> place, you need to realize that JPL's apparent place is referenced to 
>> the true equator and equinox of date whereas astropy's CIRS frame is 
>> referenced to the Celestial Intermediate Origin. Fortunately, there 
>> is a function that converts GCRS coordinates to true apparent place:
>>
>> from astropy.coordinates.solar_system import 
>> _apparent_position_in_true_coordinates
>> my_object_apparent = _apparent_position_in_true_coordinates( 
>> my_object_ICRS.transform_to('gcrs') )
>>
>> The result should compare to JPL Horizons to 53 mas in RA. This 53 
>> mas is a rather mysterious offset that I pointed out to the JPL 
>> Horizons people awhile ago. It took me awhile to convince them of 
>> this, but I'm happy to see that they have now accepted it and are 
>> making a note of it in their output files. There will be some small 
>> residual offsets due to the fact that JPL Horizons uses a slightly 
>> different set of earth orientation parameters than those used by 
>> astropy, but these are usually less than 1 mas.
>>
>> I have raised an issue in this regard on github (Issue #10230) 
>> requesting two new built-in frames for converting to geocentric or 
>> topocentric astrometric place and true apparent place. If these ever 
>> get implemented, this process will become a lot easier.
>>
>>    Best Regards,
>>
>>     Michael Brewer
>>
>>
>>
>> On 05/01/2020 04:01 AM, Paolo Tanga wrote:
>>>
>>> Hi Eric
>>>
>>> thank you for your other comments. Some answers below.y
>>>
>>> On 01/05/2020 05:09, Eric Jensen wrote:
>>>> Like Ben, I?m a little unclear on exactly what you are trying to 
>>>> achieve beyond what you?ve demonstrated already.  (I have learned 
>>>> from your example!)  You have shown that Horizons provides 
>>>> astrometric coordinates that are ICRS, and that these are 
>>>> straightforward to insert into a SkyCoord object as you show in 
>>>> your example.
>>>
>>> my whole point here is that this works *only* when you query 
>>> Horizons for astrometric coordinates with an observer at "@0" (= the 
>>> Solar System barycenter), and this is not explicitly explained in 
>>> the documentation. My other point is that I am not so expert in all 
>>> features in astropy, so I wanted to have a confirmation (which 
>>> essentially I got, I think). Eventually, somebody could be able to 
>>> define a "custom" frame that works for all output returned by Horizons.
>>>
>>>>
>>>> If for some reason you want to use the apparent coordinates 
>>>> instead, then you need to put them into a SkyCoord frame that 
>>>> precesses, which as I understand it is what the PrecessedGeocentric 
>>>> frame is for.  So with a slight modification of your example, you 
>>>> can do this:
>>>>
>>>> (...)Doing this, I get coordinates that differ by about 13 arcsec 
>>>> (mostly in RA) from the GCRS coords you create in the first part of 
>>>> your example using the ICRS coords at the barycenter.  I don?t know 
>>>> what the source of that difference is, but perhaps some of the 
>>>> various GR corrections.
>>>
>>> Thank you for this additional example, but in my view this shows 
>>> that even in this approach you do not get consistent results. 13 
>>> arcsec are a huge discrepancy, not for most amateur use, but for 
>>> today's standard. In fact, probably the effect is due to annual 
>>> aberration (most of it) and light bending (a few mas). But what is 
>>> the interest of including relativistic corrections in astropy, if 
>>> then you cannot get an agreement at ~mas level, at least? For 
>>> professional use in the Gaia era, this is a requirement.
>>>
>>>> There are indeed subtleties in converting between various 
>>>> coordinates systems, as you note, but I would say that those 
>>>> subtleties are inherent to the topic in general, not to the astropy 
>>>> software in particular.
>>> True! And the whole topic is complex. But astropy already does a 
>>> great service to the user, by providing out of the box, accurate 
>>> transformations with all the bells and whistles. So, providing 
>>> information on how to use (at full accuracy!) astroquery.horizons 
>>> (or new reference frames to improve consistency!) I think goes in 
>>> the same direction. By the way, note that the issues in the other 
>>> mail thread by Michael Brewer also partially addresses the same problem.
>>>> That said, examples are quite helpful, so I?d encourage you to 
>>>> submit an example based on your work here for inclusion on the 
>>>> examples page at 
>>>> https://docs.astropy.org/en/stable/generated/examples/ .
>>>
>>> I will certainly do, including warnings about how NOT to use the 
>>> Horizons output with SkyCoords... ;-) ...!
>>>
>>> Cheers
>>>
>>> Paolo
>>>
>>>
>>>>
>>>>
>>>>> On Apr 29, 2020, at 11:23 AM, Paolo Tanga <Paolo.Tanga at oca.eu 
>>>>> <mailto:Paolo.Tanga at oca.eu>> wrote:
>>>>>
>>>>> Hi Ben
>>>>>
>>>>> thank you for taking your time to look into this question, and 
>>>>> sorry for the delay.
>>>>>
>>>>> I would say, all that I am trying to do is to use the astroquery 
>>>>> output in a SkyCoord object coherently. If one manages to do that, 
>>>>> than it is possible to take profit of all the SkyCoord methods of 
>>>>> course, to manipulate the coordinates (transform_to ) etc.
>>>>>
>>>>> As the SkyCoord is a fundamental part of the astropy suite, I 
>>>>> would expect that there should be a "easy" method (or at least, a 
>>>>> documented one!) to pass from an astroquery/JPL result to 
>>>>> SkyCoord. But it turns out that this is not the case.
>>>>>
>>>>> So, what we have learned so far, if I am correct, is that:
>>>>>
>>>>> - JPL apparent coordinates. Precession - you are totally right - 
>>>>> creates the difference between GCRS and the JPL apparent 
>>>>> coordinates. In the documentation I would explicitly write that 
>>>>> these cannot easily be used in a SkyCoord frame. In fact I tried 
>>>>> playing with different reference frames (including 
>>>>> GeocentricTrueEquator etc) but I see the same inconsistencies as 
>>>>> with GCRS. So, I suppose that if there is a method, it is not 
>>>>> straightforward (at least, not for me).
>>>>>
>>>>> - JPL astrometric coordinates. If computed with the observer at 
>>>>> the barycenter of the Solar System, they can fit a SkyCoord object 
>>>>> in ICRS. And this is the only possibility.
>>>>>
>>>>> I think that there could be other subtleties to check, but don't 
>>>>> you think that this should be documented somewhere?
>>>>>
>>>>> Note that in the case of the ephemeris of the major planets 
>>>>> (get_body()...) a SkyCoord object is directly returned, which is 
>>>>> very convenient.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Paolo
>>>>>
>>>>>
>>>>> On 25/04/2020 10:43, Benjamin Weiner wrote:
>>>>>> Hello Paolo,
>>>>>>
>>>>>> I am not entirely sure what end result you wish to achieve, nor 
>>>>>> am I an expert on SkyCoord.  However, I have a suggestion to 
>>>>>> understand further these discrepancies (and thank you for 
>>>>>> including the notebook example). In your first example:
>>>>>> (a) JPL's barycentric coords to build ICRS at specified time, 
>>>>>> then transformed to GCRS at specified time.
>>>>>> (b) JPL's apparent coords to build GCRS at specified time.
>>>>>>
>>>>>> The separation of 16 arcmin between (a) and (b) is due to the 
>>>>>> precession of the Earth's axis from 2000 to 2020.  This can be 
>>>>>> seen if we substitute
>>>>>>  time = Time('2000-01-01T00:00:00', scale='utc')
>>>>>> in the line of your notebook that sets the time. At 2000-01-01, 
>>>>>> the separation reduces to 8 arcseconds, which you have identified 
>>>>>> as coming from the aberration of starlight.
>>>>>>
>>>>>> I think that the discrepancy is in building the GCRS coordinates 
>>>>>> from the apparent RA/Dec.  The JPL apparent coordinates are 
>>>>>> referenced to the position of the Earth's axis at the specified 
>>>>>> time. But the axes of GCRS are non-rotating with respect to the 
>>>>>> axes of BCRS and ICRS - that is, GCRS is fixed to the Earth's 
>>>>>> center, but not to the Earth's axis, and does not precess.  I 
>>>>>> believe that this is correct - USNO circular 179 has more gory 
>>>>>> details on the definition of coordinate frames, see
>>>>>> https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf
>>>>>>
>>>>>> Cheers,
>>>>>> Ben
>>>>>>
>>>>>> On Fri, Apr 24, 2020 at 9:01 AM <astropy-request at python.org 
>>>>>> <mailto:astropy-request at python.org>> wrote:
>>>>>>
>>>>>>
>>>>>>     Message: 1
>>>>>>     Date: Fri, 24 Apr 2020 15:00:22 +0200
>>>>>>     From: Paolo Tanga <Paolo.Tanga at oca.eu
>>>>>>     <mailto:Paolo.Tanga at oca.eu>>
>>>>>>     To: AstroPy at python.org <mailto:AstroPy at python.org>
>>>>>>     Subject: [AstroPy] consistency of reference frames between
>>>>>>     SkyCoord
>>>>>>             and JPL Horizons
>>>>>>     Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu
>>>>>>     <mailto:b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu>>
>>>>>>     Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>>>>
>>>>>>     Hi all
>>>>>>
>>>>>>     I am trying to plug the results by JPL Horizons into the
>>>>>>     appropriate
>>>>>>     reference system of a SkyCoord object, but it looks very
>>>>>>     trick. (bewore
>>>>>>     long message, I hope the explanation is clear for the
>>>>>>     specialists of
>>>>>>     reference systems)
>>>>>>
>>>>>>     The Horizons server returns two types of equatorial coordinates:
>>>>>>     "astrometric" (1) and (2) "apparent".
>>>>>>
>>>>>>     Their description is the following:
>>>>>>
>>>>>>     - (1): astrometric RA and Dec with respect to the observing site
>>>>>>     (coordinate origin) in the reference frame of
>>>>>>     the planetary ephemeris (ICRF). Compensated for down-leg
>>>>>>     light-time
>>>>>>     delay aberration.
>>>>>>
>>>>>>     - (2): Airless apparent RA and Dec of the target with respect
>>>>>>     to an
>>>>>>     instantaneous reference frame defined by the Earth equator
>>>>>>     of-date
>>>>>>     (z-axis) and meridian containing the Earth equinox of-date
>>>>>>     (x-axis,
>>>>>>     IAU76/80). Compensated for down-leg light-time delay,
>>>>>>     gravitational
>>>>>>     deflection of light, stellar aberration, precession &
>>>>>>     nutation. Note:
>>>>>>     equinox (RA origin) is offset -53 mas from the of-date frame
>>>>>>     defined by
>>>>>>     the IAU06/00a P & N system.
>>>>>>
>>>>>>     My guess is none of these two systems correspond to either
>>>>>>     ICRS or GCRS
>>>>>>     as defined in astropy. The simplest possibility for me, would
>>>>>>     have been
>>>>>>     to assimilate (1), computed for the Solar System barycenter,
>>>>>>     to ICRS.
>>>>>>     But definitely (2) is not GCRS and the test below easily
>>>>>>     proves that.
>>>>>>
>>>>>>     Verification (see the attached notebook if you want to play
>>>>>>     with) :
>>>>>>
>>>>>>     - I queried for Solar System barycentric coordinates (1) of
>>>>>>     an asteroid
>>>>>>     at one epoch. I inserted them in a SkyCoord object as ICRS
>>>>>>     and use the
>>>>>>     transform_to(GCRS) towards geocentric, at the given epoch.
>>>>>>
>>>>>>     - I queried again JPL Horizons for the apparent coordinates
>>>>>>     (2) from the
>>>>>>     geocenter, directly.
>>>>>>
>>>>>>     As expected, by comparing the results I get the patent
>>>>>>     confirmation that
>>>>>>     GCRS is not the frame of (2), with a discrepancy of 16 arcmin
>>>>>>     in my
>>>>>>     case. SO, IT DOES NOT WORK, AS EXPECTED. Let's put apparent
>>>>>>     coordinates
>>>>>>     (2) aside for the moment.
>>>>>>
>>>>>>     Second possibility (see notebook again).
>>>>>>
>>>>>>     I take coordinates (1), for the geocentric observer. I insert
>>>>>>     them as
>>>>>>     GCRS in a SkyCoord object. I trasform_to(ICRS) (barycentric
>>>>>>     observer)
>>>>>>     and compare the result to a query of (1) directly for the
>>>>>>     barycentric
>>>>>>     observer.
>>>>>>
>>>>>>     Again this SHOULD NOT WORK accurately. In fact the definition
>>>>>>     of (1)
>>>>>>     does not contain annual aberration and light deflection that
>>>>>>     are part of
>>>>>>     GCRS. A difference of several arcsec (mostly due to annual
>>>>>>     aberration)
>>>>>>     SHOULD show up. And in fact IT DOES, ~8 arcsec of difference.
>>>>>>
>>>>>>     The conclusions if that using SkyCoord with the output of JPL
>>>>>>     Horizons
>>>>>>     is far from obvious to the end user...
>>>>>>
>>>>>>     ----
>>>>>>
>>>>>>     So, my final questions/remarks are:
>>>>>>
>>>>>>     - How to get a fully accurate consistency between a SkyCoord
>>>>>>     frame and
>>>>>>     JPL Horizons output, in the case of a barycentric, geocentric or
>>>>>>     topocentric observer, for both "astrometric" and "apparent"
>>>>>>     coordinates
>>>>>>     as provided by JPL? Which reference SkyCoord should use and how?
>>>>>>
>>>>>>     - Does astropy implement GCRS correctly in the case of Solar
>>>>>>     System
>>>>>>     objects, by taking into account aberration and light
>>>>>>     deflection in the
>>>>>>     relativistic form, for an object at finite distance
>>>>>>     (different than for
>>>>>>     the stars!) ?
>>>>>>
>>>>>>     - ...or... Am I missing something fundamental in my
>>>>>>     interpretation?
>>>>>>
>>>>>>     - Eventually, this query to Horizons turns our to be tricky
>>>>>>     to manage as
>>>>>>     SkyCoord for the final user. I think it would be useful to
>>>>>>     provide the
>>>>>>     correct recipe and/or directly a SkyCoord as output of the
>>>>>>     query...
>>>>>>
>>>>>>     Best regards
>>>>>>
>>>>>>     Paolo
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Benjamin Weiner
>>>>>> Staff Scientist / Associate Astronomer, MMT / Steward Observatory
>>>>>> bjw at as.arizona.edu <mailto:bjw at as.arizona.edu>
>>>>>> http://mingus.mmto.arizona.edu/~bjw/ 
>>>>>> <http://mingus.as.arizona.edu/%7Ebjw/>
>>>>>>
>>>>>> _______________________________________________
>>>>>> AstroPy mailing list
>>>>>> AstroPy at python.org
>>>>>> https://mail.python.org/mailman/listinfo/astropy
>>>>> -- 
>>>>> ---------------------------------------------------------------------
>>>>> Paolo Tanga                              Astronomer
>>>>> Deputy director of Laboratoire Langrange / UMR 7293
>>>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>>>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>>>>                                           https://twitter.com/ziggypao
>>>>> _______________________________________________
>>>>> AstroPy mailing list
>>>>> AstroPy at python.org <mailto:AstroPy at python.org>
>>>>> https://mail.python.org/mailman/listinfo/astropy
>>>>
>>> -- 
>>> ---------------------------------------------------------------------
>>> Paolo Tanga                              Astronomer
>>> Deputy director of Laboratoire Langrange / UMR 7293
>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>>                                           https://twitter.com/ziggypao
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org
>>> https://mail.python.org/mailman/listinfo/astropy
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
> -- 
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>                                           https://twitter.com/ziggypao
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200508/b4ec0d46/attachment-0001.html>

From Paolo.Tanga at oca.eu  Sat May  9 04:00:10 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Sat, 9 May 2020 10:00:10 +0200
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <9c8a6657-3c7f-6593-2043-5f8210b70857@astro.umass.edu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
 <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
 <f663f629-73ba-33d9-6b76-9a45896de097@oca.eu>
 <9c8a6657-3c7f-6593-2043-5f8210b70857@astro.umass.edu>
Message-ID: <44ea2f2e-0ad1-2f01-0aaa-094db91d5a8c@oca.eu>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/2614f644/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ekgeponodiajhmkl.png
Type: image/png
Size: 74735 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/2614f644/attachment-0001.png>

From ejensen1 at swarthmore.edu  Sat May  9 11:30:58 2020
From: ejensen1 at swarthmore.edu (Eric Jensen)
Date: Sat, 9 May 2020 11:30:58 -0400
Subject: [AstroPy] Effect of observer elevation on sunset time
Message-ID: <7B3DF8E3-FFAF-4AB4-A74E-AC7764B188B0@swarthmore.edu>

Hi all, 

I was just working with astroplan to calculate some sunset times (actually nautical twilight in the example below), and I noticed that specifying the observatory elevation doesn?t seem to make any difference in the results, contrary to my expectations. 

Example code: 

from astropy.coordinates import EarthLocation
import astroplan
from astropy.time import Time
import astropy.units as u

location = EarthLocation.from_geodetic(-16.5097*u.deg, 
                                       28.3*u.deg, 
                                       2390*u.m)
# Same location, but zero elevation
location_sealevel = EarthLocation.from_geodetic(-16.5097*u.deg, 
                                                28.3*u.deg, 
                                                0*u.m)
teide = astroplan.Observer(location=location, 
                           name="Teide", 
                           timezone="Atlantic/Canary")
teide_sealevel = astroplan.Observer(location=location_sealevel, 
                                    name="Teide sea level", 
                                    timezone="Atlantic/Canary")

now = Time.now()
n = 1000
sun_set = teide.sun_set_time(now, which="next", 
                             horizon=-12*u.deg,
                             n_grid_points=n)
sun_set_sealevel = teide_sealevel.sun_set_time(now, which="next", 
                                               horizon=-12*u.deg,
                                               n_grid_points=n)
print("Sunset at altitude:  {0.iso}, JD: {0.jd}".format(sun_set))
print("Sunset at sea level: {0.iso}, JD: {0.jd}".format(sun_set_sealevel))
print("Difference: {}".format((sun_set - sun_set_sealevel).to(u.s)))

This yields the output:

Sunset at altitude:  2020-05-09 20:41:33.933, JD: 2458979.3621982955
Sunset at sea level: 2020-05-09 20:41:33.933, JD: 2458979.3621982983
Difference: -0.00024139881134033203 s

i.e. basically no difference.   There are three reasons I could think of: 

1.  The effect of observer elevation simply isn?t implemented in astroplan. 
2.  There?s something wrong with my code. 
3.  There?s something wrong with my thinking that there should be a few minutes difference (later sunset / earlier sunrise) at a few thousand meters elevation vs. at sea level. 

My guess is #1, but I?m curious to hear if others have different thoughts.  I?m using astropy 4.0.1 and astroplan 0.6. 

Thanks, 

Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/f7b5725d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/f7b5725d/attachment.bin>

From Paolo.Tanga at oca.eu  Sat May  9 11:27:27 2020
From: Paolo.Tanga at oca.eu (Paolo Tanga)
Date: Sat, 9 May 2020 17:27:27 +0200
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <44ea2f2e-0ad1-2f01-0aaa-094db91d5a8c@oca.eu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
 <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
 <f663f629-73ba-33d9-6b76-9a45896de097@oca.eu>
 <9c8a6657-3c7f-6593-2043-5f8210b70857@astro.umass.edu>
 <44ea2f2e-0ad1-2f01-0aaa-094db91d5a8c@oca.eu>
Message-ID: <a5efb6c9-474d-40a4-d74d-9775743c3e78@oca.eu>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/95705391/attachment-0001.html>
-------------- next part --------------
{
 "cells": [
  {
   "cell_type": "code",
   "execution_count": 20,
   "metadata": {},
   "outputs": [],
   "source": [
    "from astropy.table import Table\n",
    "import numpy as np\n",
    "from astroquery.jplhorizons import Horizons\n",
    "from astropy import coordinates as coord\n",
    "from astropy.coordinates import GCRS, ICRS, Distance, solar_system_ephemeris\n",
    "from astropy.time import Time, TimeDelta\n",
    "import astropy.units as u"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 21,
   "metadata": {},
   "outputs": [
    {
     "data": {
      "text/plain": [
       "<ScienceState solar_system_ephemeris: 'de430'>"
      ]
     },
     "execution_count": 21,
     "metadata": {},
     "output_type": "execute_result"
    }
   ],
   "source": [
    "from astropy.coordinates.solar_system import get_body_barycentric\n",
    "from astropy.coordinates.solar_system import _apparent_position_in_true_coordinates\n",
    "\n",
    "solar_system_ephemeris.set('de430') "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 22,
   "metadata": {},
   "outputs": [],
   "source": [
    "time = Time('2020-04-09T00:00:00', scale='utc')"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 23,
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "WARNING: ErfaWarning: ERFA function \"taiutc\" yielded 1 of \"dubious year (Note 4)\" [astropy._erfa.core]\n"
     ]
    }
   ],
   "source": [
    "dt = TimeDelta(1000.0,format='jd')\n",
    "time_start = time - dt\n",
    "time_end = time + dt"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 24,
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "WARNING: ErfaWarning: ERFA function \"d2dtf\" yielded 1 of \"dubious year (Note 5)\" [astropy._erfa.core]\n"
     ]
    }
   ],
   "source": [
    "asteroid = Horizons(id='Eris', location='500', epochs={'start':time_start.iso, 'stop':time_end.iso,\n",
    "...                        'step':'1d'})  # geocentric ICRS\n",
    "ast_eph = asteroid.ephemerides(quantities='1,2,19,20,21,23',extra_precision=True)\n",
    "\n",
    "times = Time(ast_eph['datetime_jd'],format='jd',scale='utc')"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 25,
   "metadata": {},
   "outputs": [
    {
     "name": "stderr",
     "output_type": "stream",
     "text": [
      "WARNING: ErfaWarning: ERFA function \"utctai\" yielded 370 of \"dubious year (Note 3)\" [astropy._erfa.core]\n",
      "WARNING: ErfaWarning: ERFA function \"taiutc\" yielded 370 of \"dubious year (Note 4)\" [astropy._erfa.core]\n"
     ]
    }
   ],
   "source": [
    "# Build SkyCoord object in ICRS - this will be the geocentric direction to the asteroid, shifted to ICRS barycenter\n",
    "ast_coord_ICRS = coord.SkyCoord(ra=ast_eph['RA'],dec=ast_eph['DEC'],distance=ast_eph['delta'],frame='icrs')\n",
    "# Move origin to geocenter\n",
    "ast_ICRS_geoc = coord.SkyCoord(ast_coord_ICRS.cartesian + get_body_barycentric('earth', times))"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 26,
   "metadata": {},
   "outputs": [],
   "source": [
    "my_object_apparent = _apparent_position_in_true_coordinates(ast_ICRS_geoc.transform_to(GCRS(obstime=times)))"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 27,
   "metadata": {},
   "outputs": [],
   "source": [
    "d_ra= (my_object_apparent.ra - ast_eph['RA_app']).to(u.mas)*np.cos(my_object_apparent.dec.to(u.rad))\n",
    "d_dec=(my_object_apparent.dec - ast_eph['DEC_app']).to(u.mas)"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 28,
   "metadata": {},
   "outputs": [],
   "source": [
    "import matplotlib.pyplot as plt"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 31,
   "metadata": {},
   "outputs": [
    {
     "data": {
      "text/plain": [
       "(-10.0, 10.0)"
      ]
     },
     "execution_count": 31,
     "metadata": {},
     "output_type": "execute_result"
    },
    {
     "data": {
      "image/png": "iVBORw0KGgoAAAANSUhEUgAAAY8AAAEJCAYAAABsc6siAAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAALEgAACxIB0t1+/AAAADh0RVh0U29mdHdhcmUAbWF0cGxvdGxpYiB2ZXJzaW9uMy4yLjEsIGh0dHA6Ly9tYXRwbG90bGliLm9yZy+j8jraAAAgAElEQVR4nO3dd3Qc5dXA4d+VbMuWe8UNF3Cj2oBxMBBMD90UhxJCqDEQMKTgAIGQAkmAEAgt1I9AKCahE2KaKaaDOxhsgxvGvfcq6X5/3Bnt7Gola6Xd1a58n3N0dtrOvjuS5s7bRVVxzjnnUlFQ1wlwzjmXfzx4OOecS5kHD+eccynz4OGccy5lHjycc86lzIOHc865lKUleIjIIyKyVESmRra1EZE3ReSb4LV1Je89NzjmGxE5Nx3pcc45l1npynk8ChyTsO0a4C1V7Q28FazHEZE2wO+A7wGDgN9VFmScc87ljrQED1V9D1iZsHko8Fiw/BhwcpK3/gB4U1VXquoq4E0qBiHnnHM5pkEGz72Tqi4KlhcDOyU5pgvwXWR9frCtAhEZDgwHaNq06X79+vVLY1Kdc67+mzBhwnJVbZ+Oc2UyeJRTVRWRWo2DoqoPAg8CDBw4UMePH5+WtDnn3I5CRL5N17ky2dpqiYh0AghelyY5ZgGwc2S9a7DNOedcDstk8HgZCFtPnQu8lOSY14GjRaR1UFF+dLDNOedcDktXU91RwMdAXxGZLyIXAjcDR4nIN8CRwToiMlBEHgZQ1ZXAjcC44OePwTbnnHM5TPJxSHav83DOudSJyARVHZiOc3kPc+eccynz4OGccy5lHjycc86lzIOHc865lHnwcM45lzIPHs4551LmwcM551zKPHg453Z4ZWVw/fUwb15dpyR/ePBwzlWbKlxzDdS3PrrjxsGf/gQXXRTbdsghMHx43aUp13nwcM5V26RJcMstsP/+dZ2S9Fq3zl43bYpte/99eOihuklPPvDg4Zyr0po1sZtrWVndpiVTNm+21y1b6jYd+SQr83k45/JXq1bQpAls3BgLImBFWCJ1l650CnMcGzbUbTryiQcP59x2bdoEQ4fCvvvGtm3bBo0a1V2a0ikaPBYuhKKiuk1PPvDg4Zyrlpdftp/QSy9B69Zw5JF1l6Z0iQaPLl3gsMPqNj35wIOHc65GTj/dXvNwVocKwuCxfLm9vvNObN+2bdCwYfbTlOu8wtw5V6lt27Z/zNy5sDLPp3CLtrJK5PUgyXnwcM5Vau3a7R/Tsyd065b5tGSSB4/UefBwzlVqzZrqHZfvN9iqgsf69dlLRz7JaPAQkb4iMjnys1ZEfp5wzKEisiZyzA2ZTJNzrvqiwaNlS/jzn+F736u79KTbmjVw7rlW9FaZfA+MmZLRCnNVnQEMABCRQmAB8EKSQ99X1RMymRbnXOpmzIgt77knXHstDBgAxx1Xd2lKp1degX/9q+pjPOeRXDaLrY4AZqnqt1n8TOdcLXz2WWx5113ttbI+EFUV/eSqynqU33VXbHnIkPrTGTKdshk8zgRGVbJvsIhMEZFXRWSPLKbJOVeFaIV5kyb22rhx8mOrWz+SSyorkvrJT+CLL+K35XuLsnTLSvAQkUbAScAzSXZPBLqran/gbuDFSs4xXETGi8j4ZcuWZS6xzrly0eFIwuAR5jxat7an8tDWrdlLV7ps3Jh8e3ExNG0avy3sA+JMtnIexwITVXVJ4g5VXauq64Pl0UBDEWmX5LgHVXWgqg5s37595lPsnIsLHmGOIwwehYXwq1/F9udj8KisqK1hw4rBIx9zVpmUreBxFpUUWYlIRxErURSRQUGaVmQpXc65KlQVPAoK4MQT4emnbT0fR6StLOcBFYvnVq/ObFryTcaDh4g0BY4Cno9su0RELglWhwFTRWQKcBdwpmp9GPDAufwXrfMIM/zR4AGxm2w+5TyWLoUf/xgmTIgN7tizZ/wxiQ0DPHjEy/jYVqq6AWibsO3+yPI9wD2ZTodzrnqeeAIOPxw6d4YVK+D4462l1QUX2P6w5VFhob2GN9/zz4c33oAOHbKf5lTdey88+aQtd+4M//wn7LEHdO0aOyZxxGAvtornPcydc+Xmz4dzzoEzzrDWRgsW2KyBd94Zy2G0bm2vF19sr+ET+pQpNkVtPmgbeZwtLoajj7YgEpXYPPeLL2Ds2MynLV/4qLrOuXKLF9vrBx/A3nvb8hFHxB/TrJkVUTUI7h7RJ/TqjIWVC6IV5WErsu315bjrLvtZt86uwY7Ocx7OuXLJWh/1719xW8OGsZttNHjkS0fBaK/xMHhUV74EyEzz4OGcK5d4899zT2jevOr35GPwiHYOLIjcBZs0gR/9qOLx998fW87HVmWZ4MVWzrly0Zt/+/bw7rvbf0+0VVI+Bo/S0thyZU13e/WKLXvwMJ7zcM6Vi978+/SJr1iuTL7nPKLBozLtIt2WN29Of3rykQcP51y56M2/ZcvqvScaPPKlOWttgofnPIwHD+dcuWjwaNGieu+JBo958/Jj/otUg0d0RCQPHsaDh3M7sE2b4L77oKwsth6qbvBo2DC2XFaW+6PP3nsvTJ0aawhQVfB45hm46SYLkGPG2DYvtjJeYe7cDuzaa60DYLdu1pM8Gjy218oqlNgTOzoeVq5ZsgQuv9yW+/SxtPbuXfnxw4bFlsNiPM95GM95OLcDW7jQXsO+C9Ebf3UqyyG/gsecObHl/faDRx+Fxx+v3nvDHvae8zCe83BuBxY2sw2bqK5aFdvXrsLECMlFi60gNzvRqdpYVkuXxrY1bWrzl1dXeK0852E8eDi3AwsHN1y50oYm+e672L7qBo/EYT1yMecxfbqN2RWVOF/H9njwiOfFVs7tQFTjcwbhjf/Xv7Z6j9dei+2rboV5olwMHtGgGEo1eHixVTwPHs7tQO65xyp+w7qObdti+8Llk0+2HtWDBtXsM3IxeCypMIep5zxqy4OHczuQhx6y1+nT7TXZcBy/+hV88031W1slysXgEa3rCBUXp3YODx7xvM7DuR1I2J/j5Zdh3LjkwSPZKLrb8803dnPdZZfcrDBPFjxKSlI7Rxg8vNjKeM7DuR1IGDzuvNMmbkoWPGqS4+jVC3be2d6bCzmPVavgtNMsh7V+ffI6j/BaVJeINUv2nIfx4OHcDiTxhhltmnvRRfDhh7U7/6pV1oM71af6dBszBp5/HgYPtoA2alRsXzjUyMEHp37exo3hgQcs17ajy3jwEJG5IvKFiEwWkfFJ9ouI3CUiM0XkcxHZN9Npcm5HlRg8ok/kRxwBBx6Yns+ZNSs956mpMPezenXFfcccYwM41uS7FhXZOWvamKA+yVbO4zBVHaCqA5PsOxboHfwMB+7LUpqc2+EkBo/oKLitWtX+/E8+aa/JWjdl04oVFbeFPeFVa94MOTp3yY4uF4qthgL/UvMJ0EpEOtV1opyrj7ZurXxfdYdgr8qee9rrkCF1W7GcLHjsvru97rdfzc8b9vVw2QkeCrwhIhNEZHiS/V2AaHXW/GBbHBEZLiLjRWT8smXLMpRU5+q3qiqz05Hz2Gmn2HJd/psmG9n3xBPhk0/giitqft6wR77LTvA4WFX3xYqnLhORQ2pyElV9UFUHqurA9tHB9Z1z1aKaPHgceyzstZe1lqqt6GCKyZ7+syXZZzdvDt/7Xvyc5alKtYVWfZbx4KGqC4LXpcALQGJV0wIg+mfbNdjmnEujzZuTz10xejR8/jk0a1b7z2gQ6TmWzWKrb76BCy+MfWaynEdNOz1GqSZf3hFlNHiISFMRaR4uA0cDUxMOexn4SdDq6gBgjaouymS6nNvRvPuuBYioc86BL79M/2c99pi9VlW/km433giPPGKdH6HynEdtRXMe+TBjYiZluof5TsALYqOvNQCeUtXXROQSAFW9HxgNHAfMBDYC52c4Tc7tML7+GsaOheHDK87PccUVsUrkdNp1V3vNZme6cIDHd9+10YEzlfOIBo81a9KTW8tXGQ0eqjobqDDYQRA0wmUFLstkOpzbUQ0eHLuRJj6Nt26dmc8Mm8RmM+cRNqG977749ahMBI8uFZr27Dhyoamucy5DqppPvE2bzHxmXQSPRFu2QOfO8dvSkUuI1nMkGy9rR+LBw7kdTDhnd007ym1PXQSPaGfHUGKuIN05j2TjZaXbypVw22252crLg4dzO5gXXrA+GJnqs1AXQ5cnCx5du8avp6OYLprzyMbowVddBSNHwhtvZP6zUuVDsju3g+nbN75JLaoV55KthbrIeSQbwyoxeHToUPvPieYAsjF6cNj0OBeLyDzn4dwOYtAgmDJ+Gw3eezt2FxwzxnrNTU1sQV9zuVZs1bOnjbWVjvgYzXlkI3iEaU5jbE8bDx7O7SCeew72fu1WGz73P/+xjc8/b69jxqTtc8Lgkc1iq8ScR3fmcv4jBzOYjyguTk+uA+KHsM9G8AhjfC52SPTg4Vw9tWlT/HqLFsQKzydMgH/8I9a2Nezxtm2bDXL1+OM1/txcyHkM41k6fP0hd/ALGhSq3YUfeKDWY6Y89ZQN5b7zztmp8whHBEj8XeYCDx7O1VOJzXSbNSM2WuFtt8Flke5Vv/sdfPqp7V+zJn5fisIK82wFj02b7KeIzRSxmV9wO72YCcD3+IyJXzSAv/4VLrnEZryqhdNOswmzWrTITvAIcx65GDy8wty5eioxeBTc+AeYNi35waWlcMABsTFMolMBXn01FBdbgKmGwkKrRslWsdXixXASL/ESJzOKMzmLp+P2F2iZzbkLFiBffNEmap882RI6dGjKn+nBw3MeztVb0eDRkK3w+99v/017722vmzbBxx9bYfutt1bvvRGNGsF//wuzZ6f0thpZvBgO5V2ACoGjgkWL4JRTYI894NRT4eST4bzzUu60ka3gUbh5AzfwB9bOX5u0RVld8uDhXD0Vrdz9Z3TIuHBKgxkzYtuSTXJx4IHQp0+NPrtRI8vE9O1bo7enZPFiaM2q7R8YFX2Uf+wx2H//lN7esmV2gscPZtzFH/g9a//xeMaGk6kpDx7O1VMrV8KPeZxv6cbZPBXbcffd1lSoVy/42c8si3DnnZbDSDRzZuUfsGWL3bmTCPuRREu/MmXRIujB3Io77r47fv3YYys/yZIlsVp3VXj77eTj1wdatMjOfCWy2YJcRxbTkUWsX5c7za48eDhXT61cCX/iOrqFE3U+8ADcdRcMG2a15wUFcO+9cMIJtn/kyPgT3HZb/PrcuTBxYmz9mmugU6eknSwyXVn+2muxhmKLF0NP5pTv+/wHIy0AHHVU/JtuuQUmTYKf/9zWE8crCYuu7r/fmjM/9RSVadQIli+PvxyZsG2LVXr8lptYRGeatSioesCyLPLg4Vw9tXIlFLMxtuGkk2DEiKrHJTnggNjy4YfH32B79rQJwN9914q57r3XtieZFCTTleXHHmuZpgvO3sLeNw6jO/Nin92inS1EO3dcfrmNPz9gQKz3YOLUiXvtZZ0lH37Y1n/yE7j5ZlueNy/u0HPOsdePP07XN0queFOGJiZJAw8eztVTS5ZAM9bHNlSnp9ybb1pfkPPOs5vp/PkVjznsMCsS2rbN1r/+usIh4a5MK3tqFMN4DoC1RRY0tEHQ0aR1a3jlFStfuvvuWNAMGwWEEWBQZHLTvfaKz05cey3ccQd07w7PPFO+eeBAe830PO3NtywvX36XIQzffxJbtWFmP7SaPHg4Vw+pwntjttKYSBagOpN3N2tmxT3//KdVXLRoAQ89VPV7Ro2Cb7+tXYJraHe+AuD1pqcwo8MhAJQWNYkdcPzxFceeP/poS+/VV8M998ATT1iuKirs6Qjwy1/a6/vvl28K63T+8AebAjcTtm0po3vprPL1zxjEQ+MG5Exvcw8eztVDX34JZfMizU8b1KJLV9jM5667ku9/4w3o0aPm56+hHszh1/yVrTTkvObP8/S+tzKWQ5g36Ifbf3O3bjZg1GWX2Rj1s2dbjioUFldFVVLX8OyzNfwC26EnnMi+TCpf30gxkHyiq7rgwcO5euiCc0t5m8Nt5aabalc4f8opNpdtsl7n0XqDbDStChzH/3gTqxBvxDaeeQY6DN6VQxlLx91rOMtVWIcD8OMfx4a0DSXUe4Qy8rXXrqXRmNFxmxqQvetbHRkLHiKys4i8IyJficiXInJlkmMOFZE1IjI5+LkhU+lxbkcxdixsm/h5rBL5ggtihfQ1UVAAhxySvNjrkENiy++9V/PPSNH/OIFeWJHOrHte5eCDbe6LDz6AIUNqeNLoJO9t28Y/4nfsaMVWN95YYZTCjOQERo0qX3y7sTUxbrxTK/71rwx8Vg1lMudRAvxKVXcHDgAuE5Hdkxz3vqoOCH7+mMH0OLdD+OADOJCPYhs6dkzfyd98E37xC1seMgTatYvtu/NOa+K6cWPcWzJReb4tMrJSwTFHA1YfftBBtThptBdeYqAMK9VvuAFmWdAKL0MmmiVveOUdFhV0plfDb/n74P9wNTfT4roR5XX8uSBjwUNVF6nqxGB5HTAN2IGni3cuOyZPhiObfWpPz6tXp3cyiCOPhNtvt1ZML70E110Xa7X08svWue7TT+PekhBLaq2kBGbSq3y9Zes03cYaVtGKKdoiK2hi9be/2aVNZ7PkSy6Bnj2Uza+/y1tlh/GtdmNTYTNu5WqatMqRyo5AVuo8RKQHsA/waZLdg0Vkioi8KiJ7VHGO4SIyXkTGL8t0+zjn8lRJiTXR7SfTYZ99bByNTDj+eDt3+/bw6KPx+5YsiVtNd/DYsAHasoJZ7MLxvJLebg9Dh8JvfhNbD08eLQtbsACwwFFUlN7g8fQDqzno2ydpu20JH3BwXH1Ks2bp+5x0yHjwEJFmwHPAz1U1cTSYiUB3Ve0P3A28WNl5VPVBVR2oqgPbh2PzOOfi9OgB297/mN3WjavxuFQpSyziWbiQP/85thpOFZIuq1eW0ZYVjOIsRnN8lRmGlL34IvzpT7H1KVPgo4/iO08GwQPSHzwe4GKewHJy8+gWt69Jk2TvqDsZDR4i0hALHE+q6vOJ+1V1raquD5ZHAw1FpF3icc656lmwAD7mQFvp1Cn7CSgqgkWLuPbaWBPW9eurfkuq1rz5KYWUsZws3Cp69oTBg62p84QJtm1SrPlsuoPHzsSaVy+kM8OGxYJGrvTvCGVsPg8REeD/gGmqenslx3QElqiqisggLJhlYbgx5+qfsjIYSWRww+9/P3sf/tZb0LQpnH56eZ1Aq1a2K61Dic+axd4XW3CcTr80nrga9t3XauS//dYGtmrblkaNJK0V5htoWr586Nld+es/rRSwefPs/jqrI5OTQR0EnAN8ISKTg22/AcuLqer9wDDgUhEpATYBZ6rmWnx1Lj9s2gS3cjUAX3c7kj41brNaA4cHfUo6dIClS4FYx+5VKY6WXqVx48oXy/uxZFO7dtZQIKjrKSo6N605j27MYxntuJ9L2P2QdjRsCF27wpNPpu8z0iVjwUNVPwCqbOahqvcA92QqDc7tSDZsoPy5tbRJ0yqPzZgOHayO4LbbaH3qL4GC9AaPYHap3ZrM5cOxjaoaNT0zokOdvP12eoOHKt2Yx71cxg3cyH9ybP6ORN7D3Ll6Ilox3aA0SxOIJ+rTx8qpRo6k3RzLJaR1BPE5c1hdtBN0787++8fXY2dFNFqJpLXOQ5ctpwmbyyvKE4fkyjUePJyrJ9avivXGm7jPhXWTiJ/9rHyx6cJvEEk63UfNzZ7NvIa70LVrGs+Zimjt/5IlaQ0epU/9G4Bv6Q6QczMHJvLg4Vw9sXWxPeJfwZ3MGnBa3SSid2+49FIAZMVymjWzSQvTYswYePttZpbWYfAIe9Q3bZre4DFpEg1+MQKINdH14OGcy4oweBR27MB559VhQu65x/p+rFhBs2ZpbKobzAy4YlNxhXmcsua222yyqKBVWVFRmoYniQzN68VWzrmsKl1mwePS69vQuXMdJqSgwB6bV6ygefM05jyCp/5XOabuch7Nm8OFF1rDgMWLOeO722iwMbHvcw2880754kralH9ULvPg4Vx9sGwZA/5mPZMb7ZQDj6xt28Ly5ekLHrfdBsuXM6nZ93mBU9mj0oGMsqRDBygp4YJpI7n0u99s//jtmTePVSecQxM2EjZSrc7cXXUpx5PnnKuW116j2bI5ABR1zIHC8saN4ZlnOHbzC+kJHiNHArC8yLJUBx6YhnPWRmSIpGbbatmcrKQEFi1iQ7vubCbHxiCpggcP5+qD72LDWrTco67KdCKCaWkvnntteoJHx47QrBnXNbuLH/0ovQMF10hkPvg1WsvBJxctgrIy1rWyipyDDiKn5u2ojAcP5+qBbbNs4qczGUVx6xwYujsYkKnrhhlsWlvLCT1UYfVq9JJL+XxxB7rkwsQOgwaVz6LYYOvG2o0cPH8+AKubWdC/+25yat6OynjwcK4e2DJzHhPYl/1uPbOuk2LeeKO8udD+K16r3bnWr4fNm1le2IEtW6jbxgCh1q1h3jzmtx9A022r6NVr+2+pVDBK74rGFhVzvaI85MHDufpg3jzm0S1uzqI6tdde5UOJdFw7gwceqMW5grGyfnWLFRXttFNtE5c+m5u0pg0rWbSoFicJgseyRhY8cm3ejsp48HAu36lStPhb5tGt7vo/JNOyJWWt27Ars7jkEhu4sUaC4LEMq6Su88ryiC3FbWiNDd5VVlaDE0ydCj//OQAX/NrmUPfg4ZzLjjVraLh5Pd9Jt9yoD4go6LYzXbEy/b//vQYnWLsWnn4agKV04JRToHv3NCawlrY2tZwH1HDGxNujs1VYK4Di4tqnKxs8eDiXzy64oHwciy07dacoB+rK43TqRK+mVqZTo57Yt98Od90FWM/rcI6QXLG1eRs6sZhTeL5mMyYG870/yE/LN+V6/45QniTTOVdBaSn885/lqwU9ulVxcB3p1Ik+zS14NKjJBBAzZgCwjHYsp33OBY+SZha4n+e01IdhWbIEvvoKbrmFi3kQgHnz0pzADPLg4Vy+isylDVDSfdc6SkgVOnemYNkSCimt2QCCwTSEA7D55Fq0SGPa0qCkRaw3/6ZFKU6Z+M03AGzbYwAAN95IbtVZbYcHD+fyVaSJz7MFp9O0W9s6TEwlOnVCSkspoQF7f/Zw6u+fPZsNxw5jIVaZk2vzjG5rHGtX2/TZx1J7c9AQYFNza0WWLxXlIQ8ezuWrSNft4WX3RUfMyB2RntgHf3Z7FQcmUVoKc+eyqdMu5ZvSOV94OqzoGBtkq/HU8am9OQge64vtGjWto8kfayrjwUNEjhGRGSIyU0SuSbK/SET+Hez/VER6ZDpNztULQSH7olcmsIo2tM3BjAcHHwz9+gGwqGW/1N67cCFs3cr6nWLFcZdcks7E1d7SjnvTjHV8zAEULl9c/Tf+5jfl856sK7LRgj14RIhIIXAvcCywO3CWiOyecNiFwCpV7QXcAdySyTQ5V28EwWNViRWd5OT8D506wbRpfNboYBpvTnEy86CT4Zq2lvN4663caqYLsHkzbKAZi+hEoxXVDB7r18Nf/lK+umFbI8CDR6JBwExVna2qW4GngaEJxwwFwsLCZ4EjROp82DPncltJCYwaBcDSTTkcPAJrG7aheHMKo8++/jpcdx0AKzrsBuRm/4fNm+11MR1pvGoRvPde+aCQlVq+PG41bKXlwSNeF+C7yPr8YFvSY1S1BFgDVMiAi8hwERkvIuOXLVuWoeQ6lyeuuQZGjwbghLOspjWXg8f6hm0o3lLNnEdZGRxzDHz4IeyxB6uK7ZaRi8HjssvgiCOC4LFhBQwZAqecUvWbEoJH2D/Eg0eGqOqDqjpQVQe2z8maQeey6L//LV/ciN1Ve/asq8Rs34ZGrWm/6Tt46qntH7xiRWy5Z8/ym2suBo82beDVV2ERnWIbFy6s+k3R4LH//nkbPGrSbScVC4Boy+WuwbZkx8wXkQZAS2AFLrdt2GBNRd95B774Al57Dfr3h4YNrc3hsmUwcCD06gWHHML0NZ3o1q0aN4CtW2H6dGvQv24d7LlnDkzegLURLSmBd9+FffelzmunS0rKF5UCXnwxt28+DQuDgZ/OPht+9KOqD14cqTto2pSVQWlX6xyY4yqZhg1hUeHOUBps2N6wuGHwePNNtgw8iDXP2Wq+NdXNdPAYB/QWkZ5YkDgTSPzLeRk4F/gYGAa8rZprrbmradkyK+/s399uNg0b2vZcuPlVZeVKS2+bNsnTqmpjDG3dakNtP/ssvPhibH9hobWoGT/elr/7zv4TgmPKCgopKevH6QV/5eNWx3LPPXDWWcF7t26FMWPgT3+CKVOsELm0NHbuNm3snD16WEAZNgz2399qTrdutQrZMM2rVkHLlhZ8ROx3sfPO0K2bfYdUepipwgcfwM032z/7xImxG3br1rDLLjY2eMuWcMYZcMIJ2z9nWZldx7lzbdTZtWvt/Vu32sx7qVgR/3yVqzfW0PKmkZruFSuqDr5LlsSWr7yS5f+zITtyrXd51IrinSFsOb2qiuK5sjK7TwDstx+NW8dmDmxZyzmlsi2jwUNVS0TkcuB1oBB4RFW/FJE/AuNV9WXg/4DHRWQmsBILMNlTVmbtrRcvtgrITZtseZdd4LPP7OZVXAwDBsCkSXZ8mzb2Dz9/vt3wtm61G8vGjZR3o23QwNq4b9hghaKFhVauMG8e7LabHVtWBl9+CfvtZzffE09M32D+qvZHvHKlpXHlSqvMa9nSyso3b7Yn+9atLZtdWmo3sDB7sHq1La9ZYzV6s2bFzt24sbWZ7NQJTj2VTTv14LOvmnHIIbZ7xnTl+t8KPzx4EZ+8sIjd37uPU3iB/zQ4i+PbT+OqqzpxxhlQ8PV0exKdONEmDzrvPCgqslnjNmyAdu1gwgRL25QplqageWO5Tp2gUSP7LitX2nWOBh+wQNK4sQWdAw6AESPseyc+qm/aZIFszhxrDbN4saWna1cYPtzes/POlttauxYmT7bc1xNPwMUXw513UmFwqYkTLbcyeTL8+9+xjgoFBfb7b9IEtm2DU0+1v5k2beDMM206uWRWr7bvu2ZN3OZcvrECvLLrlZRt3sLl86+F99+Hk0+u/OAweEyfDn37Mv8Bi94c5TsAAB+aSURBVNOFhdlJa00sbdk7FjxWrIB777UKkURDh8Irr0BhIZuL4qNFrvWe3x7Jx4f8gQMH6vjxKXbIAbshFRTYzeHrr+HBB+2m+PXXtl/Ebrpt29ofQO/e9vTauLHdLBo1sn/+Ro1iN58ePWyCgTZt7NwdO9rNa9Uquylv3mz/BOvW2XqHDhasws+KOuAAuzElewpds8ZuHBs22E2uuNhu6lu22Hdo2NCKj7ZssRvg+vX2PZM57DBLa3Gx3bB697a0rV5tN7IGDezGuW4d9O1rgXHPPe34E0+0p+ZG1rxwxgz4xS+s3LdjR3uoit67mzSxTMgj13zNCdf1Z0G/I+g6+b9Mv+Yx+t75MzvnLbfwv9JjaNe/C/37W3xt2TJ2mcup2ndbtMhuxl26WG4nDNi7726/HxG7zn36wMyZ1uTzq6/sfd98Y9+nuNiK1UpK4Kij7HyTJ8daynz/+3D++XZTjzwSlpXFD1w38eMt7PbPX9PkobsY2+405v3tGX58jiBaZuNOXXGFPSi0aAGHHGJzX++1l12okhL729iyBT7/3K79ihX2eYsXV/w7WLTI7qI/+Un5PKWjOZbjGc3cubnXjDXq5JNh/qwtjP+6BVx5Jdx6a/IDH3sM/vAH+9tdtQpateKww+zSfPBBdtOciu99D3o2XsTTxz4G115rGxcvrjj5SJhLLixk+eKS8o6dxcXUbGDFFInIBFUdmJaTqWre/ey3335aIwcdpGq3IPvp0kV18GDVyy5Tvece1WXLVJcvVy0rU9240d5TUmKvc+aorlqlumJFbF8qSktV16615bVr7bxz59pnrV2r+sQTlqbDD1fdtMmOW71a9ayzVDt0UC0sjE97VT9Dhqh+//uqF12kesUVquPG2c/y5TVLe4KlS1Uff9ySFv3Yrl1Vf/IT1QMPVH32WdVbb1VdsiTyxr//XRX0LkZoCQU6u8ehesfIBdqwYewcRUWx5V69LMlp9fnnqn/4g+ppp6kOGqS66672Yd272zV75hnViRPt9xLYvFn1rbdU//IX1SZN7PWGG1QvuCCW1mv4syrocbyiDz+sqldeaTsGDFCdMkV127bqpe/ss2MnnTgxft9HH8Vd8A+uf7V8df36tF2hjDj9dNVGjVTX732AXefKhF+osLD8d9Czp/2t5bITT7RftT7ySOw7fPCB7fzuO9VDD1WdNi22r2VL/fbb2GqnTtlJJ1bik5b7cKbrPHJHWZk1oevRAwYPtsfkoUMrH+ozmIO5PK/co0ftPr+gIFYkFb6Gj4rNm1vxzbp1Vixz5532xHvhhfDRR1bBuNNO9kTatKkVfy1fbk+sxcVWxLFwoW0vLbUitwxRtaSFT4EXXQSnnw5HHlmNqp0RI+C//2XEW3ezktbsN/c5Vv3V2pe2bWvnmTzZHtjmzLFMQ7t2Vmp05ZVWYnTGGbX8AnvtZT+hkhLLcbVrV+HQCRNg5EjL3ERGAil/sAw1bAitbriKbf/3CLfPu4pnb1oEc++Eyy+34cRTqfM65xx48klb3nff+NxpQhPPNU06AlZdlMuV5WCleVu3wn2fH8RV/M1yfa+/Hl/3sToysGBpKYhQWmpVaLX+vWdYq1aW8Y9rLz1njn3x116zostwYvImTeCBB+Imx8r1Ysek0hWFsvlT45xHjvvmG9UZfU/QsoIC1ZYtVRs2VL3//rpOVrnRoy1XAarHHmu5j5QtWKB6zjm67fmX9emnVR9+WPXbb1XXrIkdUlZmGbWPP7aMYTR3M2KE6u23Wwbi44/t+BkzVBctstzO0qWqd96pOmGCPfDV1Nat8RnVX/7Svu+kSaq/+pWd/6WXVBcujGVO9YUXyt+wacABqlu26KxZlo4FC1T/9CfVa69VveQS+47Tptnr5s0JH752beyDDzvMPuT3v6+Qw3z8zhUKloHNdT/9qSX7DEbFvsNDD9nOsjLVe+9VffTR2L7x41XVvhuo3ndfHSa+Gq64wv5l9b33Yt/hqquSlwzMn6+qlrEMNx19dHbSSRpzHnUeCGryU5+Cx7Jl9g8yYID9NvoyTTc1aq7aurXdqXLA9ddbqQ6o9uihesstdnPPlq++sptHYjEZqLZtm/z/M/z58Y8jN/dqGjvWvidYoPr00+q/d+HL4/QX/E3POnp5eQlUq1ZW8hhNV8+eseUOHezB4eGHVadPVz3qKNU39r82dsC//530y91zd5lCQtFgjrr8ckv23kyOfYef/cyKdqZMSXpzVbWAnawEL9f87neWzpIpU2Pfo3fvir+3Nm3K3/PBB7HNF16YnXSmM3jsOMVWWfCf/1h9Zzh42+bNllWPNsFTtVKM1avhmWesEU9Yd15cDDM29qNf8XdM+7oBTdplpiyitNRK49autcrsv/0Ndt3VctMDBlid5fjxVi8/eXKsz1OnTlaUk+2ezLvtZj8XXGCN0jZvtoZLBxxQPkIHYEVMzzxj9cwNGtj3fOIJ+zn/fHjkkao/p6zM6q3POceuz8svW/uAVHQ6cSCzhw7kpZdi29atsxKoESOscV2PHjBuXKw9w9Kl1mYhai/aclS4EjboSPDoY1Yclmor37oQltx9TZ/Yxn/8w36GDIlta9vWGgUE/vUva/vQv3+WElpDYbHTiLv7cOPuB9N25mfl83XEiUzYEZ229qKLMpzATEhXFMrmT6ZyHhs2xK9Pm6a6bl1sfc2a+Hr0U06x+tZ+/VR32SX+AaNDB6tcbd7cntxvvln1/PPtiXbYMFWR+KfjSZMs9/7WW7Zt1Kj0fq81a1T/+Ed7iO3Y0dIFqi1aVP3kXlRkdbgrVuRmpeysWdaOYdkyW9+6NVbXXVpqxQHhdzn0UNWnn678XCNHxo4dPbrmaSottdzS2LFWklWZkhIrfhs71oo9hg+Pff55PBKf8OgvRUSfum1B+erWrTVPa7acf34s+VX+wR12WNz7WrdWvfjiuklzKqIlbqCVF1kdeWT5e156SaMldFmB5zzSJ2wdGdZnlZTYU8Tgwdb8tHVra3a/zz7w299aE/Q99rBWk2HP1y5d7MmoXz+rAy8osCf3YHpibrop/jPnz7eWoJs2weOPW2vY0JAh9uD1+OP2uTW1ZYt1U3nzTatQLSuL7Qu7GIBVtI4caf35Nmywvm577mn7i4tzv6IysW1A2C8T7Hu++qrl8o45xrq5jB1rLUAPOcRa9paVWdPgRx6xuu0ePeCGG+z4miooiOWWqlJYGKu7D/vIzJ5trZFXEsnevftu/BvLypj/19hqjaZ3zbJog4NJL8xlnwWvWIOCRPvuW75YVma/u8iUIDkr2kejRQsqbzcdGRkgzHnkemOHyuTBn11mbNgAd99tN4zIhGzlXn3ViptWrYL77ovft2iRTVMwcKAVpbRrV7FvmKp9RoMG1kVjzhy7kf/qV3bTSDw+VFhoxV433GCNbs4+O7Xv9eWXltV/6ikLUgCDBllx0267WZeGG26AadNs5JCwnfn116f2OfmioMCK2T77zH4Pu+4a62d4wAHWhy/st9e7twWYjh3rLr1hl5UVFccGjbNtW2w51wcwgPg+jcubdreOs8n06hX3HtXcHvAxdPDB1gd13Dh7+GKPYJKoK66wm0xon33KF8PgkYtjdlVLurIw2fypTbHVhg3WdyBanDFggLXb37Ah1vVi0yZ7ffdd1cWLrbhnxgzVTz6JddfIlM2bVQ8+2NL2059ay55It4M4JSXWBeWZZ+IrYaNFYtu2qa5cWfk5diTvvGNFKG3aWEV269Z2nV57LUmrpzowaJClpzPz43+R0V+uqv72t3GrOW/EiFh6n3su2LhkiZULhzuGDrU/1MCsWbb50UfrJs01ccwxqvvvH6xMn27/dF262D/yqFFW/hu4+277fmGRazbgxVY18+GHVhQUPpHffrs9CAwZEnt6C3ObYSVkWJd3+unZS2dRkXXAPfBAeOgh+wF7Iu7Rw/b36wf/+58VnUUr3sDq6ebMgUMPjRXj5PrYR9ly6KH2Ez7hL1sGCxZYD+FcEBZBLaQLM95eQN8PH7Hy0ttvt35KJ50ExIpM88Utt9jABqeeag01gFh51OrVFj4SOjuE3zEfch6hxo1jf1vl5dHhDSdB2M+jSZOku3PeDhM8tm2z/71ly6zT2U03wbnn1nWqKjd4sDVE6dvXysDDoZYWL7b0jx1rxxUX2xA6S5dacdcuu1iAieT+XRJhsWHXrvaTKx5+2PqGfvwxLJLO9L3++liZ4hdflJeprcizcaebNInV65QHj1AlIwLm+mi6yRQVRYLHdoQPfR48clzDhnbDnTzZch/5UE4cls0ffjj8+c/WDLVvX+tIPmOG1b316FG3ZfQuvXbbDR54APbeG156yXJJ5fbcs3wxOmp5vggHVohWnldmzJjY4LP5lPMoKorNLrg9mzbZ8dGx0vLJDhM8oHotYHLZD38YWx6YnqHNXA7qEsy1+fe/wx13VNyvClOn2nKk/jXnNWpkN8sKOY8EX31lDTtC+ZTziCu2qsS6dXDaaXYd8jXXATtY8HAuH7RpY7nLdu1inUqjNm60Ya7+8hf49a/rJo011bz59nMeicEln4JHdXIeM2day0uwjrf5Kk8zTM7Vb/vsY80+Cwpi4yFu3Gj1WlOm2Hq7dvlX5NGixfZzHtEGIN265UcP+lB1ch7RARETxrrMK57zcC4HRacknTLFukU8/bTVh4SjXuTTE3moOjmPaPDIt+LZsMI8WY4xFA0e0f46+SbPnluc2zFEn7bDJ9mwOOS77+w1H4NHqjmPXGoJVx1FRdYzPtKRvIJo8MhnHjycy0HREQjCJ/XE13wNHu++a/1qKpvqO5xRr2NHG0wyn4RBv6qiKw8eVRCRv4rIdBH5XEReEJGkU52IyFwR+UJEJotIDeaVda5+igaPtWvtRvvee7a+dKm95mPwCJvrfvYZPPdc8mPCnMeUKfnXXyn8vb3zTuXHePCo2pvAnqq6N/A1cG0Vxx6mqgM0XfPqOlcPJOY8jjwSRo+29XBQy3zq/xCKdiKfNi35Mfk8YGD4ezvpJKv3SCYaPKIDKuabjAQPVX1DVcNSv0+APCu5dK5uJeY8Jk6M319YGHuKzyfRpqlhDipRPve8jtZVVVYsFwaPZ5+1Pi35Kht1HhcAr1ayT4E3RGSCiAyv6iQiMlxExovI+GVh11Pn6qnoTWjBgor7W7XKj1ESEoUdIKHyIVY2bLDvn2/NkCE+6Fc2CkAYPI4/Pv565Jsa/3pEZIyITE3yMzRyzHVACfBkJac5WFX3BY4FLhORQyr7PFV9UFUHqurA9uE44s7VU9Gb0MMPV9yfb2NbhaLTXIQV44k2bszPIiuID/pLliQ/ZtMmC/yVTcuQL2rcz0NVj6xqv4icB5wAHBEMBZzsHAuC16Ui8gIwCHivpmlyrr7Y3o3lRz/KTjrS7cADbWy5996rOBp0aMOG/J3jIvp7qyp4NG6cnznHqEy1tjoG+DVwkqom/RMRkaYi0jxcBo4GpmYiPc7lm8LCyvetXGkTheWj4mKbd37w4MqDx/LlNpV5PooGj2R1Oi+/bIEzH+tzEmWqh/k9QBHwplh4/URVLxGRzsDDqnocsBPwQrC/AfCUqr6WofQ4l1eq6ieQj010ExUXV95kdf78/B0pOlpsldiTfv16GBoU6nfunL00ZUpGgoeqJm2draoLgeOC5dlA/0x8vnP5LrGyuE2b/JsAqipNmlgOY/Ro6N8fBgywSc/uvtumTfjlL+s6hTWTrHNnaNKk2PLChdlJTyblYXsG5+q/M86webGPP97W83n01WSKi+3mevzxNvT88uVWj/P227Y/X1shRRsBrFsHF18Md95p6/k4B0tVPHg4l4PatIH334/N4VLVWEn5KFoh/umn9hotxsrXYLnPPrDffrY8axY8+CD8/OdWOR5tch1tdZavPHg4l8P6BwW7BxxQt+lIt2jwmDmz4v6ddspeWtKpWTMYP94mffz88/h9H39sr++/HwuY+cyHZHcuhw0YYGM8tW0Ljz1W16lJn2jwWLQoft9NNyVMv5uHmjePzfYYmjfPXr/3PZsWO995zsO5HLf33tChA+yyi83pUR9U1lS1cWP4zW/ys3d5VLKhY2bOtAr1+hA4wHMezuWFhg2tDL2+qKwOp337/O88B8mDx/LlNvtjfZHn8d05V5/Uh85zUPmglfk4mGVlPHg457Lu/PPhyittjvKoqnrW5xMPHs45lwFNm1r/jj59bD2sQM/3uo5QGCT69YvfHp2bPt/Vk1+Vcy4fTZ9ur7vvbq+DB9ddWtKpZUt7TRyjy3MezjmXBmefba8vvQR33QW/+13dpiddLrgAjjkGrr46fnt07Kt858HDOVdn/vxnmymxc2cYMQK61pM5R9u1g1dfhX33reuUZI4HD+dcnSkoqF9FOYkSJ7WqbF7zfOTBwznnMqRlS7j0UmtZBh48nHPOVYMI/OMfcPjhdZ2S9PPg4ZxzGRYWX+2zT92mI518eBLnnMuwww+H//0PfvCDuk5J+njwcM65DBOB446r61SkV8aKrUTk9yKyQEQmBz9JL52IHCMiM0Rkpohck6n0OOecS59M5zzuUNXbKtspIoXAvcBRwHxgnIi8rKpfZThdzjnnaqGuK8wHATNVdbaqbgWeBobWcZqcc85tR6aDx+Ui8rmIPCIirZPs7wJ8F1mfH2yrQESGi8h4ERm/bNmyTKTVOedcNdUqeIjIGBGZmuRnKHAfsCswAFgE/K02n6WqD6rqQFUd2L59+9qcyjnnXC3Vqs5DVY+sznEi8hDwSpJdC4CdI+tdg23OOedyWCZbW3WKrJ4CTE1y2Digt4j0FJFGwJnAy5lKk3POufTIZGurW0VkAKDAXOBiABHpDDysqsepaomIXA68DhQCj6jqlxlMk3POuTTIWPBQ1XMq2b4QOC6yPhoYnal0OOecS7+6bqrrnHMuD3nwcM45lzIPHs4551LmwcM551zKPHg455xLmQcP55xzKfPg4ZxzLmUePJxzzqXMg4dzzrmUefBwzjmXMg8ezjnnUubBwznnXMo8eDjnnEuZBw/nnHMp8+DhnHMuZR48nHPOpcyDh3POuZR58HDOOZeyjExDKyL/BvoGq62A1ao6IMlxc4F1QClQoqoDM5Ee55xz6ZWR4KGqZ4TLIvI3YE0Vhx+mqsszkQ7nnHOZkZHgERIRAU4HDs/k5zjnnMuuTNd5fB9YoqrfVLJfgTdEZIKIDM9wWpxzzqVJjXMeIjIG6Jhk13Wq+lKwfBYwqorTHKyqC0SkA/CmiExX1fcq+bzhwHCAbt261TTZzjnn0kBUNTMnFmkALAD2U9X51Tj+98B6Vb1te8cOHDhQx48fX/tEOufcDkREJqSrYVImi62OBKZXFjhEpKmINA+XgaOBqRlMj3POuTTJZPA4k4QiKxHpLCKjg9WdgA9EZArwGfA/VX0tg+lxzjmXJhlrbaWq5yXZthA4LlieDfTP1Oc755zLHO9h7pxzLmUePJxzzqXMg4dzzrmUefBwzjmXMg8ezjnnUubBwznnXMo8eDjnnEuZBw/nnHMp8+DhnHMuZR48nHPOpcyDh3POuZR58HDOOZcyDx7OOedS5sHDOedcyjx4OOecS5kHD+eccynz4OGccy5lHjycc86lzIOHc865lNUqeIjID0XkSxEpE5GBCfuuFZGZIjJDRH5Qyft7isinwXH/FpFGtUmPc8657KhtzmMqcCrwXnSjiOwOnAnsARwD/ENECpO8/xbgDlXtBawCLqxlepxzzmVBrYKHqk5T1RlJdg0FnlbVLao6B5gJDIoeICICHA48G2x6DDi5NulxzjmXHQ0ydN4uwCeR9fnBtqi2wGpVLanimHIiMhwYHqyuF5FkQSsd2gHLM3Tu2vB0pcbTlRpPV2ryNV3d0/VB2w0eIjIG6Jhk13Wq+lK6ErI9qvog8GCmP0dExqvqwO0fmV2ertR4ulLj6UqNp6sawUNVj6zBeRcAO0fWuwbbolYArUSkQZD7SHaMc865HJSpprovA2eKSJGI9AR6A59FD1BVBd4BhgWbzgWylpNxzjlXc7VtqnuKiMwHBgP/E5HXAVT1S+A/wFfAa8BlqloavGe0iHQOTnE18EsRmYnVgfxfbdKTJhkvGqshT1dqPF2p8XSlZodPl1gGwDnnnKs+72HunHMuZR48nHPOpU5V8/oHa9X1Dla/8iVwZRXH7g+UAMMi20qBycHPy5HtRwATg+0fAL2C7UXAv7GOj58CPSLvuTbYPgM4O8vp+mXwWZ8DbwHdKznXG1lO13nAssh7Loq851zgm+DnF1lO1x2R47/G+hxl83odHqRrKtZBtkGwXYC7gr+jz4F9s3y9KkvX2UF6vgA+AvpH3jM32D4ZmJLldB0KrIm854bIe47B/hdnAn/JcrpGRo6fGry/TQauVzfsb3RacI4ewfae2P1pJna/apTi/esH2733bu+AXP8BOhH8gwHNsRvB7kmOKwTeBkYnXPz1lZz3a2C3YPlnwKOR5fuD5TOBfwfLuwd/CEXBL24uMDCL6ToMKA6WLw3TlXiuOrhe5wH3JDm+DTA7eG0NfAsMyVa6Eo4ZATySreuF5fi/A/oE638ELgyWjwNexYLIAcCn2bpe20nXgUDrYPnYMF3B+lygXR1dr0OBVyo5/yxgF6ARdmM+LVvpSjjuRODtDF2vd4GjguVmxO4B/wHODJbvBy6N/A9U5/41CyhM9j8V/uR9sZWqLlLVicHyOiwCJ+upPgJ4Dlha3VMDLYLllsDCYHko9oQBNrTKEcFQK4lDsswAGmYrXar6jqpuDLZ/gvWbqfjm7F+vyvwAeFNVV6rqKqxVXuc6StdZwKikb87M9WoLbFXVr4P1N4HTguWhwL/UfIL1hepEdq5XpelS1Y+Cz4Xs/31Vdb0qMwiYqaqzVXUr8ATQp47SlZG/r2AMwQaq+mbw/vWqunE7Qz9V9/5VYUipRHkfPKJEpAewD5Ydi27vApwC3JfkbY1FZLyIfCIi0bG1LgJGB02RzwFuDrZ3wZ42UOvcuAb7IyrfHigfbiVL6Yq6EHt6rfJcWUzXaSLyuYg8KyJh59GcuF4i0h170np7e+dKY7qWAw0iI1EPI9aptrLrko3rVVW6ohL/vhR4Q0QmBMMIhZ+frXQNFpEpIvKqiOwRbMuJ6yUixVjx2XORzem6Xn2A1SLyvIhMEpG/BgPQVjX0U8r3r8pkamyrrBORZtgv6OequjZh99+Bq1W1zIJsnO6qukBEdgHeFpEvVHUWVqZ8nKp+KiIjgduxG1FOp0tEfgwMBIZUdS5gSZbS9V9glKpuEZGLsaeew3PlemFZ92c16IeUreslImcCd4hIEVZmXZr4xupI9/XaXrpE5DAseBwc2XxwcK4OwJsiMh2rB8hGuiYG71kvIscBL2KdknPiemFFVh+q6soMXK8GwPexgDMPq8s4j2x1tq6qTCtffrDiodeBX1ayfw5WzjgXWI9l/U5Octyj2NNDe2BWZHs34Ktg+XVgcLDcAHv6EKyy6drIe17H/sGykq5g/Ugs29uhimv1KHBGNtMV2V4IrAmWzwIeiOx7APhxttMFTAIOzOb1SrL9aOA/ketwVmTfDKxcPOPXq6p0Bet7Y2Xhfaq4Xr8Hfp3NdCXsm4sNDjgYeD2y/VrgumynC3gB+FEmrhdWJzY2ctw5wL3Y/Wg5scr78mtBavevwZWlW1XzP3gEX/xfwN+reXz5Lx6reCwKltthrVh2j1zUsCLsQuC5YPky4iucwn/6PYivcJoNPJ7FdO2D/WP3TjhvsnO9lMV0dYqc6xTgk2C5TfBP0Tr4mQM8na10Bev9sH9Iyeb1CtY7BK9FWOu4w4P144mvMP8sW9drO+nqhpWDH5hw3qZA88jyR8CYLKarY/j7w8ro5wXXrgH2P9gTqzCfks3fY7CtJbASaJqh61UYfK/2wfo/sdE8AJ4hvsL8Z8FyKvevKivM60Ox1UFYxP1CRCYH236D/bGjqvdX8d7dgAdEpAyr/7lZVb8CEJGfAs8F+1YBFwTv+T/gcbEhVVZivwBU9UsRCYdkKcGeAG7LYrr+irW2eCbI2s5T1ZOSnOtZ4JospusKETkpuCYrsWw1qrpSRG4ExgXHjcKefrKVLrDf3dMa/PdUcq6MXC9gpIicEGy/T1XDOpfRWIurmcBG4PxsXq8q0nUDVjb+j+Dvq0Rt9NadgBeCbQ2AD4GfAh2ylK5hwKUiUgJswm6YCpSIyOXYE3QhdmP/aRavF9jD0huquiGyLW3XS1VLReQq4C2xE04AHgp2Xw08LSI3YbnrcOin6t6/yoeUqowPT+Kccy5l9aq1lXPOuezw4OGccy5lHjycc86lzIOHc865lHnwcM65HCcij4jIUhGZWs3jTxeRr0TkSxF5KiNp8tZWzjmX20TkEKyD4L9Udc/tHNsbGxjxcFVdJSIdVLW6Y8FVm+c8nHMux6nqe1i/jHIisquIvBaMkfW+iPQLdv0UuFeDgSwzETjAg4dzzuWrB4ERqrofcBXwj2B7H6CPiHwoNpDjMZn48PrQw9w553YowQCPBxIbUQJsaBGw+3pvbK6TrsB7IrKXqq5OZxo8eDjnXP4pwIZdH5Bk33xssq5twBwR+RoLJuOSHFurBDjnnMsjasO2zxGRHwKI6R/sfhHLdSAi7bBirNnpToMHD+ecy3EiMgr4GOgrIvNF5EJsXvkLRWQKNs3u0ODw14EVIvIVNj/6SFVdkfY0eVNd55xzqfKch3POuZR58HDOOZcyDx7OOedS5sHDOedcyjx4OOecS5kHD+eccynz4OGccy5l/w+iLmbwE6YaRAAAAABJRU5ErkJggg==\n",
      "text/plain": [
       "<Figure size 432x288 with 1 Axes>"
      ]
     },
     "metadata": {
      "needs_background": "light"
     },
     "output_type": "display_data"
    }
   ],
   "source": [
    "plt.plot(times.jd,d_ra-53.*u.mas,'b-',times.jd,d_dec,'r-')\n",
    "plt.ylim([-10,10])\n",
    "# plt.xlim([2459000,2459120])"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": []
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "Python 3",
   "language": "python",
   "name": "python3"
  },
  "language_info": {
   "codemirror_mode": {
    "name": "ipython",
    "version": 3
   },
   "file_extension": ".py",
   "mimetype": "text/x-python",
   "name": "python",
   "nbconvert_exporter": "python",
   "pygments_lexer": "ipython3",
   "version": "3.8.2"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 2
}

From adrianmpw at gmail.com  Sat May  9 14:12:50 2020
From: adrianmpw at gmail.com (Adrian Price-Whelan)
Date: Sat, 9 May 2020 14:12:50 -0400
Subject: [AstroPy] Effect of observer elevation on sunset time
In-Reply-To: <7B3DF8E3-FFAF-4AB4-A74E-AC7764B188B0@swarthmore.edu>
References: <7B3DF8E3-FFAF-4AB4-A74E-AC7764B188B0@swarthmore.edu>
Message-ID: <CAEUL7mF=DMrAwpiQCH9jp3jg-Lrg1QPDBwOGMUhW=n7722k0gQ@mail.gmail.com>

Hi Eric,

I'm not sure yet what the root of the problem is, but it doesn't seem to be
an astroplan issue - see the bottom of this notebook, which computes the
difference in Sun altitude for the two elevations with astropy's AltAz
frame (used internally by astroplan):
https://gist.github.com/628c6ffed4f652d2278e970981f67854

Erik T. might have more thoughts?

best,
Adrian

On Sat, May 9, 2020 at 11:31 AM Eric Jensen <ejensen1 at swarthmore.edu> wrote:

> Hi all,
>
> I was just working with astroplan to calculate some sunset times (actually
> nautical twilight in the example below), and I noticed that specifying the
> observatory elevation doesn?t seem to make any difference in the results,
> contrary to my expectations.
>
> Example code:
>
> from astropy.coordinates import EarthLocation
> import astroplan
> from astropy.time import Time
> import astropy.units as u
>
> location = EarthLocation.from_geodetic(-16.5097*u.deg,
>                                        28.3*u.deg,
>                                        2390*u.m)
> # Same location, but zero elevation
> location_sealevel = EarthLocation.from_geodetic(-16.5097*u.deg,
>                                                 28.3*u.deg,
>                                                 0*u.m)
> teide = astroplan.Observer(location=location,
>                            name="Teide",
>                            timezone="Atlantic/Canary")
> teide_sealevel = astroplan.Observer(location=location_sealevel,
>                                     name="Teide sea level",
>                                     timezone="Atlantic/Canary")
>
> now = Time.now()
> n = 1000
> sun_set = teide.sun_set_time(now, which="next",
>                              horizon=-12*u.deg,
>                              n_grid_points=n)
> sun_set_sealevel = teide_sealevel.sun_set_time(now, which="next",
>                                                horizon=-12*u.deg,
>                                                n_grid_points=n)
> print("Sunset at altitude:  {0.iso}, JD: {0.jd}".format(sun_set))
> print("Sunset at sea level: {0.iso}, JD: {0.jd}".format(sun_set_sealevel))
> print("Difference: {}".format((sun_set - sun_set_sealevel).to(u.s)))
>
> This yields the output:
>
> Sunset at altitude:  2020-05-09 20:41:33.933, JD: 2458979.3621982955
> Sunset at sea level: 2020-05-09 20:41:33.933, JD: 2458979.3621982983
> Difference: -0.00024139881134033203 s
>
>
> i.e. basically no difference.   There are three reasons I could think of:
>
> 1.  The effect of observer elevation simply isn?t implemented in
> astroplan.
> 2.  There?s something wrong with my code.
> 3.  There?s something wrong with my thinking that there should be a few
> minutes difference (later sunset / earlier sunrise) at a few thousand
> meters elevation vs. at sea level.
>
> My guess is #1, but I?m curious to hear if others have different
> thoughts.  I?m using astropy 4.0.1 and astroplan 0.6.
>
> Thanks,
>
> Eric
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Adrian M. Price-Whelan
Flatiron Institute, NYC
http://adrn.github.io
(he / him)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/d19f11c8/attachment.html>

From s.littlefair at sheffield.ac.uk  Sat May  9 14:24:53 2020
From: s.littlefair at sheffield.ac.uk (Stuart P Littlefair)
Date: Sat, 9 May 2020 19:24:53 +0100
Subject: [AstroPy] Effect of observer elevation on sunset time
In-Reply-To: <CAEUL7mF=DMrAwpiQCH9jp3jg-Lrg1QPDBwOGMUhW=n7722k0gQ@mail.gmail.com>
References: <CAEUL7mF=DMrAwpiQCH9jp3jg-Lrg1QPDBwOGMUhW=n7722k0gQ@mail.gmail.com>
Message-ID: <237BF5AE-FD98-4117-94F3-25A6CEFA02DE@sheffield.ac.uk>

I should probably think about this more before I embarrass myself but - isn?t this right? 

The sun is 93 million miles away so a tangential movement of a few thousand metres is going to make a negligible angular distance, no?

Is the apparent difference in sunset times at high altitudes more of a refraction effect?

Stuart Littlefair
Dept. of Physics & Astronomy
Univ. of Sheffield, Sheffield, S3 7RH

email: s.littlefair at shef.ac.uk
Phone: +44 114 2224525
Sent from my iPhone

> On 9 May 2020, at 19:13, Adrian Price-Whelan <adrianmpw at gmail.com> wrote:
> 
> ?
> Hi Eric,
> 
> I'm not sure yet what the root of the problem is, but it doesn't seem to be an astroplan issue - see the bottom of this notebook, which computes the difference in Sun altitude for the two elevations with astropy's AltAz frame (used internally by astroplan):
> https://gist.github.com/628c6ffed4f652d2278e970981f67854
> 
> Erik T. might have more thoughts?
> 
> best,
> Adrian
> 
>> On Sat, May 9, 2020 at 11:31 AM Eric Jensen <ejensen1 at swarthmore.edu> wrote:
>> Hi all, 
>> 
>> I was just working with astroplan to calculate some sunset times (actually nautical twilight in the example below), and I noticed that specifying the observatory elevation doesn?t seem to make any difference in the results, contrary to my expectations. 
>> 
>> Example code: 
>> 
>> from astropy.coordinates import EarthLocation
>> import astroplan
>> from astropy.time import Time
>> import astropy.units as u
>> 
>> location = EarthLocation.from_geodetic(-16.5097*u.deg, 
>>                                        28.3*u.deg, 
>>                                        2390*u.m)
>> # Same location, but zero elevation
>> location_sealevel = EarthLocation.from_geodetic(-16.5097*u.deg, 
>>                                                 28.3*u.deg, 
>>                                                 0*u.m)
>> teide = astroplan.Observer(location=location, 
>>                            name="Teide", 
>>                            timezone="Atlantic/Canary")
>> teide_sealevel = astroplan.Observer(location=location_sealevel, 
>>                                     name="Teide sea level", 
>>                                     timezone="Atlantic/Canary")
>> 
>> now = Time.now()
>> n = 1000
>> sun_set = teide.sun_set_time(now, which="next", 
>>                              horizon=-12*u.deg,
>>                              n_grid_points=n)
>> sun_set_sealevel = teide_sealevel.sun_set_time(now, which="next", 
>>                                                horizon=-12*u.deg,
>>                                                n_grid_points=n)
>> print("Sunset at altitude:  {0.iso}, JD: {0.jd}".format(sun_set))
>> print("Sunset at sea level: {0.iso}, JD: {0.jd}".format(sun_set_sealevel))
>> print("Difference: {}".format((sun_set - sun_set_sealevel).to(u.s)))
>> 
>> This yields the output:
>> 
>> Sunset at altitude:  2020-05-09 20:41:33.933, JD: 2458979.3621982955
>> Sunset at sea level: 2020-05-09 20:41:33.933, JD: 2458979.3621982983
>> Difference: -0.00024139881134033203 s
>> 
>> i.e. basically no difference.   There are three reasons I could think of: 
>> 
>> 1.  The effect of observer elevation simply isn?t implemented in astroplan. 
>> 2.  There?s something wrong with my code. 
>> 3.  There?s something wrong with my thinking that there should be a few minutes difference (later sunset / earlier sunrise) at a few thousand meters elevation vs. at sea level. 
>> 
>> My guess is #1, but I?m curious to hear if others have different thoughts.  I?m using astropy 4.0.1 and astroplan 0.6. 
>> 
>> Thanks, 
>> 
>> Eric
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
> 
> 
> -- 
> Adrian M. Price-Whelan
> Flatiron Institute, NYC
> http://adrn.github.io
> (he / him)
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/cdb53a85/attachment-0001.html>

From sergio.pasra at gmail.com  Sat May  9 14:41:04 2020
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Sat, 9 May 2020 20:41:04 +0200
Subject: [AstroPy] Effect of observer elevation on sunset time
In-Reply-To: <237BF5AE-FD98-4117-94F3-25A6CEFA02DE@sheffield.ac.uk>
References: <CAEUL7mF=DMrAwpiQCH9jp3jg-Lrg1QPDBwOGMUhW=n7722k0gQ@mail.gmail.com>
 <237BF5AE-FD98-4117-94F3-25A6CEFA02DE@sheffield.ac.uk>
Message-ID: <CACta-Kbr0mB69gUYCmmtkc0T7wdqQQPcEqeezvt9cJAF5esYOQ@mail.gmail.com>

Hello,

I don't have my copy of Green's Spherical Astronomy with me, but I remember
there is as section about the effect of height on topocentric coordinates,
and hence, in sun set  and rise times. The affect is about a few minutes,
depending on height and latitude.

Regards

El s?b., 9 may. 2020 a las 20:25, Stuart P Littlefair (<
s.littlefair at sheffield.ac.uk>) escribi?:

> I should probably think about this more before I embarrass myself but -
> isn?t this right?
>
> The sun is 93 million miles away so a tangential movement of a few
> thousand metres is going to make a negligible angular distance, no?
>
> Is the apparent difference in sunset times at high altitudes more of a
> refraction effect?
>
> Stuart Littlefair
> Dept. of Physics & Astronomy
> Univ. of Sheffield, Sheffield, S3 7RH
>
> email: s.littlefair at shef.ac.uk
> Phone: +44 114 2224525
> Sent from my iPhone
>
> On 9 May 2020, at 19:13, Adrian Price-Whelan <adrianmpw at gmail.com> wrote:
>
> ?
> Hi Eric,
>
> I'm not sure yet what the root of the problem is, but it doesn't seem to
> be an astroplan issue - see the bottom of this notebook, which computes the
> difference in Sun altitude for the two elevations with astropy's AltAz
> frame (used internally by astroplan):
> https://gist.github.com/628c6ffed4f652d2278e970981f67854
>
> Erik T. might have more thoughts?
>
> best,
> Adrian
>
> On Sat, May 9, 2020 at 11:31 AM Eric Jensen <ejensen1 at swarthmore.edu>
> wrote:
>
>> Hi all,
>>
>> I was just working with astroplan to calculate some sunset times
>> (actually nautical twilight in the example below), and I noticed that
>> specifying the observatory elevation doesn?t seem to make any difference in
>> the results, contrary to my expectations.
>>
>> Example code:
>>
>> from astropy.coordinates import EarthLocation
>> import astroplan
>> from astropy.time import Time
>> import astropy.units as u
>>
>> location = EarthLocation.from_geodetic(-16.5097*u.deg,
>>                                        28.3*u.deg,
>>                                        2390*u.m)
>> # Same location, but zero elevation
>> location_sealevel = EarthLocation.from_geodetic(-16.5097*u.deg,
>>                                                 28.3*u.deg,
>>                                                 0*u.m)
>> teide = astroplan.Observer(location=location,
>>                            name="Teide",
>>                            timezone="Atlantic/Canary")
>> teide_sealevel = astroplan.Observer(location=location_sealevel,
>>                                     name="Teide sea level",
>>                                     timezone="Atlantic/Canary")
>>
>> now = Time.now()
>> n = 1000
>> sun_set = teide.sun_set_time(now, which="next",
>>                              horizon=-12*u.deg,
>>                              n_grid_points=n)
>> sun_set_sealevel = teide_sealevel.sun_set_time(now, which="next",
>>                                                horizon=-12*u.deg,
>>                                                n_grid_points=n)
>> print("Sunset at altitude:  {0.iso}, JD: {0.jd}".format(sun_set))
>> print("Sunset at sea level: {0.iso}, JD: {0.jd}".format(sun_set_sealevel))
>> print("Difference: {}".format((sun_set - sun_set_sealevel).to(u.s)))
>>
>> This yields the output:
>>
>> Sunset at altitude:  2020-05-09 20:41:33.933, JD: 2458979.3621982955
>> Sunset at sea level: 2020-05-09 20:41:33.933, JD: 2458979.3621982983
>> Difference: -0.00024139881134033203 s
>>
>>
>> i.e. basically no difference.   There are three reasons I could think of:
>>
>> 1.  The effect of observer elevation simply isn?t implemented in
>> astroplan.
>> 2.  There?s something wrong with my code.
>> 3.  There?s something wrong with my thinking that there should be a few
>> minutes difference (later sunset / earlier sunrise) at a few thousand
>> meters elevation vs. at sea level.
>>
>> My guess is #1, but I?m curious to hear if others have different
>> thoughts.  I?m using astropy 4.0.1 and astroplan 0.6.
>>
>> Thanks,
>>
>> Eric
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>>
>
>
> --
> Adrian M. Price-Whelan
> Flatiron Institute, NYC
> http://adrn.github.io
> (he / him)
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/926dfdfe/attachment.html>

From wtylergee at gmail.com  Sat May  9 14:45:13 2020
From: wtylergee at gmail.com (Wilfred Tyler Gee)
Date: Sat, 9 May 2020 08:45:13 -1000
Subject: [AstroPy] Effect of observer elevation on sunset time
In-Reply-To: <CACta-Kbr0mB69gUYCmmtkc0T7wdqQQPcEqeezvt9cJAF5esYOQ@mail.gmail.com>
References: <CAEUL7mF=DMrAwpiQCH9jp3jg-Lrg1QPDBwOGMUhW=n7722k0gQ@mail.gmail.com>
 <237BF5AE-FD98-4117-94F3-25A6CEFA02DE@sheffield.ac.uk>
 <CACta-Kbr0mB69gUYCmmtkc0T7wdqQQPcEqeezvt9cJAF5esYOQ@mail.gmail.com>
Message-ID: <CAESfxSCSPiGc656gkd5w=38Ltik1AuqOkMTz1r=rHipxtCSYxA@mail.gmail.com>

Hi all,

This was discussed some back in
https://github.com/astropy/astroplan/issues/242

Eric, you might want to look at changing your pressure in addition to your
elevation.

On Sat, May 9, 2020 at 8:41 AM Sergio Pascual <sergio.pasra at gmail.com>
wrote:

> Hello,
>
> I don't have my copy of Green's Spherical Astronomy with me, but I
> remember there is as section about the effect of height on topocentric
> coordinates, and hence, in sun set  and rise times. The affect is about a
> few minutes, depending on height and latitude.
>
> Regards
>
> El s?b., 9 may. 2020 a las 20:25, Stuart P Littlefair (<
> s.littlefair at sheffield.ac.uk>) escribi?:
>
>> I should probably think about this more before I embarrass myself but -
>> isn?t this right?
>>
>> The sun is 93 million miles away so a tangential movement of a few
>> thousand metres is going to make a negligible angular distance, no?
>>
>> Is the apparent difference in sunset times at high altitudes more of a
>> refraction effect?
>>
>> Stuart Littlefair
>> Dept. of Physics & Astronomy
>> Univ. of Sheffield, Sheffield, S3 7RH
>>
>> email: s.littlefair at shef.ac.uk
>> Phone: +44 114 2224525
>> Sent from my iPhone
>>
>> On 9 May 2020, at 19:13, Adrian Price-Whelan <adrianmpw at gmail.com> wrote:
>>
>> ?
>> Hi Eric,
>>
>> I'm not sure yet what the root of the problem is, but it doesn't seem to
>> be an astroplan issue - see the bottom of this notebook, which computes the
>> difference in Sun altitude for the two elevations with astropy's AltAz
>> frame (used internally by astroplan):
>> https://gist.github.com/628c6ffed4f652d2278e970981f67854
>>
>> Erik T. might have more thoughts?
>>
>> best,
>> Adrian
>>
>> On Sat, May 9, 2020 at 11:31 AM Eric Jensen <ejensen1 at swarthmore.edu>
>> wrote:
>>
>>> Hi all,
>>>
>>> I was just working with astroplan to calculate some sunset times
>>> (actually nautical twilight in the example below), and I noticed that
>>> specifying the observatory elevation doesn?t seem to make any difference in
>>> the results, contrary to my expectations.
>>>
>>> Example code:
>>>
>>> from astropy.coordinates import EarthLocation
>>> import astroplan
>>> from astropy.time import Time
>>> import astropy.units as u
>>>
>>> location = EarthLocation.from_geodetic(-16.5097*u.deg,
>>>                                        28.3*u.deg,
>>>                                        2390*u.m)
>>> # Same location, but zero elevation
>>> location_sealevel = EarthLocation.from_geodetic(-16.5097*u.deg,
>>>                                                 28.3*u.deg,
>>>                                                 0*u.m)
>>> teide = astroplan.Observer(location=location,
>>>                            name="Teide",
>>>                            timezone="Atlantic/Canary")
>>> teide_sealevel = astroplan.Observer(location=location_sealevel,
>>>                                     name="Teide sea level",
>>>                                     timezone="Atlantic/Canary")
>>>
>>> now = Time.now()
>>> n = 1000
>>> sun_set = teide.sun_set_time(now, which="next",
>>>                              horizon=-12*u.deg,
>>>                              n_grid_points=n)
>>> sun_set_sealevel = teide_sealevel.sun_set_time(now, which="next",
>>>                                                horizon=-12*u.deg,
>>>                                                n_grid_points=n)
>>> print("Sunset at altitude:  {0.iso}, JD: {0.jd}".format(sun_set))
>>> print("Sunset at sea level: {0.iso}, JD:
>>> {0.jd}".format(sun_set_sealevel))
>>> print("Difference: {}".format((sun_set - sun_set_sealevel).to(u.s)))
>>>
>>> This yields the output:
>>>
>>> Sunset at altitude:  2020-05-09 20:41:33.933, JD: 2458979.3621982955
>>> Sunset at sea level: 2020-05-09 20:41:33.933, JD: 2458979.3621982983
>>> Difference: -0.00024139881134033203 s
>>>
>>>
>>> i.e. basically no difference.   There are three reasons I could think
>>> of:
>>>
>>> 1.  The effect of observer elevation simply isn?t implemented in
>>> astroplan.
>>> 2.  There?s something wrong with my code.
>>> 3.  There?s something wrong with my thinking that there should be a few
>>> minutes difference (later sunset / earlier sunrise) at a few thousand
>>> meters elevation vs. at sea level.
>>>
>>> My guess is #1, but I?m curious to hear if others have different
>>> thoughts.  I?m using astropy 4.0.1 and astroplan 0.6.
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org
>>> https://mail.python.org/mailman/listinfo/astropy
>>>
>>
>>
>> --
>> Adrian M. Price-Whelan
>> Flatiron Institute, NYC
>> http://adrn.github.io
>> (he / him)
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
~Wilfred Tyler Gee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/bc962626/attachment-0001.html>

From ejensen1 at swarthmore.edu  Sat May  9 18:31:32 2020
From: ejensen1 at swarthmore.edu (Eric Jensen)
Date: Sat, 9 May 2020 18:31:32 -0400
Subject: [AstroPy] Effect of observer elevation on sunset time
In-Reply-To: <CAESfxSCSPiGc656gkd5w=38Ltik1AuqOkMTz1r=rHipxtCSYxA@mail.gmail.com>
References: <CAEUL7mF=DMrAwpiQCH9jp3jg-Lrg1QPDBwOGMUhW=n7722k0gQ@mail.gmail.com>
 <237BF5AE-FD98-4117-94F3-25A6CEFA02DE@sheffield.ac.uk>
 <CACta-Kbr0mB69gUYCmmtkc0T7wdqQQPcEqeezvt9cJAF5esYOQ@mail.gmail.com>
 <CAESfxSCSPiGc656gkd5w=38Ltik1AuqOkMTz1r=rHipxtCSYxA@mail.gmail.com>
Message-ID: <C122EAF1-A7FD-476D-AFF0-05BCDCD342D8@swarthmore.edu>

Hi all, 

Thanks for everyone?s comments.  To be clear, I?m not talking about refraction effects, but rather about the position of the ?true horizon? due to the curvature of the Earth.  It?s the same effect as when you look up in the sky after sunset and see a cloud or an airplane directly overhead (so at the same geodetic latitude and longitude that you are) that is still lit by the sun.  Something higher up can see to a more distant horizon than something at sea level.  

I had noticed the github issue that Wilfred mentioned (thanks!), but I hadn?t read it carefully enough - now I see that it does indeed discuss this, though the person raising the issue ultimately gets around it by calculating the correction for the true horizon himself, and applying that correction by using the true horizon?s elevation (-2 degrees relative to the uncorrected horizon) to find the true time of sunset. 

So it?s clear that that correction isn?t applied.  So I guess my question now is, why not?  It seems more practical to me, at least for the sun, since it?s the elevation relative to the true horizon that determines how dark it is. 

I could see this being added as an option to sun_set_time (and I can look into making a PR if others think it?s useful), but I?d still be interested in hearing any thoughts about why it isn?t the default behavior.  Is the altitude in the alt-az coordinate system formally defined as being that for an observer at zero elevation?  

Thanks again, 

Eric


> On May 9, 2020, at 2:45 PM, Wilfred Tyler Gee <wtylergee at gmail.com> wrote:
> 
> Hi all,
> 
> This was discussed some back in https://github.com/astropy/astroplan/issues/242 <https://github.com/astropy/astroplan/issues/242>
> 
> Eric, you might want to look at changing your pressure in addition to your elevation.
> 
> On Sat, May 9, 2020 at 8:41 AM Sergio Pascual <sergio.pasra at gmail.com <mailto:sergio.pasra at gmail.com>> wrote:
> Hello,
> 
> I don't have my copy of Green's Spherical Astronomy with me, but I remember there is as section about the effect of height on topocentric coordinates, and hence, in sun set  and rise times. The affect is about a few minutes, depending on height and latitude.
> 
> Regards
> 
> El s?b., 9 may. 2020 a las 20:25, Stuart P Littlefair (<s.littlefair at sheffield.ac.uk <mailto:s.littlefair at sheffield.ac.uk>>) escribi?:
> I should probably think about this more before I embarrass myself but - isn?t this right? 
> 
> The sun is 93 million miles away so a tangential movement of a few thousand metres is going to make a negligible angular distance, no?
> 
> Is the apparent difference in sunset times at high altitudes more of a refraction effect?
> 
> Stuart Littlefair
> Dept. of Physics & Astronomy
> Univ. of Sheffield, Sheffield, S3 7RH
> 
> email: s.littlefair at shef.ac.uk <mailto:s.littlefair at shef.ac.uk>
> Phone: +44 114 2224525
> Sent from my iPhone
> 
>> On 9 May 2020, at 19:13, Adrian Price-Whelan <adrianmpw at gmail.com <mailto:adrianmpw at gmail.com>> wrote:
>> 
>> ?
>> Hi Eric,
>> 
>> I'm not sure yet what the root of the problem is, but it doesn't seem to be an astroplan issue - see the bottom of this notebook, which computes the difference in Sun altitude for the two elevations with astropy's AltAz frame (used internally by astroplan):
>> https://gist.github.com/628c6ffed4f652d2278e970981f67854 <https://gist.github.com/628c6ffed4f652d2278e970981f67854>
>> 
>> Erik T. might have more thoughts?
>> 
>> best,
>> Adrian
>> 
>> On Sat, May 9, 2020 at 11:31 AM Eric Jensen <ejensen1 at swarthmore.edu <mailto:ejensen1 at swarthmore.edu>> wrote:
>> Hi all, 
>> 
>> I was just working with astroplan to calculate some sunset times (actually nautical twilight in the example below), and I noticed that specifying the observatory elevation doesn?t seem to make any difference in the results, contrary to my expectations. 
>> 
>> Example code: 
>> 
>> from astropy.coordinates import EarthLocation
>> import astroplan
>> from astropy.time import Time
>> import astropy.units as u
>> 
>> location = EarthLocation.from_geodetic(-16.5097*u.deg, 
>>                                        28.3*u.deg, 
>>                                        2390*u.m)
>> # Same location, but zero elevation
>> location_sealevel = EarthLocation.from_geodetic(-16.5097*u.deg, 
>>                                                 28.3*u.deg, 
>>                                                 0*u.m)
>> teide = astroplan.Observer(location=location, 
>>                            name="Teide", 
>>                            timezone="Atlantic/Canary")
>> teide_sealevel = astroplan.Observer(location=location_sealevel, 
>>                                     name="Teide sea level", 
>>                                     timezone="Atlantic/Canary")
>> 
>> now = Time.now()
>> n = 1000
>> sun_set = teide.sun_set_time(now, which="next", 
>>                              horizon=-12*u.deg,
>>                              n_grid_points=n)
>> sun_set_sealevel = teide_sealevel.sun_set_time(now, which="next", 
>>                                                horizon=-12*u.deg,
>>                                                n_grid_points=n)
>> print("Sunset at altitude:  {0.iso}, JD: {0.jd}".format(sun_set))
>> print("Sunset at sea level: {0.iso}, JD: {0.jd}".format(sun_set_sealevel))
>> print("Difference: {}".format((sun_set - sun_set_sealevel).to(u.s)))
>> 
>> This yields the output:
>> 
>> Sunset at altitude:  2020-05-09 20:41:33.933, JD: 2458979.3621982955
>> Sunset at sea level: 2020-05-09 20:41:33.933, JD: 2458979.3621982983
>> Difference: -0.00024139881134033203 s
>> 
>> i.e. basically no difference.   There are three reasons I could think of: 
>> 
>> 1.  The effect of observer elevation simply isn?t implemented in astroplan. 
>> 2.  There?s something wrong with my code. 
>> 3.  There?s something wrong with my thinking that there should be a few minutes difference (later sunset / earlier sunrise) at a few thousand meters elevation vs. at sea level. 
>> 
>> My guess is #1, but I?m curious to hear if others have different thoughts.  I?m using astropy 4.0.1 and astroplan 0.6. 
>> 
>> Thanks, 
>> 
>> Eric
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org <mailto:AstroPy at python.org>
>> https://mail.python.org/mailman/listinfo/astropy <https://mail.python.org/mailman/listinfo/astropy>
>> 
>> 
>> -- 
>> Adrian M. Price-Whelan
>> Flatiron Institute, NYC
>> http://adrn.github.io <http://adrn.github.io/>
>> (he / him)
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org <mailto:AstroPy at python.org>
>> https://mail.python.org/mailman/listinfo/astropy <https://mail.python.org/mailman/listinfo/astropy>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org <mailto:AstroPy at python.org>
> https://mail.python.org/mailman/listinfo/astropy <https://mail.python.org/mailman/listinfo/astropy>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org <mailto:AstroPy at python.org>
> https://mail.python.org/mailman/listinfo/astropy <https://mail.python.org/mailman/listinfo/astropy>
> 
> 
> -- 
> ~Wilfred Tyler Gee
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/99fa41aa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3946 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/99fa41aa/attachment-0001.bin>

From brewer at astro.umass.edu  Sat May  9 19:31:13 2020
From: brewer at astro.umass.edu (Michael Brewer)
Date: Sat, 9 May 2020 19:31:13 -0400
Subject: [AstroPy] consistency of reference frames between SkyCoord and
 JPL Horizons
In-Reply-To: <a5efb6c9-474d-40a4-d74d-9775743c3e78@oca.eu>
References: <mailman.25.1587744003.21454.astropy@python.org>
 <CAAKCKFGNeTwa27x0zfzH9oSNDvC45sU0vSuL-0=e0tnAyLUuSg@mail.gmail.com>
 <17418b6b-8206-0aee-7a0d-95911be364f1@oca.eu>
 <22CE4992-8000-4540-9E3E-9923EBC785C9@swarthmore.edu>
 <f0a53f4e-9c15-a88f-bfa5-5632d5af5491@oca.eu>
 <3c42b8fc-8b42-e692-e45b-b360aca3f510@astro.umass.edu>
 <f663f629-73ba-33d9-6b76-9a45896de097@oca.eu>
 <9c8a6657-3c7f-6593-2043-5f8210b70857@astro.umass.edu>
 <44ea2f2e-0ad1-2f01-0aaa-094db91d5a8c@oca.eu>
 <a5efb6c9-474d-40a4-d74d-9775743c3e78@oca.eu>
Message-ID: <49833c31-8c25-3cc9-44b1-9d3e6bab195c@astro.umass.edu>

Paolo,

  The current version of Astropy treats all target bodies as if they are 
at infinite distance for the gravitational deflection of light.

  The issue with going forward in time is likely due to inaccurate EOP 
predictions.

   Best,

     Michael Brewer

On 05/09/2020 11:27 AM, Paolo Tanga wrote:
>
> A couple more intriguing (troublesome?) elements.
>
> - I repeated the exercise with distant TNOs (e.g. Quaoar), and it 
> appears that the amplitude of the spikes in RA,Dec difference, 
> decreases with the object distance (in agreement with an origin 
> related to light deflection discrepancy for stars vs. nearby targets).
>
> - I realized (strikingly visible for Quaoar and Eris) that there is an 
> epoch at which the behavior of the secondary fluctuations changes 
> dramatically. Starting from my origin (April 9, 2020) and going back 
> in time by ~1000 days, basically only the spikes remain, and the 
> agreement is at ~mas level (-53 mas in RA). Forward in time, around 
> end of July, the curve starts to show suddenly the fluctuations, with 
> some added short-period variations.
>
> In the attachment, the python notebook showing these phenomena....
>
> The origin of this, for the moment, is mysterious to me.
>
> Paolo
>
> On 09/05/2020 10:00, Paolo Tanga wrote:
>>
>> Hi Michael
>>
>> yes, I figured out time was required. Concerning distance, it was a 
>> bug in my script, making confusion with a previous test in the same 
>> Jupyter notebook..... Sorry for that. Of course now it works perfectly!
>>
>> Thank you also for the topocentric example. The whole procedure looks 
>> now robust!
>>
>>> The positions are off a bit more than I'd like to see,
>> Intrigued by this, I reworked my example (asteroid Apollonia) to 
>> perform the computation of the "apparent position in true 
>> coordinates" over 1000 days, interval of 1 day.
>>
>> I then plotted the difference wrt JPL in RA*cos(Dec) (blue, after 
>> substraction of 53 mas) and Dec (red). The result looks instructive 
>> and non-trivial:
>>
>>
>> The spikes correspond to the minimum solar elongations (I plotted it 
>> to compare), which may point out to the "wrong" computation of light 
>> deflection for a finite-distance object. But the other fluctuations 
>> away from conjunction are still significant and harder to understand. 
>> RA have those secondary peaks at 7-8 mas far from conjunction that 
>> are puzzling (and nearly absent in Dec!)...
>>
>> regards
>>
>> Paolo
>>
>> On 08/05/2020 23:55, Michael Brewer wrote:
>>> Hi Paolo,
>>>
>>>   I forgot about time.  You need to tell the GCRS frame the time of 
>>> the observation. But you must have figured that out as you got good 
>>> agreement in position, so the error in distance is odd. I tried an 
>>> example with the following script:
>>>
>>> from astropy.time import Time
>>> from astropy.coordinates import get_body_barycentric, SkyCoord, GCRS
>>> from astropy.coordinates.solar_system import 
>>> _apparent_position_in_true_coordinates
>>> import astropy.units as u
>>>
>>> #Mars Geocentric JPL 2020-May-07 00:00:00     328.364842462 
>>> -14.682567251 328.634953692 -14.587885357 1.18472191315873
>>>
>>> my_time        = Time('2020-05-07T00:00:00')
>>> my_astrometric = SkyCoord( 328.364842462*u.deg, -14.682567251*u.deg, 
>>> 1.18472191315873*u.au )
>>> my_apparent    = SkyCoord( 328.634953692*u.deg, -14.587885357*u.deg, 
>>> 1.18472191315873*u.au )
>>>
>>> print ('JPL ICRS', my_astrometric)
>>>
>>> my_object_ICRS = SkyCoord( my_astrometric.cartesian + 
>>> get_body_barycentric('earth', my_time) )
>>>
>>> print ('ICRS', my_object_ICRS)
>>>
>>> my_object_apparent = _apparent_position_in_true_coordinates( 
>>> my_object_ICRS.transform_to(GCRS(obstime=my_time)))
>>>
>>> print ('apparent', my_object_apparent)
>>>
>>> print ('delta ra', (my_object_apparent.ra - my_apparent.ra).to(u.mas),
>>>        'delta dec', (my_object_apparent.dec - 
>>> my_apparent.dec).to(u.mas),
>>>        'delta distance', (my_object_apparent.distance - 
>>> my_apparent.distance).to(u.meter) )
>>>
>>> And got this result:
>>>
>>> JPL ICRS <SkyCoord (ICRS): (ra, dec, distance) in (deg, deg, AU)
>>>     (328.36484246, -14.68256725, 1.18472191)>
>>> ICRS <SkyCoord (ICRS): (ra, dec, distance) in (deg, deg, AU)
>>>     (282.36772087, -24.4176493, 1.42516501)>
>>> apparent <SkyCoord (GCRS: obstime=2020-05-07T00:00:00.000, 
>>> obsgeoloc=(0., 0., 0.) m, obsgeovel=(0., 0., 0.) m / s): (ra, dec, 
>>> distance) in (deg, deg, AU)
>>>     (328.63496745, -14.58788562, 1.18472191)>
>>> delta ra 49.5348mas delta dec -0.964467mas delta distance 
>>> -6.643480019441483e-05 m
>>>
>>> The positions are off a bit more than I'd like to see, but the 
>>> distance is right on.
>>>
>>> By the way, thanks to an example from Stuart Littlefair, I figured 
>>> out how to do this using topocentric coordinates also. This is just 
>>> a matter of setting up an EarthLocation my_loc and then doing:
>>>
>>> earth_loc = get_body_barycentric('earth', my_time)
>>> obsgeoloc, obsgeovel = my_loc.get_gcrs_posvel(my_time)
>>> earth_loc += obsgeoloc
>>>
>>> before adding earth_loc to your topocentric astrometric coordinates 
>>> from Horizons and then you also need to tell the GCRS frame your 
>>> location and velocity:
>>>
>>> my_object_apparent = _apparent_position_in_true_coordinates( 
>>> my_object_ICRS.transform_to(
>>>                       GCRS(obsgeoloc=obsgeoloc, obsgeovel=obsgeovel, 
>>> obstime=my_time)))
>>>
>>>
>>>    Regards,
>>>
>>>       Michael Brewer
>>>
>>>
>>> On 05/07/2020 09:59 AM, Paolo Tanga wrote:
>>>>
>>>> Hi Micheal
>>>>
>>>> I did the test following your instructions and I correctly found 
>>>> the result that you indicate: 52.5 mas of discrepancty in RA, and 
>>>> negligible in Dec (0.01 mas).
>>>>
>>>> However, I notice something strange. At the first step:
>>>>
>>>> my_object_ICRS = SkyCoord( SkyCoord( JPL geocentric astrometric 
>>>> coordinates ).cartesian + get_body_barycentric('earth', my_time) )
>>>>
>>>> I give as "JPL geocentric astrometric coordinates" ra, dec and 
>>>> distance. I chose first the geocentric distance (delta, in my case 
>>>> 2.0958388  au).
>>>>
>>>> Then I get
>>>>
>>>> my_object_ICRS.distance = 3.816102 au.
>>>>
>>>> Formally, this may be correct, as this is the result of the 
>>>> addition of barycenter-to-Earth vector. But then, even if I am now 
>>>> in geocentric ICRS, it does not represent the geocentric distance.
>>>>
>>>> At the end of the process, after transformation to GCRS and then to 
>>>> apparent coordinates (by _apparent_position_in_true_coordinates) I 
>>>> find:
>>>>
>>>> my_object_apparent.distance = 2.962877... au, which is off the JPL 
>>>> value for delta given above by ~0.9 au.
>>>>
>>>> If at the beginning I give 'r' (heliocentric distance = 2.95757466, 
>>>> instead of 'delta'), I still get:
>>>>
>>>> my_object_ICRS.distance = 3.810857 but now my_object_apparent.distance
>>>>
>>>> but then:
>>>>
>>>> my_object_apparent.distance =2.957567
>>>>
>>>> which is much closer to the geocentric distance.... So, whatever 
>>>> the choice, it looks like the distance goes completely wrong and 
>>>> there is no way to obtain the correct value directly from the 
>>>> transformations. As ra and dec are correct, the only solution seems 
>>>> to apply a correction to the distance at the end of the computation.
>>>>
>>>> Is this behavior consistent with what you would expect ?
>>>>
>>>> best regards
>>>>
>>>> Paolo
>>>>
>>>>
>>>>
>>>>
>>>> On 01/05/2020 23:20, Michael Brewer wrote:
>>>>> Paolo,
>>>>>
>>>>> I can tell you how to do this. First query JPL Horizons for your 
>>>>> target body setting the observer location to the Earth's 
>>>>> geocenter. This will return the astrometric position of the target 
>>>>> body in the ICRF frame referred to the Earth's geocenter including 
>>>>> the proper light time offset. Now you want these coordinates as an 
>>>>> astropy SkyCoord object in astropy's ICRS frame. The problem here 
>>>>> is that astropy always refers ICRS coordinates to the solar system 
>>>>> barycenter. This will require you to add the solar system 
>>>>> barycentric position of the Earth's geocenter. The way to do this 
>>>>> is: First create a SkyCoord object using the coordinates that you 
>>>>> got from your query, call get_body_barycentric() to get the 
>>>>> Earth's position and then add these two together to get a proper 
>>>>> astropy SkyCoord object. This looks like this:
>>>>>
>>>>> from astropy.coordinates.solar_system import get_body_barycentric
>>>>> my_object_ICRS = SkyCoord( SkyCoord( JPL geocentric astrometric 
>>>>> coordinates ).cartesian + get_body_barycentric('earth', my_time) )
>>>>>
>>>>> Now if you want to compare the result with JPL Horizons apparent 
>>>>> place, you need to realize that JPL's apparent place is referenced 
>>>>> to the true equator and equinox of date whereas astropy's CIRS 
>>>>> frame is referenced to the Celestial Intermediate Origin. 
>>>>> Fortunately, there is a function that converts GCRS coordinates to 
>>>>> true apparent place:
>>>>>
>>>>> from astropy.coordinates.solar_system import 
>>>>> _apparent_position_in_true_coordinates
>>>>> my_object_apparent = _apparent_position_in_true_coordinates( 
>>>>> my_object_ICRS.transform_to('gcrs') )
>>>>>
>>>>> The result should compare to JPL Horizons to 53 mas in RA. This 53 
>>>>> mas is a rather mysterious offset that I pointed out to the JPL 
>>>>> Horizons people awhile ago. It took me awhile to convince them of 
>>>>> this, but I'm happy to see that they have now accepted it and are 
>>>>> making a note of it in their output files. There will be some 
>>>>> small residual offsets due to the fact that JPL Horizons uses a 
>>>>> slightly different set of earth orientation parameters than those 
>>>>> used by astropy, but these are usually less than 1 mas.
>>>>>
>>>>> I have raised an issue in this regard on github (Issue #10230) 
>>>>> requesting two new built-in frames for converting to geocentric or 
>>>>> topocentric astrometric place and true apparent place. If these 
>>>>> ever get implemented, this process will become a lot easier.
>>>>>
>>>>>    Best Regards,
>>>>>
>>>>>     Michael Brewer
>>>>>
>>>>>
>>>>>
>>>>> On 05/01/2020 04:01 AM, Paolo Tanga wrote:
>>>>>>
>>>>>> Hi Eric
>>>>>>
>>>>>> thank you for your other comments. Some answers below.y
>>>>>>
>>>>>> On 01/05/2020 05:09, Eric Jensen wrote:
>>>>>>> Like Ben, I?m a little unclear on exactly what you are trying to 
>>>>>>> achieve beyond what you?ve demonstrated already.  (I have 
>>>>>>> learned from your example!)  You have shown that Horizons 
>>>>>>> provides astrometric coordinates that are ICRS, and that these 
>>>>>>> are straightforward to insert into a SkyCoord object as you show 
>>>>>>> in your example.
>>>>>>
>>>>>> my whole point here is that this works *only* when you query 
>>>>>> Horizons for astrometric coordinates with an observer at "@0" (= 
>>>>>> the Solar System barycenter), and this is not explicitly 
>>>>>> explained in the documentation. My other point is that I am not 
>>>>>> so expert in all features in astropy, so I wanted to have a 
>>>>>> confirmation (which essentially I got, I think). Eventually, 
>>>>>> somebody could be able to define a "custom" frame that works for 
>>>>>> all output returned by Horizons.
>>>>>>
>>>>>>>
>>>>>>> If for some reason you want to use the apparent coordinates 
>>>>>>> instead, then you need to put them into a SkyCoord frame that 
>>>>>>> precesses, which as I understand it is what the 
>>>>>>> PrecessedGeocentric frame is for.  So with a slight modification 
>>>>>>> of your example, you can do this:
>>>>>>>
>>>>>>> (...)Doing this, I get coordinates that differ by about 13 
>>>>>>> arcsec (mostly in RA) from the GCRS coords you create in the 
>>>>>>> first part of your example using the ICRS coords at the 
>>>>>>> barycenter.  I don?t know what the source of that difference is, 
>>>>>>> but perhaps some of the various GR corrections.
>>>>>>
>>>>>> Thank you for this additional example, but in my view this shows 
>>>>>> that even in this approach you do not get consistent results. 13 
>>>>>> arcsec are a huge discrepancy, not for most amateur use, but for 
>>>>>> today's standard. In fact, probably the effect is due to annual 
>>>>>> aberration (most of it) and light bending (a few mas). But what 
>>>>>> is the interest of including relativistic corrections in astropy, 
>>>>>> if then you cannot get an agreement at ~mas level, at least? For 
>>>>>> professional use in the Gaia era, this is a requirement.
>>>>>>
>>>>>>> There are indeed subtleties in converting between various 
>>>>>>> coordinates systems, as you note, but I would say that those 
>>>>>>> subtleties are inherent to the topic in general, not to the 
>>>>>>> astropy software in particular.
>>>>>> True! And the whole topic is complex. But astropy already does a 
>>>>>> great service to the user, by providing out of the box, accurate 
>>>>>> transformations with all the bells and whistles. So, providing 
>>>>>> information on how to use (at full accuracy!) astroquery.horizons 
>>>>>> (or new reference frames to improve consistency!) I think goes in 
>>>>>> the same direction. By the way, note that the issues in the other 
>>>>>> mail thread by Michael Brewer also partially addresses the same 
>>>>>> problem.
>>>>>>> That said, examples are quite helpful, so I?d encourage you to 
>>>>>>> submit an example based on your work here for inclusion on the 
>>>>>>> examples page at 
>>>>>>> https://docs.astropy.org/en/stable/generated/examples/ .
>>>>>>
>>>>>> I will certainly do, including warnings about how NOT to use the 
>>>>>> Horizons output with SkyCoords... ;-) ...!
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Paolo
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 29, 2020, at 11:23 AM, Paolo Tanga <Paolo.Tanga at oca.eu 
>>>>>>>> <mailto:Paolo.Tanga at oca.eu>> wrote:
>>>>>>>>
>>>>>>>> Hi Ben
>>>>>>>>
>>>>>>>> thank you for taking your time to look into this question, and 
>>>>>>>> sorry for the delay.
>>>>>>>>
>>>>>>>> I would say, all that I am trying to do is to use the 
>>>>>>>> astroquery output in a SkyCoord object coherently. If one 
>>>>>>>> manages to do that, than it is possible to take profit of all 
>>>>>>>> the SkyCoord methods of course, to manipulate the coordinates 
>>>>>>>> (transform_to ) etc.
>>>>>>>>
>>>>>>>> As the SkyCoord is a fundamental part of the astropy suite, I 
>>>>>>>> would expect that there should be a "easy" method (or at least, 
>>>>>>>> a documented one!) to pass from an astroquery/JPL result to 
>>>>>>>> SkyCoord. But it turns out that this is not the case.
>>>>>>>>
>>>>>>>> So, what we have learned so far, if I am correct, is that:
>>>>>>>>
>>>>>>>> - JPL apparent coordinates. Precession - you are totally right 
>>>>>>>> - creates the difference between GCRS and the JPL apparent 
>>>>>>>> coordinates. In the documentation I would explicitly write that 
>>>>>>>> these cannot easily be used in a SkyCoord frame. In fact I 
>>>>>>>> tried playing with different reference frames (including 
>>>>>>>> GeocentricTrueEquator etc) but I see the same inconsistencies 
>>>>>>>> as with GCRS. So, I suppose that if there is a method, it is 
>>>>>>>> not straightforward (at least, not for me).
>>>>>>>>
>>>>>>>> - JPL astrometric coordinates. If computed with the observer at 
>>>>>>>> the barycenter of the Solar System, they can fit a SkyCoord 
>>>>>>>> object in ICRS. And this is the only possibility.
>>>>>>>>
>>>>>>>> I think that there could be other subtleties to check, but 
>>>>>>>> don't you think that this should be documented somewhere?
>>>>>>>>
>>>>>>>> Note that in the case of the ephemeris of the major planets 
>>>>>>>> (get_body()...) a SkyCoord object is directly returned, which 
>>>>>>>> is very convenient.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> Paolo
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25/04/2020 10:43, Benjamin Weiner wrote:
>>>>>>>>> Hello Paolo,
>>>>>>>>>
>>>>>>>>> I am not entirely sure what end result you wish to achieve, 
>>>>>>>>> nor am I an expert on SkyCoord.  However, I have a 
>>>>>>>>> suggestion to understand further these discrepancies (and 
>>>>>>>>> thank you for including the notebook example). In your first 
>>>>>>>>> example:
>>>>>>>>> (a) JPL's barycentric coords to build ICRS at specified time, 
>>>>>>>>> then transformed to GCRS at specified time.
>>>>>>>>> (b) JPL's apparent coords to build GCRS at specified time.
>>>>>>>>>
>>>>>>>>> The separation of 16 arcmin between (a) and (b) is due to the 
>>>>>>>>> precession of the Earth's axis from 2000 to 2020. This can be 
>>>>>>>>> seen if we substitute
>>>>>>>>>  time = Time('2000-01-01T00:00:00', scale='utc')
>>>>>>>>> in the line of your notebook that sets the time. At 
>>>>>>>>> 2000-01-01, the separation reduces to 8 arcseconds, which you 
>>>>>>>>> have identified as coming from the aberration of starlight.
>>>>>>>>>
>>>>>>>>> I think that the discrepancy is in building the GCRS 
>>>>>>>>> coordinates from the apparent RA/Dec.  The JPL apparent 
>>>>>>>>> coordinates are referenced to the position of the Earth's axis 
>>>>>>>>> at the specified time. But the axes of GCRS are non-rotating 
>>>>>>>>> with respect to the axes of BCRS and ICRS - that is, GCRS is 
>>>>>>>>> fixed to the Earth's center, but not to the Earth's axis, and 
>>>>>>>>> does not precess. I believe that this is correct - USNO 
>>>>>>>>> circular 179 has more gory details on the definition of 
>>>>>>>>> coordinate frames, see
>>>>>>>>> https://www.usno.navy.mil/USNO/astronomical-applications/publications/Circular_179.pdf
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ben
>>>>>>>>>
>>>>>>>>> On Fri, Apr 24, 2020 at 9:01 AM <astropy-request at python.org 
>>>>>>>>> <mailto:astropy-request at python.org>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Message: 1
>>>>>>>>>     Date: Fri, 24 Apr 2020 15:00:22 +0200
>>>>>>>>>     From: Paolo Tanga <Paolo.Tanga at oca.eu
>>>>>>>>>     <mailto:Paolo.Tanga at oca.eu>>
>>>>>>>>>     To: AstroPy at python.org <mailto:AstroPy at python.org>
>>>>>>>>>     Subject: [AstroPy] consistency of reference frames between
>>>>>>>>>     SkyCoord
>>>>>>>>>             and JPL Horizons
>>>>>>>>>     Message-ID: <b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu
>>>>>>>>>     <mailto:b18102bb-0e8c-8b85-4e66-8de7aecab2e4 at oca.eu>>
>>>>>>>>>     Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>>>>>>>
>>>>>>>>>     Hi all
>>>>>>>>>
>>>>>>>>>     I am trying to plug the results by JPL Horizons into the
>>>>>>>>>     appropriate
>>>>>>>>>     reference system of a SkyCoord object, but it looks very
>>>>>>>>>     trick. (bewore
>>>>>>>>>     long message, I hope the explanation is clear for the
>>>>>>>>>     specialists of
>>>>>>>>>     reference systems)
>>>>>>>>>
>>>>>>>>>     The Horizons server returns two types of equatorial
>>>>>>>>>     coordinates:
>>>>>>>>>     "astrometric" (1) and (2) "apparent".
>>>>>>>>>
>>>>>>>>>     Their description is the following:
>>>>>>>>>
>>>>>>>>>     - (1): astrometric RA and Dec with respect to the
>>>>>>>>>     observing site
>>>>>>>>>     (coordinate origin) in the reference frame of
>>>>>>>>>     the planetary ephemeris (ICRF). Compensated for down-leg
>>>>>>>>>     light-time
>>>>>>>>>     delay aberration.
>>>>>>>>>
>>>>>>>>>     - (2): Airless apparent RA and Dec of the target with
>>>>>>>>>     respect to an
>>>>>>>>>     instantaneous reference frame defined by the Earth equator
>>>>>>>>>     of-date
>>>>>>>>>     (z-axis) and meridian containing the Earth equinox of-date
>>>>>>>>>     (x-axis,
>>>>>>>>>     IAU76/80). Compensated for down-leg light-time delay,
>>>>>>>>>     gravitational
>>>>>>>>>     deflection of light, stellar aberration, precession &
>>>>>>>>>     nutation. Note:
>>>>>>>>>     equinox (RA origin) is offset -53 mas from the of-date
>>>>>>>>>     frame defined by
>>>>>>>>>     the IAU06/00a P & N system.
>>>>>>>>>
>>>>>>>>>     My guess is none of these two systems correspond to either
>>>>>>>>>     ICRS or GCRS
>>>>>>>>>     as defined in astropy. The simplest possibility for me,
>>>>>>>>>     would have been
>>>>>>>>>     to assimilate (1), computed for the Solar System
>>>>>>>>>     barycenter, to ICRS.
>>>>>>>>>     But definitely (2) is not GCRS and the test below easily
>>>>>>>>>     proves that.
>>>>>>>>>
>>>>>>>>>     Verification (see the attached notebook if you want to
>>>>>>>>>     play with) :
>>>>>>>>>
>>>>>>>>>     - I queried for Solar System barycentric coordinates (1)
>>>>>>>>>     of an asteroid
>>>>>>>>>     at one epoch. I inserted them in a SkyCoord object as ICRS
>>>>>>>>>     and use the
>>>>>>>>>     transform_to(GCRS) towards geocentric, at the given epoch.
>>>>>>>>>
>>>>>>>>>     - I queried again JPL Horizons for the apparent
>>>>>>>>>     coordinates (2) from the
>>>>>>>>>     geocenter, directly.
>>>>>>>>>
>>>>>>>>>     As expected, by comparing the results I get the patent
>>>>>>>>>     confirmation that
>>>>>>>>>     GCRS is not the frame of (2), with a discrepancy of 16
>>>>>>>>>     arcmin in my
>>>>>>>>>     case. SO, IT DOES NOT WORK, AS EXPECTED. Let's put
>>>>>>>>>     apparent coordinates
>>>>>>>>>     (2) aside for the moment.
>>>>>>>>>
>>>>>>>>>     Second possibility (see notebook again).
>>>>>>>>>
>>>>>>>>>     I take coordinates (1), for the geocentric observer. I
>>>>>>>>>     insert them as
>>>>>>>>>     GCRS in a SkyCoord object. I trasform_to(ICRS)
>>>>>>>>>     (barycentric observer)
>>>>>>>>>     and compare the result to a query of (1) directly for the
>>>>>>>>>     barycentric
>>>>>>>>>     observer.
>>>>>>>>>
>>>>>>>>>     Again this SHOULD NOT WORK accurately. In fact the
>>>>>>>>>     definition of (1)
>>>>>>>>>     does not contain annual aberration and light deflection
>>>>>>>>>     that are part of
>>>>>>>>>     GCRS. A difference of several arcsec (mostly due to annual
>>>>>>>>>     aberration)
>>>>>>>>>     SHOULD show up. And in fact IT DOES, ~8 arcsec of difference.
>>>>>>>>>
>>>>>>>>>     The conclusions if that using SkyCoord with the output of
>>>>>>>>>     JPL Horizons
>>>>>>>>>     is far from obvious to the end user...
>>>>>>>>>
>>>>>>>>>     ----
>>>>>>>>>
>>>>>>>>>     So, my final questions/remarks are:
>>>>>>>>>
>>>>>>>>>     - How to get a fully accurate consistency between a
>>>>>>>>>     SkyCoord frame and
>>>>>>>>>     JPL Horizons output, in the case of a barycentric,
>>>>>>>>>     geocentric or
>>>>>>>>>     topocentric observer, for both "astrometric" and
>>>>>>>>>     "apparent" coordinates
>>>>>>>>>     as provided by JPL? Which reference SkyCoord should use
>>>>>>>>>     and how?
>>>>>>>>>
>>>>>>>>>     - Does astropy implement GCRS correctly in the case of
>>>>>>>>>     Solar System
>>>>>>>>>     objects, by taking into account aberration and light
>>>>>>>>>     deflection in the
>>>>>>>>>     relativistic form, for an object at finite distance
>>>>>>>>>     (different than for
>>>>>>>>>     the stars!) ?
>>>>>>>>>
>>>>>>>>>     - ...or... Am I missing something fundamental in my
>>>>>>>>>     interpretation?
>>>>>>>>>
>>>>>>>>>     - Eventually, this query to Horizons turns our to be
>>>>>>>>>     tricky to manage as
>>>>>>>>>     SkyCoord for the final user. I think it would be useful to
>>>>>>>>>     provide the
>>>>>>>>>     correct recipe and/or directly a SkyCoord as output of the
>>>>>>>>>     query...
>>>>>>>>>
>>>>>>>>>     Best regards
>>>>>>>>>
>>>>>>>>>     Paolo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Benjamin Weiner
>>>>>>>>> Staff Scientist / Associate Astronomer, MMT / Steward Observatory
>>>>>>>>> bjw at as.arizona.edu <mailto:bjw at as.arizona.edu>
>>>>>>>>> http://mingus.mmto.arizona.edu/~bjw/ 
>>>>>>>>> <http://mingus.as.arizona.edu/%7Ebjw/>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> AstroPy mailing list
>>>>>>>>> AstroPy at python.org
>>>>>>>>> https://mail.python.org/mailman/listinfo/astropy
>>>>>>>> -- 
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> Paolo Tanga                              Astronomer
>>>>>>>> Deputy director of Laboratoire Langrange / UMR 7293
>>>>>>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>>>>>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>>>>>>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>>>>>>>                                           https://twitter.com/ziggypao
>>>>>>>> _______________________________________________
>>>>>>>> AstroPy mailing list
>>>>>>>> AstroPy at python.org <mailto:AstroPy at python.org>
>>>>>>>> https://mail.python.org/mailman/listinfo/astropy
>>>>>>>
>>>>>> -- 
>>>>>> ---------------------------------------------------------------------
>>>>>> Paolo Tanga                              Astronomer
>>>>>> Deputy director of Laboratoire Langrange / UMR 7293
>>>>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>>>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>>>>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>>>>>                                           https://twitter.com/ziggypao
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> AstroPy mailing list
>>>>>> AstroPy at python.org
>>>>>> https://mail.python.org/mailman/listinfo/astropy
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> AstroPy mailing list
>>>>> AstroPy at python.org
>>>>> https://mail.python.org/mailman/listinfo/astropy
>>>> -- 
>>>> ---------------------------------------------------------------------
>>>> Paolo Tanga                              Astronomer
>>>> Deputy director of Laboratoire Langrange / UMR 7293
>>>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>>>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>>>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>>>                                           https://twitter.com/ziggypao
>>>>
>>>>
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at python.org
>>>> https://mail.python.org/mailman/listinfo/astropy
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org
>>> https://mail.python.org/mailman/listinfo/astropy
>> -- 
>> ---------------------------------------------------------------------
>> Paolo Tanga                              Astronomer
>> Deputy director of Laboratoire Langrange / UMR 7293
>> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
>> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
>> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>>                                           https://twitter.com/ziggypao
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
> -- 
> ---------------------------------------------------------------------
> Paolo Tanga                              Astronomer
> Deputy director of Laboratoire Langrange / UMR 7293
> Observatoire de la C?te d'Azur           Tel  +33(0)492003042
> Bv de l'Observatoire - CS 34229          Fax  +33(0)492003121
> 06304 Nice Cedex 4 - Francehttp://www.oca.eu/tanga
>                                           https://twitter.com/ziggypao
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200509/893dc78d/attachment-0001.html>

From s.littlefair at sheffield.ac.uk  Mon May 11 04:57:35 2020
From: s.littlefair at sheffield.ac.uk (Stuart P Littlefair)
Date: Mon, 11 May 2020 09:57:35 +0100
Subject: [AstroPy] Effect of observer elevation on sunset time
In-Reply-To: <C122EAF1-A7FD-476D-AFF0-05BCDCD342D8@swarthmore.edu>
References: <CAEUL7mF=DMrAwpiQCH9jp3jg-Lrg1QPDBwOGMUhW=n7722k0gQ@mail.gmail.com>
 <237BF5AE-FD98-4117-94F3-25A6CEFA02DE@sheffield.ac.uk>
 <CACta-Kbr0mB69gUYCmmtkc0T7wdqQQPcEqeezvt9cJAF5esYOQ@mail.gmail.com>
 <CAESfxSCSPiGc656gkd5w=38Ltik1AuqOkMTz1r=rHipxtCSYxA@mail.gmail.com>
 <C122EAF1-A7FD-476D-AFF0-05BCDCD342D8@swarthmore.edu>
Message-ID: <CAOrDc-_v5OawO5R7Q=kMM-M2od_LC4Nme6i1nyApGwZ=BT6fFg@mail.gmail.com>

Hi Eric,

The alt-az system reflects where a perfect theodolite would point to see
the source, so there isn't a concept of an apparent horizon in the alt-az
coordinate system.

A general correction for apparent horizon doesn't make much sense either,
since increased altitude does not necessarily lead to a lower apparent
horizon compared to a sea-level observer (for example, in mountain ranges).

But it does make a lot of sense in the context of most astronomical
observatories, so I'd think a keyword argument to astroplan's sun_set_time
would be a useful addition. Something like:

sun_set = teide.sun_set_time(now, which="next", horizon=-12*u.deg,
use_apparent_horizon=True)

On Sat, 9 May 2020 at 23:32, Eric Jensen <ejensen1 at swarthmore.edu> wrote:

> Hi all,
>
> Thanks for everyone?s comments.  To be clear, I?m not talking about
> refraction effects, but rather about the position of the ?true horizon? due
> to the curvature of the Earth.  It?s the same effect as when you look up in
> the sky after sunset and see a cloud or an airplane directly overhead (so
> at the same geodetic latitude and longitude that you are) that is still lit
> by the sun.  Something higher up can see to a more distant horizon than
> something at sea level.
>
> I had noticed the github issue that Wilfred mentioned (thanks!), but I
> hadn?t read it carefully enough - now I see that it does indeed discuss
> this, though the person raising the issue ultimately gets around it by
> calculating the correction for the true horizon himself, and applying that
> correction by using the true horizon?s elevation (-2 degrees relative to
> the uncorrected horizon) to find the true time of sunset.
>
> So it?s clear that that correction isn?t applied.  So I guess my question
> now is, why not?  It seems more practical to me, at least for the sun,
> since it?s the elevation relative to the true horizon that determines how
> dark it is.
>
> I could see this being added as an option to sun_set_time (and I can look
> into making a PR if others think it?s useful), but I?d still be interested
> in hearing any thoughts about why it isn?t the default behavior.  Is the
> altitude in the alt-az coordinate system formally defined as being that for
> an observer at zero elevation?
>
> Thanks again,
>
> Eric
>
>
> On May 9, 2020, at 2:45 PM, Wilfred Tyler Gee <wtylergee at gmail.com> wrote:
>
> Hi all,
>
> This was discussed some back in
> https://github.com/astropy/astroplan/issues/242
>
> Eric, you might want to look at changing your pressure in addition to your
> elevation.
>
> On Sat, May 9, 2020 at 8:41 AM Sergio Pascual <sergio.pasra at gmail.com>
> wrote:
>
>> Hello,
>>
>> I don't have my copy of Green's Spherical Astronomy with me, but I
>> remember there is as section about the effect of height on topocentric
>> coordinates, and hence, in sun set  and rise times. The affect is about a
>> few minutes, depending on height and latitude.
>>
>> Regards
>>
>> El s?b., 9 may. 2020 a las 20:25, Stuart P Littlefair (<
>> s.littlefair at sheffield.ac.uk>) escribi?:
>>
>>> I should probably think about this more before I embarrass myself but -
>>> isn?t this right?
>>>
>>> The sun is 93 million miles away so a tangential movement of a few
>>> thousand metres is going to make a negligible angular distance, no?
>>>
>>> Is the apparent difference in sunset times at high altitudes more of a
>>> refraction effect?
>>>
>>> Stuart Littlefair
>>> Dept. of Physics & Astronomy
>>> Univ. of Sheffield, Sheffield, S3 7RH
>>>
>>> email: s.littlefair at shef.ac.uk
>>> Phone: +44 114 2224525
>>> Sent from my iPhone
>>>
>>> On 9 May 2020, at 19:13, Adrian Price-Whelan <adrianmpw at gmail.com>
>>> wrote:
>>>
>>> ?
>>> Hi Eric,
>>>
>>> I'm not sure yet what the root of the problem is, but it doesn't seem to
>>> be an astroplan issue - see the bottom of this notebook, which computes the
>>> difference in Sun altitude for the two elevations with astropy's AltAz
>>> frame (used internally by astroplan):
>>> https://gist.github.com/628c6ffed4f652d2278e970981f67854
>>>
>>> Erik T. might have more thoughts?
>>>
>>> best,
>>> Adrian
>>>
>>> On Sat, May 9, 2020 at 11:31 AM Eric Jensen <ejensen1 at swarthmore.edu>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I was just working with astroplan to calculate some sunset times
>>>> (actually nautical twilight in the example below), and I noticed that
>>>> specifying the observatory elevation doesn?t seem to make any difference in
>>>> the results, contrary to my expectations.
>>>>
>>>> Example code:
>>>>
>>>> from astropy.coordinates import EarthLocation
>>>> import astroplan
>>>> from astropy.time import Time
>>>> import astropy.units as u
>>>>
>>>> location = EarthLocation.from_geodetic(-16.5097*u.deg,
>>>>                                        28.3*u.deg,
>>>>                                        2390*u.m)
>>>> # Same location, but zero elevation
>>>> location_sealevel = EarthLocation.from_geodetic(-16.5097*u.deg,
>>>>                                                 28.3*u.deg,
>>>>                                                 0*u.m)
>>>> teide = astroplan.Observer(location=location,
>>>>                            name="Teide",
>>>>                            timezone="Atlantic/Canary")
>>>> teide_sealevel = astroplan.Observer(location=location_sealevel,
>>>>                                     name="Teide sea level",
>>>>                                     timezone="Atlantic/Canary")
>>>>
>>>> now = Time.now()
>>>> n = 1000
>>>> sun_set = teide.sun_set_time(now, which="next",
>>>>                              horizon=-12*u.deg,
>>>>                              n_grid_points=n)
>>>> sun_set_sealevel = teide_sealevel.sun_set_time(now, which="next",
>>>>                                                horizon=-12*u.deg,
>>>>                                                n_grid_points=n)
>>>> print("Sunset at altitude:  {0.iso}, JD: {0.jd}".format(sun_set))
>>>> print("Sunset at sea level: {0.iso}, JD:
>>>> {0.jd}".format(sun_set_sealevel))
>>>> print("Difference: {}".format((sun_set - sun_set_sealevel).to(u.s)))
>>>>
>>>> This yields the output:
>>>>
>>>> Sunset at altitude:  2020-05-09 20:41:33.933, JD: 2458979.3621982955
>>>> Sunset at sea level: 2020-05-09 20:41:33.933, JD: 2458979.3621982983
>>>> Difference: -0.00024139881134033203 s
>>>>
>>>>
>>>> i.e. basically no difference.   There are three reasons I could think
>>>> of:
>>>>
>>>> 1.  The effect of observer elevation simply isn?t implemented in
>>>> astroplan.
>>>> 2.  There?s something wrong with my code.
>>>> 3.  There?s something wrong with my thinking that there should be a few
>>>> minutes difference (later sunset / earlier sunrise) at a few thousand
>>>> meters elevation vs. at sea level.
>>>>
>>>> My guess is #1, but I?m curious to hear if others have different
>>>> thoughts.  I?m using astropy 4.0.1 and astroplan 0.6.
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at python.org
>>>> https://mail.python.org/mailman/listinfo/astropy
>>>>
>>>
>>>
>>> --
>>> Adrian M. Price-Whelan
>>> Flatiron Institute, NYC
>>> http://adrn.github.io
>>> (he / him)
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org
>>> https://mail.python.org/mailman/listinfo/astropy
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org
>>> https://mail.python.org/mailman/listinfo/astropy
>>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>>
>
>
> --
> ~Wilfred Tyler Gee
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Stuart Littlefair

-------------------------------------------------------

*I don't expect you to respond to my email outside your working hours. *

*At the University of Sheffield we value and encourage flexible working
patterns, so please be assured that I respect your working pattern and I am
looking forward to your response when you are next working. *

-------------------------------------------------------

Dept. of Physics & Astronomy,
Univ. of Sheffield, Sheffield, S3 7RH.

email: S.Littlefair at sheffield.ac.uk
phone: +44 114 2224525
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200511/889717a5/attachment-0001.html>

From dianasco at astro.uni-bonn.de  Tue May 12 04:49:48 2020
From: dianasco at astro.uni-bonn.de (Diana Scognamiglio)
Date: Tue, 12 May 2020 10:49:48 +0200
Subject: [AstroPy] Fwd: Info LevMarLSQFitter
Message-ID: <ximss-926673@be2.uni-bonn.de>

An embedded message was scrubbed...
From: "Diana Scognamiglio" <dianasco at astro.uni-bonn.de>
Subject: Info LevMarLSQFitter 
Date: Mon, 11 May 2020 20:14:45 +0200
Size: 3065
URL: <http://mail.python.org/pipermail/astropy/attachments/20200512/27d470e6/attachment.mht>

From dianasco at astro.uni-bonn.de  Tue May 12 04:53:01 2020
From: dianasco at astro.uni-bonn.de (Diana Scognamiglio)
Date: Tue, 12 May 2020 10:53:01 +0200
Subject: [AstroPy] Info LevMarLSQFitter
Message-ID: <ximss-926745@be2.uni-bonn.de>

Dear Astropy Staff,
I am Diana Scognamiglio and I have some problems to deep understand how 
LevMarLSQFitter works.

  I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter classe, 
coding these lines:


ini_mod = EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n, 
x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)fitter = 
fitting.LevMarLSQFitter()fit_mod = fitter(ini_mod, x_array, y_array, stamp, 
weights=weights, maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6, 
estimate_jacobian=False)
I have figured out that if I change the initial parameters in ini_mod (i.e., 
ini_flux, ini_r_eff, etc), I counterintuitively obtain always a different 
result although the galaxy I am fitting is the same. How does the fit depend 
on those initial parameters?
Please, can you help me with this issue?
Thank you in advance.
I wait for hearing from you.
Best regards,
Diana Scognamiglio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200512/8853f646/attachment.html>

From jvmirca at gmail.com  Tue May 12 05:17:59 2020
From: jvmirca at gmail.com (=?UTF-8?B?WsOpIFZpbsOtY2l1cw==?=)
Date: Tue, 12 May 2020 17:17:59 +0800
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <ximss-926745@be2.uni-bonn.de>
References: <ximss-926745@be2.uni-bonn.de>
Message-ID: <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>

Hi Diana,

>From my understanding, LevMarLSQFitter uses the least-squares function as
the objective to be minimized using the Levenberg-Marquardt algorithm.

Because Sersic2D is a non-linear model on the parameters to be fitted, the
problem is most likely non-convex, which means that Levenberg-Marquardt
only guarantees to find a local solution, which will depend on the initial
value for those parameters.

Best,
Z?

On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <
dianasco at astro.uni-bonn.de> wrote:

> Dear Astropy Staff,
>
> I am Diana Scognamiglio and I have some problems to deep understand how
> LevMarLSQFitter works.
>
> I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter classe,
> coding these lines:
>
>
>
>
>
> ini_mod =
> EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n, x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
>
> fitter = fitting.LevMarLSQFitter()
>
> fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights, maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
> estimate_jacobian=False)
>
>
>
> I have figured out that if I change the initial parameters in ini_mod
> (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a
> different result although the galaxy I am fitting is the same. How does the
> fit depend on those initial parameters?
>
> Please, can you help me with this issue?
>
> Thank you in advance.
>
> I wait for hearing from you.
>
> Best regards,
>
> Diana Scognamiglio
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Z? Vin?cius
https://mirca.github.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200512/56690037/attachment.html>

From pdzwig at summaventures.com  Tue May 12 08:16:32 2020
From: pdzwig at summaventures.com (Peter Dzwig)
Date: Tue, 12 May 2020 13:16:32 +0100
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
References: <ximss-926745@be2.uni-bonn.de>
 <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
Message-ID: <7dd9896c-ae85-036f-367f-3e6f55d07550@summaventures.com>

Diana,

How much are you varying the parameters in ini? Are you varying them by
only a very small amount or by a substantial amount.

I was going to suggest that you might be finding local minima in the
solution when I read Z?'s comments.

Do you consistently get the same results if you repeat the run with
identical values? I am trying to understand whether your issue is: (a)
the algorithm itself; (b) sensitivity to initial conditions; or (c) some
issue with your code.

Peter Dzwig

On 12/05/2020 10:17, Z? Vin?cius wrote:
> Hi Diana,
> 
> From my understanding, LevMarLSQFitter uses the least-squares function
> as the objective to be minimized using the Levenberg-Marquardt algorithm.
> 
> Because?Sersic2D is a non-linear model on the parameters to be fitted,
> the problem is most likely non-convex, which means that
> Levenberg-Marquardt only guarantees to find a local solution, which will
> depend on the initial value for those parameters.
> 
> Best,
> Z?
> 
> On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio
> <dianasco at astro.uni-bonn.de <mailto:dianasco at astro.uni-bonn.de>> wrote:
> 
>     __
> 
>     Dear Astropy Staff,
> 
>     I am Diana Scognamiglio and I have some problems to deep understand
>     how LevMarLSQFitter works.
> 
>     I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter
>     classe, coding these lines:
> 
>     ?
> 
>     ?
> 
>     ini_mod =
>     EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n, x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
> 
>     fitter = fitting.LevMarLSQFitter()
> 
>     fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights, maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
>     estimate_jacobian=False)  
> 
>     ?
> 
>     I have figured out that if I change the initial parameters in
>     ini_mod (i.e., ini_flux, ini_r_eff, etc), I counterintuitively
>     obtain always a different result although the galaxy I am fitting is
>     the same. How does the fit depend on those initial parameters?
> 
>     Please, can you help me with this issue?
> 
>     Thank you in advance.
> 
>     I wait for hearing from you.
> 
>     Best regards,
> 
>     Diana Scognamiglio
> 
>     ?
> 
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at python.org <mailto:AstroPy at python.org>
>     https://mail.python.org/mailman/listinfo/astropy
> 
> 
> 
> -- 
> Z? Vin?cius
> https://mirca.github.io
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
> 

-- 

Dr. Peter Dzwig

From peter.erwin at gmail.com  Tue May 12 08:36:11 2020
From: peter.erwin at gmail.com (Peter Erwin)
Date: Tue, 12 May 2020 14:36:11 +0200
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
References: <ximss-926745@be2.uni-bonn.de>
 <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
Message-ID: <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>

Hi Z?,

As an aside, the fact that the Sersic2D model is nonlinear in its parameters is formally
irrelevant, since Levernberg-Marquardt is by design a *non-linear least-squares* algorithm.
(Levenberg?s original 1944 paper describing the algorithm was titled "A Method for the Solution 
of Certain Non-Linear Problems in Least Squares?.)

In practice, I find that Levenberg-Marquardt *usually* finds the global minimum
in galaxy image-fitting problems (e.g., I get the same solution when running Imfit
with Levenberg-Marquardt or with the Differential Evolution algorithm, which
doesn?t use initial values), though there *are* cases where L-M does get trapped in
local minima. (The fact that Diana says she ?always? gets a different result for 
different starting parameters maybe suggests something else is the problem.)


Diana ? have you tried using an alternate fitting algorithm, such as the SimplexLSQFitter
class? (Simplex fitters tend to be less likely to be trapped by local minima than
Levenberg-Marquardt, though they?re usually significantly slower.)


cheers,

Peter [Erwin]

> On May 12, 2020, at 11:17 AM, Z? Vin?cius <jvmirca at gmail.com> wrote:
> 
> Hi Diana,
> 
> From my understanding, LevMarLSQFitter uses the least-squares function as the objective to be minimized using the Levenberg-Marquardt algorithm.
> 
> Because Sersic2D is a non-linear model on the parameters to be fitted, the problem is most likely non-convex, which means that Levenberg-Marquardt only guarantees to find a local solution, which will depend on the initial value for those parameters.
> 
> Best,
> Z?
> 
> On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <dianasco at astro.uni-bonn.de> wrote:
> Dear Astropy Staff,
> 
> I am Diana Scognamiglio and I have some problems to deep understand how LevMarLSQFitter works.
> 
> I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter classe, coding these lines:
> 
>  
>  
> ini_mod =
> EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n, x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
> 
> fitter = fitting.LevMarLSQFitter()
> 
> fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights, maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
> estimate_jacobian=False)  
> 
>  
> I have figured out that if I change the initial parameters in ini_mod (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a different result although the galaxy I am fitting is the same. How does the fit depend on those initial parameters?
> 
> Please, can you help me with this issue?
> 
> Thank you in advance.
> 
> I wait for hearing from you.
> 
> Best regards,
> 
> Diana Scognamiglio
> 
>  
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
> 
> 
> -- 
> Z? Vin?cius
> https://mirca.github.io
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

=============================================================
Peter Erwin                   Max-Planck-Insitute for Extraterrestrial 
erwin at mpe.mpg.de              Physics, Giessenbachstrasse
tel. +49 (0)176 2481 7713     85748 Garching, Germany
fax  +49 (0)89 30000 3495     https://www.mpe.mpg.de/~erwin





From pebarrett at gmail.com  Wed May 13 10:41:22 2020
From: pebarrett at gmail.com (Paul Barrett)
Date: Wed, 13 May 2020 10:41:22 -0400
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
References: <ximss-926745@be2.uni-bonn.de>
 <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
 <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
Message-ID: <CAOqsD12c1XCWC-S+7u5AZiJ4S3=PqO042+yghkkcqrVy3+dj3A@mail.gmail.com>

Personally, I would suggest ditching the Levenberg-Marquardt and Simplex
algorithms and using an interior point method, which is more versatile and
robust in finding the global minimum. Interior point methods more easily
handle constraints and provide better convergence information. cvxopt is a
nice Python package for second order problems, which appears to be your
problem. However, if your problem is nonconvex, i.e., has local minima,
then you might want to consider using a branch-and-bound algorithm, which
will find the global minimum, although the algorithm is not as efficient.
The algorithm also works with integer parameters, which are inherently
nonconvex.

Cheers,
Paul



On Tue, May 12, 2020 at 8:36 AM Peter Erwin <peter.erwin at gmail.com> wrote:

> Hi Z?,
>
> As an aside, the fact that the Sersic2D model is nonlinear in its
> parameters is formally
> irrelevant, since Levernberg-Marquardt is by design a *non-linear
> least-squares* algorithm.
> (Levenberg?s original 1944 paper describing the algorithm was titled "A
> Method for the Solution
> of Certain Non-Linear Problems in Least Squares?.)
>
> In practice, I find that Levenberg-Marquardt *usually* finds the global
> minimum
> in galaxy image-fitting problems (e.g., I get the same solution when
> running Imfit
> with Levenberg-Marquardt or with the Differential Evolution algorithm,
> which
> doesn?t use initial values), though there *are* cases where L-M does get
> trapped in
> local minima. (The fact that Diana says she ?always? gets a different
> result for
> different starting parameters maybe suggests something else is the
> problem.)
>
>
> Diana ? have you tried using an alternate fitting algorithm, such as the
> SimplexLSQFitter
> class? (Simplex fitters tend to be less likely to be trapped by local
> minima than
> Levenberg-Marquardt, though they?re usually significantly slower.)
>
>
> cheers,
>
> Peter [Erwin]
>
> > On May 12, 2020, at 11:17 AM, Z? Vin?cius <jvmirca at gmail.com> wrote:
> >
> > Hi Diana,
> >
> > From my understanding, LevMarLSQFitter uses the least-squares function
> as the objective to be minimized using the Levenberg-Marquardt algorithm.
> >
> > Because Sersic2D is a non-linear model on the parameters to be fitted,
> the problem is most likely non-convex, which means that Levenberg-Marquardt
> only guarantees to find a local solution, which will depend on the initial
> value for those parameters.
> >
> > Best,
> > Z?
> >
> > On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <
> dianasco at astro.uni-bonn.de> wrote:
> > Dear Astropy Staff,
> >
> > I am Diana Scognamiglio and I have some problems to deep understand how
> LevMarLSQFitter works.
> >
> > I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter
> classe, coding these lines:
> >
> >
> >
> > ini_mod =
> > EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n,
> x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
> >
> > fitter = fitting.LevMarLSQFitter()
> >
> > fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights,
> maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
> > estimate_jacobian=False)
> >
> >
> > I have figured out that if I change the initial parameters in ini_mod
> (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a
> different result although the galaxy I am fitting is the same. How does the
> fit depend on those initial parameters?
> >
> > Please, can you help me with this issue?
> >
> > Thank you in advance.
> >
> > I wait for hearing from you.
> >
> > Best regards,
> >
> > Diana Scognamiglio
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
> >
> >
> > --
> > Z? Vin?cius
> > https://mirca.github.io
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
>
> =============================================================
> Peter Erwin                   Max-Planck-Insitute for Extraterrestrial
> erwin at mpe.mpg.de              Physics, Giessenbachstrasse
> tel. +49 (0)176 2481 7713     85748 Garching, Germany
> fax  +49 (0)89 30000 3495     https://www.mpe.mpg.de/~erwin
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200513/13a63594/attachment.html>

From jvmirca at gmail.com  Wed May 13 12:59:09 2020
From: jvmirca at gmail.com (=?UTF-8?B?WsOpIFZpbsOtY2l1cw==?=)
Date: Thu, 14 May 2020 00:59:09 +0800
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <CAOqsD12c1XCWC-S+7u5AZiJ4S3=PqO042+yghkkcqrVy3+dj3A@mail.gmail.com>
References: <ximss-926745@be2.uni-bonn.de>
 <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
 <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
 <CAOqsD12c1XCWC-S+7u5AZiJ4S3=PqO042+yghkkcqrVy3+dj3A@mail.gmail.com>
Message-ID: <CAB6kXFyycjVgsxhSf7wHxdGgA=8Bg-jJuL7GeZ4BgYAboW2wWQ@mail.gmail.com>

Hi Peter,

As an aside, the fact that the Sersic2D model is nonlinear in its
> parameters is formally
> irrelevant, since Levernberg-Marquardt is by design a *non-linear
> least-squares* algorithm.
> (Levenberg?s original 1944 paper describing the algorithm was titled "A
> Method for the Solution
> of Certain Non-Linear Problems in Least Squares?.)


The thing is that if the model were linear in its parameters, then the
problem would be convex, and LM would find the global unique optimum
no matter the initial point. But if that were the case, I'd advise other
methods to get that solution.

Best,
Z?

On Wed, May 13, 2020 at 10:42 PM Paul Barrett <pebarrett at gmail.com> wrote:

> Personally, I would suggest ditching the Levenberg-Marquardt and Simplex
> algorithms and using an interior point method, which is more versatile and
> robust in finding the global minimum. Interior point methods more easily
> handle constraints and provide better convergence information. cvxopt is a
> nice Python package for second order problems, which appears to be your
> problem. However, if your problem is nonconvex, i.e., has local minima,
> then you might want to consider using a branch-and-bound algorithm, which
> will find the global minimum, although the algorithm is not as efficient.
> The algorithm also works with integer parameters, which are inherently
> nonconvex.
>
> Cheers,
> Paul
>
>
>
> On Tue, May 12, 2020 at 8:36 AM Peter Erwin <peter.erwin at gmail.com> wrote:
>
>> Hi Z?,
>>
>> As an aside, the fact that the Sersic2D model is nonlinear in its
>> parameters is formally
>> irrelevant, since Levernberg-Marquardt is by design a *non-linear
>> least-squares* algorithm.
>> (Levenberg?s original 1944 paper describing the algorithm was titled "A
>> Method for the Solution
>> of Certain Non-Linear Problems in Least Squares?.)
>>
>> In practice, I find that Levenberg-Marquardt *usually* finds the global
>> minimum
>> in galaxy image-fitting problems (e.g., I get the same solution when
>> running Imfit
>> with Levenberg-Marquardt or with the Differential Evolution algorithm,
>> which
>> doesn?t use initial values), though there *are* cases where L-M does get
>> trapped in
>> local minima. (The fact that Diana says she ?always? gets a different
>> result for
>> different starting parameters maybe suggests something else is the
>> problem.)
>>
>>
>> Diana ? have you tried using an alternate fitting algorithm, such as the
>> SimplexLSQFitter
>> class? (Simplex fitters tend to be less likely to be trapped by local
>> minima than
>> Levenberg-Marquardt, though they?re usually significantly slower.)
>>
>>
>> cheers,
>>
>> Peter [Erwin]
>>
>> > On May 12, 2020, at 11:17 AM, Z? Vin?cius <jvmirca at gmail.com> wrote:
>> >
>> > Hi Diana,
>> >
>> > From my understanding, LevMarLSQFitter uses the least-squares function
>> as the objective to be minimized using the Levenberg-Marquardt algorithm.
>> >
>> > Because Sersic2D is a non-linear model on the parameters to be fitted,
>> the problem is most likely non-convex, which means that Levenberg-Marquardt
>> only guarantees to find a local solution, which will depend on the initial
>> value for those parameters.
>> >
>> > Best,
>> > Z?
>> >
>> > On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <
>> dianasco at astro.uni-bonn.de> wrote:
>> > Dear Astropy Staff,
>> >
>> > I am Diana Scognamiglio and I have some problems to deep understand how
>> LevMarLSQFitter works.
>> >
>> > I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter
>> classe, coding these lines:
>> >
>> >
>> >
>> > ini_mod =
>> > EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n,
>> x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
>> >
>> > fitter = fitting.LevMarLSQFitter()
>> >
>> > fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights,
>> maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
>> > estimate_jacobian=False)
>> >
>> >
>> > I have figured out that if I change the initial parameters in ini_mod
>> (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a
>> different result although the galaxy I am fitting is the same. How does the
>> fit depend on those initial parameters?
>> >
>> > Please, can you help me with this issue?
>> >
>> > Thank you in advance.
>> >
>> > I wait for hearing from you.
>> >
>> > Best regards,
>> >
>> > Diana Scognamiglio
>> >
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at python.org
>> > https://mail.python.org/mailman/listinfo/astropy
>> >
>> >
>> > --
>> > Z? Vin?cius
>> > https://mirca.github.io
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at python.org
>> > https://mail.python.org/mailman/listinfo/astropy
>>
>> =============================================================
>> Peter Erwin                   Max-Planck-Insitute for Extraterrestrial
>> erwin at mpe.mpg.de              Physics, Giessenbachstrasse
>> tel. +49 (0)176 2481 7713     85748 Garching, Germany
>> fax  +49 (0)89 30000 3495     https://www.mpe.mpg.de/~erwin
>>
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Z? Vin?cius
https://mirca.github.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200514/bf7b2bc0/attachment.html>

From peter.erwin at gmail.com  Wed May 13 16:10:31 2020
From: peter.erwin at gmail.com (Peter Erwin)
Date: Wed, 13 May 2020 22:10:31 +0200
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <CAB6kXFyycjVgsxhSf7wHxdGgA=8Bg-jJuL7GeZ4BgYAboW2wWQ@mail.gmail.com>
References: <ximss-926745@be2.uni-bonn.de>
 <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
 <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
 <CAOqsD12c1XCWC-S+7u5AZiJ4S3=PqO042+yghkkcqrVy3+dj3A@mail.gmail.com>
 <CAB6kXFyycjVgsxhSf7wHxdGgA=8Bg-jJuL7GeZ4BgYAboW2wWQ@mail.gmail.com>
Message-ID: <D55CA790-5BFF-4C45-A802-603A4FE1A511@gmail.com>

Hi Z?,

If the model is linear in its parameters, then it?s a linear least-squares problem and
you can find the best estimator directly (e.g., via matrix inversion or orthogonal
decomposition), without needing something like Levenberg-Marquardt.

https://en.wikipedia.org/wiki/Linear_least_squares


The fact that the galaxy-fitting problem *can* be (but is not guaranteed to be)
non-convex does not mean gradient-descent methods like L-M are *useless*;
it depends on what the actual fit-statistic (e.g., chi^2) landscape is like.

The primary justification for something like L-M is that it is *fast*. My experience
with fitting galaxy images is that it is about an order of magnitude faster than
the simplex and about *two* orders of magnitude faster than Differential
Evolution, which is considered relatively fast for a genetic-algorithms approach.
If the L-M fit converges in less than a second, then you don?t lose much with a
slower but more robust algorithm. But if the L-M fit takes an hour to converge,
then waiting ten or a hundred hours for convergence with another algorithm
may be a bit of a problem. (Or if you want to fit several tens of thousands of
different images?)


cheers,

Peter


> On May 13, 2020, at 6:59 PM, Z? Vin?cius <jvmirca at gmail.com> wrote:
> 
> Hi Peter,
> 
> As an aside, the fact that the Sersic2D model is nonlinear in its parameters is formally
> irrelevant, since Levernberg-Marquardt is by design a *non-linear least-squares* algorithm.
> (Levenberg?s original 1944 paper describing the algorithm was titled "A Method for the Solution 
> of Certain Non-Linear Problems in Least Squares?.)
> 
> The thing is that if the model were linear in its parameters, then the problem would be convex, and LM would find the global unique optimum
> no matter the initial point. But if that were the case, I'd advise other methods to get that solution.
> 
> Best,
> Z?
> 
> On Wed, May 13, 2020 at 10:42 PM Paul Barrett <pebarrett at gmail.com> wrote:
> Personally, I would suggest ditching the Levenberg-Marquardt and Simplex algorithms and using an interior point method, which is more versatile and robust in finding the global minimum. Interior point methods more easily handle constraints and provide better convergence information. cvxopt is a nice Python package for second order problems, which appears to be your problem. However, if your problem is nonconvex, i.e., has local minima, then you might want to consider using a branch-and-bound algorithm, which will find the global minimum, although the algorithm is not as efficient. The algorithm also works with integer parameters, which are inherently nonconvex.
> 
> Cheers,
> Paul
> 
> 
> 
> On Tue, May 12, 2020 at 8:36 AM Peter Erwin <peter.erwin at gmail.com> wrote:
> Hi Z?,
> 
> As an aside, the fact that the Sersic2D model is nonlinear in its parameters is formally
> irrelevant, since Levernberg-Marquardt is by design a *non-linear least-squares* algorithm.
> (Levenberg?s original 1944 paper describing the algorithm was titled "A Method for the Solution 
> of Certain Non-Linear Problems in Least Squares?.)
> 
> In practice, I find that Levenberg-Marquardt *usually* finds the global minimum
> in galaxy image-fitting problems (e.g., I get the same solution when running Imfit
> with Levenberg-Marquardt or with the Differential Evolution algorithm, which
> doesn?t use initial values), though there *are* cases where L-M does get trapped in
> local minima. (The fact that Diana says she ?always? gets a different result for 
> different starting parameters maybe suggests something else is the problem.)
> 
> 
> Diana ? have you tried using an alternate fitting algorithm, such as the SimplexLSQFitter
> class? (Simplex fitters tend to be less likely to be trapped by local minima than
> Levenberg-Marquardt, though they?re usually significantly slower.)
> 
> 
> cheers,
> 
> Peter [Erwin]
> 
> > On May 12, 2020, at 11:17 AM, Z? Vin?cius <jvmirca at gmail.com> wrote:
> > 
> > Hi Diana,
> > 
> > From my understanding, LevMarLSQFitter uses the least-squares function as the objective to be minimized using the Levenberg-Marquardt algorithm.
> > 
> > Because Sersic2D is a non-linear model on the parameters to be fitted, the problem is most likely non-convex, which means that Levenberg-Marquardt only guarantees to find a local solution, which will depend on the initial value for those parameters.
> > 
> > Best,
> > Z?
> > 
> > On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <dianasco at astro.uni-bonn.de> wrote:
> > Dear Astropy Staff,
> > 
> > I am Diana Scognamiglio and I have some problems to deep understand how LevMarLSQFitter works.
> > 
> > I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter classe, coding these lines:
> > 
> >  
> >  
> > ini_mod =
> > EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n, x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
> > 
> > fitter = fitting.LevMarLSQFitter()
> > 
> > fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights, maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
> > estimate_jacobian=False)  
> > 
> >  
> > I have figured out that if I change the initial parameters in ini_mod (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a different result although the galaxy I am fitting is the same. How does the fit depend on those initial parameters?
> > 
> > Please, can you help me with this issue?
> > 
> > Thank you in advance.
> > 
> > I wait for hearing from you.
> > 
> > Best regards,
> > 
> > Diana Scognamiglio
> > 
> >  
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
> > 
> > 
> > -- 
> > Z? Vin?cius
> > https://mirca.github.io
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
> 
> =============================================================
> Peter Erwin                   Max-Planck-Insitute for Extraterrestrial 
> erwin at mpe.mpg.de              Physics, Giessenbachstrasse
> tel. +49 (0)176 2481 7713     85748 Garching, Germany
> fax  +49 (0)89 30000 3495     https://www.mpe.mpg.de/~erwin
> 
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
> 
> 
> -- 
> Z? Vin?cius
> https://mirca.github.io
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

=============================================================
Peter Erwin                   Max-Planck-Insitute for Extraterrestrial 
erwin at mpe.mpg.de              Physics, Giessenbachstrasse
tel. +49 (0)176 2481 7713     85748 Garching, Germany
fax  +49 (0)89 30000 3495     https://www.mpe.mpg.de/~erwin





From jvmirca at gmail.com  Wed May 13 23:06:27 2020
From: jvmirca at gmail.com (=?UTF-8?B?WsOpIFZpbsOtY2l1cw==?=)
Date: Thu, 14 May 2020 11:06:27 +0800
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <D55CA790-5BFF-4C45-A802-603A4FE1A511@gmail.com>
References: <ximss-926745@be2.uni-bonn.de>
 <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
 <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
 <CAOqsD12c1XCWC-S+7u5AZiJ4S3=PqO042+yghkkcqrVy3+dj3A@mail.gmail.com>
 <CAB6kXFyycjVgsxhSf7wHxdGgA=8Bg-jJuL7GeZ4BgYAboW2wWQ@mail.gmail.com>
 <D55CA790-5BFF-4C45-A802-603A4FE1A511@gmail.com>
Message-ID: <CAB6kXFy3fT=xR6WfSXmiaTS718gVOuhBd9iPk1cqYy2gy0Jh3A@mail.gmail.com>

Hi Peter,

If the model is linear in its parameters, then it?s a linear least-squares
> problem and
> you can find the best estimator directly (e.g., via matrix inversion or
> orthogonal
> decomposition), without needing something like Levenberg-Marquardt.
>
> https://en.wikipedia.org/wiki/Linear_least_squares
>

Exactly, for which LM will find the unique solution.

The fact that the galaxy-fitting problem *can* be (but is not guaranteed to
> be)
> non-convex does not mean gradient-descent methods like L-M are *useless*;
> it depends on what the actual fit-statistic (e.g., chi^2) landscape is
> like.
>

I'd say it's better to consider optimization problems to be non-convex
until proven otherwise.
And from Diana's experiment of getting different solutions for different
initial points, I'd consider
that a good indicator of non-convexity.

The primary justification for something like L-M is that it is *fast*. My
> experience
> with fitting galaxy images is that it is about an order of magnitude
> faster than
> the simplex and about *two* orders of magnitude faster than Differential
> Evolution, which is considered relatively fast for a genetic-algorithms
> approach.
> If the L-M fit converges in less than a second, then you don?t lose much
> with a
> slower but more robust algorithm. But if the L-M fit takes an hour to
> converge,
> then waiting ten or a hundred hours for convergence with another algorithm
> may be a bit of a problem. (Or if you want to fit several tens of
> thousands of
> different images?)
>

It seems to me that the key here is to have a reasonable initial guess for
the parameters of the Sersic2D model.

Diana:

I have figured out that if I change the initial parameters in ini_mod
> (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a
> different result although the galaxy I am fitting is the same. How does the
> fit depend on those initial parameters?
>

Your problem is likely to be nonconvex, so it's not so counter-intuitive
that you get different results for different initial points: it's just
the nature of LM, it will converge to the nearest local minima.

Best,
Z?

On Thu, May 14, 2020 at 4:11 AM Peter Erwin <peter.erwin at gmail.com> wrote:

> Hi Z?,
>
> If the model is linear in its parameters, then it?s a linear least-squares
> problem and
> you can find the best estimator directly (e.g., via matrix inversion or
> orthogonal
> decomposition), without needing something like Levenberg-Marquardt.
>
> https://en.wikipedia.org/wiki/Linear_least_squares
>
>
> The fact that the galaxy-fitting problem *can* be (but is not guaranteed
> to be)
> non-convex does not mean gradient-descent methods like L-M are *useless*;
> it depends on what the actual fit-statistic (e.g., chi^2) landscape is
> like.
>
> The primary justification for something like L-M is that it is *fast*. My
> experience
> with fitting galaxy images is that it is about an order of magnitude
> faster than
> the simplex and about *two* orders of magnitude faster than Differential
> Evolution, which is considered relatively fast for a genetic-algorithms
> approach.
> If the L-M fit converges in less than a second, then you don?t lose much
> with a
> slower but more robust algorithm. But if the L-M fit takes an hour to
> converge,
> then waiting ten or a hundred hours for convergence with another algorithm
> may be a bit of a problem. (Or if you want to fit several tens of
> thousands of
> different images?)
>
>
> cheers,
>
> Peter
>
>
> > On May 13, 2020, at 6:59 PM, Z? Vin?cius <jvmirca at gmail.com> wrote:
> >
> > Hi Peter,
> >
> > As an aside, the fact that the Sersic2D model is nonlinear in its
> parameters is formally
> > irrelevant, since Levernberg-Marquardt is by design a *non-linear
> least-squares* algorithm.
> > (Levenberg?s original 1944 paper describing the algorithm was titled "A
> Method for the Solution
> > of Certain Non-Linear Problems in Least Squares?.)
> >
> > The thing is that if the model were linear in its parameters, then the
> problem would be convex, and LM would find the global unique optimum
> > no matter the initial point. But if that were the case, I'd advise other
> methods to get that solution.
> >
> > Best,
> > Z?
> >
> > On Wed, May 13, 2020 at 10:42 PM Paul Barrett <pebarrett at gmail.com>
> wrote:
> > Personally, I would suggest ditching the Levenberg-Marquardt and Simplex
> algorithms and using an interior point method, which is more versatile and
> robust in finding the global minimum. Interior point methods more easily
> handle constraints and provide better convergence information. cvxopt is a
> nice Python package for second order problems, which appears to be your
> problem. However, if your problem is nonconvex, i.e., has local minima,
> then you might want to consider using a branch-and-bound algorithm, which
> will find the global minimum, although the algorithm is not as efficient.
> The algorithm also works with integer parameters, which are inherently
> nonconvex.
> >
> > Cheers,
> > Paul
> >
> >
> >
> > On Tue, May 12, 2020 at 8:36 AM Peter Erwin <peter.erwin at gmail.com>
> wrote:
> > Hi Z?,
> >
> > As an aside, the fact that the Sersic2D model is nonlinear in its
> parameters is formally
> > irrelevant, since Levernberg-Marquardt is by design a *non-linear
> least-squares* algorithm.
> > (Levenberg?s original 1944 paper describing the algorithm was titled "A
> Method for the Solution
> > of Certain Non-Linear Problems in Least Squares?.)
> >
> > In practice, I find that Levenberg-Marquardt *usually* finds the global
> minimum
> > in galaxy image-fitting problems (e.g., I get the same solution when
> running Imfit
> > with Levenberg-Marquardt or with the Differential Evolution algorithm,
> which
> > doesn?t use initial values), though there *are* cases where L-M does get
> trapped in
> > local minima. (The fact that Diana says she ?always? gets a different
> result for
> > different starting parameters maybe suggests something else is the
> problem.)
> >
> >
> > Diana ? have you tried using an alternate fitting algorithm, such as the
> SimplexLSQFitter
> > class? (Simplex fitters tend to be less likely to be trapped by local
> minima than
> > Levenberg-Marquardt, though they?re usually significantly slower.)
> >
> >
> > cheers,
> >
> > Peter [Erwin]
> >
> > > On May 12, 2020, at 11:17 AM, Z? Vin?cius <jvmirca at gmail.com> wrote:
> > >
> > > Hi Diana,
> > >
> > > From my understanding, LevMarLSQFitter uses the least-squares function
> as the objective to be minimized using the Levenberg-Marquardt algorithm.
> > >
> > > Because Sersic2D is a non-linear model on the parameters to be fitted,
> the problem is most likely non-convex, which means that Levenberg-Marquardt
> only guarantees to find a local solution, which will depend on the initial
> value for those parameters.
> > >
> > > Best,
> > > Z?
> > >
> > > On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <
> dianasco at astro.uni-bonn.de> wrote:
> > > Dear Astropy Staff,
> > >
> > > I am Diana Scognamiglio and I have some problems to deep understand
> how LevMarLSQFitter works.
> > >
> > > I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter
> classe, coding these lines:
> > >
> > >
> > >
> > > ini_mod =
> > > EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n,
> x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
> > >
> > > fitter = fitting.LevMarLSQFitter()
> > >
> > > fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights,
> maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
> > > estimate_jacobian=False)
> > >
> > >
> > > I have figured out that if I change the initial parameters in ini_mod
> (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a
> different result although the galaxy I am fitting is the same. How does the
> fit depend on those initial parameters?
> > >
> > > Please, can you help me with this issue?
> > >
> > > Thank you in advance.
> > >
> > > I wait for hearing from you.
> > >
> > > Best regards,
> > >
> > > Diana Scognamiglio
> > >
> > >
> > > _______________________________________________
> > > AstroPy mailing list
> > > AstroPy at python.org
> > > https://mail.python.org/mailman/listinfo/astropy
> > >
> > >
> > > --
> > > Z? Vin?cius
> > > https://mirca.github.io
> > > _______________________________________________
> > > AstroPy mailing list
> > > AstroPy at python.org
> > > https://mail.python.org/mailman/listinfo/astropy
> >
> > =============================================================
> > Peter Erwin                   Max-Planck-Insitute for Extraterrestrial
> > erwin at mpe.mpg.de              Physics, Giessenbachstrasse
> > tel. +49 (0)176 2481 7713     85748 Garching, Germany
> > fax  +49 (0)89 30000 3495     https://www.mpe.mpg.de/~erwin
> >
> >
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
> >
> >
> > --
> > Z? Vin?cius
> > https://mirca.github.io
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
>
> =============================================================
> Peter Erwin                   Max-Planck-Insitute for Extraterrestrial
> erwin at mpe.mpg.de              Physics, Giessenbachstrasse
> tel. +49 (0)176 2481 7713     85748 Garching, Germany
> fax  +49 (0)89 30000 3495     https://www.mpe.mpg.de/~erwin
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Z? Vin?cius
https://mirca.github.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200514/36eefa60/attachment-0001.html>

From dianasco at astro.uni-bonn.de  Thu May 14 10:00:32 2020
From: dianasco at astro.uni-bonn.de (Diana Scognamiglio)
Date: Thu, 14 May 2020 16:00:32 +0200
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
References: <ximss-926745@be2.uni-bonn.de><CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com><D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
Message-ID: <ximss-844692@be3.uni-bonn.de>

Dear Z?, Peter, Peter and Paul,
thanks for your reply.
I didn't find yet the solution to my problem.
The problems could be due to the fact that the fit just converges in a local 
minimum and not in the global one or to the fact the the fit is not well 
constrained...in any case it sometimes completely fails giving for example 
flux=0!
I should use some particular constraints for the fitting I guess...and 
probably it will be the best solution.

About the Peter (Dwing)?s questions: I chose these ranges for the initial 
parameters: n_Sersic=[1.0,2.0,3.0,4.0,5.0,6.0] and  R_eff=[1.0,5.0, 10.0, 
30.0, 50.0,100.0], and ini_flux=[100, 1000].
If I repeat the run (using the same initial parameters), yes I get the same 
results.

I also used the SimplexLSQFitter, but the things doesn?t change.

Thanks again.
Cheers,
Diana

On Tue, 12 May 2020 14:36:11 +0200
         Peter Erwin <peter.erwin at gmail.com> wrote:
> Hi Z?,
> 
> As an aside, the fact that the Sersic2D model is nonlinear in its parameters is formally
> irrelevant, since Levernberg-Marquardt is by design a *non-linear least-squares* algorithm.
> (Levenberg?s original 1944 paper describing the algorithm was titled "A Method for the Solution of Certain Non-Linear Problems in Least Squares?.)
> 
> In practice, I find that Levenberg-Marquardt *usually* finds the global minimum
> in galaxy image-fitting problems (e.g., I get the same solution when running Imfit
> with Levenberg-Marquardt or with the Differential Evolution algorithm, which
> doesn?t use initial values), though there *are* cases where L-M does get trapped in
> local minima. (The fact that Diana says she ?always? gets a different result for different starting parameters maybe suggests something else is the problem.)
> 
> 
> Diana ? have you tried using an alternate fitting algorithm, such as the SimplexLSQFitter
> class? (Simplex fitters tend to be less likely to be trapped by local minima than
> Levenberg-Marquardt, though they?re usually significantly slower.)
> 
> 
> cheers,
> 
> Peter [Erwin]
> 
>> On May 12, 2020, at 11:17 AM, Z? Vin?cius <jvmirca at gmail.com> wrote:
>> 
>> Hi Diana,
>> 
>> From my understanding, LevMarLSQFitter uses the least-squares function as the objective to be minimized using the Levenberg-Marquardt algorithm.
>> 
>> Because Sersic2D is a non-linear model on the parameters to be fitted, the problem is most likely non-convex, which means that Levenberg-Marquardt only guarantees to find a local solution, which will depend on the initial value for those parameters.
>> 
>> Best,
>> Z?
>> 
>> On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <dianasco at astro.uni-bonn.de> wrote:
>> Dear Astropy Staff,
>> 
>> I am Diana Scognamiglio and I have some problems to deep understand how LevMarLSQFitter works.
>> 
>> I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter classe, coding these lines:
>> 
>>  
>> ini_mod =
>> EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n, x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
>> 
>> fitter = fitting.LevMarLSQFitter()
>> 
>> fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights, maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
>> estimate_jacobian=False)   I have figured out that if I change the initial parameters in ini_mod (i.e., ini_flux, ini_r_eff, etc), I counterintuitively obtain always a different result although the galaxy I am fitting is the same. How does the fit depend on those initial parameters?
>> 
>> Please, can you help me with this issue?
>> 
>> Thank you in advance.
>> 
>> I wait for hearing from you.
>> 
>> Best regards,
>> 
>> Diana Scognamiglio
>> 
>>  
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>> 
>> 
>> -- 
>> Z? Vin?cius
>> https://mirca.github.io
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
> 
> =============================================================
> Peter Erwin                   Max-Planck-Insitute for Extraterrestrial erwin at mpe.mpg.de              Physics, Giessenbachstrasse
> tel. +49 (0)176 2481 7713     85748 Garching, Germany
> fax  +49 (0)89 30000 3495    https://www.mpe.mpg.de/~erwin
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy










From jvmirca at gmail.com  Thu May 14 10:09:54 2020
From: jvmirca at gmail.com (=?UTF-8?B?WsOpIFZpbsOtY2l1cw==?=)
Date: Thu, 14 May 2020 22:09:54 +0800
Subject: [AstroPy] Info LevMarLSQFitter
In-Reply-To: <ximss-844692@be3.uni-bonn.de>
References: <ximss-926745@be2.uni-bonn.de>
 <CAB6kXFw1M4A7SgBF9_AB-Jmb-OKcKbXbqotrQesNtaU2KYV6=A@mail.gmail.com>
 <D28F0BD7-C361-4CFD-8832-06BE09FC6EAE@gmail.com>
 <ximss-844692@be3.uni-bonn.de>
Message-ID: <CAB6kXFyc-3Y_bSE-3K96y_z5Le_LZaasfa8_eQ6z2qThUMb-tw@mail.gmail.com>

Dear Diana,

I should use some particular constraints for the fitting I guess...and
> probably it will be the best solution.
>

Absolutely! I would definitely take advantage of imposing the constraints
on the parameters in whatever fitting algorithm I would use.
That's possibly the only way to make sure that you don't get physically
unreasonable results.

Best,
Z?

On Thu, May 14, 2020 at 10:00 PM Diana Scognamiglio <
dianasco at astro.uni-bonn.de> wrote:

> Dear Z?, Peter, Peter and Paul,
> thanks for your reply.
> I didn't find yet the solution to my problem.
> The problems could be due to the fact that the fit just converges in a
> local
> minimum and not in the global one or to the fact the the fit is not well
> constrained...in any case it sometimes completely fails giving for example
> flux=0!
> I should use some particular constraints for the fitting I guess...and
> probably it will be the best solution.
>
> About the Peter (Dwing)?s questions: I chose these ranges for the initial
> parameters: n_Sersic=[1.0,2.0,3.0,4.0,5.0,6.0] and  R_eff=[1.0,5.0, 10.0,
> 30.0, 50.0,100.0], and ini_flux=[100, 1000].
> If I repeat the run (using the same initial parameters), yes I get the
> same
> results.
>
> I also used the SimplexLSQFitter, but the things doesn?t change.
>
> Thanks again.
> Cheers,
> Diana
>
> On Tue, 12 May 2020 14:36:11 +0200
>          Peter Erwin <peter.erwin at gmail.com> wrote:
> > Hi Z?,
> >
> > As an aside, the fact that the Sersic2D model is nonlinear in its
> parameters is formally
> > irrelevant, since Levernberg-Marquardt is by design a *non-linear
> least-squares* algorithm.
> > (Levenberg?s original 1944 paper describing the algorithm was titled "A
> Method for the Solution of Certain Non-Linear Problems in Least Squares?.)
> >
> > In practice, I find that Levenberg-Marquardt *usually* finds the global
> minimum
> > in galaxy image-fitting problems (e.g., I get the same solution when
> running Imfit
> > with Levenberg-Marquardt or with the Differential Evolution algorithm,
> which
> > doesn?t use initial values), though there *are* cases where L-M does get
> trapped in
> > local minima. (The fact that Diana says she ?always? gets a different
> result for different starting parameters maybe suggests something else is
> the problem.)
> >
> >
> > Diana ? have you tried using an alternate fitting algorithm, such as the
> SimplexLSQFitter
> > class? (Simplex fitters tend to be less likely to be trapped by local
> minima than
> > Levenberg-Marquardt, though they?re usually significantly slower.)
> >
> >
> > cheers,
> >
> > Peter [Erwin]
> >
> >> On May 12, 2020, at 11:17 AM, Z? Vin?cius <jvmirca at gmail.com> wrote:
> >>
> >> Hi Diana,
> >>
> >> From my understanding, LevMarLSQFitter uses the least-squares function
> as the objective to be minimized using the Levenberg-Marquardt algorithm.
> >>
> >> Because Sersic2D is a non-linear model on the parameters to be fitted,
> the problem is most likely non-convex, which means that Levenberg-Marquardt
> only guarantees to find a local solution, which will depend on the initial
> value for those parameters.
> >>
> >> Best,
> >> Z?
> >>
> >> On Tue, May 12, 2020 at 4:53 PM Diana Scognamiglio <
> dianasco at astro.uni-bonn.de> wrote:
> >> Dear Astropy Staff,
> >>
> >> I am Diana Scognamiglio and I have some problems to deep understand how
> LevMarLSQFitter works.
> >>
> >> I am trying to fit a mock Sersic galaxy using the LevMarLSQFitter
> classe, coding these lines:
> >>
> >>
> >> ini_mod =
> >> EllipSersic2D(flux=ini_flux, r_eff=ini_r_eff, n=ini_n,
> x_0=stampsize/2.0, y_0=stampsize/2.0, g1=0.0, g2=0.0)
> >>
> >> fitter = fitting.LevMarLSQFitter()
> >>
> >> fit_mod = fitter(ini_mod, x_array, y_array, stamp, weights=weights,
> maxiter = 1000, acc=1.0e-7, epsilon=1.0e-6,
> >> estimate_jacobian=False)   I have figured out that if I change the
> initial parameters in ini_mod (i.e., ini_flux, ini_r_eff, etc), I
> counterintuitively obtain always a different result although the galaxy I
> am fitting is the same. How does the fit depend on those initial parameters?
> >>
> >> Please, can you help me with this issue?
> >>
> >> Thank you in advance.
> >>
> >> I wait for hearing from you.
> >>
> >> Best regards,
> >>
> >> Diana Scognamiglio
> >>
> >>
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at python.org
> >> https://mail.python.org/mailman/listinfo/astropy
> >>
> >>
> >> --
> >> Z? Vin?cius
> >> https://mirca.github.io
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at python.org
> >> https://mail.python.org/mailman/listinfo/astropy
> >
> > =============================================================
> > Peter Erwin                   Max-Planck-Insitute for Extraterrestrial
> erwin at mpe.mpg.de              Physics, Giessenbachstrasse
> > tel. +49 (0)176 2481 7713     85748 Garching, Germany
> > fax  +49 (0)89 30000 3495    https://www.mpe.mpg.de/~erwin
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
>
>
>
>
>
>
>
>
>
>

-- 
Z? Vin?cius
https://mirca.github.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200514/3044b0bf/attachment.html>

From cbrasseur at stsci.edu  Thu May 21 12:24:36 2020
From: cbrasseur at stsci.edu (Clara Brasseur)
Date: Thu, 21 May 2020 16:24:36 +0000
Subject: [AstroPy] Kudos for Thomas Robitaille (astrofrog)
Message-ID: <9863B97F-4B30-46FF-98A8-015DA26B46A1@stsci.edu>

Shout out to Thomas Robitaille (astrofrog) for adding the fallback and warning when a memory error is encountered opening a memmap fits file in readonly mode. In addition to the fallback keeping my code from crashing, the informative warning allowed me to understand why I was encountering memory errors in the first place and to adjust my memmap mode accordingly.

-Clara



--
Software Engineer, Archive Sciences Branch
Space Telescope Science Institute
3700 San Martin Dr, Baltimore, MD 21218

cbrasseur at stsci.edu<mailto:cbrasseur at stsci.edu>
410-338-6769



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200521/7aa9b527/attachment.html>

From thomas.robitaille at gmail.com  Mon May 25 14:59:47 2020
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 25 May 2020 19:59:47 +0100
Subject: [AstroPy] astropy v4.1rc1 release candidate
Message-ID: <CAGMHX_0VZadRriLHP8ow2ddoY=1Ew9Vg6wzYT9uF8kBX7=Gu0w@mail.gmail.com>

Hi everyone,

The first astropy v4.1 release candidate (RC) is now available and
ready for testing!

https://pypi.python.org/pypi/astropy/4.1rc1

You should be able to install the RC by doing:

pip install astropy --pre

or

pip install astropy==4.1rc1

You can find the documentation corresponding to this release at:

https://docs.astropy.org/en/v4.1rc1/

including the 'What's new in v4.1?' page.

We would appreciate if you could try out this RC and report back any
success or failure via the following wiki page:

https://github.com/astropy/astropy/wiki/astropy-v4.1-release-candidate-(RC)-Testing

For example, you can try running the test suite as mentioned on the
wiki page. In addition, if you maintain any packages that use astropy,
please check that your package(s) works well with this RC and let us
know if there are any issues or whether everything works fine. There
is a section to list packages that work/don't work at the bottom of
the wiki page. Please also open an issue in the astropy core package
issue tracker for any issues you encounter (and open separate issues
for separate problems you run into).

If you use conda, be sure to either remove the existing conda astropy
package or make a new environment before installing the RC. Note that
there are no conda packages for the RC.

Thanks!
Tom

From afonsoangelarodrigues at gmail.com  Thu May 28 03:43:46 2020
From: afonsoangelarodrigues at gmail.com (Angela Rodrigues)
Date: Thu, 28 May 2020 17:43:46 +1000
Subject: [AstroPy] Fwd: Help with finding absorption lines
In-Reply-To: <CACO1jaDx0E-MSN8EYP=9qBBR_-JCfEnS_N7J_5LKbbz9TLH2LA@mail.gmail.com>
References: <CACO1jaDx0E-MSN8EYP=9qBBR_-JCfEnS_N7J_5LKbbz9TLH2LA@mail.gmail.com>
Message-ID: <CACO1jaCmR-Jryy+OQ9nB3bmcmy-TEp6cSANBUzYOivDSpnfqBQ@mail.gmail.com>

Hello,

I have been trying to use astropy to extract lines of absorption from a
mineral spectrum.
so I have the attached hdr file with the spectral analysis from a mineral.
The code to extract the data from the file is as follows:

import spectral.io.envi as envi
lib = envi.open('GFZ_HySpex_REMin.hdr')

a=lib.metadata
wvl = a.get('wavelength')
wvl = [int(float(i)) for i in wvl]

import matplotlib.pyplot as plt
plt.plot(wvl,spectra[13])

#grab spectra for parisite
names = lib.names

spectra_parisite = spectra[8]
plt.plot(wvl, spectra_parisite)


I wanted to extract the absorption lines as in the documentation example
here <https://specutils.readthedocs.io/en/stable/fitting.html>.
Here's what I've done:


w = np.array(wvl)

import astropy.units as u
w = w*u.nm
spectra_parisite = spectra_parisite*u.Jy
from specutils import Spectrum1D, SpectralRegion
spectrum = Spectrum1D(spectral_axis = w, flux = spectra_parisite)

from matplotlib import pyplot as plt
plt.plot(spectrum.spectral_axis, spectrum.flux)
plt.xlabel('Spectral Axis ({})'.format(spectrum.spectral_axis.unit))
plt.ylabel('Flux Axis({})'.format(spectrum.flux.unit))
plt.grid(True)

from specutils.manipulation import noise_region_uncertainty
noise_region = SpectralRegion(450*u.nm, 2500*u.nm)
spectrum2 = noise_region_uncertainty(spectrum, noise_region)

from specutils.fitting import find_lines_threshold
lines = find_lines_threshold(spectrum2, noise_factor=0)
lines[lines['line_type'] == 'absorption']
lines[lines['line_type'] == 'emission']

# Derivative technique
from specutils.fitting import find_lines_derivative
lines = find_lines_derivative(spectrum2, flux_threshold=0)
lines[lines['line_type'] == 'absorption']


However, I get no absorption feature lines. Am I doing something wrong? The
emission zones seem to be alright, but I really need the absorption loci.
Thank you so much for your help!!
Warm regards,
Angela Rodrigues
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200528/73bbc2fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GFZ_HySpex_REMin
Type: application/octet-stream
Size: 45696 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20200528/73bbc2fc/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GFZ_HySpex_REMin.hdr
Type: application/octet-stream
Size: 6193 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20200528/73bbc2fc/attachment-0003.obj>

From pdzwig at summaventures.com  Thu May 28 05:15:19 2020
From: pdzwig at summaventures.com (Peter Dzwig)
Date: Thu, 28 May 2020 10:15:19 +0100
Subject: [AstroPy] Fwd: Help with finding absorption lines
In-Reply-To: <CACO1jaCmR-Jryy+OQ9nB3bmcmy-TEp6cSANBUzYOivDSpnfqBQ@mail.gmail.com>
References: <CACO1jaDx0E-MSN8EYP=9qBBR_-JCfEnS_N7J_5LKbbz9TLH2LA@mail.gmail.com>
 <CACO1jaCmR-Jryy+OQ9nB3bmcmy-TEp6cSANBUzYOivDSpnfqBQ@mail.gmail.com>
Message-ID: <0a1ff555-121e-ee1d-a9c0-49aca9d51e01@summaventures.com>

Angela,

first thing to be said is that I sympathize. :-)  I have had similar
issues although my datasets are very different (QSOs); the second is
that I can't open either of your files. Perhaps you tell us what format
they are in.

I tried running similar code to yours (despite the different context). I
found that the answers, from both thresholding and derivative, I got
were quite sensitive to the data density per unit wavelength, the amount
of noise in the data and the threshold that you set.

Unless the data is sufficiently dense both thresholding and derivative
will produce inaccurate or even false results.

In the end I found the best solution was to make a table of all the
lines that I was interested in and simply overplot them on my spectrum.
I can then see what's where and (using a combination of astropy and
numpy) re-plot and re-examine pertinent parts of the spectrum, but as
ever the limiting factor is data density.

I guess in your case the lines that you would plot would be Calcium,
Cerium, Lanthanum, Carbon, Flourine  - and Neodymium? and some of their
molecular forms. Tables for most are available from NIST:
https://www.nist.gov/pml/atomic-spectra-database

There probably is a best approach - a tutorial would be a good idea -
and I will watch this space to see what solutions others offer.

Regards,

Peter Dzwig

On 28/05/2020 08:43, Angela Rodrigues wrote:
> Hello,
> 
> I have been trying to use astropy to extract lines of absorption from a
> mineral spectrum.
> so I have the attached hdr file with the spectral analysis from a mineral.
> The code to extract the data from the file is as follows:
> 
> import spectral.io.envi as envi
> lib = envi.open('GFZ_HySpex_REMin.hdr')
> 
> a=lib.metadata
> wvl = a.get('wavelength')
> wvl = [int(float(i)) for i in wvl]
> 
> import matplotlib.pyplot as plt
> plt.plot(wvl,spectra[13])
> 
> #grab spectra for parisite
> names = lib.names
> 
> spectra_parisite = spectra[8]
> plt.plot(wvl, spectra_parisite)
> 
> 
> I wanted to extract the absorption lines as in the documentation example
> here <https://specutils.readthedocs.io/en/stable/fitting.html>.
> Here's what I've done:
> 
> 
> w = np.array(wvl)
> 
> import astropy.units as u
> w = w*u.nm
> spectra_parisite = spectra_parisite*u.Jy
> from specutils import Spectrum1D, SpectralRegion
> spectrum = Spectrum1D(spectral_axis = w, flux = spectra_parisite)
> 
> from matplotlib import pyplot as plt
> plt.plot(spectrum.spectral_axis, spectrum.flux)
> plt.xlabel('Spectral Axis ({})'.format(spectrum.spectral_axis.unit))
> plt.ylabel('Flux Axis({})'.format(spectrum.flux.unit))
> plt.grid(True)
> 
> from specutils.manipulation import noise_region_uncertainty
> noise_region = SpectralRegion(450*u.nm, 2500*u.nm)
> spectrum2 = noise_region_uncertainty(spectrum, noise_region)
> 
> from specutils.fitting import find_lines_threshold
> lines = find_lines_threshold(spectrum2, noise_factor=0)
> lines[lines['line_type'] == 'absorption']
> lines[lines['line_type'] == 'emission']
> 
> # Derivative technique
> from specutils.fitting import find_lines_derivative
> lines = find_lines_derivative(spectrum2, flux_threshold=0)
> lines[lines['line_type'] == 'absorption']?
> 
> 
> However, I get no absorption feature lines. Am I doing something wrong?
> The emission zones seem to be alright, but I really need the absorption
> loci.
> Thank you so much for your help!!
> Warm regards,
> Angela Rodrigues
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
> 

-- 

Dr. Peter Dzwig

From afonsoangelarodrigues at gmail.com  Thu May 28 05:55:04 2020
From: afonsoangelarodrigues at gmail.com (Angela Rodrigues)
Date: Thu, 28 May 2020 19:55:04 +1000
Subject: [AstroPy] Fwd: Help with finding absorption lines
In-Reply-To: <0a1ff555-121e-ee1d-a9c0-49aca9d51e01@summaventures.com>
References: <CACO1jaDx0E-MSN8EYP=9qBBR_-JCfEnS_N7J_5LKbbz9TLH2LA@mail.gmail.com>
 <CACO1jaCmR-Jryy+OQ9nB3bmcmy-TEp6cSANBUzYOivDSpnfqBQ@mail.gmail.com>
 <0a1ff555-121e-ee1d-a9c0-49aca9d51e01@summaventures.com>
Message-ID: <CACO1jaAT9yN94eewCS3tVvLXe2twAv0gMgXAzFtoonY5+96LoQ@mail.gmail.com>

Hi Dr. Peter

Thank you kindly for your reply.

Here's a folder with the file (it's an hdr file):
https://drive.google.com/file/d/1Rb25_mzAKq7ZqFI9fPyOX8TnTtspYxpF/view?usp=sharing

I am looking for really small shifts that reflect chemistry, and therefore,
I cannot just eyeball it, I need the actual values.
Indeed it is a complicated task to do without specialized software.
Regarding the threshold, I've changed it multiple times between 0 and 20,
and still no absorption values...

Thank you so much for looking into it! :)


Peter Dzwig <pdzwig at summaventures.com> escreveu no dia quinta, 28/05/2020
?(s) 19:15:

> Angela,
>
> first thing to be said is that I sympathize. :-)  I have had similar
> issues although my datasets are very different (QSOs); the second is
> that I can't open either of your files. Perhaps you tell us what format
> they are in.
>
> I tried running similar code to yours (despite the different context). I
> found that the answers, from both thresholding and derivative, I got
> were quite sensitive to the data density per unit wavelength, the amount
> of noise in the data and the threshold that you set.
>
> Unless the data is sufficiently dense both thresholding and derivative
> will produce inaccurate or even false results.
>
> In the end I found the best solution was to make a table of all the
> lines that I was interested in and simply overplot them on my spectrum.
> I can then see what's where and (using a combination of astropy and
> numpy) re-plot and re-examine pertinent parts of the spectrum, but as
> ever the limiting factor is data density.
>
> I guess in your case the lines that you would plot would be Calcium,
> Cerium, Lanthanum, Carbon, Flourine  - and Neodymium? and some of their
> molecular forms. Tables for most are available from NIST:
> https://www.nist.gov/pml/atomic-spectra-database
>
> There probably is a best approach - a tutorial would be a good idea -
> and I will watch this space to see what solutions others offer.
>
> Regards,
>
> Peter Dzwig
>
> On 28/05/2020 08:43, Angela Rodrigues wrote:
> > Hello,
> >
> > I have been trying to use astropy to extract lines of absorption from a
> > mineral spectrum.
> > so I have the attached hdr file with the spectral analysis from a
> mineral.
> > The code to extract the data from the file is as follows:
> >
> > import spectral.io.envi as envi
> > lib = envi.open('GFZ_HySpex_REMin.hdr')
> >
> > a=lib.metadata
> > wvl = a.get('wavelength')
> > wvl = [int(float(i)) for i in wvl]
> >
> > import matplotlib.pyplot as plt
> > plt.plot(wvl,spectra[13])
> >
> > #grab spectra for parisite
> > names = lib.names
> >
> > spectra_parisite = spectra[8]
> > plt.plot(wvl, spectra_parisite)
> >
> >
> > I wanted to extract the absorption lines as in the documentation example
> > here <https://specutils.readthedocs.io/en/stable/fitting.html>.
> > Here's what I've done:
> >
> >
> > w = np.array(wvl)
> >
> > import astropy.units as u
> > w = w*u.nm
> > spectra_parisite = spectra_parisite*u.Jy
> > from specutils import Spectrum1D, SpectralRegion
> > spectrum = Spectrum1D(spectral_axis = w, flux = spectra_parisite)
> >
> > from matplotlib import pyplot as plt
> > plt.plot(spectrum.spectral_axis, spectrum.flux)
> > plt.xlabel('Spectral Axis ({})'.format(spectrum.spectral_axis.unit))
> > plt.ylabel('Flux Axis({})'.format(spectrum.flux.unit))
> > plt.grid(True)
> >
> > from specutils.manipulation import noise_region_uncertainty
> > noise_region = SpectralRegion(450*u.nm, 2500*u.nm)
> > spectrum2 = noise_region_uncertainty(spectrum, noise_region)
> >
> > from specutils.fitting import find_lines_threshold
> > lines = find_lines_threshold(spectrum2, noise_factor=0)
> > lines[lines['line_type'] == 'absorption']
> > lines[lines['line_type'] == 'emission']
> >
> > # Derivative technique
> > from specutils.fitting import find_lines_derivative
> > lines = find_lines_derivative(spectrum2, flux_threshold=0)
> > lines[lines['line_type'] == 'absorption']
> >
> >
> > However, I get no absorption feature lines. Am I doing something wrong?
> > The emission zones seem to be alright, but I really need the absorption
> > loci.
> > Thank you so much for your help!!
> > Warm regards,
> > Angela Rodrigues
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
> >
>
> --
>
> Dr. Peter Dzwig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200528/07436b36/attachment.html>

From xavier at ucolick.org  Thu May 28 08:22:10 2020
From: xavier at ucolick.org (J. Xavier Prochaska)
Date: Thu, 28 May 2020 05:22:10 -0700
Subject: [AstroPy] Fwd: Help with finding absorption lines
In-Reply-To: <CACO1jaAT9yN94eewCS3tVvLXe2twAv0gMgXAzFtoonY5+96LoQ@mail.gmail.com>
References: <CACO1jaDx0E-MSN8EYP=9qBBR_-JCfEnS_N7J_5LKbbz9TLH2LA@mail.gmail.com>
 <CACO1jaCmR-Jryy+OQ9nB3bmcmy-TEp6cSANBUzYOivDSpnfqBQ@mail.gmail.com>
 <0a1ff555-121e-ee1d-a9c0-49aca9d51e01@summaventures.com>
 <CACO1jaAT9yN94eewCS3tVvLXe2twAv0gMgXAzFtoonY5+96LoQ@mail.gmail.com>
Message-ID: <CAPqNJpuyg7YnxzNDaXAdt_Q_i+ZRq71V5dWEk=TWZR+H-mzMqw@mail.gmail.com>

Consider

linetools -- https://github.com/linetools/linetools

and

ALIS -- https://github.com/rcooke-ast/ALIS

Built by scientists who study absorption lines for a living..

X


On Thu, May 28, 2020 at 2:55 AM Angela Rodrigues <
afonsoangelarodrigues at gmail.com> wrote:

> Hi Dr. Peter
>
> Thank you kindly for your reply.
>
> Here's a folder with the file (it's an hdr file):
>
> https://drive.google.com/file/d/1Rb25_mzAKq7ZqFI9fPyOX8TnTtspYxpF/view?usp=sharing
>
> I am looking for really small shifts that reflect chemistry, and
> therefore, I cannot just eyeball it, I need the actual values.
> Indeed it is a complicated task to do without specialized software.
> Regarding the threshold, I've changed it multiple times between 0 and 20,
> and still no absorption values...
>
> Thank you so much for looking into it! :)
>
>
> Peter Dzwig <pdzwig at summaventures.com> escreveu no dia quinta, 28/05/2020
> ?(s) 19:15:
>
>> Angela,
>>
>> first thing to be said is that I sympathize. :-)  I have had similar
>> issues although my datasets are very different (QSOs); the second is
>> that I can't open either of your files. Perhaps you tell us what format
>> they are in.
>>
>> I tried running similar code to yours (despite the different context). I
>> found that the answers, from both thresholding and derivative, I got
>> were quite sensitive to the data density per unit wavelength, the amount
>> of noise in the data and the threshold that you set.
>>
>> Unless the data is sufficiently dense both thresholding and derivative
>> will produce inaccurate or even false results.
>>
>> In the end I found the best solution was to make a table of all the
>> lines that I was interested in and simply overplot them on my spectrum.
>> I can then see what's where and (using a combination of astropy and
>> numpy) re-plot and re-examine pertinent parts of the spectrum, but as
>> ever the limiting factor is data density.
>>
>> I guess in your case the lines that you would plot would be Calcium,
>> Cerium, Lanthanum, Carbon, Flourine  - and Neodymium? and some of their
>> molecular forms. Tables for most are available from NIST:
>> https://www.nist.gov/pml/atomic-spectra-database
>>
>> There probably is a best approach - a tutorial would be a good idea -
>> and I will watch this space to see what solutions others offer.
>>
>> Regards,
>>
>> Peter Dzwig
>>
>> On 28/05/2020 08:43, Angela Rodrigues wrote:
>> > Hello,
>> >
>> > I have been trying to use astropy to extract lines of absorption from a
>> > mineral spectrum.
>> > so I have the attached hdr file with the spectral analysis from a
>> mineral.
>> > The code to extract the data from the file is as follows:
>> >
>> > import spectral.io.envi as envi
>> > lib = envi.open('GFZ_HySpex_REMin.hdr')
>> >
>> > a=lib.metadata
>> > wvl = a.get('wavelength')
>> > wvl = [int(float(i)) for i in wvl]
>> >
>> > import matplotlib.pyplot as plt
>> > plt.plot(wvl,spectra[13])
>> >
>> > #grab spectra for parisite
>> > names = lib.names
>> >
>> > spectra_parisite = spectra[8]
>> > plt.plot(wvl, spectra_parisite)
>> >
>> >
>> > I wanted to extract the absorption lines as in the documentation example
>> > here <https://specutils.readthedocs.io/en/stable/fitting.html>.
>> > Here's what I've done:
>> >
>> >
>> > w = np.array(wvl)
>> >
>> > import astropy.units as u
>> > w = w*u.nm
>> > spectra_parisite = spectra_parisite*u.Jy
>> > from specutils import Spectrum1D, SpectralRegion
>> > spectrum = Spectrum1D(spectral_axis = w, flux = spectra_parisite)
>> >
>> > from matplotlib import pyplot as plt
>> > plt.plot(spectrum.spectral_axis, spectrum.flux)
>> > plt.xlabel('Spectral Axis ({})'.format(spectrum.spectral_axis.unit))
>> > plt.ylabel('Flux Axis({})'.format(spectrum.flux.unit))
>> > plt.grid(True)
>> >
>> > from specutils.manipulation import noise_region_uncertainty
>> > noise_region = SpectralRegion(450*u.nm, 2500*u.nm)
>> > spectrum2 = noise_region_uncertainty(spectrum, noise_region)
>> >
>> > from specutils.fitting import find_lines_threshold
>> > lines = find_lines_threshold(spectrum2, noise_factor=0)
>> > lines[lines['line_type'] == 'absorption']
>> > lines[lines['line_type'] == 'emission']
>> >
>> > # Derivative technique
>> > from specutils.fitting import find_lines_derivative
>> > lines = find_lines_derivative(spectrum2, flux_threshold=0)
>> > lines[lines['line_type'] == 'absorption']
>> >
>> >
>> > However, I get no absorption feature lines. Am I doing something wrong?
>> > The emission zones seem to be alright, but I really need the absorption
>> > loci.
>> > Thank you so much for your help!!
>> > Warm regards,
>> > Angela Rodrigues
>> >
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at python.org
>> > https://mail.python.org/mailman/listinfo/astropy
>> >
>>
>> --
>>
>> Dr. Peter Dzwig
>>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
-- 
----------------------------------------------
J. Xavier Prochaska
UCO/Lick Observatory
1156 High St.
UC Santa Cruz
Santa Cruz, CA 95064

Affiliate of IPMU
Affiliate of LBNL

http://www.ucolick.org/~xavier/
https://aaii.ucsc.edu/
http://www.ucolick.org/f-4 <https://www.ucolick.org/f-4>

831-459-2135 (Direct)
831-459-2991 (UCO/Lick Main)
831-459-5244 (Fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20200528/664a2f4c/attachment-0001.html>

From pdzwig at summaventures.com  Thu May 28 09:53:19 2020
From: pdzwig at summaventures.com (Peter Dzwig)
Date: Thu, 28 May 2020 14:53:19 +0100
Subject: [AstroPy] Fwd: Help with finding absorption lines
In-Reply-To: <CACO1jaAT9yN94eewCS3tVvLXe2twAv0gMgXAzFtoonY5+96LoQ@mail.gmail.com>
References: <CACO1jaDx0E-MSN8EYP=9qBBR_-JCfEnS_N7J_5LKbbz9TLH2LA@mail.gmail.com>
 <CACO1jaCmR-Jryy+OQ9nB3bmcmy-TEp6cSANBUzYOivDSpnfqBQ@mail.gmail.com>
 <0a1ff555-121e-ee1d-a9c0-49aca9d51e01@summaventures.com>
 <CACO1jaAT9yN94eewCS3tVvLXe2twAv0gMgXAzFtoonY5+96LoQ@mail.gmail.com>
Message-ID: <ce538097-d04b-9fc8-acf6-22bcd22a9f91@summaventures.com>

Angela,

I will think about this some more - and hopefully some more astropy
users will join in.

Going to your point about really small shifts: You don't specify what
you mean by that, but what I did was to provide myself with a tool that
enabled me to plot a small section of the data I had and then overplot
with lines within that. But, again, data density is everything.

To look for the lines you might find NIST the best source, in the end I
used a combination of (fairly) standard data, together with transitions
calculated from quantum mechanics, so that I had tables which included
not only the main lines, but also forbidden and semi-forbidden
transitions. At that point I wasn't interested in molecular orbitals and
so on, but I guess that in prionciple you could extend it to that.

I will, as I say continue to look at it, but I hope others will contribute.

Peter

On 28/05/2020 10:55, Angela Rodrigues wrote:
> Hi Dr. Peter
> 
> Thank you kindly for your reply.
> 
> Here's a folder with the file (it's an hdr file):
> https://drive.google.com/file/d/1Rb25_mzAKq7ZqFI9fPyOX8TnTtspYxpF/view?usp=sharing
> 
> I am looking for really small shifts that reflect chemistry, and
> therefore, I cannot just eyeball it, I need the actual values.
> Indeed it is a complicated task to do without specialized software.
> Regarding the threshold, I've changed it multiple times between 0 and
> 20, and still no absorption values...
> 
> Thank you so much for looking into it! :)
> 
> 
> Peter Dzwig <pdzwig at summaventures.com <mailto:pdzwig at summaventures.com>>
> escreveu no dia quinta, 28/05/2020 ?(s) 19:15:
> 
>     Angela,
> 
>     first thing to be said is that I sympathize. :-)? I have had similar
>     issues although my datasets are very different (QSOs); the second is
>     that I can't open either of your files. Perhaps you tell us what format
>     they are in.
> 
>     I tried running similar code to yours (despite the different context). I
>     found that the answers, from both thresholding and derivative, I got
>     were quite sensitive to the data density per unit wavelength, the amount
>     of noise in the data and the threshold that you set.
> 
>     Unless the data is sufficiently dense both thresholding and derivative
>     will produce inaccurate or even false results.
> 
>     In the end I found the best solution was to make a table of all the
>     lines that I was interested in and simply overplot them on my spectrum.
>     I can then see what's where and (using a combination of astropy and
>     numpy) re-plot and re-examine pertinent parts of the spectrum, but as
>     ever the limiting factor is data density.
> 
>     I guess in your case the lines that you would plot would be Calcium,
>     Cerium, Lanthanum, Carbon, Flourine? - and Neodymium? and some of their
>     molecular forms. Tables for most are available from NIST:
>     https://www.nist.gov/pml/atomic-spectra-database
> 
>     There probably is a best approach - a tutorial would be a good idea -
>     and I will watch this space to see what solutions others offer.
> 
>     Regards,
> 
>     Peter Dzwig
> 
>     On 28/05/2020 08:43, Angela Rodrigues wrote:
>     > Hello,
>     >
>     > I have been trying to use astropy to extract lines of absorption
>     from a
>     > mineral spectrum.
>     > so I have the attached hdr file with the spectral analysis from a
>     mineral.
>     > The code to extract the data from the file is as follows:
>     >
>     > import spectral.io.envi as envi
>     > lib = envi.open('GFZ_HySpex_REMin.hdr')
>     >
>     > a=lib.metadata
>     > wvl = a.get('wavelength')
>     > wvl = [int(float(i)) for i in wvl]
>     >
>     > import matplotlib.pyplot as plt
>     > plt.plot(wvl,spectra[13])
>     >
>     > #grab spectra for parisite
>     > names = lib.names
>     >
>     > spectra_parisite = spectra[8]
>     > plt.plot(wvl, spectra_parisite)
>     >
>     >
>     > I wanted to extract the absorption lines as in the documentation
>     example
>     > here <https://specutils.readthedocs.io/en/stable/fitting.html>.
>     > Here's what I've done:
>     >
>     >
>     > w = np.array(wvl)
>     >
>     > import astropy.units as u
>     > w = w*u.nm
>     > spectra_parisite = spectra_parisite*u.Jy
>     > from specutils import Spectrum1D, SpectralRegion
>     > spectrum = Spectrum1D(spectral_axis = w, flux = spectra_parisite)
>     >
>     > from matplotlib import pyplot as plt
>     > plt.plot(spectrum.spectral_axis, spectrum.flux)
>     > plt.xlabel('Spectral Axis ({})'.format(spectrum.spectral_axis.unit))
>     > plt.ylabel('Flux Axis({})'.format(spectrum.flux.unit))
>     > plt.grid(True)
>     >
>     > from specutils.manipulation import noise_region_uncertainty
>     > noise_region = SpectralRegion(450*u.nm, 2500*u.nm)
>     > spectrum2 = noise_region_uncertainty(spectrum, noise_region)
>     >
>     > from specutils.fitting import find_lines_threshold
>     > lines = find_lines_threshold(spectrum2, noise_factor=0)
>     > lines[lines['line_type'] == 'absorption']
>     > lines[lines['line_type'] == 'emission']
>     >
>     > # Derivative technique
>     > from specutils.fitting import find_lines_derivative
>     > lines = find_lines_derivative(spectrum2, flux_threshold=0)
>     > lines[lines['line_type'] == 'absorption']?
>     >
>     >
>     > However, I get no absorption feature lines. Am I doing something
>     wrong?
>     > The emission zones seem to be alright, but I really need the
>     absorption
>     > loci.
>     > Thank you so much for your help!!
>     > Warm regards,
>     > Angela Rodrigues
>     >
>     > _______________________________________________
>     > AstroPy mailing list
>     > AstroPy at python.org <mailto:AstroPy at python.org>
>     > https://mail.python.org/mailman/listinfo/astropy
>     >
> 
>     -- 
> 
>     Dr. Peter Dzwig
> 

-- 

Dr. Peter Dzwig

From pdzwig at summaventures.com  Thu May 28 10:01:33 2020
From: pdzwig at summaventures.com (Peter Dzwig)
Date: Thu, 28 May 2020 15:01:33 +0100
Subject: [AstroPy] Fwd: Help with finding absorption lines
In-Reply-To: <CAPqNJpuyg7YnxzNDaXAdt_Q_i+ZRq71V5dWEk=TWZR+H-mzMqw@mail.gmail.com>
References: <CACO1jaDx0E-MSN8EYP=9qBBR_-JCfEnS_N7J_5LKbbz9TLH2LA@mail.gmail.com>
 <CACO1jaCmR-Jryy+OQ9nB3bmcmy-TEp6cSANBUzYOivDSpnfqBQ@mail.gmail.com>
 <0a1ff555-121e-ee1d-a9c0-49aca9d51e01@summaventures.com>
 <CACO1jaAT9yN94eewCS3tVvLXe2twAv0gMgXAzFtoonY5+96LoQ@mail.gmail.com>
 <CAPqNJpuyg7YnxzNDaXAdt_Q_i+ZRq71V5dWEk=TWZR+H-mzMqw@mail.gmail.com>
Message-ID: <4f75cd19-3388-b50e-8cae-10d1e35e6033@summaventures.com>

Xavier, Angela,

for absorption lines that looks like a good idea.

I still don't understand why astropy has such difficulties. Anyone any
comments on the code?

Xavier, I will look at ALIS for emission lines.

Peter



On 28/05/2020 13:22, J. Xavier Prochaska wrote:
> Consider
> 
> linetools -- https://github.com/linetools/linetools
> 
> and
> 
> ALIS -- https://github.com/rcooke-ast/ALIS
> 
> Built by scientists who study absorption lines for a living..
> 
> X
> 
> 
> On Thu, May 28, 2020 at 2:55 AM Angela Rodrigues
> <afonsoangelarodrigues at gmail.com
> <mailto:afonsoangelarodrigues at gmail.com>> wrote:
> 
>     Hi Dr. Peter
> 
>     Thank you kindly for your reply.
> 
>     Here's a folder with the file (it's an hdr file):
>     https://drive.google.com/file/d/1Rb25_mzAKq7ZqFI9fPyOX8TnTtspYxpF/view?usp=sharing
> 
>     I am looking for really small shifts that reflect chemistry, and
>     therefore, I cannot just eyeball it, I need the actual values.
>     Indeed it is a complicated task to do without specialized software.
>     Regarding the threshold, I've changed it multiple times between 0
>     and 20, and still no absorption values...
> 
>     Thank you so much for looking into it! :)
> 
> 
>     Peter Dzwig <pdzwig at summaventures.com
>     <mailto:pdzwig at summaventures.com>> escreveu no dia quinta,
>     28/05/2020 ?(s) 19:15:
> 
>         Angela,
> 
>         first thing to be said is that I sympathize. :-)? I have had similar
>         issues although my datasets are very different (QSOs); the second is
>         that I can't open either of your files. Perhaps you tell us what
>         format
>         they are in.
> 
>         I tried running similar code to yours (despite the different
>         context). I
>         found that the answers, from both thresholding and derivative, I got
>         were quite sensitive to the data density per unit wavelength,
>         the amount
>         of noise in the data and the threshold that you set.
> 
>         Unless the data is sufficiently dense both thresholding and
>         derivative
>         will produce inaccurate or even false results.
> 
>         In the end I found the best solution was to make a table of all the
>         lines that I was interested in and simply overplot them on my
>         spectrum.
>         I can then see what's where and (using a combination of astropy and
>         numpy) re-plot and re-examine pertinent parts of the spectrum,
>         but as
>         ever the limiting factor is data density.
> 
>         I guess in your case the lines that you would plot would be Calcium,
>         Cerium, Lanthanum, Carbon, Flourine? - and Neodymium? and some
>         of their
>         molecular forms. Tables for most are available from NIST:
>         https://www.nist.gov/pml/atomic-spectra-database
> 
>         There probably is a best approach - a tutorial would be a good
>         idea -
>         and I will watch this space to see what solutions others offer.
> 
>         Regards,
> 
>         Peter Dzwig
> 
>         On 28/05/2020 08:43, Angela Rodrigues wrote:
>         > Hello,
>         >
>         > I have been trying to use astropy to extract lines of
>         absorption from a
>         > mineral spectrum.
>         > so I have the attached hdr file with the spectral analysis
>         from a mineral.
>         > The code to extract the data from the file is as follows:
>         >
>         > import spectral.io.envi as envi
>         > lib = envi.open('GFZ_HySpex_REMin.hdr')
>         >
>         > a=lib.metadata
>         > wvl = a.get('wavelength')
>         > wvl = [int(float(i)) for i in wvl]
>         >
>         > import matplotlib.pyplot as plt
>         > plt.plot(wvl,spectra[13])
>         >
>         > #grab spectra for parisite
>         > names = lib.names
>         >
>         > spectra_parisite = spectra[8]
>         > plt.plot(wvl, spectra_parisite)
>         >
>         >
>         > I wanted to extract the absorption lines as in the
>         documentation example
>         > here <https://specutils.readthedocs.io/en/stable/fitting.html>.
>         > Here's what I've done:
>         >
>         >
>         > w = np.array(wvl)
>         >
>         > import astropy.units as u
>         > w = w*u.nm
>         > spectra_parisite = spectra_parisite*u.Jy
>         > from specutils import Spectrum1D, SpectralRegion
>         > spectrum = Spectrum1D(spectral_axis = w, flux = spectra_parisite)
>         >
>         > from matplotlib import pyplot as plt
>         > plt.plot(spectrum.spectral_axis, spectrum.flux)
>         > plt.xlabel('Spectral Axis
>         ({})'.format(spectrum.spectral_axis.unit))
>         > plt.ylabel('Flux Axis({})'.format(spectrum.flux.unit))
>         > plt.grid(True)
>         >
>         > from specutils.manipulation import noise_region_uncertainty
>         > noise_region = SpectralRegion(450*u.nm, 2500*u.nm)
>         > spectrum2 = noise_region_uncertainty(spectrum, noise_region)
>         >
>         > from specutils.fitting import find_lines_threshold
>         > lines = find_lines_threshold(spectrum2, noise_factor=0)
>         > lines[lines['line_type'] == 'absorption']
>         > lines[lines['line_type'] == 'emission']
>         >
>         > # Derivative technique
>         > from specutils.fitting import find_lines_derivative
>         > lines = find_lines_derivative(spectrum2, flux_threshold=0)
>         > lines[lines['line_type'] == 'absorption']?
>         >
>         >
>         > However, I get no absorption feature lines. Am I doing
>         something wrong?
>         > The emission zones seem to be alright, but I really need the
>         absorption
>         > loci.
>         > Thank you so much for your help!!
>         > Warm regards,
>         > Angela Rodrigues
>         >
>         > _______________________________________________
>         > AstroPy mailing list
>         > AstroPy at python.org <mailto:AstroPy at python.org>
>         > https://mail.python.org/mailman/listinfo/astropy
>         >
> 
>         -- 
> 
>         Dr. Peter Dzwig
> 
>     _______________________________________________
>     AstroPy mailing list
>     AstroPy at python.org <mailto:AstroPy at python.org>
>     https://mail.python.org/mailman/listinfo/astropy
> 
> 
> 
> -- 
> -- 
> ----------------------------------------------
> J. Xavier Prochaska
> UCO/Lick Observatory
> 1156 High St.
> UC Santa Cruz
> Santa Cruz, CA 95064
> 
> Affiliate of IPMU
> Affiliate of LBNL
> 
> http://www.ucolick.org/~xavier/
> https://aaii.ucsc.edu/
> http://www.ucolick.org/f-4 <https://www.ucolick.org/f-4>
> 
> 831-459-2135 (Direct)
> 831-459-2991 (UCO/Lick Main)
> 831-459-5244 (Fax)
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
> 

-- 

Dr. Peter Dzwig