[mesa-users] Tying Up Loose End on Discussion of eps_grav for Accretion
Broxton Miles
bjmiles at crimson.ua.edu
Mon May 5 15:51:14 EDT 2014
Hi Bill,
Thanks! I've attached the files.
On Mon, May 5, 2014 at 2:43 PM, Bill Paxton <paxton at kitp.ucsb.edu> wrote:
> 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.<http://sourceforge.net/p/mesa/mailman/mesa-users/thread/33DCDFC8-C9D5-4F5F-B944-9FFB65EB0392%40kitp.ucsb.edu/#msg31494991>)
> 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<http://sourceforge.net/p/mesa/mailman/message/31510302/> 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/501a5c8b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adjust_mass.f
Type: text/x-fortran
Size: 54822 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140505/501a5c8b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: evolve.f
Type: text/x-fortran
Size: 62295 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140505/501a5c8b/attachment-0001.bin>
More information about the Mesa-users
mailing list