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

Bill Paxton Paxton at kitp.ucsb.edu
Fri Apr 12 14:30:38 EDT 2013

Hi Richard,

Here's the Hu et al paper from 2011.

Yes, the radiative acceleration is recalculated at each step of the stellar evolution
and is tweaked at each substep of the diffusion solution using the calculated
partial derivatives of the acceleration with respect to changes in abundances
(this is the same scheme as used by Hu et al).

The accelerations are calculated by calling the op_mono_get_radacc in mesa/kap.
It is based on Haili's changes to the op_ax.f routine from OP and uses the OP set
of 17 species (H, He, C, N, O, Ne, Na, Mg, Al, Si, S, Ar, Ca, Cr, Mn, Fe, and Ni).
For each cell, the code maps the current chemical composition to these 17 before calling
the op_mono_get_radacc routine.  That routine uses the OP monochromatic tables
from their website to mix together an overall opacity for the given composition.
Also, the stellar evolution code uses the same OP monochromatic scheme when
calculating opacities in the envelope -- that's why we get that small convection zone
at the location of the excess Fe and Ni.   If we were using the pre-built opacity tables,
we'd miss that feature completely. 

It will be interesting to see how the results compare!


On Apr 12, 2013, at 11:12 AM, Richard Monier wrote:

> 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/3a94465a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hu_11.pdf
Type: application/pdf
Size: 2002138 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130412/3a94465a/attachment.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20130412/3a94465a/attachment-0001.html>

More information about the Mesa-users mailing list