Comments (10)
If both stars are isotropic, then by definition they have the same flux for every observer. So, when you integrate the specific intensity over the visible disk (and over wavelength if the bolometric luminosities are equal; otherwise you require the specific luminosities to be equal), then the fluxes must match.
from starry.
from starry.
Stellar radius and luminosity are now fixed to unity. I'm going to tackle the normalization issue next.
from starry.
Case in point:
import matplotlib.pyplot as pl
import starry
import numpy as np
star = starry.Star()
planet = starry.Planet(L=1e-2, r=0.1, a=3)
sys = starry.System([star, planet])
time = np.linspace(0.25, 1.25, 10000)
sys.compute(time)
pl.plot(time, sys.flux / np.nanmedian(sys.flux), label="Uniform")
star[1] = 0.4
star[2] = 0.26
sys.compute(time)
pl.plot(time, sys.flux / np.nanmedian(sys.flux), label="Limb-Darkened")
pl.legend()
pl.show()
from starry.
The luminosity is equal to the integral over the surface brightness of the l=0 m=0 integral.
To see this, integrate the spherical harmonic over the sphere:
Now, if l' = m' = 0, then this just gives the integral of the spherical harmonic over the sphere (times a constant), so the only spherical harmonic with a non-zero mean flux (integrated over the sphere) is l=m=0.
All to say: the total luminosity is just governed by the l=0 spherical harmonic.
from starry.
OK, I think I understand what I'm doing wrong. Currently my Y_{0,0}
coefficient depends on the limb darkening coefficients:
because that's what I get when I express
in spherical harmonics. So I just need to normalize the map so the luminosity doesn't change when the limb darkening coefficients are changed.
But I'm still a bit confused about this, because the stellar brightness isn't really a sum of the Y_{l,0}
harmonics -- it just looks that way from our vantage point. If we go around to the backside of the star, we don't see negative flux! So I'm not convinced the limb darkening terms integrate to zero over all 4 * pi steradians. Does that make sense?
from starry.
Right - there is some sleight-of-hand here, and so it depends on what quantity you are interested in.
If you want the apparent luminosity, then you should integrate the observed flux and multiply by 4\pi d^2. If you want the total luminosity (i.e. sum of fluxes of observers at same distance distributed over 4\pi steradians), then it's only the monopole that counts.
from starry.
Ok, let me ask you a specific question then: say I have two solar-type stars with the same total luminosity, but one is strongly limb-darkened and the other isn't. When I integrate the specific intensity of each one over their visible disk, should I get the same value for both? Or should the limb-darkened one be dimmer?
This will help me decide how to normalize the units...
from starry.
Ha, turns out I had done this before! From Equation (67) in our PPO paper, all we need to do is multiply the flux by
to ensure the integral over the visible disk is unity.
from starry.
Actually the above expression normalizes the flux to pi
. Anyways, this issue is now resolved. The stellar flux is now always unity.
import matplotlib.pyplot as pl
import starry
import numpy as np
star = starry.Star()
planet = starry.Planet(L=1e-2, r=0.1, a=3)
sys = starry.System([star, planet])
time = np.linspace(0.25, 1.25, 10000)
sys.compute(time)
pl.plot(time, sys.flux, label="Uniform")
star[1] = 0.4
star[2] = 0.26
sys.compute(time)
pl.plot(time, sys.flux, label="Limb-Darkened")
pl.legend()
pl.show()
from starry.
Related Issues (20)
- Issue with computing flux when total=False in starry oblate
- Model spectrum is wrong at very small velocities
- Issues downloading planet data from nexsci HOT 1
- Issues with `[skip ci]` commits
- Set a prior that maps are physical/non-negative? HOT 8
- Starry dependencies issues HOT 2
- Unable to use limb darkening HOT 6
- ModuleNotFoundError: No module named 'starry._c_ops' HOT 3
- Only C op is implemented HOT 13
- Oblate maps unexpected amplitude
- Allow users to define both the semi-major axis and the orbital period HOT 1
- Starry crashes following Quickstart tutorial HOT 2
- EOFError when multi-processing and orbit is variable HOT 5
- Theano issue HOT 5
- Add multi-wavelength quadratic limb-darkening
- Loaded planetary flux numpy array not normalized relative to the star?
- Duplicate Longitude and Latitude from Pixel Transform
- Error building numpy, exoplanet-core wheels on installation HOT 5
- Running starry on WSL HOT 2
- map.flux() Normalization problem HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from starry.