From rspencercarr at gmail.com  Wed Feb  2 15:11:28 2022
From: rspencercarr at gmail.com (Robert Carr)
Date: Wed, 2 Feb 2022 15:11:28 -0500
Subject: [AstroPy] Vizier.query stopped working properly
Message-ID: <CAP6WE=0WuzsRqwwMQjE5NedC56wwwbmRSoMBNtw-erU2_g7oZQ@mail.gmail.com>

I am going crazy with a problem that should not be a problem at all.  I
have run a section of code successfully probably two or three thousand
times.  Today, it does not work.  The only thing that has changed on my end
is that about a week ago I updated my installed modules in Python.



The relevant section of my code, including installed modules, is:

>>> from astropy.coordinates import SkyCoord

>>> import astropy.units as u

>>> from astroquery.vizier import Vizier

>>>

>>> STAR_NAME = 'J005736.73+120753.3'

>>> field_of_view =0.001

>>> results = Vizier.query_region(STAR_NAME, radius=field_of_view * u.deg,
catalog = 'SDSS12')

>>> results



Until today, this returned coordinates and other information for the target
STAR_NAME.  It now returns:

                >>> Empty TableList



I have upgraded my modules.  I have tried playing with the ?field_of_view?
variable but have not been able to restore the desired behavior where
Vizier returns results just for the target STAR_NAME.  (I use similar code
with different ?field_of_view? elsewhere in my program so I need to fix
this in the general case.)



Incidentally, I ran the sample code from astroquery:docs at
*https://astroquery.readthedocs.io/en/latest/vizier/vizier.html
<https://astroquery.readthedocs.io/en/latest/vizier/vizier.html>*

>>> import astropy.units as u

>>> result = Vizier.query_region("3C 273", radius=0.1*u.deg, catalog='GSC')

>>> result



This is supposed to return:

TableList with 3 tables:

   '0:I/254/out' with 10 column(s) and 17 row(s)

   '1:I/271/out' with 11 column(s) and 50 row(s)

   '2:I/305/out' with 11 column(s) and 50 row(s)



But instead returns:

TableList with 5 tables:

        '0:I/254/out' with 10 column(s) and 17 row(s)

        '1:I/255/out' with 9 column(s) and 17 row(s)

        '2:I/271/out' with 11 column(s) and 53 row(s)

        '3:I/305/out' with 11 column(s) and 206 row(s)

        '4:I/353/gsc242' with 35 column(s) and 5370 row(s)



Does this make any sense?  I appreciate any help!

Bob Carr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220202/a24c1ce9/attachment.html>

From adam.g.ginsburg at gmail.com  Wed Feb  2 15:52:19 2022
From: adam.g.ginsburg at gmail.com (Adam Ginsburg)
Date: Wed, 2 Feb 2022 15:52:19 -0500
Subject: [AstroPy] Vizier.query stopped working properly
In-Reply-To: <CAP6WE=0WuzsRqwwMQjE5NedC56wwwbmRSoMBNtw-erU2_g7oZQ@mail.gmail.com>
References: <CAP6WE=0WuzsRqwwMQjE5NedC56wwwbmRSoMBNtw-erU2_g7oZQ@mail.gmail.com>
Message-ID: <CAEBNSwZWDaEaS2mG-WCymCh3SGrfoQ4C7s7UUy3YKCYXYwcZmA@mail.gmail.com>

Hi Bob,

