[mesa-users] mesa release 4906 -- with radiative levitation

Richard Monier richard.monier75 at gmail.com
Fri Apr 12 14:12:35 EDT 2013


Hello Bill,

   Thank you for this very important progress. I cannot get access to 
the original paper right now from home. Does this mean that the 
radiative acceleration is recalculated at each time step in each cell 
using the actual monochromatic (?) opacity that takes into account the 
actual chemical composition in that cell at that time (due to nuclear 
reactions, radiative diffusion, turbulent diffusion?)?.
I am wondering whether the predicted "surface" mass fraction are 
actually comparable to the abundances we painfully derive by adjusting 
synthetic spectra to observed ones?

Best wishes,

Richard Monier



On 04/12/2013 05:42 AM, Bill Paxton wrote:
> Hi,
>
> We now have an option to include radiative levitation effects in element diffusion.
> The implementation includes routines to calculate opacities for specific abundances
> on a cell-by-cell basis during a stellar evolution run.
>
> A big thank you goes to Haili Hu for providing code that guided
> the mesa implementation both for radiative levitation and for
> the opacities option.   Please reference her paper if you
> use these new mesa features:
>
>   Haili Hu, C. A. Tout, E. Glebbeek and M.-A. Dupret,
>   "Slowing down atomic diffusion in subdwarf B stars: mass loss or turbulence?",
>   Mon. Not. R. Astron. Soc. 418, 195--205 (2011)
>
>
> The new opacity options are a part of the kap module and can be used
> from mesa/star for evolution independently of radiative levitation.
> Since it is doing a lot of computation on the fly rather than
> using prebuilt tables, it is much slower, but there are cases where the standard
> faster scheme just won't do the job.  Here's an example -- this is an sdb star where
> radiative levitation has pushed fe56 and ni58 to the surface where their contribution
> to the opacity results in a small convective zone in the outer 10^-10 Msun of the envelope.
>
>
> That plot represents basically all of the testing that I've done!
> It seems to be okay, but it is up to you the users to verify that
> it is actually working before you publish.  ;-)
>
> There are 2 new test cases in star/test_suite related to this.
> The "make_sdb" case starts from just before he core flash
> at tip of RGB and evolves with an extra strong wind to remove
> the envelope as the star begins core helium burning.
> The "sdb" test case continues this with radiative levitation
> turned on and evolves long enough to develop the distinctive
> surface convective layer enriched with fe56 and ni58.
>
>
>
> The new opacities use data from the OP website.  Because it is
> such a large amount of data we've decided not to include it in the
> standard mesa download.  You'll need to get it yourself if you
> decide to try this:  http://cdsweb.u-strasbg.fr/topbase/TheOP.html
> Get the 669 Mb tar file for OPCD_3.3
>
> 	http://cdsweb.u-strasbg.fr/topbase/OPCD_3.3.tar
>
> Put it anyplace you want on your disk.  Set the inlist controls
> to tell mesa where to find the "mono" directory with the data files.
> (It's the directory with files named like "a06.140")
> For example, in my case it looks like this, but you can put
> the files anywhere you like -- they don't need to be in the
> mesa/data directory.
>
>           op_mono_data_path = '/Users/bpaxton/mesa/data/kap_data/op_mono'
>           op_mono_data_cache_filename = '/Users/bpaxton/mesa/data/kap_data/op_mono_cache.bin'
>
> There are some controls for how the mono kap option is used:
>
>           ! op mono full on if log10T <= logT_op_mono_full_on
>           ! op mono full off if log10T >= logT_op_mono_full_off
>           logT_op_mono_full_off = -1d99
>           logT_op_mono_full_on = -1d99
>           
>           op_mono_min_X_to_include = 1d-20 ! skip iso if mass fraction < this
>           
>           use_op_mono_alt_get_kap = .false.
>
> Check mesa/kap/public/kap_lib for more information.
>
>
> The addition of radiative levitation was an opportunity to rework element
> diffusion that I couldn't resist.   For example, there is no longer a
> separate "diffusion" module -- it has been eaten by mesa/star.
>
> If you use diffusion, you'll need to do a careful check to find out
> what I've broken in the process.  One big change is that the code
> is much better at conserving total species abundances (people
> mentioned that the old version sometimes did alchemy by changing
> one element into another).  We also now have the option to use
> atomic diffusion coefficients according to Paquette et al. (1986)
> instead of assuming a pure Coulomb treatment.
>
> There are several test cases that use diffusion, and they are all working okay.
> For example, here are the final abundances at the end of the wd_diffusion test case.
> We're getting much cleaner results now down to very low abundances.
> The abrupt break at the bottom of the envelope is because we explicitly
> turned off diffusion for Z > 0.5.   That is a help with performance for
> a case like this where our focus is on the envelope.
>
>
>
> As usual, with improvements come bugs, so be on the lookout.
>
> Cheers,
> Bill
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130412/88f3516b/attachment.html>


More information about the Mesa-users mailing list