[mesa-users] accretion

Mon Oct 7 18:35:35 EDT 2013

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>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
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131007/ca60696f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profiledata.png
Type: image/png
Size: 116406 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131007/ca60696f/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timestep.png
Type: image/png
Size: 72474 bytes
Desc: not available
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20131007/ca60696f/attachment-0001.png>