It might be helpful to post this sort of question as an Issue on the
astroquery github issue tracker (https://github.com/astropy/astroquery).

Anyway, I can't reproduce your exact issue.  When I run your code, I get a
multi-tiered error because the STAR_NAME is being treated as a coordinate:
"ValueError: Cannot parse first argument data "00 57 36.73" for attribute
ra"

This points to the solution: you should be using Vizier.query_object, not
query_region:

In [2]: >>> results = Vizier.query_object(STAR_NAME, radius=field_of_view *
u.deg, catalog = 'SDSS12')

In [3]: results
Out[3]:
TableList with 1 tables:
        '0:V/147/sdss12' with 23 column(s) and 2 row(s)

In [4]: results[0]
Out[4]:
<Table length=2>
 RA_ICRS    DE_ICRS    mode q_mode class        SDSS12       m_SDSS12
 ObsDate    Q     umag   e_umag   gmag   e_gmag   rmag   e_rmag   imag
e_imag   zmag   e_zmag   zsp     zph    e_zph   __zph_
   deg        deg
yr            mag     mag     mag     mag     mag     mag     mag     mag
  mag     mag
 float64    float64   uint8  str1  uint8        str19          str1
 float64  uint8 float32 float32 float32 float32 float32 float32 float32
float32 float32 float32 float64 float64 float64 float32
---------- ---------- ----- ------ ----- ------------------- --------
--------- ----- ------- ------- ------- ------- ------- ------- -------
------- ------- ------- ------- ------- ------- -------
 14.403077  12.131476     1      +     6 J005736.73+120753.3        *
2008.8279     3  18.459   0.018  17.151   0.005  16.611   0.005  16.414
0.006  16.327   0.009      --      --      --      --
 14.403551  12.130666     1            6 J005736.85+120750.3
 2008.8279     3  24.337   0.967  25.347   0.578  23.120   0.277  21.869
0.132  21.272   0.338      --      --      --      --

If you want to use query_region, first use
coordinates.SkyCoord.from_name(STAR_NAME) for the same result:

In [8]: Vizier.query_region(SkyCoord.from_name(STAR_NAME),
radius=field_of_view * u.deg, catalog = 'SDSS12')
Out[8]:
TableList with 1 tables:
        '0:V/147/sdss12' with 23 column(s) and 2 row(s)



The second issue you note is just because new GSC versions have been added
since the documentation was written.  We expect there to be more catalogs
for the same query over time.

On Wed, Feb 2, 2022 at 3:11 PM Robert Carr <rspencercarr at gmail.com> wrote:

> I am going crazy with a problem that should not be a problem at all.  I
> have run a section of code successfully probably two or three thousand
> times.  Today, it does not work.  The only thing that has changed on my end
> is that about a week ago I updated my installed modules in Python.
>
>
>
> The relevant section of my code, including installed modules, is:
>
> >>> from astropy.coordinates import SkyCoord
>
> >>> import astropy.units as u
>
> >>> from astroquery.vizier import Vizier
>
> >>>
>
> >>> STAR_NAME = 'J005736.73+120753.3'
>
> >>> field_of_view =0.001
>
> >>> results = Vizier.query_region(STAR_NAME, radius=field_of_view * u.deg,
> catalog = 'SDSS12')
>
> >>> results
>
>
>
> Until today, this returned coordinates and other information for the
> target STAR_NAME.  It now returns:
>
>                 >>> Empty TableList
>
>
>
> I have upgraded my modules.  I have tried playing with the ?field_of_view?
> variable but have not been able to restore the desired behavior where
> Vizier returns results just for the target STAR_NAME.  (I use similar code
> with different ?field_of_view? elsewhere in my program so I need to fix
> this in the general case.)
>
>
>
> Incidentally, I ran the sample code from astroquery:docs at *https://astroquery.readthedocs.io/en/latest/vizier/vizier.html
> <https://astroquery.readthedocs.io/en/latest/vizier/vizier.html>*
>
> >>> import astropy.units as u
>
> >>> result = Vizier.query_region("3C 273", radius=0.1*u.deg, catalog='GSC')
>
> >>> result
>
>
>
> This is supposed to return:
>
> TableList with 3 tables:
>
>    '0:I/254/out' with 10 column(s) and 17 row(s)
>
>    '1:I/271/out' with 11 column(s) and 50 row(s)
>
>    '2:I/305/out' with 11 column(s) and 50 row(s)
>
>
>
> But instead returns:
>
> TableList with 5 tables:
>
>         '0:I/254/out' with 10 column(s) and 17 row(s)
>
>         '1:I/255/out' with 9 column(s) and 17 row(s)
>
>         '2:I/271/out' with 11 column(s) and 53 row(s)
>
>         '3:I/305/out' with 11 column(s) and 206 row(s)
>
>         '4:I/353/gsc242' with 35 column(s) and 5370 row(s)
>
>
>
> Does this make any sense?  I appreciate any help!
>
> Bob Carr
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Adam Ginsburg
Assistant Professor, Department of Astronomy
University of Florida, Gainesville
http://www.adamgginsburg.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220202/f0cc2d79/attachment-0001.html>

From rspencercarr at gmail.com  Fri Feb  4 12:06:53 2022
From: rspencercarr at gmail.com (Robert Carr)
Date: Fri, 4 Feb 2022 12:06:53 -0500
Subject: [AstroPy] AstroPy Digest, Vol 184, Issue 1
In-Reply-To: <mailman.389.1643835101.2975.astropy@python.org>
References: <mailman.389.1643835101.2975.astropy@python.org>
Message-ID: <CAP6WE=0uCZu_Gh4kARutx4iWCbNJwyJ3poLWfBT_Eyn2_COvRA@mail.gmail.com>

Thank you, Adam, for your guidance on the astroquery GitHub.  I shall make
use of this.

Thank you, too, for suggesting that I employ* Vizier.query_object *in lieu
of *Vizier.query_region*.  This indeed worked.  Problem solved.

Interestingly, my region query format was built upon the example provided
in the instructions as astroquery.vizier which goes
*result = Vizier.query_region("3C 273", radius=0.1*u.deg, catalog='GSC').  *As
I mentioned, this worked perfectly the prior couple thousand runs.  But it
did not work the other day and it does not work today..

I take the moral to be: when you hit your head against the wall and the
wall is winning, look for a way to walk around the wall.  Thank you again
for pointing my way around the wall.

Bob C.


On Wed, Feb 2, 2022 at 3:51 PM <astropy-request at python.org> wrote:

> Send AstroPy mailing list submissions to
>         astropy at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
>         astropy-request at python.org
>
> You can reach the person managing the list at
>         astropy-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
>
>
> Today's Topics:
>
>    1. Vizier.query stopped working properly (Robert Carr)
>    2. Re: Vizier.query stopped working properly (Adam Ginsburg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Feb 2022 15:11:28 -0500
> From: Robert Carr <rspencercarr at gmail.com>
> To: astropy at python.org
> Subject: [AstroPy] Vizier.query stopped working properly
> Message-ID:
>         <CAP6WE=
> 0WuzsRqwwMQjE5NedC56wwwbmRSoMBNtw-erU2_g7oZQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I am going crazy with a problem that should not be a problem at all.  I
> have run a section of code successfully probably two or three thousand
> times.  Today, it does not work.  The only thing that has changed on my end
> is that about a week ago I updated my installed modules in Python.
>
>
>
> The relevant section of my code, including installed modules, is:
>
> >>> from astropy.coordinates import SkyCoord
>
> >>> import astropy.units as u
>
> >>> from astroquery.vizier import Vizier
>
> >>>
>
> >>> STAR_NAME = 'J005736.73+120753.3'
>
> >>> field_of_view =0.001
>
> >>> results = Vizier.query_region(STAR_NAME, radius=field_of_view * u.deg,
> catalog = 'SDSS12')
>
> >>> results
>
>
>
> Until today, this returned coordinates and other information for the target
> STAR_NAME.  It now returns:
>
>                 >>> Empty TableList
>
>
>
> I have upgraded my modules.  I have tried playing with the ?field_of_view?
> variable but have not been able to restore the desired behavior where
> Vizier returns results just for the target STAR_NAME.  (I use similar code
> with different ?field_of_view? elsewhere in my program so I need to fix
> this in the general case.)
>
>
>
> Incidentally, I ran the sample code from astroquery:docs at
> *https://astroquery.readthedocs.io/en/latest/vizier/vizier.html
> <https://astroquery.readthedocs.io/en/latest/vizier/vizier.html>*
>
> >>> import astropy.units as u
>
> >>> result = Vizier.query_region("3C 273", radius=0.1*u.deg, catalog='GSC')
>
> >>> result
>
>
>
> This is supposed to return:
>
> TableList with 3 tables:
>
>    '0:I/254/out' with 10 column(s) and 17 row(s)
>
>    '1:I/271/out' with 11 column(s) and 50 row(s)
>
>    '2:I/305/out' with 11 column(s) and 50 row(s)
>
>
>
> But instead returns:
>
> TableList with 5 tables:
>
>         '0:I/254/out' with 10 column(s) and 17 row(s)
>
>         '1:I/255/out' with 9 column(s) and 17 row(s)
>
>         '2:I/271/out' with 11 column(s) and 53 row(s)
>
>         '3:I/305/out' with 11 column(s) and 206 row(s)
>
>         '4:I/353/gsc242' with 35 column(s) and 5370 row(s)
>
>
>
> Does this make any sense?  I appreciate any help!
>
> Bob Carr
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.python.org/pipermail/astropy/attachments/20220202/a24c1ce9/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 2 Feb 2022 15:52:19 -0500
> From: Adam Ginsburg <adam.g.ginsburg at gmail.com>
> To: Astronomical Python mailing list <astropy at python.org>
> Subject: Re: [AstroPy] Vizier.query stopped working properly
> Message-ID:
>         <
> CAEBNSwZWDaEaS2mG-WCymCh3SGrfoQ4C7s7UUy3YKCYXYwcZmA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Bob,
>
> It might be helpful to post this sort of question as an Issue on the
> astroquery github issue tracker (https://github.com/astropy/astroquery).
>
> Anyway, I can't reproduce your exact issue.  When I run your code, I get a
> multi-tiered error because the STAR_NAME is being treated as a coordinate:
> "ValueError: Cannot parse first argument data "00 57 36.73" for attribute
> ra"
>
> This points to the solution: you should be using Vizier.query_object, not
> query_region:
>
> In [2]: >>> results = Vizier.query_object(STAR_NAME, radius=field_of_view *
> u.deg, catalog = 'SDSS12')
>
> In [3]: results
> Out[3]:
> TableList with 1 tables:
>         '0:V/147/sdss12' with 23 column(s) and 2 row(s)
>
> In [4]: results[0]
> Out[4]:
> <Table length=2>
>  RA_ICRS    DE_ICRS    mode q_mode class        SDSS12       m_SDSS12
>  ObsDate    Q     umag   e_umag   gmag   e_gmag   rmag   e_rmag   imag
> e_imag   zmag   e_zmag   zsp     zph    e_zph   __zph_
>    deg        deg
> yr            mag     mag     mag     mag     mag     mag     mag     mag
>   mag     mag
>  float64    float64   uint8  str1  uint8        str19          str1
>  float64  uint8 float32 float32 float32 float32 float32 float32 float32
> float32 float32 float32 float64 float64 float64 float32
> ---------- ---------- ----- ------ ----- ------------------- --------
> --------- ----- ------- ------- ------- ------- ------- ------- -------
> ------- ------- ------- ------- ------- ------- -------
>  14.403077  12.131476     1      +     6 J005736.73+120753.3        *
> 2008.8279     3  18.459   0.018  17.151   0.005  16.611   0.005  16.414
> 0.006  16.327   0.009      --      --      --      --
>  14.403551  12.130666     1            6 J005736.85+120750.3
>  2008.8279     3  24.337   0.967  25.347   0.578  23.120   0.277  21.869
> 0.132  21.272   0.338      --      --      --      --
>
> If you want to use query_region, first use
> coordinates.SkyCoord.from_name(STAR_NAME) for the same result:
>
> In [8]: Vizier.query_region(SkyCoord.from_name(STAR_NAME),
> radius=field_of_view * u.deg, catalog = 'SDSS12')
> Out[8]:
> TableList with 1 tables:
>         '0:V/147/sdss12' with 23 column(s) and 2 row(s)
>
>
>
> The second issue you note is just because new GSC versions have been added
> since the documentation was written.  We expect there to be more catalogs
> for the same query over time.
>
> On Wed, Feb 2, 2022 at 3:11 PM Robert Carr <rspencercarr at gmail.com> wrote:
>
> > I am going crazy with a problem that should not be a problem at all.  I
> > have run a section of code successfully probably two or three thousand
> > times.  Today, it does not work.  The only thing that has changed on my
> end
> > is that about a week ago I updated my installed modules in Python.
> >
> >
> >
> > The relevant section of my code, including installed modules, is:
> >
> > >>> from astropy.coordinates import SkyCoord
> >
> > >>> import astropy.units as u
> >
> > >>> from astroquery.vizier import Vizier
> >
> > >>>
> >
> > >>> STAR_NAME = 'J005736.73+120753.3'
> >
> > >>> field_of_view =0.001
> >
> > >>> results = Vizier.query_region(STAR_NAME, radius=field_of_view *
> u.deg,
> > catalog = 'SDSS12')
> >
> > >>> results
> >
> >
> >
> > Until today, this returned coordinates and other information for the
> > target STAR_NAME.  It now returns:
> >
> >                 >>> Empty TableList
> >
> >
> >
> > I have upgraded my modules.  I have tried playing with the
> ?field_of_view?
> > variable but have not been able to restore the desired behavior where
> > Vizier returns results just for the target STAR_NAME.  (I use similar
> code
> > with different ?field_of_view? elsewhere in my program so I need to fix
> > this in the general case.)
> >
> >
> >
> > Incidentally, I ran the sample code from astroquery:docs at *
> https://astroquery.readthedocs.io/en/latest/vizier/vizier.html
> > <https://astroquery.readthedocs.io/en/latest/vizier/vizier.html>*
> >
> > >>> import astropy.units as u
> >
> > >>> result = Vizier.query_region("3C 273", radius=0.1*u.deg,
> catalog='GSC')
> >
> > >>> result
> >
> >
> >
> > This is supposed to return:
> >
> > TableList with 3 tables:
> >
> >    '0:I/254/out' with 10 column(s) and 17 row(s)
> >
> >    '1:I/271/out' with 11 column(s) and 50 row(s)
> >
> >    '2:I/305/out' with 11 column(s) and 50 row(s)
> >
> >
> >
> > But instead returns:
> >
> > TableList with 5 tables:
> >
> >         '0:I/254/out' with 10 column(s) and 17 row(s)
> >
> >         '1:I/255/out' with 9 column(s) and 17 row(s)
> >
> >         '2:I/271/out' with 11 column(s) and 53 row(s)
> >
> >         '3:I/305/out' with 11 column(s) and 206 row(s)
> >
> >         '4:I/353/gsc242' with 35 column(s) and 5370 row(s)
> >
> >
> >
> > Does this make any sense?  I appreciate any help!
> >
> > Bob Carr
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at python.org
> > https://mail.python.org/mailman/listinfo/astropy
> >
>
>
> --
> Adam Ginsburg
> Assistant Professor, Department of Astronomy
> University of Florida, Gainesville
> http://www.adamgginsburg.com/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mail.python.org/pipermail/astropy/attachments/20220202/f0cc2d79/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
>
> ------------------------------
>
> End of AstroPy Digest, Vol 184, Issue 1
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220204/cc3a6609/attachment-0001.html>

From Nathaniel.J.Livesey at jpl.nasa.gov  Sun Feb  6 17:14:47 2022
From: Nathaniel.J.Livesey at jpl.nasa.gov (Nathaniel J Livesey)
Date: Sun, 6 Feb 2022 14:14:47 -0800
Subject: [AstroPy] astropy Quantity, dask serializer conflict?
Message-ID: <DCB7148D-2A40-4CC6-9354-F309B68722F3@jpl.nasa.gov>

Dear all,

   I?m encountering issues with mixing dask and astropy Quantity.  If I run an astropy Quantity instance through the default dask serializer/deserializer, what emerges is a ndarray.  To make it work I have to disable the ?dask? serializer method and have it use only the ?pickle? one.

   See the MWE below:
==============
import astropy.units as units
import dask.distributed as distributed
import numpy as np

x = np.arange(5) << units.s
print(f"Input is {type(x)}: {x}")

# In the first case, serializers defaults to ["dask", "pickle"]
header, frames = distributed.protocol.serialize(x)
y = distributed.protocol.deserialize(header, frames)
print(f"Default serialization gives {type(y)}: {y}")

# Here we disable the "dask" serializer
header, frames = distributed.protocol.serialize(x, serializers=["pickle"])
y = distributed.protocol.deserialize(header, frames)
print(f"With dask serialization disabled we get {type(y)}: {y}")
===============

Which results in:

Input is <class 'astropy.units.quantity.Quantity'>: [0. 1. 2. 3. 4.] s
Default serialization gives <class 'numpy.ndarray'>: [0. 1. 2. 3. 4.]
With dask serialization disabled we get <class 'astropy.units.quantity.Quantity'>: [0. 1. 2. 3. 4.] s

===============
I?m currently running astropy 4.3.1, but the same thing happens with the latest version from github.  I?m using python 3.9, dask 2021.10.0 and numpy 1.20.3

Many thanks for any pointers.

Yours,

Nathaniel

P.S. I have a work around that disables the ?dask? serializer when I start the dask Client.  However, that sometimes doesn?t work because something else (I suspect xarray) seems to overwrite that setting.

Nathaniel Livesey
Mail Stop 183-701, Jet Propulsion Laboratory
4800 Oak Grove Drive, Pasadena, California 91109.
Phone: +1 818 354-4214   Fax: +1 818 393-5065


From mirosaide at gmail.com  Fri Feb 11 05:49:37 2022
From: mirosaide at gmail.com (Miro Saide)
Date: Fri, 11 Feb 2022 14:49:37 +0400
Subject: [AstroPy] How to separate %H %M %S in LST CALCULATION
Message-ID: <CAAtcJ92zgtSMr2VUgng_SkqDHLo1iLKCYvr9E1=yrMw8bSvB2w@mail.gmail.com>

Hi all

I am calculating local sidereal time and I wonder how can I split the
output to have hours, minutes and seconds and the put it in iso format.
The code example is below:

import numpy as np
import astropy.units as u
from astropy.time import Time
from astropy.coordinates import SkyCoord, EarthLocation, AltAz
from astroplan import Observer, FixedTarget

target = SkyCoord.from_name("Barnard's star")
time = Time("2021-9-21 00:00:00", scale='utc')
Location = Observer(latitude=65.033*u.deg, longitude=-18.536*u.deg)

star_rise_time = Location.target_rise_time(time, target, which='previous')
star_set_time = Location.target_set_time(time, target, which='next')

print(star_rise_time.iso)
print(star_set_time.iso)

time_LST_rise = Location.local_sidereal_time(star_rise_time,'mean',
model=None)
time_LST_set = Location.local_sidereal_time(star_set_time,'mean',
model=None)
print(time_LST_rise)
print(time_LST_set)

Thanks in advance.

*Ramiro Caisse Saide*
*MPhil Research Student*
Department of Physics
University of Mauritius
Contact Number: +258 845672884
Email: ramiro.saide at umail.uom.mu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220211/30998e5c/attachment.html>

From m.shemuni at gmail.com  Sat Feb 12 18:49:33 2022
From: m.shemuni at gmail.com (Mohammad Shameoni Niaei)
Date: Sun, 13 Feb 2022 02:49:33 +0300
Subject: [AstroPy] How to separate %H %M %S in LST CALCULATION
In-Reply-To: <CAAtcJ92zgtSMr2VUgng_SkqDHLo1iLKCYvr9E1=yrMw8bSvB2w@mail.gmail.com>
References: <CAAtcJ92zgtSMr2VUgng_SkqDHLo1iLKCYvr9E1=yrMw8bSvB2w@mail.gmail.com>
Message-ID: <CAAXud8McKkELkPMF3GSwdOMaywXd0HLbY4wAg62QEYvnxapg=Q@mail.gmail.com>

Hello Mario

Since the time_LST_set is an hourangle type, you can use hms to return it
as an hms_tuple.

The hms_tuple has h, m and s attributes which I believe is what you are
looking for.

print(time_LST_rise.hms)
print(time_LST_rise.hms.h)
print(time_LST_rise.hms.m)
print(time_LST_rise.hms.s)

see:
https://docs.astropy.org/en/stable/_modules/astropy/coordinates/angles.html









On Fri, Feb 11, 2022 at 1:50 PM Miro Saide <mirosaide at gmail.com> wrote:

> Hi all
>
> I am calculating local sidereal time and I wonder how can I split the
> output to have hours, minutes and seconds and the put it in iso format.
> The code example is below:
>
> import numpy as np
> import astropy.units as u
> from astropy.time import Time
> from astropy.coordinates import SkyCoord, EarthLocation, AltAz
> from astroplan import Observer, FixedTarget
>
> target = SkyCoord.from_name("Barnard's star")
> time = Time("2021-9-21 00:00:00", scale='utc')
> Location = Observer(latitude=65.033*u.deg, longitude=-18.536*u.deg)
>
> star_rise_time = Location.target_rise_time(time, target, which='previous')
> star_set_time = Location.target_set_time(time, target, which='next')
>
> print(star_rise_time.iso)
> print(star_set_time.iso)
>
> time_LST_rise = Location.local_sidereal_time(star_rise_time,'mean',
> model=None)
> time_LST_set = Location.local_sidereal_time(star_set_time,'mean',
> model=None)
> print(time_LST_rise)
> print(time_LST_set)
>
> Thanks in advance.
>
> *Ramiro Caisse Saide*
> *MPhil Research Student*
> Department of Physics
> University of Mauritius
> Contact Number: +258 845672884
> Email: ramiro.saide at umail.uom.mu
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>


-- 
Mohammad Shameoni Niaei
Astronomer
Atat?rk University, Astrophysics Research and Application Center.
ERZURUM-TURKEY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220213/64d6fc52/attachment.html>

From mirosaide at gmail.com  Tue Feb 15 11:16:53 2022
From: mirosaide at gmail.com (Miro Saide)
Date: Tue, 15 Feb 2022 20:16:53 +0400
Subject: [AstroPy] How to separate %H %M %S in LST CALCULATION
In-Reply-To: <CAAXud8McKkELkPMF3GSwdOMaywXd0HLbY4wAg62QEYvnxapg=Q@mail.gmail.com>
References: <CAAtcJ92zgtSMr2VUgng_SkqDHLo1iLKCYvr9E1=yrMw8bSvB2w@mail.gmail.com>
 <CAAXud8McKkELkPMF3GSwdOMaywXd0HLbY4wAg62QEYvnxapg=Q@mail.gmail.com>
Message-ID: <CAAtcJ91c=mPNQQ4G_ePyZgi5G4a-rHmRk7qc4cCJAErXwiQg-g@mail.gmail.com>

Thanks, Mohammad

It works.



*Ramiro Caisse Saide*
*MPhil Research Student*
Department of Physics
University of Mauritius
Contact Number: +258 845672884
Email: ramiro.saide at umail.uom.mu




Mohammad Shameoni Niaei <m.shemuni at gmail.com> escreveu no dia domingo,
13/02/2022 ?(s) 03:50:

> Hello Mario
>
> Since the time_LST_set is an hourangle type, you can use hms to return it
> as an hms_tuple.
>
> The hms_tuple has h, m and s attributes which I believe is what you are
> looking for.
>
> print(time_LST_rise.hms)
> print(time_LST_rise.hms.h)
> print(time_LST_rise.hms.m)
> print(time_LST_rise.hms.s)
>
> see:
> https://docs.astropy.org/en/stable/_modules/astropy/coordinates/angles.html
>
>
>
>
>
>
>
>
>
> On Fri, Feb 11, 2022 at 1:50 PM Miro Saide <mirosaide at gmail.com> wrote:
>
>> Hi all
>>
>> I am calculating local sidereal time and I wonder how can I split the
>> output to have hours, minutes and seconds and the put it in iso format.
>> The code example is below:
>>
>> import numpy as np
>> import astropy.units as u
>> from astropy.time import Time
>> from astropy.coordinates import SkyCoord, EarthLocation, AltAz
>> from astroplan import Observer, FixedTarget
>>
>> target = SkyCoord.from_name("Barnard's star")
>> time = Time("2021-9-21 00:00:00", scale='utc')
>> Location = Observer(latitude=65.033*u.deg, longitude=-18.536*u.deg)
>>
>> star_rise_time = Location.target_rise_time(time, target, which='previous')
>> star_set_time = Location.target_set_time(time, target, which='next')
>>
>> print(star_rise_time.iso)
>> print(star_set_time.iso)
>>
>> time_LST_rise = Location.local_sidereal_time(star_rise_time,'mean',
>> model=None)
>> time_LST_set = Location.local_sidereal_time(star_set_time,'mean',
>> model=None)
>> print(time_LST_rise)
>> print(time_LST_set)
>>
>> Thanks in advance.
>>
>> *Ramiro Caisse Saide*
>> *MPhil Research Student*
>> Department of Physics
>> University of Mauritius
>> Contact Number: +258 845672884
>> Email: ramiro.saide at umail.uom.mu
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
>>
>
>
> --
> Mohammad Shameoni Niaei
> Astronomer
> Atat?rk University, Astrophysics Research and Application Center.
> ERZURUM-TURKEY
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220215/6d7e063e/attachment.html>

From m.shemuni at gmail.com  Tue Feb 15 12:01:39 2022
From: m.shemuni at gmail.com (Mohammad Shameoni Niaei)
Date: Tue, 15 Feb 2022 20:01:39 +0300
Subject: [AstroPy] How to separate %H %M %S in LST CALCULATION
In-Reply-To: <CAAtcJ91c=mPNQQ4G_ePyZgi5G4a-rHmRk7qc4cCJAErXwiQg-g@mail.gmail.com>
References: <CAAtcJ92zgtSMr2VUgng_SkqDHLo1iLKCYvr9E1=yrMw8bSvB2w@mail.gmail.com>
 <CAAXud8McKkELkPMF3GSwdOMaywXd0HLbY4wAg62QEYvnxapg=Q@mail.gmail.com>
 <CAAtcJ91c=mPNQQ4G_ePyZgi5G4a-rHmRk7qc4cCJAErXwiQg-g@mail.gmail.com>
Message-ID: <CAAXud8P7GPkzvLM06e6b8bhe70RR19YxAua6V3wJHO-drKou1w@mail.gmail.com>

You're welcome. And I wish to apologise for misspell your name.

On Tue, 15 Feb 2022, 19:17 Miro Saide, <mirosaide at gmail.com> wrote:

> Thanks, Mohammad
>
> It works.
>
>
>
> *Ramiro Caisse Saide*
> *MPhil Research Student*
> Department of Physics
> University of Mauritius
> Contact Number: +258 845672884
> Email: ramiro.saide at umail.uom.mu
>
>
>
>
> Mohammad Shameoni Niaei <m.shemuni at gmail.com> escreveu no dia domingo,
> 13/02/2022 ?(s) 03:50:
>
>> Hello Mario
>>
>> Since the time_LST_set is an hourangle type, you can use hms to return
>> it as an hms_tuple.
>>
>> The hms_tuple has h, m and s attributes which I believe is what you are
>> looking for.
>>
>> print(time_LST_rise.hms)
>> print(time_LST_rise.hms.h)
>> print(time_LST_rise.hms.m)
>> print(time_LST_rise.hms.s)
>>
>> see:
>> https://docs.astropy.org/en/stable/_modules/astropy/coordinates/angles.html
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 11, 2022 at 1:50 PM Miro Saide <mirosaide at gmail.com> wrote:
>>
>>> Hi all
>>>
>>> I am calculating local sidereal time and I wonder how can I split the
>>> output to have hours, minutes and seconds and the put it in iso format.
>>> The code example is below:
>>>
>>> import numpy as np
>>> import astropy.units as u
>>> from astropy.time import Time
>>> from astropy.coordinates import SkyCoord, EarthLocation, AltAz
>>> from astroplan import Observer, FixedTarget
>>>
>>> target = SkyCoord.from_name("Barnard's star")
>>> time = Time("2021-9-21 00:00:00", scale='utc')
>>> Location = Observer(latitude=65.033*u.deg, longitude=-18.536*u.deg)
>>>
>>> star_rise_time = Location.target_rise_time(time, target,
>>> which='previous')
>>> star_set_time = Location.target_set_time(time, target, which='next')
>>>
>>> print(star_rise_time.iso)
>>> print(star_set_time.iso)
>>>
>>> time_LST_rise = Location.local_sidereal_time(star_rise_time,'mean',
>>> model=None)
>>> time_LST_set = Location.local_sidereal_time(star_set_time,'mean',
>>> model=None)
>>> print(time_LST_rise)
>>> print(time_LST_set)
>>>
>>> Thanks in advance.
>>>
>>> *Ramiro Caisse Saide*
>>> *MPhil Research Student*
>>> Department of Physics
>>> University of Mauritius
>>> Contact Number: +258 845672884
>>> Email: ramiro.saide at umail.uom.mu
>>>
>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at python.org
>>> https://mail.python.org/mailman/listinfo/astropy
>>>
>>
>>
>> --
>> Mohammad Shameoni Niaei
>> Astronomer
>> Atat?rk University, Astrophysics Research and Application Center.
>> ERZURUM-TURKEY
>> _______________________________________________
>> 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: <https://mail.python.org/pipermail/astropy/attachments/20220215/59c126d4/attachment.html>

From mirosaide at gmail.com  Tue Feb 15 12:17:47 2022
From: mirosaide at gmail.com (Miro Saide)
Date: Tue, 15 Feb 2022 21:17:47 +0400
Subject: [AstroPy] How to separate %H %M %S in LST CALCULATION
In-Reply-To: <CAAXud8P7GPkzvLM06e6b8bhe70RR19YxAua6V3wJHO-drKou1w@mail.gmail.com>
References: <CAAtcJ92zgtSMr2VUgng_SkqDHLo1iLKCYvr9E1=yrMw8bSvB2w@mail.gmail.com>
 <CAAXud8McKkELkPMF3GSwdOMaywXd0HLbY4wAg62QEYvnxapg=Q@mail.gmail.com>
 <CAAtcJ91c=mPNQQ4G_ePyZgi5G4a-rHmRk7qc4cCJAErXwiQg-g@mail.gmail.com>
 <CAAXud8P7GPkzvLM06e6b8bhe70RR19YxAua6V3wJHO-drKou1w@mail.gmail.com>
Message-ID: <CAAtcJ90Ttk8f-mi3gGqH+8zMcH2OXd0E3W6VUmrVrxc4_d-unA@mail.gmail.com>

Never mind.

barak allah

*Ramiro Caisse Saide*
*MPhil Research Student*
Department of Physics
University of Mauritius
Contact Number: +258 845672884
Email: ramiro.saide at umail.uom.mu




Mohammad Shameoni Niaei <m.shemuni at gmail.com> escreveu no dia ter?a,
15/02/2022 ?(s) 21:02:

> You're welcome. And I wish to apologise for misspell your name.
>
> On Tue, 15 Feb 2022, 19:17 Miro Saide, <mirosaide at gmail.com> wrote:
>
>> Thanks, Mohammad
>>
>> It works.
>>
>>
>>
>> *Ramiro Caisse Saide*
>> *MPhil Research Student*
>> Department of Physics
>> University of Mauritius
>> Contact Number: +258 845672884
>> Email: ramiro.saide at umail.uom.mu
>>
>>
>>
>>
>> Mohammad Shameoni Niaei <m.shemuni at gmail.com> escreveu no dia domingo,
>> 13/02/2022 ?(s) 03:50:
>>
>>> Hello Mario
>>>
>>> Since the time_LST_set is an hourangle type, you can use hms to return
>>> it as an hms_tuple.
>>>
>>> The hms_tuple has h, m and s attributes which I believe is what you are
>>> looking for.
>>>
>>> print(time_LST_rise.hms)
>>> print(time_LST_rise.hms.h)
>>> print(time_LST_rise.hms.m)
>>> print(time_LST_rise.hms.s)
>>>
>>> see:
>>> https://docs.astropy.org/en/stable/_modules/astropy/coordinates/angles.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Feb 11, 2022 at 1:50 PM Miro Saide <mirosaide at gmail.com> wrote:
>>>
>>>> Hi all
>>>>
>>>> I am calculating local sidereal time and I wonder how can I split the
>>>> output to have hours, minutes and seconds and the put it in iso format.
>>>> The code example is below:
>>>>
>>>> import numpy as np
>>>> import astropy.units as u
>>>> from astropy.time import Time
>>>> from astropy.coordinates import SkyCoord, EarthLocation, AltAz
>>>> from astroplan import Observer, FixedTarget
>>>>
>>>> target = SkyCoord.from_name("Barnard's star")
>>>> time = Time("2021-9-21 00:00:00", scale='utc')
>>>> Location = Observer(latitude=65.033*u.deg, longitude=-18.536*u.deg)
>>>>
>>>> star_rise_time = Location.target_rise_time(time, target,
>>>> which='previous')
>>>> star_set_time = Location.target_set_time(time, target, which='next')
>>>>
>>>> print(star_rise_time.iso)
>>>> print(star_set_time.iso)
>>>>
>>>> time_LST_rise = Location.local_sidereal_time(star_rise_time,'mean',
>>>> model=None)
>>>> time_LST_set = Location.local_sidereal_time(star_set_time,'mean',
>>>> model=None)
>>>> print(time_LST_rise)
>>>> print(time_LST_set)
>>>>
>>>> Thanks in advance.
>>>>
>>>> *Ramiro Caisse Saide*
>>>> *MPhil Research Student*
>>>> Department of Physics
>>>> University of Mauritius
>>>> Contact Number: +258 845672884
>>>> Email: ramiro.saide at umail.uom.mu
>>>>
>>>>
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at python.org
>>>> https://mail.python.org/mailman/listinfo/astropy
>>>>
>>>
>>>
>>> --
>>> Mohammad Shameoni Niaei
>>> Astronomer
>>> Atat?rk University, Astrophysics Research and Application Center.
>>> ERZURUM-TURKEY
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220215/36b5c38e/attachment-0001.html>

From rspencercarr at gmail.com  Sat Feb 26 14:56:22 2022
From: rspencercarr at gmail.com (Robert Carr)
Date: Sat, 26 Feb 2022 14:56:22 -0500
Subject: [AstroPy] A Mystery: DAOStarFinder Not Finding an Obvious Star in
 Just One Image
Message-ID: <CAP6WE=1Y+FmkBBc_CX=8MN7eWcUvxx+=nLJ=gKWZEivqT9rqug@mail.gmail.com>

I am hoping for help with a mystery!

I am mystified by a problem with DAOStarFinder.  DAOStarFinder has seemed
to be working flawlessly.  But a couple days ago I was surprised to
discover that it refused to find a target in one of my images.  The target
is bright: 15.3 magnitude in g with a peak flux of about 350.  The star's
image is quite round.  DAOStarFinder has no problem finding other stars of
comparable luminosity, as well as a great number of brighter and dimmer
stars, all the way down to about 38.  DAOStarFinder finds the star in
other better and worse frames.  But it refuses to find my target in just
this one image!  Why?!  This is completely maddening.  And worrying: what
else might it be missing?

The relevant code is very simple.  I have set few options for DAOStarFinder:
>>from photutils import DAOStarFinder
>>fwhm = hdulist[0].header['FWHM']*2.5
>>source_snr = 1.5
>>bkg_sigma = mad_std(data)
>>daofind = DAOStarFinder(fwhm=fwhm, threshold=source_snr*bkg_sigma)
>>sources = daofind(data)

The numbers above work out to be:
- fwhm = 4.76 * 2.5 = 11.9
- bkg_sigma = 8.9
- threshold = 13.3

I have tried playing with the above settings with no effect.  I have
rounded up the usual suspects but the mystery remains.  It is like the star
has a cloak of invisibility when it comes to DAOStarFinder for just this
image!

Clues and leads on solving my mystery are very much appreciated.  Thank you!

Bob Carr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220226/982b0ec2/attachment.html>

From ejensen1 at swarthmore.edu  Sat Feb 26 15:30:00 2022
From: ejensen1 at swarthmore.edu (Eric Jensen)
Date: Sat, 26 Feb 2022 15:30:00 -0500
Subject: [AstroPy] A Mystery: DAOStarFinder Not Finding an Obvious Star
 in Just One Image
In-Reply-To: <CAP6WE=1Y+FmkBBc_CX=8MN7eWcUvxx+=nLJ=gKWZEivqT9rqug@mail.gmail.com>
References: <CAP6WE=1Y+FmkBBc_CX=8MN7eWcUvxx+=nLJ=gKWZEivqT9rqug@mail.gmail.com>
Message-ID: <1C47F886-F684-40F6-94C4-8D4D4E69AF98@swarthmore.edu>

Hi Bob, 

You might take a look at the individual pixel values for that star in that particular image - I wonder if it might have a cosmic ray hit or some other anomaly in the pixel values that might cause it to be rejected, for example by exceeding the ?peakmax? setting, or by throwing off the roundness or sharpness values. 

Just a thought - 

Eric


> On Feb 26, 2022, at 2:56 PM, Robert Carr <rspencercarr at gmail.com> wrote:
> 
> I am hoping for help with a mystery!
> 
> I am mystified by a problem with DAOStarFinder.  DAOStarFinder has seemed to be working flawlessly.  But a couple days ago I was surprised to discover that it refused to find a target in one of my images.  The target is bright: 15.3 magnitude in g with a peak flux of about 350.  The star's image is quite round.  DAOStarFinder has no problem finding other stars of comparable luminosity, as well as a great number of brighter and dimmer stars, all the way down to about 38.  DAOStarFinder finds the star in other better and worse frames.  But it refuses to find my target in just this one image!  Why?!  This is completely maddening.  And worrying: what else might it be missing?
> 
> The relevant code is very simple.  I have set few options for DAOStarFinder:
> >>from photutils import DAOStarFinder
> >>fwhm = hdulist[0].header['FWHM']*2.5
> >>source_snr = 1.5
> >>bkg_sigma = mad_std(data)    
> >>daofind = DAOStarFinder(fwhm=fwhm, threshold=source_snr*bkg_sigma)    
> >>sources = daofind(data) 
> 
> The numbers above work out to be:
> - fwhm = 4.76 * 2.5 = 11.9
> - bkg_sigma = 8.9
> - threshold = 13.3
> 
> I have tried playing with the above settings with no effect.  I have rounded up the usual suspects but the mystery remains.  It is like the star has a cloak of invisibility when it comes to DAOStarFinder for just this image!  
> 
> Clues and leads on solving my mystery are very much appreciated.  Thank you!
> 
> Bob Carr


From larry.bradley at gmail.com  Mon Feb 28 09:30:49 2022
From: larry.bradley at gmail.com (Larry Bradley)
Date: Mon, 28 Feb 2022 09:30:49 -0500
Subject: [AstroPy] A Mystery: DAOStarFinder Not Finding an Obvious Star
 in Just One Image
In-Reply-To: <1C47F886-F684-40F6-94C4-8D4D4E69AF98@swarthmore.edu>
References: <CAP6WE=1Y+FmkBBc_CX=8MN7eWcUvxx+=nLJ=gKWZEivqT9rqug@mail.gmail.com>
 <1C47F886-F684-40F6-94C4-8D4D4E69AF98@swarthmore.edu>
Message-ID: <CAFfmSa2sLeg7pBHWjTGQOCdtzJt6RWeNpKiYcW2FqvLzhWnNyA@mail.gmail.com>

Bob,

As Eric suggested, it could be rejected because of the sharpness,
roundness, or peakmax criteria.  You could test that by relaxing those
bounds.

The other reason it could be rejected is because the threshold is too
high.  Actually, it's the combination of threshold and fwhm that matter
here because the thresholding is performed on the convolved image (e.g., as
you increase the fwhm, you generally need to lower the threshold).  The
first thing I would try here is lowering the threshold.

Larry

On Sat, Feb 26, 2022 at 3:30 PM Eric Jensen <ejensen1 at swarthmore.edu> wrote:

> Hi Bob,
>
> You might take a look at the individual pixel values for that star in that
> particular image - I wonder if it might have a cosmic ray hit or some other
> anomaly in the pixel values that might cause it to be rejected, for example
> by exceeding the ?peakmax? setting, or by throwing off the roundness or
> sharpness values.
>
> Just a thought -
>
> Eric
>
>
> > On Feb 26, 2022, at 2:56 PM, Robert Carr <rspencercarr at gmail.com> wrote:
> >
> > I am hoping for help with a mystery!
> >
> > I am mystified by a problem with DAOStarFinder.  DAOStarFinder has
> seemed to be working flawlessly.  But a couple days ago I was surprised to
> discover that it refused to find a target in one of my images.  The target
> is bright: 15.3 magnitude in g with a peak flux of about 350.  The star's
> image is quite round.  DAOStarFinder has no problem finding other stars of
> comparable luminosity, as well as a great number of brighter and dimmer
> stars, all the way down to about 38.  DAOStarFinder finds the star in other
> better and worse frames.  But it refuses to find my target in just this one
> image!  Why?!  This is completely maddening.  And worrying: what else might
> it be missing?
> >
> > The relevant code is very simple.  I have set few options for
> DAOStarFinder:
> > >>from photutils import DAOStarFinder
> > >>fwhm = hdulist[0].header['FWHM']*2.5
> > >>source_snr = 1.5
> > >>bkg_sigma = mad_std(data)
> > >>daofind = DAOStarFinder(fwhm=fwhm, threshold=source_snr*bkg_sigma)
> > >>sources = daofind(data)
> >
> > The numbers above work out to be:
> > - fwhm = 4.76 * 2.5 = 11.9
> > - bkg_sigma = 8.9
> > - threshold = 13.3
> >
> > I have tried playing with the above settings with no effect.  I have
> rounded up the usual suspects but the mystery remains.  It is like the star
> has a cloak of invisibility when it comes to DAOStarFinder for just this
> image!
> >
> > Clues and leads on solving my mystery are very much appreciated.  Thank
> you!
> >
> > Bob Carr
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220228/0211719d/attachment.html>

From rspencercarr at gmail.com  Mon Feb 28 12:27:07 2022
From: rspencercarr at gmail.com (Robert Carr)
Date: Mon, 28 Feb 2022 12:27:07 -0500
Subject: [AstroPy] A Mystery: DAOStarFinder Not Finding an Obvious Star
 in Just One Image
Message-ID: <CAP6WE=3pSKWOYpb_pVqV8+W_q4j5ZRGBUabmDQM3p+s647JcqQ@mail.gmail.com>

Thank you to Eric and Larry for their helpful tips. The Obvious Star is
obviously about perfectly round and so I was not surprised that
revising roundlo and roundhi did not uncloak my object.  The pixel-by-pixel
inspection suggested by Eric, however, revealed that the pixel values were
rather constant across much of the object and then dropped off sharply
toward the edges.  This was distinctly non-Gaussian.  I had naively assumed
that the default values of DAOStarFinder were the least restrictive ones
but a little education can be a marvelous thing.  Revising the sharpness
parameters sharplo and sharphi caused DAOStarFinder to "discover" a great
number of additional objects in the image, some of them real and one of
them my Obvious Star!

Thank you so much for your help!

Bob Carr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20220228/5f4658ce/attachment.html>

From ejensen1 at swarthmore.edu  Mon Feb 28 13:35:40 2022
From: ejensen1 at swarthmore.edu (Eric L. N. Jensen)
Date: Mon, 28 Feb 2022 13:35:40 -0500
Subject: [AstroPy] A Mystery: DAOStarFinder Not Finding an Obvious Star
 in Just One Image
In-Reply-To: <CAP6WE=3pSKWOYpb_pVqV8+W_q4j5ZRGBUabmDQM3p+s647JcqQ@mail.gmail.com>
References: <CAP6WE=3pSKWOYpb_pVqV8+W_q4j5ZRGBUabmDQM3p+s647JcqQ@mail.gmail.com>
Message-ID: <8A01496C-4DA1-4FC5-AB36-02281EB726CF@swarthmore.edu>


> On Feb 28, 2022, at 12:27 PM, Robert Carr <rspencercarr at gmail.com> wrote:
> 
> The pixel-by-pixel inspection suggested by Eric, however, revealed that the pixel values were rather constant across much of the object and then dropped off sharply toward the edges.  

This sounds like you may have stars that are saturated, in which case the default parameters will indeed not perform very well (as you discovered!)

Eric


From pdzwig at summaventures.com  Mon Feb 28 14:46:15 2022
From: pdzwig at summaventures.com (Peter Dzwig)
Date: Mon, 28 Feb 2022 19:46:15 +0000
Subject: [AstroPy] A Mystery: DAOStarFinder Not Finding an Obvious Star
 in Just One Image
In-Reply-To: <CAP6WE=3pSKWOYpb_pVqV8+W_q4j5ZRGBUabmDQM3p+s647JcqQ@mail.gmail.com>
References: <CAP6WE=3pSKWOYpb_pVqV8+W_q4j5ZRGBUabmDQM3p+s647JcqQ@mail.gmail.com>
Message-ID: <e219489b-e804-b3f0-ad08-bd8a264ad05a@summaventures.com>

Is this issue something that could/should be mentioned in the manual(s)?

Peter Dzwig

On 28/02/2022 17:27, Robert Carr wrote:
> Thank you to Eric and Larry for their helpful tips. The?Obvious Star is 
> obviously about perfectly?round and so I was not surprised that 
> revising?roundlo and roundhi?did not uncloak my object.? The 
> pixel-by-pixel inspection suggested by Eric, however, revealed that the 
> pixel values were rather constant across much of the object and then 
> dropped off sharply toward the edges.? This was distinctly 
> non-Gaussian.? I had naively assumed that the default values of 
> DAOStarFinder were the least restrictive ones but a little education can 
> be a marvelous thing.? Revising the sharpness parameters sharplo and 
> sharphi?caused DAOStarFinder to "discover" a great number of additional 
> objects in the image, some of them real and one of them my Obvious Star!
> 
> Thank you so much for your help!
> 
> Bob Carr
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at python.org
> https://mail.python.org/mailman/listinfo/astropy

-- 

Dr. Peter Dzwig