[mesa-users] accretion

Dean Townsley Dean.M.Townsley at ua.edu
Tue Oct 8 00:27:22 EDT 2013


Hi Bill,

Wow!  Sounds great!  That is a pretty significant addition.  Thanks for 
working on this.

Is there another factor of q in your (dm/dt)_q ? should it be q*Mdot?  
or maybe I haven't thought it through enough.


Dean



On 10/07/2013 05:56 PM, Bill Paxton wrote:
> Hi Broxton,
>
> I hope to have a new release for you to try very soon (a day or two if 
> I get lucky).  It will have a new eps_grav treatment based on the the 
> "Eulerian" scheme of Sugimoto&Nomoto 1981, but it will replace their 
> form of the homologous term by using the method of Townsley&Bildsten 
> 2004.   Here's a quick outline of what I'm doing --- lots more details 
> in the next release message (assuming I can actually make it all work!).
>
> S&N 1981
> eps_grav == eps_grav_h + eps_grav_nh
> eps_grav_h == T*(ds/dm)*(dm/dt)_q       (homologous)
> eps_grav_nh == -T*(ds/dt)_q           (non-homologous)
>
> T&B 2004
> ds/dm = (ds/dP)*(dP/dm)
> dP/dm = - Gm/(4 pi r^4)
> ds/dP = (gradT - grada)*Cp/P
> gradT = (dlnT/dlnP)_actual
> grada = (dlnT/dlnP)_adiabatic
> in mesa/star m = M_center + q*xmstar, so (dm/dt)_q = d(xmstar)/dt = 
> Mdot since M_center is constant during timesteps.
> Putting it all together, we get the T&B eps_grav_h = (G m Mdot Cp 
> T)*(grada - gradT)/(4 pi r^4 P)
>
> -Bill
>
>
>
>
>
>
> On Oct 7, 2013, at 3:35 PM, Broxton Miles wrote:
>
>> Hey everyone,
>>
>> As Dean said in previous email, we've been looking at how 
>> the constraint LdivCpTMdot works. So far, I've run three different 
>> cases using a .6 solar mass white dwarf with an average accretion 
>> rate of 10^-10 solar masses per year with different values of 
>> factor_for_recently_added and LdivCpTMdot_limit. These cases were run 
>> with a factor of 5 and LdivCpTMdot limit of 2 (the default values), a 
>> factor of 5 and LdivCpTMdot limit of 10, and finally a  factor of 1.1 
>> and LdivCpTMdot limit of 10. I've attached a figure that shows the 
>> values of LdivCpTModt, eps_grav*logP, and t_thermal/t_accrete 
>> (1/LdivCpTMdot) as a function of log P taken from a profile that was 
>> dropped after 1e-5 solar masses of material has been accreted. The 
>> 2nd panel in the profile figure is similar to middle panel in figure 
>> 26 of the 2nd MESA instrument paper, and you can see that the same 
>> discontinuity exists where the equations for calculating 
>> eps_grav change (section 5.3 of the 2nd instrument paper). The 
>> location/height of this discontinuity changes with different values 
>> for the two parameters. Changing LdivCpTMdot to a higher values seems 
>> to shift the discontinuity further towards the surface, and reducing 
>> factor_for_recently_added seems to increase the height of the 
>> discontinuity; however, I'm looking at other cases to confirm both 
>> observations to be certain.
>>
>> Another thing we checked was how these constraints affected the size 
>> of the time steps so I've also attached a figure that shows how 
>> the time step size changed up until the profile for the previous 
>> figure was dropped. The time steps are a few orders of magnitude 
>> smaller in the more constrained cases when compared to the defaults. 
>> As a possible consequence of the small time steps, increased number 
>> of models may be causing noise to accumulate and create the jagged 
>> lines in the profile figure, but once again this is just an 
>> unconfirmed observation. Any comments are appreciated.
>>
>> Broxton
>>
>>
>>
>> On Sun, Oct 6, 2013 at 11:57 PM, Dean Townsley 
>> <Dean.M.Townsley at ua.edu <mailto:Dean.M.Townsley at ua.edu>> wrote:
>>
>>     Hi again,
>>
>>     I'm going to take on the CFL question first, and then reply to your
>>     further comments.
>>
>>     The way I would say it is that the CFL is not an issue because the
>>     validity of what we are doing does not come from the the equations
>>     themselves.  In order to properly solve the equations in
>>     generality we
>>     must obey the CFL.  But for the outer layers we want to deal with a
>>     special case, not the general one.  We want to make the assumptions
>>     that, at least approximately:
>>     1. Mdot is constant in time
>>     2. T and L at the "base" of some outer layers are constant in time
>>     3. There has been enough time for the layers to relax into a
>>     steady state
>>
>>     These are basically assumptions about the boundary conditions,
>>     not about
>>     the equations.  If they are violated, then yes we must fall back to
>>     cfl-limited considerations.  But as long as these assumptions
>>     hold, we
>>     can construct a solution with a method that is not cfl limited.
>>      This is
>>     more analogous to a steady flow problem rather than a convection
>>     simulation.
>>
>>     On 10/04/2013 07:20 PM, Bill Paxton wrote:
>>     > Consider this fairy tale.  We don't need to worry about a CFL
>>     limit for advection here because we aren't actually doing a time
>>     integration of the time derivative that includes the advection
>>     term.  For the near-surface cases where df/dt at constant
>>     relative mass is very tiny, then the time derivative will be
>>     dominated by the spatial term.  That means we are using values
>>     from different locations at the same time to form an
>>     "instantaneous" value of the time derivative to calculate an
>>     instantaneous eps_grav for use in the instantaneous energy
>>     balance equation (dL/dm = ...).  Hurray!   no CFL timestep
>>     worries after-all because we aren't doing any time integration of
>>     the Ds/Dt term; we're just using an instantaneous value of it to
>>     check instantaneous self-consistency for energy conservation.
>>      This is completely different than the time integration of
>>     convection and the CFL limits it must respect.  So I should stop
>>     worrying about advection terms in the eps_grav calculation, right?
>>
>>     I wouldn't say "stop worrying".  We do have to take some care
>>     that the
>>     appropriate assumptions are satisfied.
>>
>>     > Well, maybe I should still worry a little.  When the dt/dt term
>>     isn't tiny, then it is approximated by an average value by a
>>     simple 1st order difference.  If we don't have an advection term,
>>     then we are consistently using average time derivatives since
>>     (f_final - f_init)/(t_final - f_init) is the average rate of
>>     change and is not necessarily the instantaneous rate of change at
>>     the final time.  When we split the Lagrangian into a time part
>>     and a space part, we necessarily introduce a mix of average and
>>     instantaneous.  But maybe that's okay.  Maybe it is even good.
>>      But we should keep it in mind; the Lagrangian time derivatives
>>     in the split scheme will be instantaneous values near the surface
>>     (where df/dt at constant q is tiny and the spatial term
>>     dominates) and will change to average values in places where
>>     df/dt|q begins to dominate.
>>
>>     I haven't worked it out carefully, but I'm concerned that the
>>     either/or
>>     method of choosing the treatment is not the right thing in the
>>     end.  It
>>     seems like there should be a contribution from the advection and one
>>     from the df/dt (at constant q).  This allows the equations to
>>     still be
>>     correct even when df/dt in small enough to have a large advection
>>     term,
>>     but still nonzero.
>>
>>     > There is also still a potential concern about increased
>>     numerical round off errors introduced by the spatial derivatives.
>>       In the Sugimoto&Nomoto form, we use a spatial derivative of
>>     entropy wrt relative mass which will be approximated by (S(k-1) -
>>     S(k))/dq_bar(k) where S(k-1)is the entropy at the center of cell
>>     k-1, S(k) is at the center of k, and dq_bar(k) is the relative
>>     mass difference between the cell centers.  We've seen that dq's
>>     can get very small so the difference between the S's at adjacent
>>     cells will be correspondingly small, so the difference may suffer
>>     from round off.  In Townsley&Bildsten you replace the dS/dq by a
>>     difference between adiabatic and actual temperature gradients,
>>     both measured at the same location and hence not dependent on the
>>     size of the cell or round off from subtraction of nearly equal
>>     values.  Excellent!  But do we need to enforce that this is only
>>     used in radiative regions?  Out near the surface we can get
>>     superadiabatic convection regions -- will they screw up the
>>     Townsley&Bildsten scheme?
>>
>>     I think you probably have a better command of round-off issues than I
>>     do.  I tend to try to use actual derivatives instead of finite
>>     differences that approximate them whenever possible.  I think I have
>>     used the T&B scheme to integrate through convection zones just fine.
>>     Since the gradient is superadiabatic, then nominally the fluid
>>     passing
>>     through the convection region is technically gaining heat on the way
>>     through.  But as long as the eddy turnover time is much less than the
>>     crossing time of the convection zone I think this all makes sense,
>>     though I agree it is a little weird.  Also note that I don't
>>     think the
>>     T&B method assumes a thin shell.
>>
>>     I would have thought that round-off in the entropy would be a problem
>>     deeper in the star, not out in the surface layers.  Even if
>>     things are a
>>     little noisy across the convection zone(s), it seems like it would be
>>     okay in a net sense.
>>
>>     > We'll also need to take care to minimize round off problems in
>>     calculating the time difference part of the Lagrangian time
>>     derivative.  If we are doing differences in values at same
>>     relative mass then we should try to make the cell have the same
>>     relative mass coordinates at the end of the step as at the start.
>>      Similarly if we are doing time difference at constant mass, then
>>     we should try to make the cell have the same mass coordinates at
>>     start and end.  If we can manage that, then we can arrange to
>>     have the newton solver directly give us the difference df for the
>>     cell without needing to do the subtraction df = f_final - f_init.
>>       That works when f is one of the "basic" variables being solved
>>     directly in the newton iterations -- e.g., lnT and lnd (or
>>     lnPgas) are basic variables so we can do this trick, but entropy
>>     is not basic in that way -- it comes from the eos as a function
>>     of lnT and lnd.  But we can get Ds/Dt for eps_grav and still
>>     avoid the roundoff by rewriting the time derivative of entropy in
>>     eps_grav in terms of the time derivatives of lnT and lnd: Ds/Dt =
>>     cp*((1-grada*chiT)*DlnT/Dt - grada*chiRho*Dlnd/Dt).    Note that
>>     we can do this if the cell has either constant mass coordinates
>>     or constant relative mass coordinates.  The mesa adjust_mass
>>     routine arranges it so that cells near the surface have constant
>>     relative mass coordinates and ones in the core have constant mass
>>     coordinates, with a typically small transition region where the
>>     coords are changing in both absolute and relative mass.  
>>      Perhaps we'll be okay if we limit the round off problems to that
>>     transition region.
>>     >
>>     >
>>
>>     As I say, I think you have a much better handle on round-off and
>>     accuracy issues than me.
>>
>>
>>     Dean
>>
>>
>>     ------------------------------------------------------------------------------
>>     October Webinars: Code for Performance
>>     Free Intel webinars can help you accelerate application performance.
>>     Explore tips for MPI, OpenMP, advanced profiling, and more. Get
>>     the most from
>>     the latest Intel processors and coprocessors. See abstracts and
>>     register >
>>     http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>     _______________________________________________
>>     mesa-users mailing list
>>     mesa-users at lists.sourceforge.net
>>     <mailto:mesa-users at lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>> <profiledata.png><timestep.png>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131007/891ddd46/attachment.html>


More information about the Mesa-users mailing list