[mesa-users] Tying Up Loose End on Discussion of eps_grav for Accretion
Bill Paxton
paxton at kitp.ucsb.edu
Mon May 5 15:43:02 EDT 2014
Hi Broxton,
Excellent work! Please send your edited versions of adjust_mass.f and evolve.f so I can be sure to get the patches correctly.
Cheers,
Bill
On May 5, 2014, at 11:43 AM, Broxton Miles wrote:
> Hi everyone,
>
> Dean and I have been looking into the 'new' methods that are used in calculating in eps_grav. (See this email chain from the archive.) Previously, as presented in the second instrument paper, newly accreted material was treated with a quasi-steady approximation based on Townsley & Bildsten 2004. This approximation is usually only valid in the outer regions of the star where the heat capacity is small compared to the energy flowing through in a given timestep. After some discussion with Bill, and with his new implementation (for which we are immensely grateful), the calculation of the eps_grav energy term is now broken into three forms: a Lagrangian form (constant mass), an Eulerian form (constant q), and a blended component that is a linear combination of the other two forms.
>
> The previous discussion reached the point of considering a new set of controls, which would determine what regions the constant q or constant M forms of the derivatives used to calculate eps_grav would be used. However, we're not sure that these are the controls that we're looking for. The grid is also split up into constant M and constant q regions, and it appears to us that the appropriate thing to do is to use the corresponding derivative forms in those regions. In order to implement this, in evolve.f, I hardcode k_below_Eulerian_eps_grav = k_below_const_q and k_Lagrangian_eps_grav = k_const mass.
>
> In order to prevent the taking of Lagrangian (constant mass) derivatives in regions where m was not constant and likewise with the Eluerian derivatives in regions where q was not constant, I changed the way that the boundaries are determined in the revise_q_and_dq subroutine in the adjust_mass.f module. Specifically I couple k_below_const_q to the time step by requiring it to be both at least 5 zones away from the newly accreted material as well as 5 times deeper in q. The factor for depth was just a number of our choosing so it could be a tunable parameter that is linked somehow with the pre-existing control min_dxm_Eulerian_div_dxm_added, but we are unsure if that's the right way to got about it. I changed nothing with the determination of k_const_mass.
>
> To test these changes, I ran a test very similar to the case run in the second instrument paper. I started with a 0.6 solar mass white dwarf with an accretion rate of 10^-11 solar masses per year. I stopped the run when 10^-4 solar masses of material had been accreted. I've attached the starting model, inlist, as well as the run_stars_extras that would be needed to reproduce these results.
>
> The attached figure has three panels, Temperature vs LogP, eps_grav*P vs LogP, and an abundance profile also with respect to LogP. The orange curve is the result from version 6208 without the 'the patch'. As you can see, the mesh boundaries are completely uncoupled from the derivative boundaries resulting in the 'Eulerian' constant q derivatives being used in regions constant M where the Lagrangian form should be used. The results of the 'patch' can be seen in the green curve in the attached figure. The blue curve is the same run with an older version (5329) from before the change in the eps_grav routine with the discontinuity that existed from pasting the Lagrangian calculation with the quasi-steady state calculations a la Townsley & Bildsten 2004, that also presents itself in figure 26 of the 2nd instrument paper. As can be seen with the green curve, the new method fixes the discontinuity when proper restraints are placed on the boundaries.
>
> I hope this has been informative, and if you have any questions please ask. We also want to thank Bill again for the work he's put into this new implementation. The guts of the 'patch' are below.
>
> Thanks,
> Broxton Miles
>
> ************Patch Notes******************
> In adjust_mass.f
> added logical flag
> added integer k_check
> replaced lines 480 - 491 with:
>
> s% max_q_for_k_below_const_q = frac
> i_lnT = s% i_lnT
>
> lnTmax = maxval(s% xh(i_lnT,1:nz))
>
> lnT_A = min(lnTmax, lnTlim_A)
> kA = min_kA
> do k = min_kA, nz-1
> kA = k
> if (s% q(k) > s% max_q_for_k_below_const_q) cycle
> if (s% q(k) <= frac) then
> if( .not. flag) then
> k_check = k
> flag = .true.
> end if
>
> if( (k > 5+k_check) .and. ((frac - s% q(k)) > 5*(1- &
> frac))) then
> exit
> else
> cycle
> end if
> end if
> if (s% xh(i_lnT,k) >= lnT_A .or. &
> s% q(k) <= s% min_q_for_k_below_const_q) exit
> end do
>
> In evolve.f
> replaced lines 726-727 with:
>
> s% k_below_Eulerian_eps_grav = s% k_below_const_q
> s% k_Lagrangian_eps_grav = s% k_const_mass
> <06sm_9.5e6_wd.mod><eps_grav_fig.png><inlist_eps_grav><run_star_extras.f>------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> 3 signs your SCM is hindering your productivity
> Requirements for releasing software faster
> Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce_______________________________________________
> 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/20140505/114cedbe/attachment.html>
More information about the Mesa-users
mailing list