Hot answers tagged

11

In Astropy, u.G represents a Gauss, not the gravitational constant. That's why you get the "A" in one of the error messages; it represents an ampere. To use the gravitational constant in your code, you need to use astropy.constants and replace u.G in your code with constants.G (or just add import astropy.constants as c and use c.G, if you prefer).


8

The fringing pattern is caused by thin-film interference within the CCD. The signal received in a pixel will be proportional to the light falling on it, multiplied by a sensitivity, but then some extra signal is added or subtracted which depends on how much of the incoming light is at particular wavelengths that are affected by the interference (i.e. the ...


6

This code reads coordinates as equatorial (ra, dec) and transforms them to galactic (l, b): eq = SkyCoord(xarr[:], yarr[:], unit=u.deg) gal = eq.galactic The contents of 'galacticwperiod.csv' are already in galactic coordinates and should not be transformed. Something like this may give better results: gal = SkyCoord(xarr[:], yarr[:], frame='galactic', ...


5

The visual appearance of fringing is caused by the CCD (thickness) being comparable to the size of the wavelength (thin-film interference). An everyday example (same physics except with more colors) is an oilslick one sees in a puddle. The wavelengths of visible light are similar in size to the layer of oil on top of the water. The slight variation in ...


5

While I'm not familiar with the package, a very quick look at the documentation suggests that you want In [90]: c.M_sun.uncertainty instead. I've just checked and this appears to be correct. > python -c "from astropy import constants as c ; print c.M_sun.uncertainty" 5e+25


5

The second light curve you show has no obvious periodic behaviour and I cannot see any sign of a planetary transit. The period-finding algorithm appears to be working correctly. The planet (if it exists) is supposed to be one of the smallest planetary candidates found by Kepler and will have a barely detectable transit (depth of order 0.004%). The small ...


4

I haven't done much astronomical image processing before, but as this question is unanswered I'll give it a shot - hopefully to some avail. If the problem is more specific, a code sample/image sample would probably be useful for further diagnosis, but otherwise this example may help. It discusses the process of writing a 3-channel image to separate FITS ...


4

The astropy.coordinates packages has the SkyCoord.from_name() convenience method (docs link) uses the Sesame name resolver at CDS to search Simbad, the NASA/IPAC Extragalactic Database NED and VizieR database of astronomical catalogs. Since these encompass basically every known object in astronomy, there is no "list"; simply put something in and it'...


3

I think you may be seeing the planet in the periodogram! But also another signal - higher harmonics of other periodic signals example - various periodic signals in our sun - with a characteristic period of 11 years (in the bottom panel you also see Earth's, as this is a local measure, and thus is mostly affected by our distance from the sun) Patterns of ...


3

The accepted string formats for date-hms are: Format Class Example argument fits TimeFITS ‘2000-01-01T00:00:00.000’ iso TimeISO ‘2000-01-01 00:00:00.000’ isot TimeISOT ‘2000-01-01T00:00:00.000’ https://docs.astropy.org/en/stable/time/index.html You can either change one of these, or you can define your own format by deriving a ...


3

What they did was the following: for each individual filter, they assembled overlapping frames into a combined, single-filter image. E.g., they combined several g-band images into a single g-band image, combined several r-band images into a single r-band image, etc. (So they ran SWarp five times, once for each filter.) They then put each combined single-...


3

Ok, community helped me to figure out that I faced the “mapping from the inside” issue (explained here). I'll use this answer to show my final code. import numpy as np from astropy.coordinates import SkyCoord import astropy.units as u import matplotlib.pyplot as plt import seaborn as sns sns.set() def eq2gal(ra, dec): ''' Transforms equatorial ...


3

One keyword to search for is "spice kernel". SPICE stands for Spacecraft Planet Instrument C-matrix Event. That is a type of data format in which orbital data are commonly provided by ESA, NASA and other institutions dealing with detailed data; it is the recommended format by IAU to use. Often the so-called kernels for objects and missions are also ...


3

For Gaia EDR3: Note (G1): Note on magnitude errors: They are obtained with a simple propagation of errors with the formulas e_Gmag = sqrt((-2.5/ln(10)*e_FG/FG)**2 + sigmaG_0**2) e_GBPmag = sqrt((-2.5/ln(10)*e_FGBP/FGBP)**2 + sigmaGBP_0**2)) e_GRPmag = sqrt((-2.5/ln(10)*e_FGRP/FGRP)**2 + sigmaGRP_0**2)) with the G, G_BP, G_RP zero point uncertainties ...


3

That is because what is measured is a flux and the flux errors are in the DR2 catalogue. Since magnitudes are based on the logarithm of the flux, then there is no straightforward correspondence (although it matters little if the error bars are less than a few hundredths if a magnitude). Simple error propagation formulae give $$|\Delta G| \simeq \frac{2.5}{\...


3

BTW if anyone wants a quick and fast query to solution do the following: Go to https://skyserver.sdss.org/dr12/en/tools/search/sql.aspx. Paste a query like this: SELECT s.specobjid, s.ra, s.dec, s.z FROM SpecObj as s WHERE s.z > 0 AND s.z < .18 AND s.ra > 0 AND s.ra < 50 AND s.dec > 0 AND s.dec < 30 Then after downloading a csv file ...


3

SDSS DR12 Catalog Data looks like a good starting point, apparently pretty open to those willing and able to figure it out. Their SciServer Compute site hosts Jupyter notebooks to query CasJobs in SQL. The Large Scale Structure galaxy catalog under BOSS value added catalogs may also be relevant.


3

From eq. 10 in Hogg's classic paper, assuming that the peculiar velocity $v_\mathrm{pec} \ll c$: $$v_\mathrm{pec} = c \frac{z_\mathrm{obs} - z_\mathrm{cos}}{1 + z_\mathrm{cos}},$$ where $z_\mathrm{obs}$ is the observed redshift, and $z_\mathrm{cos}$ is the redshift from cosmological expansion only. Let me invert that and wrap it up in Python for ya: def ...


2

You can't really get a PSF for an extended object. The Point-Spread-Function is a parameter of your imaging system which describes the shape of the image of a putative point source. I don't have any knowledge of what your python package is intended to do, so I can't comment directly on the results. I will point (sorry) out that the geometric centroid of ...


2

Perhaps the difference stems from the conversion algorithm? Almost certainly this is the answer. It's not clear to me exactly what Stellarium assumes for is refraction calculation, but I know Astropy's algorithm. Given that the altitude you've listed here is below the horizon (i.e., alt is negative), it's not really clear what the correct interpretation ...


2

The conceptual problem is that the half-light radius is the radius of a circle enclosing half the total light, assuming that the object is circular with a radial intensity profile equal to the Sersic function. So you need to integrate over circular rings, each of which has an area of $2 \pi r \, dr$ and an intensity (or surface brightness) of $S(r)$: $$L(&...


2

I think I see what is going on. Your best fit is actually a beat frequency between the true frequency (0.005) and double the sampling frequency (0.05). This does indeed produce a model that goes through your data points but because you have only plotted 50 points in the model you haven't been able to see it. If you change this line t_fit = np.linspace(x[i][...


2

Bad news, this type of SPK file has a different sort of interpolation that is not supported by the jplephem package (Hermite interpolation vs Chebyshev polynomials). You can find this out by doing: In [1]: print(len(kernel.segments)) 1 In [2]: print(kernel.segments[0]....


2

This is because the ICRS has an origin at the barycenter and this is not the same as the center of the Sun (the heliocenter). The heliocenter is offset from the barycenter (although it's still within the radius of the Sun) and varies with time, primarily due to the perturbations of Jupiter and Saturn. If you use BarycentricTrueEcliptic it will work fine: ...


2

The answer turned out to be that I was pushing the models package too far with the data that I was giving it. More careful background subtraction and much more localised fitting helped greatly.


2

Calculation of both, depth and duration, is usually done not on the raw data but derived from a fit to the data. In your last three lines of code you also calculate the average / medium over all data while you should calculate the uneclipsed mean or median flux only for the non-transit time (with using median it possibly has only a tiny influence, yet it ...


2

Not being familiar with Lomb-Scargle (never having used it myself) the first thing I would say is that your graph is not really suitable for this kind of analysis. If I graph it in my spreadsheet I get what looks more like a "bumpy line" not a periodic pattern : The purpose of this algorithm is to take data that has a periodic pattern and find ...


2

How should I interpret the lomb scargle results shown in the picture(below picture)? That there are no specific periodicities present. Why does the maximum appear near zero(below picture)? Because your signal is dominated by a dc component plus slow (low frequency) drift.


2

The answer probably depends on what you want, what is 'long time' for you. Astropy offers a method to handle coordinates and proper motion: https://docs.astropy.org/en/stable/coordinates/apply_space_motion.html. However, unless you have actual positional information for times you are interested in, you have to forward or backward integrate from what you know ...


2

The projected separation of Mizar and Alcor is 12 arcminutes. If they are both at a distance of 25 pc (suggested by the Hipparcos satellite), then this equates to a physical separation of at least 18,000 au. Using Kepler's third law we can then estimate an orbital period of at least 800,000 years (assuming a total system mass of around $9M_\odot$. Thus over ...


Only top voted, non community-wiki answers of a minimum length are eligible