[mesa-users] type 2 opacities

[Bill Paxton]

Hi Radek,

One fundamental problem here is that I've never been able to figure out a pleasing way to integrate Type2 opacities into mesa.   Aaron and Falk and others have tried for years to clear this up for me, but I in spite of that, I remain dissatisfied and that is probably reflected in the code.  We might need someone other than me to take this over and make a fresh start, but until then I'll try to explain what is there now and maybe we'll collectively see how to improve it.

Also, keep in mind that there are trade-offs between type1 and type2.  type2 does a better job taking into account the actual composition, but it is limited in that there are no tables for X > 0.7 whereas the type1 tables go all the way to the max X = 1.0-Z.  The type2 tables also come in fewer values of X and Z so the interpolation gaps are larger than for type1.   Some of the type2 messiness comes from trying to provide controls for the decision between type1 vs type2 that needs to take into consideration these tradeoffs.

But even after dealing with the type1 vs type2 question, I've still had problems with the next question: how do you do the interpolation in the type2 tables for a given composition?  Each type2 table is for a given X, Zbase, dXC, and dXO.  The values dXC and dXO are the (non-negative) enhancements in carbon and oxygen.  So the actual Z for the table is Zbase + dXC + dXO.   So the seemingly simple question is given the cell abundances, which type2 tables do you use to interpolate?  The code in mesa/kap is my current attempt do answer this, but there may be better solutions.   It is all there for anyone who would like to dig into the details.

After those general comments, here are some answers for your specific questions.

On Oct 22, 2013, at 7:20 AM, Radek Smolec wrote:

> Hi,
> 
> Since I plan to burn helium, I want to clarify the meaning of some controls related to type 2 opacities.
> In controls.default I find kap_Type2_full_off_X and kap_Type2_full_on_X. To make sure: this criteria apply to X at each mesh point, i.e. with default values of these parameters, if X in a cell is larger than 0.71 only type 1 opacities are used in this cell and if X<0.7 then only type 2 opacities are used (and some interpolation in-between)?

right.  modulo the limit on logT you bring up next, X is used to decide the relative contributions of type1 and type2 opacities.

> In addition I can put constraint related to temperature - through kappa_type2_logT_lower_bdy living in star_job.defaults. Now, consider a cell in which temperature is larger than kappa_type2_logT_lower_bdy but hydrogen content is higher than  kap_Type2_full_off_X. Which opacities are used in that cell?

The logT limit takes priority --- so if logT less than this limit, then use type1 independent of X.

> 
> Since the default value for kappa_type2_logT_lower_bdy is not given in the .defaults file I made some grepping to find it. I was surprised to find it atm module and in kap/test/src/test_kap_support.f with very low value (3.8). Is it hidden elsewhere as well?

Sorry --- I have a naming inconsistency on this one.  The variable is called "kap_type2_logT_lower_bdy" in mesa/kap/public/kap_def.  The "truth" value is that one.  But we don't access that directly from star inlists, so there is another variable introduced as a control in star that is then used to set the one in kap_def.  So "kappa_type2_logT_lower_bdy" in star_job is passed along from the routine "run1_star" in star/job/run_star_support to "star_init" in star/public/star_lib to "do_star_init" in star/private/init to "stardata_init" in star_private_def to "kap_init" in kap/public/kap_lib to "Setup_Kap_Tables" in kap/private/load_kap where if it is > 0, it is stored in the variable "kap_type2_logT_lower_bdy" defined in kap_def.   Since the default for the control "kappa_type2_logT_lower_bdy" back in star is 0, if you use that star default, then Setup_Kap_Tables doesn't change kap_type2_logT_lower_bdy in kap_def, so that variable keeps it's initialization value (found in kap_def):
      real(dp) :: kap_type2_logT_lower_bdy = 3.8d0
      ! below this, turn off type2

So "kappa_type2_logT_lower_bdy" in star is optionally used to set "kap_type2_logT_lower_bdy" in kap_def.   They really are two different variables, and I might claim that I gave them different names for that reason.  But it probably was just an accident.

The exact same thing is true for kappa_blend_logT_upper_bdy and kappa_blend_logT_lower_bdy.  They are controls defined in star and are used to set the variables kap_blend_logT_upper_bdy and kap_blend_logT_lower_bdy in kap_def.  The critical difference is that for these, I gave them the same default values in star as in kap.  For the next release I'll change the default for kappa_type2_logT_lower_bdy in star_job.defaults to be the same as the initial value for kap_type2_logT_lower_bdy in kap_def.

> 
> If type 2 opacities are used one has to set the reference fractions of C, N , O to calculate C/O enhancements. I am confused at this point.
> In controls.default I find: base_fC, base_fN, base_fO and base_fNe.
> 
> In star_job.defaults I find similar controls: kap_base_fC, kap_base_fN and kap_base_fO. These I guess are used only when set_kap_base_CNO_Z_fracs=.true. 
> What is the difference between these two sets of controls? I also noted that the default values for base_* and kap_base_* are slightly different for a given element (different solar mixtures?)
> 

Again, the "truth" resides in the kap data and star has various controls that is uses to set the kap variables.  If you follow the calls starting from star/private/opacities, you'll eventually get to "kap_get_blend_1_2" in kap/public/kap_lib.  The inputs include the star value for Zbase and the star cell values for temperature, density, and mass fractions X, Z, XC, XN, XO, XNe.   The routine "kap_get_blend_1_2" decides the fractions of Type1 and Type2 and dXC and dXO for Type2 by a calculation using kap values for base_fC, base_fN, base_fO, base_fNe, kap_Type2_full_off_X, and kap_Type2_full_on_X.   It then calls the routine "Get_kap_Results" in kap/private/kap_eval.  It checks for logT<= kap_type2_logT_lower_bdy and sets the Type1 fraction to 1 if that is true.  Then using the fractions, it evaluates one or both of the Type1 and Type2 opacties and combines the results to get "kap_rad", the radiative opacity.  Then it optionally combines opacities for Compton and electron conduction.

The values kap_get_blend_1_2 uses for base_fC, base_fN, base_fO, base_fNe, kap_Type2_full_off_X, kap_Type2_full_on_X come from the kap data structure accessed using the kap_handle passed from star.  Those values are given initial values by the routine "kap_def_init" in kap/public/kap_def.  The initial values set in kap can be changed by star using the controls.default variables:
      ! these metal fractions are used to calculate enhancements in C and O for Type2 opacities
      base_fC = 0.173312d0 ! base value for C fraction of metals (< 0 means use kap default)
      base_fN = 0.053152d0 ! base value for N fraction of metals (< 0 means use kap default)
      base_fO = 0.482398d0 ! base value for O fraction of metals (< 0 means use kap default)
      base_fNe = 0.098668d0 ! base value for Ne fraction of metals (< 0 means use kap default)

Once upon a time, the base fractions were set from run_star_extras using the star_job.defaults variables kap_base_fC, kap_base_fN and kap_base_fO.  But now those are unused -- I'll remove them for the next release.  Sorry for the confusion caused by failing to remove them before.

> Finally, similar to Type 2 opacities, does MESA eos tables take into account the enhanced C/O abundances during late evolutionary stages, i.e are type 2 EOS tables from the OPAL web page incorporated into MESA tables.

Good question -- we do not currently support type2 EOS tables.  If someone would like to take that on as a project, great!  It isn't currently on my (already very full) list of urgent things to do.

Cheers,
Bill










---------