karllark / dust_attenuation Goto Github PK
View Code? Open in Web Editor NEWAstronomical Dust Attenuation
Home Page: http://dust-attenuation.readthedocs.io/
License: BSD 3-Clause "New" or "Revised" License
Astronomical Dust Attenuation
Home Page: http://dust-attenuation.readthedocs.io/
License: BSD 3-Clause "New" or "Revised" License
Add in one of the classics.
Mention limitations - no shape change with changing dust column.
Selection effects - made with star forming galaxy observations
Add in the attenuation curves from the radiative transfer simulations of Seon 2016
http://adsabs.harvard.edu/abs/2016ApJ...833..201S
Publicly available here: https://seoncafe.github.io/MoCafe.html
Attenuation curves are described by 3 physical parameters:
Aim: make interpolation between the discretized values.
Need to decide the output from the model.
Attenuation (Att) in mags?
Optical depth (tau)?
Tests need to check that actual calculation of the numbers for both C00 and WG00.
Ideally, this would be against tables published in those papers. Otherwise, calculations from another source. Or even calculations with this code frozen so that at least we will know if something changes.
A(V) = 1.086*tau(V) = amount of dust in the model (for RT models at least)
Att(V) = attenuation at V = effective attenuation(extinction?) at V
Currently the output of the WG00 model is tau. Needs to be converted to tau.
And a helper function added to convert the output to tau. This could be done as another model that could be paired with any model as a compound model. Then the output of any model could be converted to tau.
As the attenuation law is not universal, one should use a model allowing different UV slope, 2175 bump strength whenever the spectral coverage allows it. For this purpose, one of the most used recipe is the one of Noll+09.
In particular cases, for instance the SED fitting of a galaxy known to be starburst and a lack of rest-frame UV data, the Calzetti law can be used.
One should always avoid to use recipe derived from measurements of individual stars (i.e extinction curves) such as the average LMC, SMC or MW extinction laws.
The functional forms of FM90 or CCM89 are just analytical formulas and so even if they were initially applied to measurement of individual stars they could in principle also be used for galaxies. The FM recipe has a lot of parameters to fit though and setting the parameters to average values derived from measurement of individual stars is not recommended as the physical processes at stake are not the same.
The Charlot and Fall 2000 recipe is dependent on the star formation history
Attenuation curves derived with radiative transfer models are described by physically motivated parameters related to the structure of the ISM: dust/star geometry, local distribution of dust, type of dust grain, optical depth.
Add in the analytical attenuation law defined in Noll 2009
http://adsabs.harvard.edu/abs/2009A%26A...507.1793N
This prescription allows the slope of the curve to deviate from the slope of the Calzetti curve and add a UV bump following a Drude profile.
There's a generalization of the CCM89 dust extinction model in the Appendix of Conroy+10 that varies the bump strength to allow for modeling attenuation in galaxies. A possible addition for this package. Originally proposed for the dust_extinction package, but more appropriate here.
Makes it easier to add models
Attenuation curves from dust radiative transfer models for "galactic environments."
I am thinking that it would be better to not break things into one file per model as the imports look like:
from dust_attenuation.C00 import C00
Instead, how about having 3 files for each type of model? One for averages, one for radiative transfer mdoels, and one for shape fitting models. The base classes for each type of model could go into the appropriate file with, if needed, one more file with any generic code that is used by multiple types of models. The imports would then be:
from dust_attenuation.averages import C00
from dust_attenuation.radiative_transfer import WG00
from dust_attenuation.shapes import N09
Comments?
For average attenuation curves, should we declare the scaling factor (Av or tau) as a fitable parameter in the class (for instance in the C00) or should we return the normalised attenuation curve and then find a way to fit the scaling factor.
My personal view is that we should make a distinction between the shape of the attenuation curve, i.e normalised attenuation curve, and the amount of attenuation, i.e scaling factor.
Complimentary docs to those given in the dust_extinction package. See karllark/dust_extinction#47.
Here we will focus on attenuation with a brief discussion of extinction w/ a pointer to the dust_extinction
docs.
Currently, the WG00 model has a two step initialization.
First the model is initialized as normal. Then the get_model function is called to load in the appropriate table given the model geometry, dust_type, and dust_distribution.
Why not have the get_model functionality in an explicit initialization step? This would make it more like other models and reduce the number of initialization lines.
I have seen that this is possible in other implementations of astropy.modeling (can't find it right now, but could if this sounds like a good idea).
Code is broken in Astropy 6.0.0 due to deprecation in the Configuration System module (see Astropy issue #11497)
Error that arises comes when the code attempts to import update_default_config
which has been deprecated.
Possible solutions are to:
a. Pin to astropy < 6.0.0 in setup.cfg
.
b. Update to use updated interface.
This also affects packages that use this as a dependency (e.g. eazy @gbrammer)
Why this package? Goals.
Difference from dust_extinction. Point to dust_extinction package.
I am using LevMarLSQFitter and am trying to fit hundreds of attenuation curves automatically. Sometimes the fit failed. It is also sensitive to initial conditions, which is logical.
Hence my question: does anyone know how to assess the quality of a fit performed by astropy.modeling.fitting?
If one fits only a few attenuation curves, one can still check by eye. However in a automatised process, one should rely on a criteria to assess the quality of the fit, for instance the chi2. There is still the solution to compute the chi2 myself but I can not believe that there is no such quantity to assess the quality of the fit provided by the package, though I haven't found it in the documentation yet.
With a nice fit quality assessment it will be possible to fix the sensitivity to the initial values, by running the fit with different initial conditions and keeping the best fit. Otherwise a MCMC algorithm could also fix the problem.
C00 test is failing as the import is incorrect. Needs fixing.
Not all the plots are showing up in the documentation. This usually means there is some error making the plot. Need to track down.
At least the L02 reference is missing from the naming convention page. L02 plot is empty.
A few minor problems, just noting them here for cleanup at the appropriate time.
Adding S07 extinction curve from PAHFIT (Smith et al. 2007).
The plot for the example of fitting attenuation curves with WG00 does not appear in the documentation though it was produced as written in the travis log
May be because it is too large. Need to check it.
It would be very illustrative and pedagogical to create a widget showing side by side a picture of the dust/star geometry, clumpiness of dust distribution, (others?) and the corresponding attenuation curve for a given dust type (i.e. extinction curve).
Easier units to work in for model development and users.
Both for range testing and as the default input unit for x.
Could not find any docs for WG00 widget. Maybe there are there and I just missed them.
Hello from Astropy Project!
The following updates to your package might be necessary to ensure compatibility with the latest stable version of Astropy:
ci-helpers
, packages expecting interactive plotting should override it in .travis.yml
sphinx-astropy
as a package dependency if you are using astropy-helpers
3.1 or later. Otherwise, your documentation build (e.g., on ReadTheDocs) might fail.six
that is bundled with Astropy, please consider using the standalone six
package instead.If these are no longer applicable to you, please close the issue.
This is an automated issue for packages that opted in for automated astropy-helpers update. If this is opened in error, please let @pllim know.
As discussed in #40 (review)
One idea.
A few stars in a blob of dust with different colors representing different amount of extinction (blue = none, red and dim = lots). Have scattered light halo around at least one of the extinguished stars.
Hi,
I'm about to prepare your project to Guix, may you advise the license type you
would like to have been assigned as I did not find any mentioning of any kind it
uses.
Thanks,
Oleg
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.