[mesa-users] accretion

[Dean Townsley]

Hi Dave,

This is a good question, and is good to think through, so I'll take a 
stab at my viewpoint.


I think things are straightforward as long as the accretion is "slow" in 
the sense that
   Mdot * dt < dm(1)
where Mdot is the accretion rate, dt is the timestep, and dm(1) is the 
mass in the "outermost" zone.  In this case having the material arrive 
at the same entropy as the surface can happen in the obvious way, you 
just add mass to the outermost zone, and then sometime down the line 
rezone things in a sensible way.  So we get the simple timestep 
constraint dt < dm/Mdot, just for our first-order differences for the 
outermost zones to make sense.

(If you want to think of a pretend physical problem here, I think of it 
as a corona in reverse.  Where material is settling into the surface of 
the star through the photosphere, and outside this the material is free 
to lose energy via Xrays or something that doesn't "count" toward the 
stellar photospheric luminosity.  In practice we tend to use it for 
"bursty" accretion, in which the photosphere is allowed to cool between 
accretion events.  Or use this as a baseline and then add additional 
heating terms on top of it.  For things deep in the star, the surface 
state is not critical.)

The case I would like to do is one in which the accretion rate is 
"large" compared to the meshing of the outer part of the star for the 
timesteps I am taking.  i.e. Mdot*dt is larger than even the top few 
zones taken together.  This makes sense because Mdot is constant, so the 
thermal state of the outermost zones is fairly well-determined and 
varying slowly, although the identity of the material in the outermost 
zones is changing.

The way I understand this has been handled in other codes of the 
Sugimoto and Nomoto heritage is that the coordinate used for gridding 
the star is not a truly Lagrangian one.  (Forgive me if this is 
oversimplified, as I realize that I have not written a stellar evolution 
code myself as both you, Dave, and Bill have! (gulp))  They use q = 
1-m(r)/M.  Then the rate of change in mass, Mdot, appears in various 
terms in the stellar structure equations, rather than as mass added to 
any particular zone, and material is naturally added at the same entropy 
as the photosphere without any particularly special treatment.

This is similar to the way we did things in Townsley & Bildsten '04.  By 
writing everything in pressure coordinates (which are not lagrangian), 
the relevant Mdot-dependent terms appear in the structure equations.  We 
then assume quasi-steady-state and can integrate the equations to get a 
solution by assuming some boundary conditions.


So I think the essential hurdle is that I want to take timesteps that 
are much bigger than dm(1)/Mdot.  I think Bill's older implementation 
did that at the cost of making some not-so-general approximations.  
Nominally the right thing will probably be, as Bill suggests, to 
implement some special mass addition method like the "old one" for the 
problem we are trying to do -- and, for example, the similar mesa test 
suite problem "wd" (basically a classical nova).  This may not be 
necessary for "wd2" (basically a supersoft source) since it goes into 
runaway in the first 100 years, so the timesteps are small for other 
reasons.  Though if one wants to run the SSS for a long time (with the 
test suite problem does not do) one might want to take bigger timesteps.


Hopefully that helps with the general picture a little.  Bill can chime 
in and fix all the things that I have glossed over or misrepresented :)  
(sorry!)

Dean




On 10/02/2013 02:31 PM, David Arnett wrote:
> Historically we have used accretion as a way to change mass slowly, 
> often without worrying about the entropy of the accreted matter or 
> more rapid time dependence. That is actually a complex 
> multidimensional radiation-hydrodynamics problem itself, as Dean knows 
> perhaps too well ;-)
>
> I have a question: are the short time steps due to accuracy 
> constraints or causality constraints? If the former, we have to 
> integrate through them (or change the algorithm). Are they due to 
> instability (physical or numerical)? If the latter, we also can change 
> the algorithm. I am curious about what MESA is trying to do here. Is 
> it clumping?  Is it numerical inconsistency? Something else?
>
> -- 
> David Arnett
> Regents Professor
> Steward Observatory
> University of Arizona
>
> Facts are stubborn, but statistics are more pliable.  Mark Twain
> Facts do not cease to exist because they are ignored.  Aldous Huxley
>
>
> ------------------------------------------------------------------------------
> 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/20131002/8ae62a8f/attachment.html>